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
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
