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

[Carsten Bormann <cabo@tzi.org>]

On Mar 14, 2019, at 22:43, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> if a specific link technology is prone to introduce reordering due to retransmit it might as well try to clean up after itself

The end-to-end argument applies:  Ultimately, there needs to be resequencing at the end anyway, so any reordering in the network would be a performance optimization.  It turns out that keeping packets lying around in some buffer somewhere in the network just to do resequencing before they exit an L2 domain (or a tunnel) is a pessimization, not an optimization.

For three decades now, we have acted as if there is no cost for in-order delivery from L2 — not because that is true, but because deployed transport protocol implementations were built and tested with simple links that don’t reorder.  Techniques for ECMP (equal-cost multi-path) have been developed that appease that illusion, but they actually also are pessimizations at least in some cases.

The question at hand is whether we can make the move back to end-to-end resequencing techniques that work well, at least within some limits that we still have to find.  That probably requires some evolution at the end-to-end transport implementation layer.  We are in a better position to make that happen than we have been for a long time.

Grüße, Carsten