From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 F236F3B29D for ; Tue, 5 Apr 2022 11:44:16 -0400 (EDT) Received: by mail-ej1-x636.google.com with SMTP id k23so24117817ejd.3 for ; Tue, 05 Apr 2022 08:44:16 -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=avCmmXSZ7XUiajW6MhYrMyUXj4W71SGL0EgraUK3p+g=; b=qg0zM5nasasKNZQyhcPn9+6RyxCCj7d5DTt6nzms5JpmDXsoOXYAQFEkqW4OzbAxSz 1LXXJLJZmIRQRRWWy+H0fIlbEe1Y5/5r98HE/0D5r+4LHiyElegVoo+e96HfQcwPXlFm 1AoZR/F0itLo3+JcZVlnMjfNriPt9klMhweHLbA1DMezyjyN41D/xE7TYcpAWtbs54np DJ8z5cyjIBP5J8KAuZTe0JYqzBdKI+gEVRCBUuqU8soSYhNQdl3Ep9HfowhWJYMJuDSd IzsGczjplyLZPxgSJXZ5tBO6LlOifB2wpWtERfT6DuJaGII/HeykC37aBBNF3mB1OxRg PHQA== 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=avCmmXSZ7XUiajW6MhYrMyUXj4W71SGL0EgraUK3p+g=; b=7V+i0Ypapn6abdoZKGFb7DttELaMlL3T0PP/esGtUaFrjgcJUI1Vt/9GTZkCXUIu8S hvkoMKhIraU+L/oGInyIUy6Wiv2xCqJ5nsjJx/CF+genMCGhx0giSry6doDejoRNBio+ ZPXadv4GjGJT14HZpNMhrGHCY32USoKgJD2yyHwHlrXCoRbsYqceQFoyMSS7fJc7mdD9 EC6T1prW8ST1bs2LCmLChdyReoZwiD5/GvsnFD5pLNLmjIi1CNYdSu4g1adaB2RjZ4yq I7uStW6HO5vMRn7BHz6JwbkbWCR3skLS6X2XWc9PstVsethVGtMQDeR6wOcFTiBY9CZ5 6GGw== X-Gm-Message-State: AOAM53116JeVRVUcfHUHk9hDmv2e2Gorn7Qh+SChc16R8IJ2vIvr7RhF a0Y5XnJVD4+6M7hMgsQv4CFKXqc4l3Fq5Qrus2EuQb9B X-Google-Smtp-Source: ABdhPJwE2voIGdnQ30maN4VgHrlyixd3kOgbTi0PDZV5AXCrsjsBx0rRPgN+22Kl8UyPvcgvusy24ikbk2IKdGNjwIA= X-Received: by 2002:a17:906:1ece:b0:6ce:e14:6d92 with SMTP id m14-20020a1709061ece00b006ce0e146d92mr4148458ejj.408.1649173455769; Tue, 05 Apr 2022 08:44:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Qian Li Date: Tue, 5 Apr 2022 23:44:00 +0800 Message-ID: To: Dave Taht Cc: bloat Content-Type: multipart/alternative; boundary="00000000000001132805dbea1e24" X-Mailman-Approved-At: Wed, 06 Apr 2022 04:55:52 -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: Tue, 05 Apr 2022 15:44:17 -0000 --00000000000001132805dbea1e24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 CC that can preserve low priority even when AQM is used. However, I could not test FlexiS with CoDel on the CORE emulator probably because CoDel drops packets at the dequeue time. More tests should be done to verify that FlexiS does preserve low priority in the presence of various AQM algorithms= . 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 proxy 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 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 reduce rate below 2 mss per RTT. This may include what you have suggested -- use small packets and sub-packet window. I am also interested in using pacing to slow down sending rate and maybe more alternative solutions. 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? 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 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 > --00000000000001132805dbea1e24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Dave,

Thank you for your interest= =C2=A0in my work.

I have read another paper author= ed by D. Rossi at el. presenting the priority inversion problem of LEDBAT w= hen it is used together with AQM. And it has become one of the factors that= motivated me to devise a new LBE CC that can preserve low priority even wh= en AQM is used. However, I could not test FlexiS with CoDel on the CORE emu= lator probably because CoDel drops packets at the dequeue time.=C2=A0 More = tests should be done to verify that FlexiS does preserve low priority in th= e presence of various AQM algorithms.

I am now ada= pting FlexiS to the receiver side. The main motivation to do so is that the= re might be HTTP/TCP proxies between the sender and the receiver. A receive= r side LBE CC and make the connection between the proxy and the receiver LB= E. In this work, I am going to tackle some open issues with FlexiS. For exa= mple, I am going to test if trend analysis can be done based on one way del= ay so that the throughput is less affected by ack path congestion. And I am= going to evaluate various techniques to reduce rate below 2 mss per RTT. T= his may include what you have suggested -- use small packets and sub-packet= window. I am also interested in using pacing to slow down sending rate and= maybe more alternative solutions.=C2=A0

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 th= e source code, I can ask the University of Oslo if I am allowed to distribu= te it freely?

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.org/articl= es/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.f= r/drossi/paper/rossi14comnet-b.pdf

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