> -----Original Message----- > From: Gorry Fairhurst <[email protected]> > Sent: Monday, February 7, 2022 9:00 AM > To: Martin Thomson <[email protected]>; MORTON JR., AL <[email protected]>; > [email protected] > Cc: [email protected]; [email protected]; > [email protected] > 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
