From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 2C8F53B29D for ; Sat, 9 Apr 2022 02:56:37 -0400 (EDT) Received: by mail-ed1-x52e.google.com with SMTP id r3so2740413edi.8 for ; Fri, 08 Apr 2022 23:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f9LuhrW27fot7x1Y/JRVzZZhoVXh63YoC04RCQWgTVg=; b=Mzx+jlahP0igoOamr4nd19NU0DnpXGJACL6vOpfZOCfhjIkTcRIyigDuFWwAYYX3QG 9RmOopKKKZNOBD5nOnAW2xaAl0ZtOCfozRyCG2x70ZguIZapo0/4x18XSsOMAdeyzcAz VH4IqIQWaCTzXizPYk4EljlNrO8ZHSYFAr3BXrUcZtDxkkkU1wv8/awyRhNOMQl/GT++ Zg7f14NO4ou9S5tg6CzgFzX1O8cUWrF/5GOrLYHobmuyn9GmHgSHKGKKn7G129zS064y npkMbyDmzDwmNii3xZ5KZ0n/orzyMsG7X+rwiWGO3CMleupkF9D01oQJTpSH7dt90XAW VLyg== 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=f9LuhrW27fot7x1Y/JRVzZZhoVXh63YoC04RCQWgTVg=; b=KGkckOjgjXawCyvILF+vEX2yfE6LQLDFmFm/9G9WtodPTY6DHeW1aSvqNC4f/kla+X 9ahucI0EX6WiyxDW0gz5jL9oyECqVnP+pH4u4WDVtV7ed9xwvaOYuhQUI/tf1LIl4Cc7 58nDahCfw4uwyci8078j2kX7thtBV+/ypj5CCYILsm+UnrKrd1ZUGPYZ50B66sqJUZdB vyah5gL/5T1vn7UMkvfjVf3HIjIHGnvijeSGfi74AIjGYN+PZlXdUi9QLm4OBNykbflS uduCa3IZQ33dvbmMY2bIJHQCny4MvSijImA60UbFO5yrmGzGrkFzVXw5tpneJeG9sBOA PLCw== X-Gm-Message-State: AOAM533qkE3k0/Yj095zvXlGnYQEU8TmDuL1zuIXPkAfSwlzWUcy6ErU e7fefUI/guBcZ2z0lGngdUgn/K8mlhZnL9u/J5srwZvD29E= X-Google-Smtp-Source: ABdhPJx41XpZs0hP07s4iRC6QzWbwbeOlbepDJZrpvstK9jKgYOxbHxXR8cWiT3FDX86/TX96Ic/iX4kRuIGqG0D4jE= X-Received: by 2002:a50:c3c6:0:b0:416:293f:1f42 with SMTP id i6-20020a50c3c6000000b00416293f1f42mr22842205edf.187.1649487395600; Fri, 08 Apr 2022 23:56:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Qian Li Date: Sat, 9 Apr 2022 14:56:22 +0800 Message-ID: To: Dave Taht Cc: bloat Content-Type: multipart/alternative; boundary="00000000000046bed405dc33367c" X-Mailman-Approved-At: Fri, 15 Apr 2022 15:40:47 -0400 Subject: Re: [Bloat] less than best effort: TCP - flexis - A New Approach To Incipient Congestion Detection and Control 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: Sat, 09 Apr 2022 06:56:37 -0000 --00000000000046bed405dc33367c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello again, I have uploaded the source code to GitHub. You can find it here: https://github.com/tinalee77/FlexiS I have done some editing to the original code that was used to produce the results in the paper. First, I removed all debugging statements. Second, I updated comments so that they are more readable. Third, I made variable names consistent with the paper. And finally, I licensed it with Gnu GPL. Best regards, Qian On Thu, Apr 7, 2022 at 10:35 PM Qian Li wrote: > Hi Dave, > > I was just told that I am allowed to distribute the code freely. I will > upload it to GitHub and will send you the link as soon as I am done with = it. > > As for the AQM test, I set the QDisc to FQ-CoDel, CoDel, and CAKE, but > none worked on CORE. In contrast, RED and PIE worked as expected. As far = as > I know, the major difference between these two groups of AQMs is the time > when the packets are dropped. But I am not 100% sure it was the cause. I > may somehow test FlexiS or FlexiR (FlexiS adapted to the receiver side) o= n > a testbed with various AQMs. But it will be toward the end of the > adaptation I guess :) > > Best regards, > Qian > > On Thu, Apr 7, 2022 at 8:52 AM Dave Taht wrote: > >> On Tue, Apr 5, 2022 at 8:44 AM Qian Li wrote: >> > >> > Dear Dave, >> > >> > Thank you for your interest in my work. >> > >> > I have read another paper authored by D. Rossi at el. presenting the >> priority inversion problem of LEDBAT when it is used together with AQM. = And >> it has become one of the factors that motivated me to devise a new LBE C= C >> that can preserve low priority even when AQM is used. >> >> We'd given up hope circa 2014 as of the publication of the paper I >> cited, and moved on. >> >> >However, I could not test FlexiS with CoDel on the CORE emulator >> probably because CoDel drops packets at the dequeue time. >> >> I don't really understand that statement. >> >> > More tests should be done to verify that FlexiS does preserve low >> priority in the presence of various AQM algorithms. >> >> Yes. until fairly recently I had had a testbed setup that allowed >> testing of various tcps and aqm systems, but its been in storage since >> covid. >> >> > I am now adapting FlexiS to the receiver side. The main motivation to >> do so is that there might be HTTP/TCP proxies between the sender and the >> receiver. A receiver side LBE CC and make the connection between the pro= xy >> and the receiver LBE. In this work, I am going to tackle some open issue= s >> with FlexiS. For example, I am going to test if trend analysis can be do= ne >> based on one way delay so that the throughput is less affected by ack pa= th >> congestion. And I am going to evaluate various techniques to reduce rate >> below 2 mss per RTT. This may include what you have suggested -- use sma= ll >> packets and sub-packet window. I am also interested in using pacing to s= low >> down sending rate and maybe more alternative solutions. >> >> Cool! >> >> > >> > I don't have a git tree for the source code mainly because I don't kno= w >> if I am allowed to publish the code as open source. If you are intereste= d >> in the source code, I can ask the University of Oslo if I am allowed to >> distribute it freely? >> >> I would hope they would allow publication. The world is full of half >> baked projects that if only someones new also stepped in, were >> completed. An example of this is BBR which originally was about half >> what it is today, until source was released among the right people. >> >> > >> > Best regards, >> > Qian >> > >> > >> > >> > On Sun, Apr 3, 2022 at 6:38 AM Dave Taht wrote: >> >> >> >> Dear Qian: >> >> >> >> Pretty promising paper. I liked that it tackled congestion on the ack >> >> path, among other things. >> >> >> >> >> https://www.techrxiv.org/articles/preprint/TCP_FlexiS_A_New_Approach_To_= Incipient_Congestion_Detection_and_Control/19077161/1/files/33905018.pdf >> >> >> >> I like also that you tackled, inter-rtt fairness, and, ledbat's >> >> latecomer advantage problem, and in fig 9, the basic problem with >> >> delay based LBE vs AQMs (in that ledbat degrades to reno)... [1] >> >> >> >> Towards your conclusion... >> >> >> >> I have always disagreed with the "don't reduce segment size" crowd, >> >> btw. If you have a rate where you need to go below 2mss, it doesn't >> >> hurt the network to reduce the size of the packet, and you can keep >> >> the signal strength up by reducing that size and continuing to sample >> >> rtt, to respond quickly. >> >> >> >> Even if you are only passing a single byte of data, by lowering this >> >> below everyone else's 2mss noise floor, you still eventually win, and >> >> also you occupy space in packet fifos, reducing overall latency, as >> >> bytes=3Dtime. IMHO. >> >> >> >> elsewhere, sub-packet windows are being experimented in bbrv2, I'm >> >> told, but not in LBE. >> >> >> >> I'm also a big believer in packet pacing, and I think this is the >> >> first paper I've seen that attempted LBE with it. Thx! >> >> >> >> Got a git tree? >> >> >> >> [1] do wish you'd had cited >> >> https://perso.telecom-paristech.fr/drossi/paper/rossi14comnet-b.pdf >> >> >> >> -- >> >> 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 >> >> >> >> -- >> 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 >> > --00000000000046bed405dc33367c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello again,

