Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs

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

On Wed, 7 Aug 2019, Jeremy Harris wrote:

> I can't quite tell if you're noting that transports need to be aware of,
> and handle (in one way or another) packets re-ordered by lower layers
> [ I thought this was a given, already ]

My statement here is that most if not all media is designed around 
delivering 5 tuple traffic in-order, and any out of order delivery is 
considered an anomily, and to be avoided.

Juniper had a bug in one of their routers back in 2000 which would 
re-order 5-tuple flows occasionally. They were ridiculed by ISP peeps for 
years about this and it was kind of a scandal. We in the ISP business 
generally try really-really-really hard to deliver at least 5 tuple 
traffic in order. Most media try really really really hard to deliver the 
entire queue in order. For instance a mobile network typically will have a 
buffer that can hold many hundreds of packets, and it'll never re-order. 
It'll sit on a single packet being re-transmitted over and over again and 
hold the queue and nothing will be delivered until the entire queue 
ordering "promise" is met. So this is not 5-tuple, this is entire queue.

All media I know of that has ARQ, for instance wifi, DOCSIS, *DSL, 3GPP 
networks, they all deliver the entire queue in-order. They'll hold up the 
entire queue if there is a single packet that needs several re-transmits 
to be delivered.

So it's not uncommon to see packets being delivered in a very bursty 
fashion because there might have been 200 packets being held up for that 
single packet to be re-transmitted a few times, and it might not even have 
been in the same 5-tuple flow as any of those 200 packets.

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