Thanks for your feedback. So far, support for reporting out of order packets has been strong and it's not that costly in terms of bytes. As you said, it's particularly valuable for understanding network behavior. https://github.com/wcsmith/draft-quic-receive-ts/issues/2
On Wed, Mar 19, 2025 at 3:18 PM Chris Box <[email protected]> wrote: > Hi. > > In another thread, Greg flagged the draft on robustness to packet > reordering: > > On Wed, 12 Mar 2025 at 02:46, Greg White <g.white= > [email protected]> wrote: > >> The current WIP can be found at: >> https://gwhitecl.github.io/draft-white-intarea-reordering/draft-white-intarea-reordering.html >> > > I think this is a great start on describing a widespread performance issue > with common layer 2 networks. > > In today's meeting we saw large support (32 for, 0 against) for working on > ACK receive timestamps. Clearly such timestamps would be a useful tool for > senders to be able to handle such networks better, if sent at high > frequency. But the timestamp capability really ought to support reordering. > > Why? My overall takeaway from the reordering draft is that many links have > tended to go to great lengths to shuffle packets back into the original > sequence before delivering them to the endpoint. This protects the > throughput of old TCP stacks, but at the cost of tens to hundreds of > milliseconds of jitter. If we're able to successfully move the dial towards > less resequencing, it implies draft-smith-quic-receive-ts > <https://datatracker.ietf.org/doc/draft-smith-quic-receive-ts/> should > support out of order packets well. > > Chris >
