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

[Gorry Fairhurst <[e-mail]>]

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?
>
> 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).

Gorry