General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Mikel Irazabal Bengoa <mikel.irazabal@upc.edu>
To: Dave Taht <dave.taht@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.net>,
	Navid Nikaein <navid.nikaein@eurecom.fr>,
	 Elena Lopez Aguilera <ma.elena.lopez@upc.edu>,
	Ilker Demirkol <ilker.demirkol@upc.edu>,
	 Robert Schmidt <robert.schmidt@eurecom.fr>,
	irazabal@eurecom.fr
Subject: Re: [Bloat] Preventing RLC Buffer Sojourn Delays in 5G
Date: Mon, 29 Nov 2021 11:28:00 +0100	[thread overview]
Message-ID: <CAAb+pRXGT=Ycwz4ErUNH6Vbuf1yNYXf7gfO5MiD2HBH3aDZ9Uw@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw4YdKZXoQtr3UucwqvsJdYVKbGG2LUypvn_BNFXApwghg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]

Hi Dave,

It is nice to see that this journal caught your attention. Answers between
the lines


*I am always puzzled as to why folk don't benchmark fq-codel (or something
like BQL)*
One solution that we propose, DRQL (Dynamic RLC Queue Limit) is pretty much
inspired by BQL, as the name suggests. So yes, one could say that we
implemented BQL for RAN.
Maybe this article also answers some questions
https://ieeexplore.ieee.org/document/9169837
Regarding fq-codel, we implemented codel, which for our scenario was
sufficient as they were arriving two different QFI type of flows. (one
could think of QFIs as DiffServ as there are also exists 64 QoS defined  by
3GPP TS 23.501)
If you want to implement fq-codel on the RLC DRBs, you have to slightly
contradict the 3GPP standard. DRBs are initiated by the UEs and, I believe,
that you cannot have packets with the same QFI in different DRBs.
If, on the other hand, you want to implement them in the upper sublayers
(e.g., above SDAP) you need to go beyond the 3GPP specification.
In any case, among other things, we are currently working at Eurecom in a
flexible traffic flow control mechanism for at least, OpenAirInterface's
RAN stack, to enable more people test their algorithms in a real 5G RAN
testbed.


* in scenarios like these. Are the headers not available in the RAN?
(forgive me for forgetting)*

They are available until the PDCP sublayer, AFAIR.


*Anyway, their "vanilla" scenario shows 5G with > 1sec of buffering. Is
that real?*

It is real in the OpenAirInterface project.
https://gitlab.eurecom.fr/oai/openairinterface5g
This does not prove that is real or false in commercial base stations.
Additionally, even though the queuing structure does not change, keep in
mind that the experiments where conducted with a 3GPP compliant 4G RAN
stack and some additional code for the described scenario.

BR,
Mikel


On Mon, 29 Nov 2021 at 01:34, Dave Taht <dave.taht@gmail.com> wrote:

> A nice comparison of BBR vs Codel vs FIFO vs their cross-layer
> solution. (they used irtt!)
>
> I am always puzzled as to why folk don't benchmark fq-codel (or
> something like BQL)
> in scenarios like these. Are the headers not available in the RAN?
> (forgive me for forgetting)
>
> Anyway, their "vanilla" scenario shows 5G with > 1sec of buffering.
> Is that real?
>
> https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9369375
>
> --
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>
> Dave Täht CEO, TekLibre, LLC
>

[-- Attachment #2: Type: text/html, Size: 3699 bytes --]

  reply	other threads:[~2021-11-29 10:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-29  0:33 Dave Taht
2021-11-29 10:28 ` Mikel Irazabal Bengoa [this message]
2021-11-29 12:02   ` Dave Taht

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='CAAb+pRXGT=Ycwz4ErUNH6Vbuf1yNYXf7gfO5MiD2HBH3aDZ9Uw@mail.gmail.com' \
    --to=mikel.irazabal@upc.edu \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --cc=ilker.demirkol@upc.edu \
    --cc=irazabal@eurecom.fr \
    --cc=ma.elena.lopez@upc.edu \
    --cc=navid.nikaein@eurecom.fr \
    --cc=robert.schmidt@eurecom.fr \
    /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