jiebi/CodeConvo huggingface dataset:
I don't fully understand when would someone want to set ignore-order = true, i.e., what is a valid use case for this? Lets say for whatever reason the sender sets this to True, this would if there is actual packet loss and receiver receives OOO packets, it won't send an immediate ACK. Meaning the sender won't enter loss recovery immediately and will continue sending packets at the same rate. This is not good, as it directly increases queuing on the network node and for a tail drop queue (most widespread deployment), it will also affect other flows. Meaning, other flows will experience packet loss due to non-responsiveness of this flow for certain period of time. I probably missed past conversations about ignore-order field, so my apologies if this has already been discussed. I read the draft and didn't see any explanation about where would this be useful and what are the fallbacks of setting this to true.
One use case that I know and care is for sending QUIC traffic from a server cluster. Some packets would be sent directly from a server node that governs the connections, but others would be sent via different nodes within the same cluster. Once we deploy a sender like this, the receiver would observe what looks like reordering (because most packets will be essentially delivered through an additional hop, and that would cause delays). But we do not want the receiver to send ACK for each packet being received. Regarding the problem, I'm not sure I agree with the impact. Typically, congestion controllers react to congestion after 1 RTT. When packet-number-based detection is turned off, that changes to 9/8 RTT. That does cause more pressure on the bottleneck queue, but it is no worse than that caused by a path with an 9/8 greater RTT. Assuming that congestion controllers are designed to be fair against flows having different RTTs, I tend to believe that this is a non-issue.
I agree with NAME though I think adding a SHOULD NOT use a delay longer than an RTT(URL) would be a good addition, since if the delay is extremely large(ie multiple RTTs), that could be bad.
In general, the spirit of this draft is to provide control over acking behavior to the sender, since it is the consumer of this information and ought to be able to control how frequently it needs to see this information.
If there are subtle consequences to these decisions, it is worth noting them in the draft. It seems useful to add some text on the consequences of using Ignore Order, so that senders can make informed decisions. We can do that.
NAME is this something that Fastly does or is planning to do? How would you share the connection secrets between different server nodes? When we set ignore-reorder = true, and lets assume that max ACK delay > 1RTT, it can be 1RTT or 2 or 10RTT. this would result in loss recovery to be delayed by at least an additional RTT, i.e. it will take >16/8RTT (>2RTT) instead of 9/8RTT to declare packets lost. That is significant IMO. >Assuming that congestion controllers are designed to be fair against flows having different RTTs, I tend to believe that this is a non-issue. CUBIC throughput is inversely proportional to RTT in New Reno mode. Nonetheless, I am more concerned about high queuing in bottleneck due to late loss recovery. Specifying the use-cases where ignore-order = true SHOULD be used will prevent new implementors from using it randomly. And as Jana said, some text around the consequences when it is used would allow informed decision making.
NAME I do not speak for Fastly's plan, but the OSS branch of H2O has a working prototype that does this: URL The calculation is correct. At the same time, I do not think that senders will be willing to use Max Ack Delay as large as that, when setting the Ignore Order bit. The problem here is the impact on loss recovery. If Max Ack Delay is set to a value as large as 1 RTT, then the sender needs to spend more than 2 RTTs for detecting a loss. That means that the size of the send and receive buffers have to be twice as large, and that it would take as twice as long to recover from a loss. Based on existing advice that we have in other RFCs, I think we should discourage Max Ack Delay that is greater than 9/8 RTT when Ignore Order bit is used (please see my comment on ).
I'd suggest 5/4, but otherwise agree with you NAME
Should the Max ACK Delay be restricted to 1/8 or 1/4 RTT as there is inherent 1RTT time spent while sending data and receiving ACKs? That would make a total of 1 + 1/8 or 1 +1/4 RTT total/
I think this is best as a sender-side SHOULD, since it knows what time threshold it's using. For example, we use 1/4 RTT, but have considered making it adaptive(ie: 1/16 RTT to 1 RTT) based on observed reordering. Also, if your RTT is 100us, and your timers have coarser granularity, 1/8 RTT or 1/4 RTT just doesn't make sense. I'm not sure what does, because I'm not an expert in datacenter networking, but that's why I think this is a SHOULD, not a MUST. Of course, it's also unenforceable, which is a good reason for a SHOULD.
+1 to SHOULD. The only argument I might disagree with NAME is that it is unenforceable (IMO a receiver can enforce by capping Ack Delay to a fraction of the RTT that the receiver has observed). But I do not think there's any reason to require the receiver to enforce, considering the fact that a sender can send as many packets as it likes, regardless of ACKs the receiver sends (or lack of).
I am fine with SHOULD and with a mention of how a sender would compute Max ACK Delay when he sets ignore-order = true. An example is fine too.
I believe this is the same issue as
There are two things that are impacted by setting a high value for ack delay: congestion control and time-threshold loss detection. On congestion control, we need some protection for the network, so we should recommend something. On loss detection, a sender that chooses and sets an ack delay higher than the time-threshold loss detection time period risks triggering unnecessary retransmissions.
So, I propose adding the following for a sender: SHOULD set the ack frequency to be at least one ack per RTT (so that congestion control responses are reasonably quick) a word of caution that setting the ack delay to be longer than time threshold can cause the sender to unnecessary retransmit
In 9.3. Window-based Congestion Controllers I thought that unless there is loss reported, a QUIC ACK Frame releases sending window. In a similar manner as the accurate byte counting style in TCP, a QUIC sender solely operates on the basis of bytes acked, not the number of ACK frames received. So while a delayed ACK could delay a round of growth when the ACK Ratio is larger, it is only delayed by the time to ACK the set of received packets. In looking at various QUIC CC over medium and longer path RTTs this effect was quite small, and the default ACK delay was not unreasonable; for shorter path RTTs this might be different
See PR
To me, ACK Clocking is a separate point that applies to any type of CC when the cwnd limits the sender. I agree there could be a concern is around whether a less frequent ACK policy can induce a cwnd-limited sender to send bursts of packets that could induce loss or disrupt sharing of the path with other flows. The QUIC specification already permits an initial window of 10 packets, and motivates the need for pacing. I think it is important this text refers to the QUIC transport section on pacing to mitigate bursts.
Better worded perhaps in PR .
Section 9.1 - There are CC considerations with respect to how long it is reasonable for a flow to hold-off detecting congestion and responding. This needs to be discussed. When an endpoint detects persistent congestion, it MUST promptly reduce the rate of transmission when it receive or detects an indication of congestion (e.g., loss or ECN marking) [RFC2914], the Ignore Order value of true (0x01) in this ID allows a sender to extend that period, postponing detection of loss. That might be reasonable, but excessive delay can be dangerous - and therefore the impact really needs to be discussed: delaying a fraction of a RTT is in my mind safe, intentionally delaying by an RTT is arguable.
A delay of many RTTs is endangers other flows, and we need to at least say that in some way ([RFC8084] took an alternate view of how long might be safe).
See PR
I think this warrants a note about how a sender SHOULD NOT use a delay that is larger than an RTT unless the sender has other information about either the network or current network conditions. Otherwise, the receiver does not need to enforce anything here.
NAME Delay of loss detection has negative impact on loss recovery as well. Considering that the time threshold defined in RFC 9002 is 9/8 RTT, I might ague that, when Ignore Order is set to true, then the maximum delay being advertised SHOULD be no greater than 9/8 RTT. These values provide responsiveness comparable to Rack when a packet is lost - the loss would be detected within 5/4 RTT. (stuck out, as this point is already covered by Section 8).
In a successful issuance exchange, the attester provides the issuer with information about the client. The text in Section 3.2.1 points out that the way in which information about the client is combined could reduce anonymity set size in ways that affect privacy. Given that we have a chain of custody, I imagine that the privacy property here is about what the issuer learns about a client. More information means more information that might then propagate from the issue onward to the origin. This means that the attester needs to limit what it passes along to only that which is relevant. The client needs to trust the attester to do this. ... or does it? The text in Section 3.2.1 implies strongly that this anonymity set size is important, but the constraints on the client-issuer interaction, especially consistency rules, very much limits what the issuer can pass along to the origin. So maybe the system depends less on trusting the attester and more on the combination of the cryptographic properties of the token and the consistency system that mitigates against misuse. None of this appears in the privacy considerations. Should it?
On this point: "Clients do not explicitly trust Issuers." (Section 3.2.2) This would invalidate much of the discussion of anonymity sets in attestations. This is quite confusing. The client doesn't need to trust the issuer, because the issuer is unable to pass information on to others. However, the client cannot trust the issuer with information, so it has to trust the attester not to pass stuff along AND it has to use an anonymizing proxy to interact with the issuer so that nothing leaks. This is quite contradictory overall.
There are issuance protocols wherein the issuer learns information about the origin by design, like the . In this variant, if the attester were to pass information about the client on to the issuer, then the issuer would be able to reconstruct the (client, origin) pair, breaking the unlinkability goals. I agree that in the case where the issuer learns nothing about the origin in the protocol then reliance on the attester is lessened, but we need to make sure we accommodate future issuance protocols here. I'll think about ways in which we can try to make this more clear. This might go into the privacy considerations, as suggested.
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM
The point of is a little odd, because it seems to imply that ALL operations require access to the information that is integrity- or confidentiality-protected. That's clearly not the case, I think, as it is merely pointing out that if you want to modify data, then you have to be an endpoint. I think that this might be better phrased as: Note: This drops the last sentence of the original paragraph. If proxying is out of scope, then it doesn't help to talk about it so much. The point about cooperation should do.
Created a PR based on your proposed text but added some of the information about proxies to make it more clear what kind of proxies we are talking about.
Closes: URL See-Also: URL
From Benjamin Kaduk's comments: Is it? Paging NAME NAME and NAME as I honestly don't know. Trouble is: The way CTs come across in the examples, the CT goes in, does its job and leaves. But the RD's lifetimes are finite, and "Registrations in the RD are soft state and need to be periodically refreshed". So what happens when the time runs out?
A CT can indeed come in later to assist in a reconfiguration of the network/applications, e.g. adding a device, removing, or changing members of a group, or changing parameters of devices. When the CT performed a registration on behalf of an IoT device the expectation is that a very long lifetime will be picked, such that the CT doesn't have to come back to refresh. This looks problematic in case the RD state is easily lost - e.g. suppose it reboots and loses all such entries? Then there may be no CT around to send the entries to the RD again. (I would assume in this scenario that the CT's registration are more "permanent" so they would survive a reboot for example. Can be restored back from a database. In another project I work in the CT can perform such persistent registrations that survive reboots, using a special 'max' value of lifetime that signals persistent registration.)
Thanks, with that I can at least phrase an answer to the immediate question. Would it, in the deployments you describe, be conceivable that the CT is recalled on site on extraordinary events, like when the RD host is migrated to a different system or address? On the reboots, I hope that we are OK with the current situation that an RD would persist its state when it can, and administrators would not use the more volatile variety when they intend to configure long lifetimes. (If we aren't, we'd need to start thinking about negotiation of lifetimes, and that'd bring a new aspect of complexity I hope to avoid).
chrysn wrote: Hi. I thought I had commented on this somewhere already. A BRSKI-based "CT" would have a registrar which does not really leave. If we are talking about how I think that brski-async-enroll will work, then the CT will enter the no-internet-zone, do some connections, and then leave.
(Think new home construction in a new suburb) The RD lifetimes could be finite, but a few years in duration. The home owner, upon getting the keys (physically and cryptographically), would of course, rekey the entire house, and now there would be a management system to update RD lifetimes. Thread has a CT. I have no idea how it works, but perhaps NAME could comment. Zigbee CHIP project is doing something, but it's all NDA for now. I think that, when the time runs out, if there is nothing else to manage the system, then it should fail. I think that's okay. I think that the timeouts won't be minutes, but months... yes, there are issues. I don't think that the RD document needs to cover them though. {Feel free to invite me to collaborate on a script for the sequel to Sneakers/Leverage/MissionImpossible/EnemyOfTheState. I suggest it star Tom Greene rather than WillSmith or TomCruise.}
I think that there is probably a followup document that provides a way to backup/restore RD host data. OPC UA told me that they have created a spec for device independent backup/restore of configuration data in the case of device failure, but I don't have the details yet.
This might fit into -- any exchange format between the RDs could also be re-used for persistence. (With the caveat that the receiving server would need to inhabit the same address as the original server, or otherwise it could not service registration updates.)
Well, could it be an anycast address so that the RD could be highly available?
I don't see this as a viable design for a deployment. A change of system/address/network in the backend should never require the CT to come in and redo commissioning operations on IoT devices. Feeding the 'new RD' with stored information from a database is what would be most useful here. This database could be all those entries of devices that the CT had scanned initially, not necessarily the full RD state. Or alternatively all RD entries with lifetime e.g. > 48 hours could be restored; other devices need to re-register. Those entries that were registered with the CT could have a 10-year lifetime for example.
HI all, There are many installation firms, all with their own procedures and tools.
It is possible that an installation company deploys a CT during installation and takes it home afterwards. The contract might stipulate that he leaves behind a program to restart, update or refresh the network. It might be that an another company does the maintenance with another set of tools. Concerning duration, we may talk about years of operation without interruption. On other sites weekly upgrades may be necessary. At the end of the day, There are no general rules that may fix the CT behavior. I am afraid this does not help a lot and emphasizes that the CT example is just a likely example. Cheerio, Peter Esko Dijk schreef op 2020-10-21 09:02: Links: [1] URL [2] URL Thanks for addressing my DISCUSS and COMMENT feedback
Issue
NAME NAME pl review re issue
Looks good
the examples of errors use a pattern of using a link in a header, and then (supposedly) using a human-readable error message. what about using RFC 7807 instead and using examples that use problem reports to indicate failure semantics in addition to the status code?
I agree. coming up in the next draft.
NAME should we close this issue if it is resolved?
NAME closing this issue. Let me know if not addressed with my latest PR.
And while we're at it, update an obsolete reference to Oblivious HTTP, which has long since been adopted by its WG. VDAF-05 isn't expected until Monday 3/13, but we can get this change ready to go.
DAP-04 will need some routine changes: [x] Update version tags for HPKE to () [x] Bump VDAF-03 to 05 () [x] Update change log () [x] Run spell check ()
Public key pinning isn't implemented in most HTTPS libraries outside of browsers, so this is a considerable burden on implementers. Public key pinning carries a fairly high risk of footgunning. The consequence of a failed pin for a CA that serves many ACME clients would be that some of those clients would fail to renew their certs, causing cascading breakage. There is relatively little confidential information conveyed in ACME, and there are other defenses built into ACME (like including the account key as part of the challenge data), so HPKP is not strongly necessary.
The intent was that the server always sends the retry keys (it cannot distinguish stale keys from GREASE when the client is actually trying to connect to the public name), while the client just ignores them, but I did a poor job of describing this, so add a key sentence. This addresses .
(EDITED.) To recap the discussion on , your point is that the client-facing server needn't attempt to distinguish GREASE from non-GREASE based on outer SNI, because if the outer SNI != public name, then the client knows to ignore the retry config and continue as usual. I think this is weird because if rejection was the intent, then the client is supposed to abort with "ech_required". So the server only knows that non-GREASE was intended once it receives this signal.
I mean, yeah, that's how this was designed and is what we merged to the spec. :-) This formulation, in particular, does not break if the client tries to connect to the public name (it's a perfectly valid URL) without knowing the ECH config (maybe it the HTTPS record didn't get through Do53) but still sends GREASE (because the intent is that every client can GREASE). It seems to me breaks this. Do you have an alternate formulation which keeps this working? Connecting to the public name is especially important if the public name is a non-throwaway domain. The only requirement on the public name is that it's some name which knows about and serves the client-facing server's config. (I.e. this particular backend server is the same entity as the client-facing server.) doesn't relax this requirement, since the public name continues to be the entity trusted to replace, and possibly disable, ECH on config mismatch.
I don't see this as an issue. If the client sends GREASE, it doesn't expect to use ECH, so it won't abort. The text here only requires that the client check the extension if present, and ignore it if absent.
I don't have an alternative formulation. I was evnisioning the public name only being verified on the ECH rejection path, or when neither real nor dummy ECH was offered to the client-facing server. I'm fine with rejection not being known until "ech_required". I support this PR as the resolution to .
NAME and I were sitting down and thinking and we realized the following scenario can happen: URL is on URL, which supports ECH URL has an HTTPS record, an A record, AAAA record pointing at the IP for URL A user of a browsers latest release that supports ECH and greases the extension is using a resolver that doesn't resolve HTTPS records This results in an ECH request being made with URL, and a rejection of the ECH. So now the question is what the client should do and what should servers expect? Try again, with the outer SNI the one matching the one in the new config Use the connection authoritatively for URL since the connection has already revealed the issue.
The intention was the latter, but the text could probably be clearer. I don't think there's much point in trying again since the name has already been revealed. See URL
NAME is this still an issue now that is merged?
I think the client behavior remains equally unspecified. In particular the lengthy argument NAME and I had about server enforcement of the client behavior I think isn't changed.
Care to file a PR, presuming the latter behavior is intended?
A proposed resolution is here: .
NAME a proposed fix has been merged. See .
I think this text works.
In the HTTP/3 draft 30, section 4.4 on Server Push says and then adds in 10.4 (URL) I don't think normative requirements belong in security considerations except in reference to that requirement elsewhere. Also, requirements in general should clearly state who is responsible for implementing them, whereas the latter requirement implies a client (maybe). And sending CANCEL_PUSH is kind of like the MUST NOT, but not really the same thing; it seems a bit weak in response given that the server just tried to poison the client. I think the server MUST is an interop requirement because the client MUST NOT is a critical security requirement. I think both should be described in Server Push and merely noted in the Security Considerations, since they are really important. Way more important than the spec reads now. My guess is that this is editorial, but is the kind of thing that should be fixed before IESG last call.
The reason it's only a SHOULD CANCEL_PUSH is that the server can't know with certainty for which origins the client considers it authoritative. The server only knows for which origins it believes that it's authoritative. So having received a push the client considers out-of-bounds, the client can't know for sure whether it's a poisoning attempt or simply a difference in view. Yes, I think this is editorial, since the core request is to relocate existing text without changing the normative requirements.