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: swm...@swm.pp.se _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
