Sebastian, The latency benefit of eliminating the in-order delivery assumption comes from the fact that L2 links aren't reordering within each microflow. They are reordering on the link as a whole. So, (e.g.) packets from microflows x, y and z can be held up in a resequencing buffer waiting for a packet from microflow w. So, it is a definite latency benefit for flows x, y & z if this can be shut off.
Philosophically, since protocols and applications can vary in their need for in-order delivery, why does it not make sense to rely on the applications/protocols that need in-order delivery to implement their own resequencing? -Greg On 3/14/19, 2:43 AM, "Bloat on behalf of Sebastian Moeller" <[email protected] on behalf of [email protected]> wrote: Hi, > On Mar 14, 2019, at 09:26, Ingemar Johansson S <[email protected]> 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 <[email protected]> > To: Sebastian Moeller <[email protected]> > Cc: Mikael Abrahamsson <[email protected]>, "Holland, Jake" > <[email protected]>, Cake List <[email protected]>, > "[email protected]" <[email protected]>, bloat > <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [Bloat] [Cake] The "Some Congestion Experienced" ECN > codepoint - a new internet draft - > Message-ID: <nycvar.QRO.7.76.6.1903122137430.6242@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 > [email protected] > https://lists.bufferbloat.net/listinfo/bloat _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
