Re: [tcpm] alpha_cubic

[Bob Briscoe <[e-mail]>]

Neal, [re-sending with trimmed message body - too big for ML]

On 23/09/2021 22:46, Neal Cardwell wrote:
>
>
> On Thu, Sep 23, 2021 at 1:16 PM Bob Briscoe <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Yoshi,
>
>     To summarize the main concern I already wrote in my first email
>     (but perhaps didn't summarize well): the formula assumes
>     deterministic marking (i.e. some but not all AQMs, and definitely
>     not drop-tail). I believe a large majority of the bottleneck
>     buffers on the Internet are still drop tail, despite the efforts
>     of many to recommend AQM deployment. So it's not particularly
>     applicable to the real Internet.
>
>     It also assumes the sawteeth of flows with different RTTs all
>     centre on an operating point around the middle of the sawteeth,
>     which is perhaps true of RED, but not most other AQMs.
>
>     I will still try to develop a better formula - I've thought how to
>     do it in principle, but haven't developed the maths for it - it's
>     hard. But pls don't wait for me. The Cubic RFC's good enough, and
>     the precise value of the Reno-Friendly alpha parameter is fairly
>     irrelevant given the most prevalent deployment (Linux) ignores the
>     RFC and sets it much more aggressively to 1 instead of 0.53 anyway.
>
>
> Hi Bob,
>
> Can you please elaborate on the characterization of Linux TCP CUBIC as 
> using an alpha of 1 instead of 0.53?
>
> My experience in reading the Linux TCP CUBIC code and testing it and 
> examining its packet-by-packet behavior in congestion avoidance is 
> that it uses the 0.53 value.
>
> This is implemented in the code here:
> https://elixir.bootlin.com/linux/v5.14/source/net/ipv4/tcp_cubic.c#L297 
> <https://elixir.bootlin.com/linux/v5.14/source/net/ipv4/tcp_cubic.c#L297>
>
> Note that we have:
>   beta_scale = 15
> So the computation of:
>   delta = (cwnd * scale) >> 3;
> means:
>   delta = (cwnd * 15) >> 3;
> That means basically delta is:
>     cwnd * 15/8
>
> That means, for example, for a cwnd of 100, the number of packets that 
> need to be ACKed before increasing cwnd is:
>   100 * 15/8 = 187.5
>
> Since 187.5 is 1.875x the cwnd, the rate of cwnd increase is  1 packet 
> / 1.875 rounds, or  .533 packets per 1 round .
>
> So AFAICT this is implementing the correct 0.53 value you mention.

[BB] OMG. I've been labouring under this misapprehension for years. I 
just believed what someone told me about the Linux code because I 
trusted them, without ever checking it.

>
> Where Linux TCP CUBIC Reno-emulation additive increase is not ideal is 
> that once cwnd reaches W_max, it does not return the additive increase 
> to 1, in order to match Reno for long-term cwnd growth. I have a patch 
> series with that and a few related fixes that I am trying to find time 
> to polish up and send upstream.

[BB] Yes, that would be useful to fix.

>
> Apologies if I'm missing something or off in the weeds. :-)

[BB] No, mea culpa. I'm the one in the weeds.

So it matters even more whether 0.53 is really the correct value.


Thank you.


Bob

> best regards,
> neal
>
>
>
>     Bob
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/