[tcpPrague] Re: Reno fallback

[Szilveszter Nadas <[e-mail]>]

I like this argument, it makes sense.

I was also wondering about why slow start was that slower for Prague ( see slide 3 in https://datatracker.ietf.org/meeting/120/materials/slides-120-anrw-7-1406-1428-to-switch-or-not-to-switch-to-l4s-incentives-for-adopting-l4s-in-a-partial-deployment-f-paper25-slides ), but with this argument it makes sense.

Was slow start like this for DCTCP already?
Do you have improvements in mind for this? (Maybe is some of the discussion in this thread is also applicable for slow start?)

Sz.

From: Koen De Schepper (Nokia) <[e-mail]>
Sent: Thursday, July 25, 2024 10:49
To: Neal Cardwell <ncardwell=[e-mail]>
Cc: Anna Brunström <[e-mail]>; Szilveszter Nadas <[e-mail]>; [e-mail]
Subject: RE: [tcpPrague] Re: Reno fallback

Yes, this is also considered still. As far as I remembered, it is still not such a big improvement for the bigger RTTs, if you want to keep the overshoot around a few ms’s. Trying faster will create a bigger overshoot and latency spike. Even Cubic on loss can increase up to doubling per RTT (like slow start). We were also thinking on increasing the pacing in the first halve of a window and decreasing it in the second half, to get sooner marks. We do this already during congestion avoidance (+3% / -3%), to get marks every RTT. This improves fairness (removes the on/off behaviour of full RTT marks which is rather 1/p² instead of 1/p). For slow start it might give marks earlier and limit the overshoot.

Anyway, L4S can be used next to classic. If you want to get fast up to speed, then use classic as it will buffer, if you want low latency you need to be more careful and use Prague. I don’t believe in Prague being good in everything (although it can get better still), it is better to know which side of the compromise you can take (L4S=lowest latency or Classic=highest throughput), instead of trying to settle somewhere in the middle, disappointing both type of use-cases. An app can open both type of connections and use them as appropriate for the content if useful.

Koen.

From: Neal Cardwell <ncardwell=[e-mail]<mailto:ncardwell=[e-mail]>>
Sent: Thursday, July 25, 2024 7:12 PM
To: Koen De Schepper (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: Anna Brunström <[e-mail]<mailto:[e-mail]>>; Szilveszter Nadas <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [tcpPrague] Re: Reno fallback


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


I'm still a little concerned about this strategy of "Cubic after a loss and Prague after a mark". "Cubic after a loss" sounds fine. But a pure "Prague after a mark" strategy seems like it would imply that when bandwidth frees up (e.g., some L4S flow departs the bottleneck) it will take a long (Reno-time-scale) period of time for the flow to fully utilize the bandwidth.

For example, AFAICT for a 1Gbps bottleneck w/ RTT of 40ms, if there initially are 2 Prague flows and then one flow stops, then (due to the slow Reno-style cwnd growth) it will take the remaining flow about 2.75 minutes (165 secs) for the remaining flow to reach full utilization:

BDP/2 * RTT =
 = (1Gbps * 40ms / 1514 bytes / 2) * 100ms
 = 10^9 * .040 / (1514*8) / 2 * .1 sec
 = 165 sec

I'd imagine users will not be happy with that Reno-scale performance, and sites will not want to deploy Prague with that kind of performance.

AFAICT it makes sense to come up with some strategy for faster-than-Reno cwnd growth if the time since the last ECN mark is quite "long".

One approach would be to simply always use CUBIC growth, since CUBIC growth is very similar to Reno growth at low BDPs, and is faster than Reno at large BDPs.

IIRC Bob Briscoe had an alternative proposal that involved increasing cwnd based on a delay target and the current effective throughput, increasing the cwnd by something like target_delay*current_throughput if it's been a long time since the last ECN mark. That seems like a nice improvement as well.

neal




On Wed, Jul 24, 2024 at 10:18 PM Koen De Schepper (Nokia) <koen.de_schepper=[e-mail]<mailto:[e-mail]>> wrote:
Hi all,

We plan to fall back to Cubic, just like Apple QUIC is doing, but still todo for Linux. The goal is “to fall back” and not to use Cubic during marks, as this would completely make Prague behave different. Apple’s QUIC does Cubic after a loss and does Prague after a mark. So if marks take over you are back at the link capacity, when loss occurs, you usually loose the marks as you backed off too much. So faster recovery with cubic gives you again marks.

If people have code to do this, we are happy to take it in the L4STeam git, and include it in the upstream.

Regards,
Koen.

From: Anna Brunström <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, July 25, 2024 12:16 AM
To: Szilveszter Nadas <Szilveszter.Nadas=[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [tcpPrague] Re: Reno fallback


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information.


Hi,

As a data point connected to Szilveszter’s question, we have been running some Prague experiments over 5G.  We have seen that when there is packet loss Pargue performs significantly worse than Cubic.

Cheers,
Anna

From: Szilveszter Nadas <Szilveszter.Nadas=[e-mail]<mailto:Szilveszter.Nadas=[e-mail]>>
Sent: den 24 juli 2024 22:34
To: [e-mail]<mailto:[e-mail]>
Subject: [tcpPrague] Reno fallback

Hi,

I asked this question at ANRW yesterday, and would like to repeat this here:

-Why Prague is based on Reno, and uses Reno for loss response, as opposed to Cubic?
--Is it just historic reason, as DCTCP is also based on Reno?
--Is there any fundamental issues to base it on Cubic?
--Is there a Prague or Prague-like CC based on Cubic? I heard rumors about Apple having such a CC implementation.

I think it would be important to use Cubic, because Prague is supposed to work well in environments, where the congestion signal is loss, and Cubic is more efficient in those cases.

Cheers,
Szilveszter

När du skickar e-post till Karlstads universitet behandlar vi dina personuppgifter<https://www.kau.se/gdpr>.
When you send an e-mail to Karlstad University, we will process your personal data<https://www.kau.se/en/gdpr>.
_______________________________________________
tcpPrague mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>