Re: [tcpm] Proceeding CUBIC draft - thoughts and late follow-up

[Markku Kojo <[e-mail]>]

Hi Yoshi,

See below inline.

On Thu, 14 Jul 2022, Yoshifumi Nishida wrote:

> Hi Markku,
> 
> Thanks for the comments. I think we're mostly on the same page for RFC9002. 
> I put some comments on the issue 1 part.
> 
> On Mon, Jul 11, 2022 at 7:54 PM Markku Kojo <[e-mail]> wrote:
>
>       > BTW, my intention is not saying RFC9002 is overly aggressive. I just meant comparing with reno
>       precisely might
>       > not be a very good idea for modern networks. 
>
>       Agreed, it is not overly aggressive.
>
>       I am not saying that CUBIC should be precisely as aggressive as Reno even
>       though its design goal has been to be equally aggressive in the
>       Reno-friendly region.
>
>       Instead, with the issue 1, for example, a CUBIC flow competing with a
>       Reno flow will incorrectly and against its design goal opt out
>       roughly every second cwnd decrease that the Reno flow executes. Doesn't
>       that result in systematic and significant difference in peformance like
>       the measuement results that I've pointed to also confirm?
> 
> I think we'll need more analysis on this point. 
> Let's say a CUBIC connection has 50 packets cwnd and a Reno connection has 51 packets cwnd, the available
> buffer is only 100 packets.
> In this case, I'm not very sure which connection of packets will be dropped hence not sure about the
> consequences.

I am not quite sure what you are looking after here? It does not matter 
what are the cwnd sizes. They may differ. What matters is what happens on 
the RTT when the buffer capacity has been exhausted and a flow (or flows) 
injects an additional packet once cwnd has increased by one full MSS.
For Reno this occurs every RTT but for CUBIC (creno = CUBIC in the 
Reno-friendly region) roughly every second RTT (for simplicity I use here 
Beta = 0.5 for CUBIC). When I say creno opts out (roughly) every second 
cwnd decrease that is true when the flows are synchronized. When they are 
not, things are a bit more complex and I didn't want to go there for 
simplicity and because for that we would need more analysis and 
measurements to learn the exact impact of the incorrect formula.
In addition, we shold not consider only the case of two competing flows 
but any number with different proportion of Reno and creno.
I used the simple two-flow case to illustrate why the model (and formula) 
are incorrect.

Of course also two Reno flows may become desynchronized (and they do in 
real networks) and then their cwnds are not the same each CA cycle but at 
times only one of the flows gets a drop and continues with a smaller 
cwnd. However, this happens randomly to either of the flows and there is 
no systematic bias. And, when it happens the flow with the smaller cwnd 
(statistically) catches up with the larger cwnd in some number of CA 
cycles. creno that increases its cwnd by full MSS only every second RTT 
creates a systematic bias that results in unjustified performance gain 
because of systematically not being candidate for a pkt drop each time 
the buffer becomes full. I must also say that the problem is present in 
full as described in deterministic network environments but it does not 
become negligible when the network does not behave in such deterministic 
way due to varying pkt timings. Nonetheless, we have plenty of 
deterministic enough network environments today and the CC algos must work 
correctly also in these environments.

> I still believe we cannot be sure until we see some deep analysis for this.

The problem is true but the exact impact is unknown indeed.

> This may take time, but I think it's necessary to get the conclusion on this point. 

Whatever the conclusion is, it must not ignore the problem.

Thanks,

/Markku

> --
> Yoshi  
> 
>