Re: [Bloat] Preventing RLC Buffer Sojourn Delays in 5G

[Dave Taht <dave.taht@gmail.com>]

On Mon, Nov 29, 2021 at 2:28 AM Mikel Irazabal Bengoa
<mikel.irazabal@upc.edu> wrote:
>
> Hi Dave,
>
> It is nice to see that this journal caught your attention. Answers between the lines

Good paper!

I try to catch up on the backlog of bufferbloat related publications
on sundays. Lately, the backlog has got out of hand.

> 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

Thx!

> 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)

Wading through the maze of these standards here is always hard and
thank you for referencing the correct document and translating back
into language I sort of understand.

But in the internet, voice and video are not diffserved, pretty much
everything is best effort.

> 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.

It used to be when standards met an actual implementation issue, that
the implementation lept forward with something that worked, the vendor
kept the idea proprietary
for several years, and then, maybe, maybe, it made it into a future
revision of the spec.

> 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.

I am delighted to hear of this effort. How do we get in on it?

> 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

That steer especially. I do much better reading code than specs.

> This does not prove that is real or false in commercial base stations.

But it is a starting point.

One of the cooler things we've been doing with irtt btw is using it at
a very high (3ms) interval to map networks like starlinks. I'd really
like to start up a project to
look harder at lte/5g this way.

> 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



-- 
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