Re: [tsvwg] QUIC with L4S

[Vidhi Goel <[e-mail]>]

Thank you Christian for resuming the work on scalable CC. I have been using picoQUIC as a receiver for my testing and once you merge it to main, I would use it as a sender too.

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

This is the latest - https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-prague-congestion-control-00

All your points are valid and I have noted them.

> 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.

Which AQM are you using on your router? For me setting fixed threshold = 2ms when testing over Ethernet and threshold = 4ms when testing over Wi-Fi worked well.


Vidhi

> On Jul 5, 2022, at 3:39 PM, Christian Huitema <[e-mail]> wrote:
> 
> 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]><mailto:[e-mail]>
>> www.ericsson.com <http://www.ericsson.com/><http://www.ericsson.com/>
>> 
>>   Your're always standing on the shoulders
>>     of something that you've experienced
>>                        May El-Toukhy
>> ===================================