General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: "bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Packet reordering and RACK (was The "Some Congestion Experienced" ECN codepoint)
Date: Thu, 14 Mar 2019 09:43:45 +0100	[thread overview]
Message-ID: <E3154B34-123E-4A64-B15A-F5F8CF5C55B4@gmx.de> (raw)
In-Reply-To: <HE1PR07MB442526730269DA318B2ED38BC24B0@HE1PR07MB4425.eurprd07.prod.outlook.com>

Hi,


> On Mar 14, 2019, at 09:26, Ingemar Johansson S <ingemar.s.johansson@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@lang.hm>
> To: Sebastian Moeller <moeller0@gmx.de>
> Cc: Mikael Abrahamsson <swmike@swm.pp.se>,  "Holland, Jake"
> 	<jholland@akamai.com>,  Cake List <cake@lists.bufferbloat.net>,
> 	"codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>,  bloat
> 	<bloat@lists.bufferbloat.net>,  "ecn-sane@lists.bufferbloat.net"
> 	<ecn-sane@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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat


  reply	other threads:[~2019-03-14  8:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-14  8:26 Ingemar Johansson S
2019-03-14  8:43 ` Sebastian Moeller [this message]
2019-03-14 19:23   ` Greg White
2019-03-14 21:43     ` Sebastian Moeller
2019-03-14 22:05       ` David Lang
2019-03-16 22:59         ` Michael Richardson
2019-03-17 10:23       ` Carsten Bormann
2019-03-17 11:45         ` Sebastian Moeller
2019-03-17 14:34           ` Carsten Bormann
2019-03-17 15:56             ` Sebastian Moeller
2019-03-17 17:09               ` Carsten Bormann
2019-03-17 19:57                 ` Sebastian Moeller
2019-03-18  0:05                   ` David Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E3154B34-123E-4A64-B15A-F5F8CF5C55B4@gmx.de \
    --to=moeller0@gmx.de \
    --cc=bloat@lists.bufferbloat.net \
    --cc=ingemar.s.johansson@ericsson.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox