Re: [Bloat] Packet reordering and RACK (was The "Some Congestion Experienced" ECN codepoint)

[David Lang <david@lang.hm>]

On Thu, 14 Mar 2019, Sebastian Moeller wrote:

> 	As I tried to convey, if the local ARQ is considerably faster than the 
> bottleneck link for each flow, local re-ordering comes at a considerably lower 
> intra-flow latency cost than re-ordering past the bottleneck link. And one 
> could argue, if a specific link technology is prone to introduce reordering 
> due to retransmit it might as well try to clean up after itself...

As soon as you introduce parallelism (either multiple cores working on the 
traffic or multiple paths, including different frequencies in the medium) then 
strict ordering starts becomingexpensive

> To my knowledge most traffic is currently TCP, and TCP has strict ordering 
> requirements, and even if clever techniques like RACK can make it more robust 
> against reordering, the applications will see the full latency hit incurred by 
> re-sorting re-ordered packets in the receivers TCP stack, no?

not necessarily.

which is going to take longer, having packets sit in a buffer somewhere in the 
network until they get re-ordered, or having them sit in the buffer on the 
target machine until they get re-ordered?

if there is no resouce contention, they should be equal.

In practice, since the network devices are more likely to run into resource 
contention (think locking overhead between cores if nothing else), it can easily 
be faster to sort them at the destination.

David Lang