Re: [tsvwg] QUIC with L4S

[Christian Huitema <[e-mail]>]

Ingemar,

The implementation of Prague in Picoquic that you mentioned was really 
old. I am updating it before checking it in the main branch, and I wrote 
a little blog about it: 
https://huitema.wordpress.com/2022/07/05/a-low-latency-internet-with-l4s/

Is there a new Prague draft? I could only find an obsolete draft from 
2019. Maybe I did not look in the right places.

I found a few issue when doing the implementation:

  * Alpha smoothing does not handle well the sudden onset of congestion. 
My implementation overrides the smoothing if there are sudden onset of 
marks, setting "alpha" to "frac" immediately, instead of using 1/16 
smoothing. Not doing that improves performance, but also causes a sharp 
increase in the number of losses.

* Hysteresis. This is an issue with many  congestion control algorithms. 
When congestion is noticed, it was caused by the CWIND set 2 RTT before 
the notification -- the packets sent in the last RTT are still in 
flight. This is mitigated in Reno by not acting on losses of packets 
sent before entering recovery. In Prague, ECN marks triggered by these 
packets do increase the ECN counters, which means alpha increases and we 
get an extra round of CWIND reduction 1 RTT after the first one.

* Restart after idle. In my tests, I simulate a suggestion of "GET 1MB", 
each one starting after the previous is service. That means the sender 
is idle for 1RTT. On restart, the sender starts with a large CWIND, 
sends a lot of packets, which causes a bump in latency and a large 
number of ECN marks. Maybe that's linked to my implementation of pacing 
using a leaky bucket, and the leaky bucket is too large. I will try fix 
that, but I suspect the draft should say something about resuming from idle.

We may also need to do some work on "slow start". My implementation 
exist slow start on first ECN-CE mark, but at that point there is a full 
flight of packets in transit, which is going to cause either packet 
losses or spikes in latency.

I also had to try a couple of different settings for the threshold value 
used in the simulation. Too low, and the throughput drops. Too high, and 
the amount of losses increases too much. In the tests, the router has a 
queue size of 1 BDP, and setting the threshold to BDP/4 appears to work 
well.

I am going to test more scenarios, such as starting with a high 
bandwidth and simulating a rapid decrease, or vice versa. Also, testing 
what happens with higher bandwidth and RTT. And looking at ways to plug 
the Prague concepts in BBR, possibly as a way to replace the "scan for 
min RTT" phases of BBR. In any case, the initial results seem encouraging.

-- Christian Huitema

On 6/28/2022 1:02 AM, Ingemar Johansson S wrote:
> And to clarify, as indicated by the subject line. QUIC with L4S support
>
> /Ingemar
>
> From: Ingemar Johansson S <[e-mail]>
> Sent: Tuesday, 28 June 2022 09:47
> To: [e-mail]
> Cc: Ingemar Johansson S <[e-mail]>
> Subject: QUIC with L4S
>
> Hi
>
> A fairly short question.
> What QUIC implementations, open source and well as propietary exist today.
> I know of the following
> + Apples implementation, presented by Vihdi Goel
> + Pico-quic with Prague maintained/presented by Bob, Koen and others ( https://github.com/qdeconinck/picoquic/tree/quic-prague  )
>
> Are there any other examples available ?
>
> Regards
> /Ingemar
> ==================================
> Ingemar Johansson  M.Sc.
> Master Researcher
>
> Ericsson AB
> GFTL ER Networks RNS Protocol & E2E Perf
> Labratoriegränd 11
> 977 53, Luleå, Sweden
> Phone [phone]
> SMS/MMS [phone]
> [e-mail]<mailto:[e-mail]>
> www.ericsson.com<http://www.ericsson.com/>
>
>    Your're always standing on the shoulders
>      of something that you've experienced
>                         May El-Toukhy
> ===================================
>