> -----Original Message----- > From: Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> > Sent: Monday, February 7, 2022 9:00 AM > To: Martin Thomson <mt@xxxxxxxxxxxxxx>; MORTON JR., AL <acmorton@xxxxxxx>; > ops-dir@xxxxxxxx > Cc: last-call@xxxxxxxx; draft-ietf-quic-manageability.all@xxxxxxxx; > quic@xxxxxxxx > Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14 > > On 06/02/2022 22:19, Martin Thomson wrote: > > Hi Al, > > > > On Sun, Feb 6, 2022, at 09:11, Al Morton via Datatracker wrote: > >> What rerodering extent (yes, that's a metric) would be required to cause > >> failure or unnecessary retransmission? > > For my benefit: Is "rerodering" a typo, or a clever joke? [acm] Typo this time, clever joke next time 😊 My original joke idea was that the reordering RFC # should illustrate reordering with single-digit seq numbers. Instead, we were assigned 4737, which has loss (5,6), duplication (7), and reordering (3). Not quite the clear example I was looking for... > > > > As for the question, I believe that QUIC implementations will deal with any > amount of reordering within their timeout period (which varies, but it might > be 10s or 30s in common cases). > > > > There are some narrow cases where packets might be discarded, but that would > be down to specific constraints on the deployment, not the protocol itself. > For example, a server might choose not to take on arbitrary state based on the > first packet, so it might discard any data that arrives out of order. This is > still likely to resolve as the client is required to retransmit. Worst case, > it takes N round trips to resolve, where N is the number of packets in the > flight. If that ends up taking more than the timeout (on either endpoint), > then it will fail. N == 1 in most current cases, so this is more of a > theoretical problem than a practical one. > > > > This scenario was extensively tested. interop.seemann.io has a bunch of > tests of handshake robustness, which sometimes produces a lot of reordering. > You can see there that quant, which has the above behaviour, fails the L1 and > C1 tests in some cases as a result. > > > > That's probably more detail than the doc needs though. > > The transport uses pretty normal standard transport stuff: Reordering > *can* impact loss detection and hence lead to spurious retransmission > (DUPack threshold is at least 3 by default for Reno - used thresholds > depend on the sender implementation). Spurious retransmission can > potentially lead to spurious CC reaction (mitigated/avoided when if > original data is ACked as received). [acm] Thanks Martin and Gorry, there is plenty to work with above if the authors agree to add some more detail. Al -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
