From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 15CB03B29E for ; Thu, 14 Mar 2019 04:43:47 -0400 (EDT) Received: from [172.16.12.10] ([134.76.241.253]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MXUmw-1hZmjM2um6-00WRvI; Thu, 14 Mar 2019 09:43:46 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 14 Mar 2019 09:43:45 +0100 Cc: "bloat@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ingemar Johansson S X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:v0mtdkJ/UnNgrx35JLjNqP1z3cPfd/ETMnk2RRr3cmdCVrxN1Ic 03Ebtmwn42vTDsUUSbCdPI00V9UACi0D/yimtCtGiG7r1esOqHG92jh5ypvvuXib8S7k/Cl 41+LZhJracx1EzmZbPG1IzVQGkccKIi71aAWxo0onhxBXY009HrDRu4Jj2OMHAIsXNQ3Sl2 Dgo4NQNxNyPHlku/VslVg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:R2yEwUkStCg=:tWA2lriCjuOdN1gCyb22e9 C22rzkhgT59XcAYIehDHIDwiGpHzJQon51XWUOl/VhlOCIH6RcKc280GWvinkHKYlfBGaymJ6 DxfkuixNUE9lB74vfyGiXuiY3RlmMU3pt5IhPGroDVIk+9sIALogFJGBIRy28PayKlS+ZcpkH x9IHEKPof7l8/6CL1f47xql+ZFxI0qFFvrvpGMYRGRfxjkemxOGRbeX3vCRARUImw4oOlRe0r cYgwzEuOxJxAbWdL+sTtKpJdcyjfe4gN8/0Vy7QQUmm+yolWe/Zt/4tcPz/4aAwEJVEBnvSl1 gRwihsQ1B7oSKB+p9tART8rOpo5qgDuaVIPgxqsI9/SNwwEGip/AKoMYWeHZ9ErO2blbisQEQ ae765xmgTDXIpOEmvuaszqptgogfQH3dJ5m9LxKXAUEqdMLK8Hv0EAu5K5beSL9Zq6l9zXeNy Huxj0PZu/HHuy0WrJJq4B29cAPi+QHKzDORIciMKQX7D3BliK7xkhMHa6ijtxQMSVjjXOmQf0 3AfV6fuH3vW3M7Gco2G0NlTgdpsGQsQINtFsrtw9wK08dSMkv3llyu8fkYsdHmZwVCSJZB0jF +KXBRUK+CCDSMZbFUWNwfQpelAudYc3m1emJmEUg6GsK1ZuWtAX3hK+ubbcJIxRVSJ+7ibaGL LZSixsqkYNPC2d/3QE6OalnpbNvqVo6iSdDTh7SjLNz3gGnJAJ4HcDjVM8ikcIuCHu/9l5kwN SUA/owZu88G7rccELbVY5fM+M+lKLTtAUZjDziVrO2lDohvdXTqyCliF0gYiZPiYoqAig8A9M TdkDn41RNxb8eq40woFblAVppRretvfXhDQ8m3WK1TTJnJAZwFdORG/lgqoiffKt7WJd0bNrS 43hd2LXSGaSWnals40rPefLYQz0btaugn9kYi35jz0zi/kW17zFWaXCfqJkaN5tPYtsVTdl/A kB6MmBP8kgw== 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 08:43:48 -0000 Hi, > 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. Unfortunate... > 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. 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=20 > 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? >=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