Re: [tsvwg] QUIC with L4S

[Sebastian Moeller <[e-mail]>]

Hi Christian,

> On Jul 6, 2022, at 00:39, 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.

	[SM] Is this actually fixable? This seems to require an oracle or alternatively a quick side-effect-free method to empirically estimate a given flows immediate path capacity. Then again, current Prague essentially only works reasonably well on short-RTT paths without bottlenecks with plain FIFOs, so the scenarios were L4S signaling has been demonstrated to work (to some degree) will not suffer from too much data in flight, no?

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

	[SM] I thought both legs of an L4S-AQM engage based on sojourn time (either measured directly or estimated from queue size and known egress rate), why does the maximal length of the queue matter here? What AQM are you using?


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