RE: Opsdir last call review of draft-ietf-quic-manageability-14

["MORTON JR., AL" <[e-mail]>]

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