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

[Sebastian Moeller]

Hi,


> On Mar 14, 2019, at 09:26, Ingemar Johansson S <ingemar.s.johansson at ericsson.com> wrote:
> 
> Hi
> 
> In addition to the below, in NR (=New Radio, a part of 5G) the RLC layer will 
> no longer ensure
> in sequence delivery to higher layers. Packet reordering can occur on the MAC 
> layer as several HARQ (Hybrid ARQ) run simultaneously to transmit packets, 
> some processes need to retransmit and there you get packet reordering.

	Unfortunate...

> The PDCP layer can however (optionally) enforce in sequence delivery, 
> personally I am sceptic about the benefits of this as it adds extra HoL 
> blocking to solve a problem that RACK can solve.

	In the context of the L4S (over-) promises it can not IMHO, unless the lossy link is slower than the internet access link. My rationale is that direct retransmits of packets that did not pass the current "physical" connection and sorting at the remote end of the link before passing the packets on, is only going to introduce more (sorting-)delay then sending out of order and expect the receiver to put things in sequence again, IFF the retransmit process takes the order of time as the transfer of the un-ordered packets over the bottleneck access link. As far as I understand L$S is all about reducing application visible latency, and RACK, in my layman's understanding, is also not going to help much here as it basically introduces another timeout (aka potential delay). I am not trying to pass a judgment on RACK here (and as far as I understand it solves a different problem, by making TCP more tolerant against mild reordering it will increase bandwidth utilization and reduce delays from having to slow down, but it will do nothing for the perceived latency from re-odered packets), all I want to understand how this is going to work in the context of "ultra-low latency" (a term from the L4S RFCs that I believe to be a tad too much)?


> In addition it costs more 
> memory in nodes that potentially need to transmit 10s of GByte of data.

	Sure, but such is life, this reminds me a bit on debates about cache coherency and un-aligned memory accesses, the hardware people seem to argue life would be simpler/faster if these could be traded-in, but that simply pushes cost and complexity on the software side ;)

Best Regards
        Sebastian

P.S.: What is the best place to discuss L4S? Certainly not this mailing list, or?



> 
> /Ingemar
> ======
> 
> Date: Tue, 12 Mar 2019 21:39:42 -0700 (PDT)
> From: David Lang <david at lang.hm>
> To: Sebastian Moeller <moeller0 at gmx.de>
> Cc: Mikael Abrahamsson <swmike at swm.pp.se>,  "Holland, Jake"
> 	<jholland at akamai.com>,  Cake List <cake at lists.bufferbloat.net>,
> 	"codel at lists.bufferbloat.net" <codel at lists.bufferbloat.net>,  bloat
> 	<bloat at lists.bufferbloat.net>,  "ecn-sane at lists.bufferbloat.net"
> 	<ecn-sane at lists.bufferbloat.net>
> Subject: Re: [Bloat] [Cake] The "Some Congestion Experienced" ECN
> 	codepoint - a new internet draft -
> Message-ID: <nycvar.QRO.7.76.6.1903122137430.6242 at qynat-yncgbc>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> 
> On Mon, 11 Mar 2019, Sebastian Moeller wrote:
> 
>> How is packet reordering for anybody but the folks responsible for
>> operating the "conduits" in any way attractive?
> 
> It's more that not worrying about maintaining the order, and just moving the
> packets as fast as possible reduces the overhead.
> 
> The majority of the time, packets will be in order, but race conditions and
> corner cases are allowed to forward packets out of order rather than having
> the delay some packets to maintain the order.
> 
> David Lang
> 
> 
> 
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat