From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 4E5AD3CB44 for ; Mon, 22 Aug 2022 00:27:52 -0400 (EDT) Received: by mail-ed1-x536.google.com with SMTP id a22so12257618edj.5 for ; Sun, 21 Aug 2022 21:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=2AAXzSnBD7a3tTXwcKRc0qOjaC2D9b+I2aZOEokHP7g=; b=PlaNUQ4FpFMjGHjI4lHzDmIB8pBplsoh2A0ENa7brqDxAFxtLlzTYv7IjUQlfdm2FC R+MdziOTQVc1KLJYssc0yhGm2IAhGPeuHnM1djPFJImb4VDMhHMU6OfEtfdBh1bPDhbn OAP1T37XP0grKC/PRPf6dYP+mPjL04T6yCCK1WVF4Mqft5yz4tyqYV752wduK7krArSd CLjomoSItPk0j56N29HGM58yjzo9euLMOtxNU+fWFCyQvH5g3pHw3jb3m96xfUK77Hyu zE75igV/zPv17n8BKQEimq4UqRqiw9kSnfCMYKra6qm5PbQaNaoHVBAmTUlMhdp353Qk wDDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=2AAXzSnBD7a3tTXwcKRc0qOjaC2D9b+I2aZOEokHP7g=; b=2NYBZPZG3/k5zH6TrXma2SQgPkAOYVBbOfDCkWeug4WY/fZJbrjcB6iWFcU/PlQS1M /W6cPmdS+CxfnbAA5XSP6TkZhQpg6thue3DlAMBwz5nbMeMxcNj6kjMSNf6nkXMrDdf9 B5Uv1FEhQQCdAXYEO3FRcSE5L48F78ZXQ+KNJEO/wReQVUqvlQd1QfXsRcGLrrjOEUoc zbkafYiqKiLrzMsmqzsJfhSBVk/gKOe1s86TbQIAoDgUaZIIzNib+r9K6JEPvgf4OhM0 ippQFRQc+SvkylHrKKMc8Tg16aJ2sa2ZQtz7cWD9+2RBdjaK6T/Smes02QbvD5KJAXpH 3MeA== X-Gm-Message-State: ACgBeo3jEPiQKNkeS7R+ABLJfxAMPIySo1IvmnMl/SM0FoUbh/pVnTDa OHOaoo3jUpqt3pgBXFp+WH3PD0McWezv44oWne8OaBQm X-Google-Smtp-Source: AA6agR5CQbAW2g/EEVKozXYfW8N0IAJL8HV91EjpGLX1kN2KTVbuEnyqKY/YwEXKEtFWHEUYDlTNr/03RA+n2sj2Qe8= X-Received: by 2002:a05:6402:3805:b0:43e:8335:3a2a with SMTP id es5-20020a056402380500b0043e83353a2amr14946851edb.296.1661142471015; Sun, 21 Aug 2022 21:27:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Qian Li Message-ID: To: Dave Taht Cc: bloat Content-Type: multipart/alternative; boundary="000000000000e800ab05e6ccdee2" X-Mailman-Approved-At: Mon, 12 Sep 2022 10:39:53 -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: , Date: Mon, 22 Aug 2022 04:27:52 -0000 X-Original-Date: Mon, 22 Aug 2022 12:27:38 +0800 X-List-Received-Date: Mon, 22 Aug 2022 04:27:52 -0000 --000000000000e800ab05e6ccdee2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for the feedback! I had been working on a major revision of the submitted paper. I was asked to compare FlexiS with LEDBAT++. I also added a greedy BE to greedy LBE test, something like that reported in your work. And I also added a reference to your suggested work. It is possible to reduce packet size below the max MSS at times of severe intrusion. However, this will only mitigate bit congestion (congestion caused by comparatively slow transmission link) but not packet congestion (congestion caused by comparatively slow processing power) if the minimum packet rate is kept at 2MSS/RTT [1]. The second problem is easier to fix. I guess it is caused by WiFi contention and delayed ack? Did FlexiS become less efficient (low utilization) or more intrusive? I can also add some loss tolerant code to make it more robust in wireless scenarios. I am now deciding the focus of the next paper, which I need for my Ph.D. thesis. It can be an optimization of FlexiS if you think it is desirable? Please let me know all known issues with FlexiS so far based on your evaluation. I will try to figure out solutions/mitigations for them. [1] RFC6077. Open Research Issues in Internet Congestion Control I have switched from Gmail to Hotmail because I can no longer access Gmail easily due to the firewall. Please send follow-up emails to my new email address: li_qian_pro@hotmail.com Best regards, Qian On Mon, Aug 22, 2022 at 2:27 AM Dave Taht wrote: > I have not had time to play with this much more, but it remains > promising. Although you dismiss the ieas of not reducing the mss as > not cost effective, I think for certain kinds of traffic it it worth > pursuing. > > Also, based on some tests on a busy wifi network elsewhere, doing > packet pacing on a per packet (rather than two packets at a time) > seems interesting. > > What are you working on these days? > > On Fri, Apr 8, 2022 at 11:56 PM Qian Li wrote: > > > > 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 wil= l > 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 th= e > priority inversion problem of LEDBAT when it is used together with AQM. A= nd > it has become one of the factors that motivated me to devise a new LBE CC > 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 sinc= e > >>> 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 t= he > receiver. A receiver side LBE CC and make the connection between the prox= y > and the receiver LBE. In this work, I am going to tackle some open issues > with FlexiS. For example, I am going to test if trend analysis can be don= e > based on one way delay so that the throughput is less affected by ack pat= h > 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 smal= l > packets and sub-packet window. I am also interested in using pacing to sl= ow > 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 > know if I am allowed to publish the code as open source. If you are > interested 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_I= ncipient_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 kee= p > >>> >> 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 th= is > >>> >> below everyone else's 2mss noise floor, you still eventually win, > 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'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.pd= f > >>> >> > >>> >> -- > >>> >> 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 > > > > -- > FQ World Domination pending: > https://blog.cerowrt.org/post/state_of_fq_codel/ > Dave T=C3=A4ht CEO, TekLibre, LLC > --000000000000e800ab05e6ccdee2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

Thanks for th= e feedback!

I had been working on a major revision= of the submitted paper. I was asked to compare FlexiS with LEDBAT++. I als= o added a greedy BE to greedy LBE test, something like that reported in you= r work. And I also added a reference to your suggested work.

=
It is possible to reduce packet size below the max MSS at times = of severe intrusion. However, this will only mitigate bit congestion (conge= stion caused by comparatively slow transmission link) but not packet conges= tion (congestion caused by comparatively slow processing power) if the mini= mum packet rate is kept at 2MSS/RTT [1].=C2=A0

The= second problem is easier to fix. I guess it is caused by WiFi contention a= nd delayed ack? Did FlexiS become less efficient (low utilization) or more = intrusive?=C2=A0

I can also add some loss tolerant= code to make it more robust in wireless scenarios.

I am now deciding the focus of the next paper, which I need for my Ph.D. = thesis. It can be an optimization of FlexiS if you think it is desirable? P= lease let me know all known issues with FlexiS so far based on your evaluat= ion. I will try to figure out solutions/mitigations for them.
[1] RFC6077. Open Research Issues in Internet Congestion Contro= l

I have switched from Gmail to Hotmail becaus= e I can no longer access Gmail easily due to the firewall. Please send foll= ow-up emails to my new email address: li_qian_pro@hotmail.com

Best regards,
Qian


On Mon, A= ug 22, 2022 at 2:27 AM Dave Taht <dave.taht@gmail.com> wrote:
I have not had time to play with this= much more, but it remains
promising. Although you dismiss the ieas of not reducing the mss as
not cost effective, I think for certain kinds of traffic it it worth
pursuing.

Also, based on some tests on a busy wifi network elsewhere, doing
packet pacing on a per packet (rather than two packets at a time)
seems interesting.

What are you working on these days?

On Fri, Apr 8, 2022 at 11:56 PM Qian Li <biz.tinalee@gmail.com> wrote:
>
> 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. Secon= d, I updated comments so that they are more readable. Third, I made variabl= e 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 <biz.tinalee@gmail.com> 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 w= ith 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 f= ar 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) = on a testbed with various AQMs. But it will be toward the end of the adapta= tion I guess :)
>>
>> Best regards,
>> Qian
>>
>> On Thu, Apr 7, 2022 at 8:52 AM Dave Taht <dave.taht@gmail.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. pre= senting the priority inversion problem of LEDBAT when it is used together w= ith AQM. And it has become one of the factors that motivated me to devise a= new LBE CC 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 em= ulator 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 pres= erve low priority in the presence of various AQM algorithms.
>>>
>>> Yes. until fairly recently I had had a testbed setup that allo= wed
>>> testing of various tcps and aqm systems, but its been in stora= ge since
>>> covid.
>>>
>>> > I am now adapting FlexiS to the receiver side. The main m= otivation to do so is that there might be HTTP/TCP proxies between the send= er and the receiver. A receiver side LBE CC and make the connection between= the proxy and the receiver LBE. In this work, I am going to tackle some op= en issues with FlexiS. For example, I am going to test if trend analysis ca= n be done based on one way delay so that the throughput is less affected by= ack path congestion. And I am going to evaluate various techniques to redu= ce rate below 2 mss per RTT. This may include what you have suggested -- us= e small packets 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 be= cause I don't know if I am allowed to publish the code as open source. = If you are interested 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 o= f half
>>> baked projects that if only someones new also stepped in, were=
>>> completed. An example of this is BBR which originally was abou= t half
>>> what it is today, until source was released among the right pe= ople.
>>>
>>> >
>>> > Best regards,
>>> > Qian
>>> >
>>> >
>>> >
>>> > On Sun, Apr 3, 2022 at 6:38 AM Dave Taht <dave.taht@gmail.com> wr= ote:
>>> >>
>>> >> Dear Qian:
>>> >>
>>> >> Pretty promising paper. I liked that it tackled conge= stion on the ack
>>> >> path, among other things.
>>> >>
>>> >> https://w= ww.techrxiv.org/articles/preprint/TCP_FlexiS_A_New_Approach_To_Incipient_Co= ngestion_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 r= eno)... [1]
>>> >>
>>> >> Towards your conclusion...
>>> >>
>>> >> I have always disagreed with the "don't redu= ce segment size" crowd,
>>> >> btw. If you have a rate where you need to go below 2m= ss, it doesn't
>>> >> hurt the network to reduce the size of the packet, an= d you can keep
>>> >> the signal strength up by reducing that size and cont= inuing to sample
>>> >> rtt, to respond quickly.
>>> >>
>>> >> Even if you are only passing a single byte of data, b= y lowering this
>>> >> below everyone else's 2mss noise floor, you still= eventually win, and
>>> >> also you occupy space in packet fifos, reducing overa= ll 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 t= hink 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://per= so.telecom-paristech.fr/drossi/paper/rossi14comnet-b.pdf
>>> >>
>>> >> --
>>> >> I tried to build a better future, a few times:
>>> >> https://wayfo= rward.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.arc= hive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org
>>>
>>> Dave T=C3=A4ht CEO, TekLibre, LLC



--
FQ World Domination pending: https://blog.cerowrt.or= g/post/state_of_fq_codel/
Dave T=C3=A4ht CEO, TekLibre, LLC
--000000000000e800ab05e6ccdee2--