Re: [Bloat] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?)

[Jonathan Morton <chromatix99@gmail.com>]

>> I have to ask, why would the network care?  What optimisations can be obtained by reordering packets *within* a flow, when it's usually just as easy to deliver them in order?
> 
> Because most implementations aren't flow aware at all and might have 4 queues, saying "oh, this single queue is for transports that don't care about ordering" means everything in that queue can just be sent as soon as it can, ignoring HOL caused by ARQ.

Ah, so you're thinking in terms of link-layers which perform local retransmission, like wifi.  So the optimisation is to not delay packets "behind" a corrupted packet while the latter is retransmitted.

It's possible for a TCP to interpret a reordered packet as missing, triggering an end-to-end retransmission which is then discovered to be unnecessary.  At the application level, TCP also performs the same HoL blocking in response to missing data.  So it's easy to see why links try to preserve ordering, even to this extent, but I suspect they typically do so on a per-station basis rather than per-flow.

Personally I think the problem of reordering packets is overblown, and that TCPs can cope with occasional missing or reordered packets without serious consequences to performance.  So if you add "reordering tolerant" to the list of stuff that Diffserv can indicate, you might just end up with all traffic being marked that way.  Is that really worthwhile?

>> Of course, we already have FQ which reorders packets in *different* flows.  The benefits are obvious in that case.
> 
> FQ is a fringe in real life (speaking as a packet moving monkey). It's just on this mailing list that it's the norm.

Oddly enough, wifi is now one of the places where FQ is potentially easiest to find, with Toke's work reaching the Linux kernel and so many wifi routers being Linux based.

An acknowledged problem is overly persistent retries by the ARQ mechanism, such that the time horizon for the link-layer retransmission often exceeds that of the end-to-end RTO, both for TCP and request-response protocols like DNS. I say, retransmit at the link layer once or twice, then give up and let the end-hosts sort it out.

 - Jonathan Morton