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

[Mikael Abrahamsson <swmike@swm.pp.se>]

On Fri, 30 Nov 2018, Jonathan Morton wrote:

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

Yes.

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

It's a "truth-everybody-knows" in networking that "NEVER RE-ORDER PACKETS 
WITHIN 5-TUPLE FLOW!!!!! THERE BE DRAGONS THERE!". I'd also say I see 
enough transport people who says that this should be true generally, if 
nothing else because of legacy.

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

Question isn't so much about TCP, it's the other things I am worried 
about. TCP handles re-ordering kind of gracefully, other protocols might 
not.

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

Again, even if they're using Linux they will/might have packet 
accelerators that just grab the flow and the kernel never sees it again. 
No FQ_CODEL for that.

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

I agree, but I also think that it would help some link-layers if the 
re-ordering requirement could be relaxed. However, before that can be 
communicated a lot of study needs to be done to check if this is actually 
true. I've had incidents in my 20 year networking career where it's not 
and applications misbehaved when they were re-ordered.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se