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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