I have uploaded= the source code to GitHub. You can find it here:

<= div>https://github.com/tina= lee77/FlexiS

I have done some editing to the o= riginal code that was used to produce the results in the paper. First, I re= moved all debugging statements. Second, I updated comments so that they are= more readable. Third, I made variable names consistent with the paper. And= finally, I licensed it with Gnu GPL.

Best reg= ards,
Qian



=


On Thu, Apr 7, 2022 at 10:35 PM Qian Li <biz.tinalee@gmail.com> wrote:
Hi=C2=A0Dav= e,

I was just told that I am allowed to distribute the c= ode freely. I will upload it to GitHub and will send you the link as soon a= s I am done with it.

As for the AQM test, I set th= e QDisc to FQ-CoDel, CoDel, and CAKE, but none worked on CORE. In contrast,= RED and PIE worked as expected. As far as I know, the major difference bet= ween these two groups of AQMs is the time when the packets are dropped. But= I am not 100% sure it was the cause. I may somehow test FlexiS or FlexiR (= FlexiS adapted to the receiver side) on a testbed with various AQMs. But it= will be toward the end of the adaptation I guess :)

Best regards,
Qian

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr 7, 2022 at 8:52 AM Dave Ta= ht <dave.taht@g= mail.com> wrote:
On Tue, Apr 5, 2022 at 8:44 AM Qian Li <biz.tinalee@gmail.com> wrote:
>
> Dear Dave,
>
> Thank you for your interest in my work.
>
> I have read another paper authored by D. Rossi at el. presenting the p= riority inversion problem of LEDBAT when it is used together with AQM. And = it has become one of the factors that motivated me to devise a new LBE CC t= hat can preserve low priority even when AQM is used.

