From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3343F3B2A4 for ; Thu, 14 Mar 2019 17:43:51 -0400 (EDT) Received: from hms-beagle2.lan ([77.189.129.198]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lh7PL-1gjI9N2ZoV-00oUyy; Thu, 14 Mar 2019 22:43:46 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 14 Mar 2019 22:43:45 +0100 Cc: Ingemar Johansson S , "bloat@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Greg White X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:vMXwSVCRjT17JfcLOwZQDvHh35Yf9eijSZ/b+jIMp+n0cdqbiQK 8iR0UYa7cYrTJQbBusDu9wWpbYl845C3HPb6uXW48by2s3o9DH+bbXeorRyDkhev6ODPHJH jvm1JolLOJV3nZyk1JMIjoxxdAH26Jq+Sxia5iDw6AQQHPSaMMNmlSP7OqAooOz9eVzuOJo 4fCLbCfSJLoWPtPu3dOPg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:zkfANSQIJyI=:TLyzl7iH2tlWg32KGwArh7 C0xklAxzFNnEDXVak6L7V+k9hb+dqlicVwrvQlN2rKvSXucZ3v+DIFmcSCo2ga7i78ATGdEJr Us5oghCSRr8om57a72omYLgF/nDkifYCSvXfi4WE7v3AMbaweTx72WJ7Fu/ixdylAwJokCbwN 908l6rVT7z4f/2zAkRRMwDNOZHaF/JhsEu+RF/VHzCAyI+JttiRkKYcxFpQ5ysNVK9Fa2lKwq 5ssKmYoGK+I9SN032jeeT1Oi8tb6eukioilWLRrD0j9JcXh5ik+Yi9F1IzwMOgeNqugL1KshL c1FF039XYZV1II3yVsLpCgoAkjhlpD/mfWXbSR9C7AFuN8nFnbQUBMF7cS9liG0T9Kma2Ykwa f8NFx0Lh4uzREx3VD6/6RX7nfiDvcW9wE7cN3An9c7gEg8n1QTrhoprnxQgQl04Dz79yaJ3lD 0bOkrLnAtbP3xxLfps+QDxtxyzMRtb1fCvZP8omNKZsa/6wEkfCudMYL1p+E8mtQUovvZYS++ AN35f999T7juLtdPrCzIT5T2zMdv8i9uPV2msg76U8KF4BbyAUenu/8K8e7ph5TTK1V7t3upM RSL8wkdAvU7OaxVEpXSaWkhbXklBX0G5EKe6ZSAxeaMhx0aF8pTbywWk7eiJhY2gpS9a1cSoj SWfw6yAYfON73FNVaN89gnjGcKD4yxyYLv9WbQYbmpMX1m/XEjcTeN+orae+n/mf3bgegrOOT mM+6ri1RIPnm/JeAI98itUQmcP77wfDVntJDtzlX7mkL51Gv3kChs6i8ISJP/hhd7woL39inY fAaZ+pQ3VbwJPwRGVufarnaVq9PleT6ooYNF+BKeJlbwWEvg+1pi0x/W6wEOx/yEn6ERGZL3j hLDeC3EHBT7k3RI9xFa3bTSn7qccHqmCBEbet23FSJZZEitAEsSSf5D3t299l7f42KYW4yv0T 1Dm/sA400sQ== Subject: Re: [Bloat] Packet reordering and RACK (was The "Some Congestion Experienced" ECN codepoint) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 21:43:51 -0000 Hi Greg, > On Mar 14, 2019, at 20:23, Greg White wrote: >=20 > Sebastian, >=20 > 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. =20 I see, that I can understand; it is also sad, that nobody = thought about doing the reordering per flow, which would reduce one of = the cited costs for doing re-sorting, namely increased memory = requirement for worst-case queueing, no? >=20 > 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?=20 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... 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? Anyway, thanks for helping me understand the issues here, as always = reality trumps theoretical musings... >=20 > -Greg >=20 >=20 > =EF=BB=BFOn 3/14/19, 2:43 AM, "Bloat on behalf of Sebastian Moeller" = = wrote: >=20 > Hi, >=20 >=20 >> On Mar 14, 2019, at 09:26, Ingemar Johansson S = wrote: >>=20 >> Hi >>=20 >> In addition to the below, in NR (=3DNew Radio, a part of 5G) the RLC = layer will=20 >> no longer ensure >> in sequence delivery to higher layers. Packet reordering can occur on = the MAC=20 >> layer as several HARQ (Hybrid ARQ) run simultaneously to transmit = packets,=20 >> some processes need to retransmit and there you get packet = reordering. >=20 > Unfortunate... >=20 >> The PDCP layer can however (optionally) enforce in sequence delivery,=20= >> personally I am sceptic about the benefits of this as it adds extra = HoL=20 >> blocking to solve a problem that RACK can solve. >=20 > 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)? >=20 >=20 >> In addition it costs more=20 >> memory in nodes that potentially need to transmit 10s of GByte of = data. >=20 > 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 ;) >=20 > Best Regards > Sebastian >=20 > P.S.: What is the best place to discuss L4S? Certainly not this = mailing list, or? >=20 >=20 >=20 >>=20 >> /Ingemar >> =3D=3D=3D=3D=3D=3D >>=20 >> Date: Tue, 12 Mar 2019 21:39:42 -0700 (PDT) >> From: David Lang >> To: Sebastian Moeller >> Cc: Mikael Abrahamsson , "Holland, Jake" >> , Cake List , >> "codel@lists.bufferbloat.net" , = bloat >> , "ecn-sane@lists.bufferbloat.net" >> >> Subject: Re: [Bloat] [Cake] The "Some Congestion Experienced" ECN >> codepoint - a new internet draft - >> Message-ID: >> Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed >>=20 >> On Mon, 11 Mar 2019, Sebastian Moeller wrote: >>=20 >>> How is packet reordering for anybody but the folks responsible for >>> operating the "conduits" in any way attractive? >>=20 >> It's more that not worrying about maintaining the order, and just = moving the >> packets as fast as possible reduces the overhead. >>=20 >> 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. >>=20 >> David Lang >>=20 >>=20 >>=20 >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >=20 >=20