Re: [Bloat] less than best effort: TCP - flexis - A New Approach To Incipient Congestion Detection and Control

[Qian Li <biz.tinalee@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3251 bytes --]

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 <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/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=time. 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=https%3A%2F%2Fwww.icei.org
>
> Dave Täht CEO, TekLibre, LLC
>

[-- Attachment #2: Type: text/html, Size: 4212 bytes --]