[tcpPrague] Re: Reno fallback

[Neal Cardwell <[e-mail]>]

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]> 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]>
> *Sent:* Thursday, July 25, 2024 12:16 AM
> *To:* Szilveszter Nadas <Szilveszter.Nadas=[e-mail]>;
> [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 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]>
>
> *Sent:* den 24 juli 2024 22:34
> *To:* [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]
> To unsubscribe send an email to [e-mail]
>