From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 B01653B2A4 for ; Mon, 29 Nov 2021 05:28:13 -0500 (EST) Received: by mail-io1-xd31.google.com with SMTP id c3so20757025iob.6 for ; Mon, 29 Nov 2021 02:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=upc-edu.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZOi9/dAk1tjOm6eOd+4ZXxMSBnYDhQ27dHeMErW4U7I=; b=km01EE7UH0xV+qEzVvmc1KZ87i3BU3aoOTvj7/zQDYaD1CuMJyKnF78tDsAc61lKKg 1+t9wOKjTaVMPHhA9LB4uA9OfM1ZL/0Uyfr22pGmmO43Xqo/iKbCeo1gyM1LnKP/E6Xz VeRMgsMPZSgle49r6jVmKhsZ4y5FdT1UM4Ys9+IXrQZIwXmkeYiSTmBaVPV5+qsMyd5x EchWG2NSNtzADazFcsQ31Z82W4fHF+p/IThnyxGs3jh/6iFTE0gzP/CbB6MpVbHo4d3f NcRogP/Qd+wT6d6FIe/ihXZyD8ISmUEyS7OzuitilhtbjX6hsll+MRvgQV+YKNMZdh3E fHGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZOi9/dAk1tjOm6eOd+4ZXxMSBnYDhQ27dHeMErW4U7I=; b=RLjs/gPm/6X73fzQ2zkY4ktM4pY7nKWtELOjOXv3WGlQpp+GYOb2L0VdH3u5B4PJwz g8vClI4hbpB/xTqCX1cuMrsPG2bvleYPSa/ipQVgKEvM4BTNQXo7XrvbNB3DkmJnDHMW hlrbjozs48R5o14EQHxzS7k+mrTGD1FI5AhlNLgCzIxkGEK6OtWoMnFDWfJIRe5QWVMV LFlHG2lmKS27D24LnjOI2NWVjCJ4zwyeX/bZbFG8xruSgCdv6scJIQRiHhWM31KMOYHw HHDY7AUrxfdPBnIEFhZEoO4Rs2W1yaI9+7qUJxFrwhVSLDLYJ7Gj6RkiNfBZOqshKvH/ lRiQ== X-Gm-Message-State: AOAM5318BOse7l18LAoC4/l+dIzjK1TvDOquOFw8n+GgOXH7Iu9eyXLf 9aNp2oJs2jdcpNrDpzwFxWFAkfklJsPKTBTQAkJG6Q== X-Google-Smtp-Source: ABdhPJwiekh65j6cYoYovE9EyVlhn0cKIJpvhpNz7qdA0jFnXNOFL3YRXmg0EopHL8QFhvuEkDScRjefN/upUOcJnDo= X-Received: by 2002:a6b:7c46:: with SMTP id b6mr60677210ioq.129.1638181693036; Mon, 29 Nov 2021 02:28:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mikel Irazabal Bengoa Date: Mon, 29 Nov 2021 11:28:00 +0100 Message-ID: To: Dave Taht Cc: bloat , Navid Nikaein , Elena Lopez Aguilera , Ilker Demirkol , Robert Schmidt , irazabal@eurecom.fr Content-Type: multipart/alternative; boundary="000000000000e42c0905d1eae536" X-Mailman-Approved-At: Mon, 29 Nov 2021 05:31:29 -0500 Subject: Re: [Bloat] Preventing RLC Buffer Sojourn Delays in 5G 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: Mon, 29 Nov 2021 10:28:13 -0000 --000000000000e42c0905d1eae536 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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=3D9369375 > > -- > I tried to build a better future, a few times: > https://wayforward.archive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org > > Dave T=C3=A4ht CEO, TekLibre, LLC > --000000000000e42c0905d1eae536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

It is nice to see t= hat this journal caught your attention. Answers between the lines

I am always puzzled as to why folk don't benchmar= k fq-codel (or
something like BQL)
One solution that we propose, DRQL (D= ynamic RLC Queue Limit) is pretty much inspired by BQL, as the name suggest= s. So yes, one could say that we implemented BQL for RAN.
May= be this article also answers some questions
Regarding fq-codel, we implemented codel, which for our= scenario was sufficient as they were arriving two different QFI type of fl= ows. (one could think of QFIs as DiffServ as there are also exists 64 QoS d= efined=C2=A0 by 3GPP TS 23.501)
If you want to implement fq-c= odel on the RLC DRBs, you have to slightly contradict the 3GPP standard. DR= Bs are initiated by the UEs and, I believe, that you cannot have packets wi= th the same QFI in different DRBs.
If, on the other hand, you wan= t to implement them in the upper sublayers (e.g., above SDAP) you need to g= o beyond the 3GPP specification.
In any case, among other th= ings, we are currently working at Eurecom in a flexible traffic flow contro= l mechanism for at least, OpenAirInterface's RAN stack, to enable more = people test their algorithms in a real 5G RAN testbed.

<= /div>
in scenarios like these. Are the headers not available in the RAN?
(forgive me for forgetting)

They ar= e available until the PDCP sublayer, AFAIR.

Anyway, their "vanilla" scenario shows 5G with > 1sec of b= uffering.
Is that real?

It is real in the OpenAirInt= erface project.
=
This does not prove that is real or false in commercial base stations.= =C2=A0
Additionally, even though the queuing structure does = not change, keep in mind that the experiments where conducted with a 3GPP c= ompliant 4G RAN stack and some additional code for the described scenario. =

BR,
Mikel=C2=A0


On Mon, 29 Nov 2021 at 01:34, Dave Taht <dave.taht@gmail.com> wrote:
A nice comparison of BBR vs C= odel 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 buffe= ring.
Is that real?

https://ieeexplore.ieee.org/stamp/stam= p.jsp?arnumber=3D9369375

--
I tried to build a better future, a few times:
https://wayforward.archive.org/?sit= e=3Dhttps%3A%2F%2Fwww.icei.org

Dave T=C3=A4ht CEO, TekLibre, LLC
--000000000000e42c0905d1eae536--