We'd given up hope circa 2014 as of the publication of the paper I
cited, and moved on.

>However, I could not test FlexiS with CoDel on the CORE emulator probab= ly because CoDel drops packets at the dequeue time.

I don't really understand that statement.

> More tests should be done to verify that FlexiS does preserve low prio= rity in the presence of various AQM algorithms.

Yes. until fairly recently I had had a testbed setup that allowed
testing of various tcps and aqm systems, but its been in storage since
covid.

> I am now adapting FlexiS to the receiver side. The main motivation to = do so is that there might be HTTP/TCP proxies between the sender and the re= ceiver. A receiver side LBE CC and make the connection between the proxy an= d the receiver LBE. In this work, I am going to tackle some open issues wit= h FlexiS. For example, I am going to test if trend analysis can be done bas= ed on one way delay so that the throughput is less affected by ack path con= gestion. And I am going to evaluate various techniques to reduce rate below= 2 mss per RTT. This may include what you have suggested -- use small packe= ts and sub-packet window. I am also interested in using pacing to slow down= sending rate and maybe more alternative solutions.

Cool!

>
> I don't have a git tree for the source code mainly because I don&#= 39;t know if I am allowed to publish the code as open source. If you are in= terested in the source code, I can ask the University of Oslo if I am allow= ed to distribute it freely?

I would hope they would allow publication. The world is full of half
baked projects that if only someones new also stepped in, were
completed. An example of this is BBR which originally was about half
what it is today, until source was released among the right people.

>
> Best regards,
> Qian
>
>
>
> On Sun, Apr 3, 2022 at 6:38 AM Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Dear Qian:
>>
>> Pretty promising paper. I liked that it tackled congestion on the = ack
>> path, among other things.
>>
>> https://www.techrxiv.o= rg/articles/preprint/TCP_FlexiS_A_New_Approach_To_Incipient_Congestion_Dete= ction_and_Control/19077161/1/files/33905018.pdf
>>
>> I like also that you tackled, inter-rtt fairness, and, ledbat'= s
>> latecomer advantage problem, and in fig 9, the basic problem with<= br> >> delay based LBE vs AQMs (in that ledbat degrades to reno)... [1] >>
>> Towards your conclusion...
>>
>> I have always disagreed with the "don't reduce segment si= ze" crowd,
>> btw. If you have a rate where you need to go below 2mss, it doesn&= #39;t
>> hurt the network to reduce the size of the packet, and you can kee= p
>> the signal strength up by reducing that size and continuing to sam= ple
>> rtt, to respond quickly.
>>
>> Even if you are only passing a single byte of data, by lowering th= is
>> below everyone else's 2mss noise floor, you still eventually w= in, and
>> also you occupy space in packet fifos, reducing overall latency, a= s
>> bytes=3Dtime. IMHO.
>>
>> elsewhere, sub-packet windows are being experimented in bbrv2, I&#= 39;m
>> told, but not in LBE.
>>
>> I'm also a big believer in packet pacing, and I think this is = the
>> first paper I've seen that attempted LBE with it. Thx!
>>
>> Got a git tree?
>>
>> [1] do wish you'd had cited
>> https://perso.telecom-pa= ristech.fr/drossi/paper/rossi14comnet-b.pdf
>>
>> --
>> 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



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