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

[Yoshifumi Nishida <[e-mail]>]

Hi Markku,

Sorry for not being very clear.
What I meant was even though Reno increases cwnd every RTT and Cubic
increases it every other RTT (which can indicate the presumption of the
model is not very accurate), I think it doesn't necessarily mean Reno has
higher packet loss rate than Cubic.
They might not be equal, but the gaps might not be that big. Well, I'm not
sure at this point.

So, while I agree this should not be required, I still believe we'll need
more analysis on this.
I think it'll be difficult to think about the best way to fix it until we
understand the details of the issue
--
Yoshi

On Tue, Jul 19, 2022 at 4:56 PM Markku Kojo <[e-mail]> wrote:

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