Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ?

From: Lisong Xu <[email-masked]>
Date: Tue, 15 Mar 2016 22:30:43 -0500

On 3/15/2016 3:19 AM, Karen Elisabeth Egede Nielsen wrote:
>
> Hi Lisong, Neal, All,
>
> I understand the basic principle of the TCP friendliness function and 
> I have no problem
>
> with having the window follow TCP New Reno when the CUBIC algorithm 
> would return a smaller value.
>
> I.e., following section 1 of the draft:
>
> When the cubic
>
>    function grows slower than the window of Standard TCP, CUBIC simply
>
>    follows the window size of Standard TCP to ensure fairness to
>
>    Standard TCP in a small BDP network.
>
> With the disclaimer that I have not studied reference [FHP00] I have, 
> however, a problem understanding how this is achieved
>
> with formula (Eq. 4) of section 3.2 of draft-ietf-tcpm-cubic-01.
>
> From whatever in [FDP00] one get that the average window of AIMD TCP CC is
>
>        AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) /
>
>           (2*(1-beta_aimd)*p) ]^0.5          (eq. 3)
>
> which with alpha = 1 and beta = 0,5 indeed yields AVG_W_Newreno = 
> (1.5/p)^0.5.(Good otherwise we were in trouble).
> One can further observe from (3), of course,  that generally for AIMD 
> CC with  alpha equal to
>
>    3*(1-beta)/(1+beta) then one get the same average window as of 
> NewReno TCP.  But how does it follow that
>
> W_aimd(t) = W_max*beta_aimd +
>
> [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4)
>
> is a reasonable estimate for the window of standard TCP CC as quoted 
> as being the intention in section 1 ?
>

We can prove that Eq (4) has the same average window size as a reno flow.

> QUESTION:
>
> Is (Eq. 4) the best implementation choice for comparison with TCP New 
> Reno that were manageable from an implementation perspective or is (Eq 
> 4) the rule that a CUBIC implementation
>
> should aim to follow ? I.e., that the Linux TCP implementation aims to 
> follow ?
>
> In the latter case, then I think one should probably use the following 
> formulation in Section 1:
>
> When the cubic
>
>    function grows slower than the window of standard AIMD CC, CUBIC simply
>
>    follows the window size of standard AIMD CC to ensure fairness to
>
>    Standard TCP in a small BDP network.
>
> And then probably relate to that the fairness comes (?) from 
> calibration towards same average window - - -
>

There are two methods to get the average window size of a reno flow.

1. simulate a reno flow for each ack and each packet. but this method 
requires more variables and more code to simulate reno.

2. use Eq (4) to directly calculate the average window size of a reno 
flow. this method is much simpler than the first method, because it does 
not need to simulate a reno flow. this is what Cubic does.

Lisong

> Thanks !
>
> BR, Karen
>
> *******************************************************************************************
>
> *Karen Egede Nielsen*
>
> Software Architect, Ph.D.
>
> *Tieto Denmark A/S*
>
> R&D, Telecom & Media
>
> Åhave Parkvej, 8260 Viby J, DK-Denmark
>
> Direct Phone / Mobile +45 25134336
>
> E-mail: [email-masked] <mailto:[email-masked]>
>
> *****************************************************************************************
>
> www.tieto.com <http://www.tieto.com>
>
> //
>
> /Please note: The information contained in this message may be legally 
> privileged and confidential and protected from disclosure. If the 
> reader of this message is not the intended recipient, you are hereby 
> notified that any unauthorised use, distribution or copying of this 
> communication is strictly prohibited. If you have received this 
> communication in error, please notify us immediately by replying to 
> the message and deleting it from your computer. Thank You./
>

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 16 Mar 2016 09:10:39 +0100

HI Lisong,

Thanks.

Please see below.

BR, Karen

*From:* Lisong Xu [mailto:[email-masked]]
*Sent:* 16. marts 2016 04:31
*To:* Karen Elisabeth Egede Nielsen <[email-masked]>;
[email-masked]
*Cc:* [email-masked]
*Subject:* Re: TCP friendly formulation in CUBIC-draft ?

Hi Lisong, Neal, All,

I understand the basic principle of the TCP friendliness function and I
have no problem

with having the window follow TCP New Reno when the CUBIC algorithm would
return a smaller value.

When the cubic

which with alpha = 1 and beta = 0,5 indeed yields AVG_W_Newreno =
(1.5/p)^0.5. (Good otherwise we were in trouble).

   3*(1-beta)/(1+beta) then one get the same average window as of NewReno
TCP.  But how does it follow that

is a reasonable estimate for the window of standard TCP CC as quoted as
being the intention in section 1 ?

*[Karen Elisabeth Egede Nielsen] Sure – I don’t doubt that.*

QUESTION:

Is (Eq. 4) the best implementation choice for comparison with TCP New Reno
that were manageable from an implementation perspective or is (Eq 4) the
rule that a CUBIC implementation

When the cubic

And then probably relate to that the fairness comes (?) from calibration
towards same average window - - -

2. use Eq (4) to directly calculate the average window size of a reno flow.
this method is much simpler than the first method, because it does not need
to simulate a reno flow. this is what Cubic does.

*[Karen Elisabeth Egede Nielsen] You don’t use (Eq 4) to calculate the
average window. You use eq 4 – you say - because this algorithm gives the
same average window as New Reno and therefore you say it is a valid
approach.*

*From an implementation perspective I am not sure there is so much
difference, there is one namely the ramp down at FR, but otherwise they
need to do the same, just with a different alpha (the beta_scale in Linux.
Both needs to take care of underutilization. *

*[Karen Elisabeth Egede Nielsen] Yes – my question was whether you wanted
1, but were doing 2  because of ease of implementation, or whether you from
a model perspective wanted to do 2.*

*What I hear you saying is that you want 1, but is doing 2.*

*1 and 2 are really two different things – at least from a theoretical
perspective. Especially as you only use the calculation on a fraction of
the domain only. *

*I think it should be obvious that 2 can give a higher CWND just after FR,
but also that the difference goes away over time (at which point CUBIC then
likely uses the CUBIC graph **J**).*

*On the other hand Eg 4 may be more modest generally – e.g. when increasing
from a non-validated window. Just thinking out load.*

*Have you experimented with to which extend 2 _significantly_ differs from
1 – especially in conjunction with CUBIC ?*

*I am not saying even that 2 is not the ideal approach – but it need some
more persuading to tell that it models New Reno well in the way it is being
used.*

*[Karen Elisabeth Egede Nielsen] It had actually been simpler (I think) if
the argument was that you wanted 2 and then argue for why this is
reasonable fair with New Reno.*

*As said before, we are defining this for SCTP – let’s see  - we may
experiment with both 1 and 2. *

*I have not understood (not tried to understand) what kind of validation
TCP Linux is running with when the cwnd is underutilized (not cwnd
limited). In SCTP there is no cwnd increase during*

*cwnd underutilization, but not any cwnd decaying either. This may give a
difference in the overall resulting behavior of course.*

Many Thanks.

Lisong

Thanks !

BR, Karen

*Karen Egede **N**ielsen*

*Tieto Denmark A/S*

R&D, Telecom & Media

E-mail: [email-masked]

www.tieto.com

*Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the reader of
this message is not the intended recipient, you are hereby notified that
any unauthorised use, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and deleting it
from your computer. Thank You.*

---

From: Lisong Xu <[email-masked]>
Date: Fri, 18 Mar 2016 23:07:22 -0500

Hi Karen,

What we want is to make sure that the average window size is not less 
than that of reno.  We do not need the instantaneous reno window size in 
each rtt, and thus what we want is not exactly (1). Both (1) and (2) can 
be used to achieve what we want. But (2) is simpler to implement, 
because (2) only considers the cwnd increase function whereas (1) must 
consider both the cwnd increase function and the cwnd decrease function 
(i.e., beta).

Have a good weekend!
Lisong

On 3/16/2016 3:10 AM, Karen Elisabeth Egede Nielsen wrote:
>
> HI Lisong,
>
> Thanks.
>
> Please see below.
>
> BR, Karen
>
> *From:*Lisong Xu [mailto:[email-masked] <mailto:[email-masked]>]
> *To:* Karen Elisabeth Egede Nielsen <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
>     I understand the basic principle of the TCP friendliness function
>     and I have no problem
>
>     with having the window follow TCP New Reno when the CUBIC
>     algorithm would return a smaller value.
>
>     With the disclaimer that I have not studied reference [FHP00] I
>     have, however, a problem understanding how this is achieved
>
>     One can further observe from (3), of course,  that generally for
>     AIMD CC with  alpha equal to
>
>     is a reasonable estimate for the window of standard TCP CC as
>     quoted as being the intention in section 1 ?
>
>
> */[Karen Elisabeth Egede Nielsen] Sure – I don’t doubt that.
>
> /*
>
>     QUESTION:
>
>     Is (Eq. 4) the best implementation choice for comparison with TCP
>     New Reno that were manageable from an implementation perspective
>     or is (Eq 4) the rule that a CUBIC implementation
>
>     should aim to follow ? I.e., that the Linux TCP implementation
>     aims to follow ?
>
>     In the latter case, then I think one should probably use the
>     following formulation in Section 1:
>
>     When the cubic
>
> flow. this method is much simpler than the first method, because it 
> does not need to simulate a reno flow. this is what Cubic does.
>
> *//*
>
> */[Karen Elisabeth Egede Nielsen] You don’t use (Eq 4) to calculate 
> the average window. You use eq 4 – you say - because this algorithm 
> gives the same average window as New Reno and therefore you say it is 
> a valid approach./*
>
> *//*
>
> */From an implementation perspective I am not sure there is so much 
> difference, there is one namely the ramp down at FR, but otherwise 
> they need to do the same, just with a different alpha (the beta_scale 
> in Linux. Both needs to take care of underutilization. /*
>
> *//*
>
> */[Karen Elisabeth Egede Nielsen] Yes – my question was whether you 
> wanted 1, but were doing 2  because of ease of implementation, or 
> whether you from a model perspective wanted to do 2./*
>
> */What I hear you saying is that you want 1, but is doing 2./*
>
> *//*
>
> */1 and 2 are really two different things – at least from a 
> theoretical perspective. Especially as you only use the calculation on 
> a fraction of the domain only. /*
>
> *//*
>
> */I think it should be obvious that 2 can give a higher CWND just 
> after FR, but also that the difference goes away over time (at which 
> point CUBIC then likely uses the CUBIC graph /**/J/**/)./*
>
> */On the other hand Eg 4 may be more modest generally – e.g. when 
> increasing from a non-validated window. Just thinking out load./*
>
> *//*
>
> */Have you experimented with to which extend 2 _significantly_ differs 
> from 1 – especially in conjunction with CUBIC ?/*
>
> *//*
>
> */I am not saying even that 2 is not the ideal approach – but it need 
> some more persuading to tell that it models New Reno well in the way 
> it is being used./*
>
> */[Karen Elisabeth Egede Nielsen] It had actually been simpler (I 
> think) if the argument was that you wanted 2 and then argue for why 
> this is reasonable fair with New Reno./*
>
> *//*
>
> */As said before, we are defining this for SCTP – let’s see  - we may 
> experiment with both 1 and 2. /*
>
> */I have not understood (not tried to understand) what kind of 
> validation TCP Linux is running with when the cwnd is underutilized 
> (not cwnd limited). In SCTP there is no cwnd increase during/*
>
> */cwnd underutilization, but not any cwnd decaying either. This may 
> give a difference in the overall resulting behavior of course./*
>
> Many Thanks.
>
> Lisong
>
>
>     Thanks !
>
>     BR, Karen
>
>     /Please note: The information contained in this message may be
>     legally privileged and confidential and protected from disclosure.
>     If the reader of this message is not the intended recipient, you
>     are hereby notified that any unauthorised use, distribution or
>     copying of this communication is strictly prohibited. If you have
>     received this communication in error, please notify us immediately
>     by replying to the message and deleting it from your computer.
>     Thank You./
>

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 21 Mar 2016 08:28:49 +0100

Hi Lisong,

I am not opposed to what you’re doing. Just to make that absolutely clear !

I also think that you achieve a larger average than Reno, which is part of
what you want for the RTT fairness generally of CUBIC.

I don’t understand _*your argumentation*_ for the TCP friendliness function
though.  Again I am not (necessarily) opposed to the function itself,
whether (1) or (2).

It is the argumentation which isn’t clear.

You take two functions (1) and (2) that have the same average (integral)
over a large domain and then apply them on _*a subset of subset of the
domain*_

and CUBIC in another subset of the domain.

Have you proven that (1) and (2) have the same average in the subset of the
domain where they are applied (i.e. away from where CUBIC is applied).
Otherwise please change your argumentation to

Better reflect exactly what you’re doing.

Thanks.

BR, Karen

*Sent:* 19. marts 2016 05:07

Hi Karen,

What we want is to make sure that the average window size is not less than
that of reno.  We do not need the instantaneous reno window size in each
rtt, and thus what we want is not exactly (1). Both (1) and (2) can be used
to achieve what we want. But (2) is simpler to implement, because (2) only
considers the cwnd increase function whereas (1) must consider both the
cwnd increase function and the cwnd decrease function (i.e., beta).

Have a good weekend!
Lisong

HI Lisong,

Thanks.

Please see below.

BR, Karen

Hi Lisong, Neal, All,

When the cubic

QUESTION:

When the cubic

Many Thanks.

Lisong

Thanks !

BR, Karen

*Tieto Denmark A/S*

R&D, Telecom & Media

www.tieto.com

---

From: Lisong Xu <[email-masked]>
Date: Tue, 29 Mar 2016 12:23:31 -0500

Hello Karen,

Sorry for the late reply. I see your questions now. You are right. Our 
goal is not to very accurately estimate the window size of reno, and we 
did not rigorously prove that our implementation has the same average as 
reno even in a short interval.

Thanks
Lisong

On 3/21/2016 2:28 AM, Karen Elisabeth Egede Nielsen wrote:
> I also think that you achieve a larger average than Reno, which is 
> part of what you want for the RTT fairness generally of CUBIC.
>
> I don’t understand _/your argumentation/_ for the TCP friendliness 
> function though.  Again I am not (necessarily) opposed to the function 
> itself, whether (1) or (2).
>
> You take two functions (1) and (2) that have the same average 
> (integral) over a large domain and then apply them on _/a subset of 
> subset of the domain/_
>
> Have you proven that (1) and (2) have the same average in the subset 
> of the domain where they are applied (i.e. away from where CUBIC is 
> applied). Otherwise please change your argumentation to
>
> than that of reno.  We do not need the instantaneous reno window size 
> in each rtt, and thus what we want is not exactly (1). Both (1) and 
> (2) can be used to achieve what we want. But (2) is simpler to 
> implement, because (2) only considers the cwnd increase function 
> whereas (1) must consider both the cwnd increase function and the cwnd 
> decrease function (i.e., beta).
>
> Have a good weekend!
> Lisong
>
>         I understand the basic principle of the TCP friendliness
>         function and I have no problem
>
>         With the disclaimer that I have not studied reference [FHP00]
>         I have, however, a problem understanding how this is achieved
>
>         which with alpha = 1 and beta = 0,5 indeed yields
>         AVG_W_Newreno = (1.5/p)^0.5.(Good otherwise we were in trouble).
>
>         One can further observe from (3), of course,  that generally
>         for AIMD CC with  alpha equal to
>
>            3*(1-beta)/(1+beta) then one get the same average window as
>         of NewReno TCP.  But how does it follow that
>
>     */[Karen Elisabeth Egede Nielsen] Sure – I don’t doubt that./*
>
>         QUESTION:
>
>         Is (Eq. 4) the best implementation choice for comparison with
>         TCP New Reno that were manageable from an implementation
>         perspective or is (Eq 4) the rule that a CUBIC implementation
>
>     1. simulate a reno flow for each ack and each packet. but this
>     method requires more variables and more code to simulate reno.
>
>     2. use Eq (4) to directly calculate the average window size of a
>     reno flow. this method is much simpler than the first method,
>     because it does not need to simulate a reno flow. this is what
>     Cubic does.
>
>     *//*
>
>     */[Karen Elisabeth Egede Nielsen] You don’t use (Eq 4) to
>     calculate the average window. You use eq 4 – you say - because
>     this algorithm gives the same average window as New Reno and
>     therefore you say it is a valid approach./*
>
>     *//*
>
>     */From an implementation perspective I am not sure there is so
>     much difference, there is one namely the ramp down at FR, but
>     otherwise they need to do the same, just with a different alpha
>     (the beta_scale in Linux. Both needs to take care of
>     underutilization. /*
>
>     *//*
>
>     */[Karen Elisabeth Egede Nielsen] Yes – my question was whether
>     you wanted 1, but were doing 2  because of ease of implementation,
>     or whether you from a model perspective wanted to do 2./*
>
>     theoretical perspective. Especially as you only use the
>     calculation on a fraction of the domain only. /*
>
>     *//*
>
>     after FR, but also that the difference goes away over time (at
>     which point CUBIC then likely uses the CUBIC graph /**/J/**/)./*
>
>     */Have you experimented with to which extend 2 _significantly_
>     differs from 1 – especially in conjunction with CUBIC ?/*
>
>     *//*
>
>     */I am not saying even that 2 is not the ideal approach – but it
>     need some more persuading to tell that it models New Reno well in
>     the way it is being used./*
>
>     think) if the argument was that you wanted 2 and then argue for
>     why this is reasonable fair with New Reno./*
>
>     *//*
>
>     */As said before, we are defining this for SCTP – let’s see  - we
>     may experiment with both 1 and 2. /*
>
>     validation TCP Linux is running with when the cwnd is
>     underutilized (not cwnd limited). In SCTP there is no cwnd
>     increase during/*
>
>     */cwnd underutilization, but not any cwnd decaying either. This
>     may give a difference in the overall resulting behavior of course./*
>
>     Many Thanks.
>
>     Lisong
>
>         Thanks !
>
>         BR, Karen
>
>         legally privileged and confidential and protected from
>         disclosure. If the reader of this message is not the intended
>         recipient, you are hereby notified that any unauthorised use,
>         distribution or copying of this communication is strictly
>         prohibited. If you have received this communication in error,
>         please notify us immediately by replying to the message and
>         deleting it from your computer. Thank You./
>

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 30 Mar 2016 10:47:04 +0200

HI Lisong,

Thank you.

Thanks a lot for your support in understanding the function !

I am happy that we seem to have reached a common understanding.

So what we have is an argumentation of the TCP friendliness function which
follows

(1): Make CUBIC CWND be no less than what TCP New Reno would give

And an implementation of CUBIC TCP friendliness function which does:

(2): Make CUBIC CWND be no less than what AIMD( 3*(1-beta)/(1+beta) ,
beta ) would
give

I think that it is substantially more straightforward to make a theoretical
argumentation for why (1) is the right thing to do, than for why (2) is an
appropriate thing to do.

The theoretical arguments for (1) is in the CUBIC draft and in the CUBIC
papers.

Not knowing so much about this from a general research perspective, I
wonder if there exists theoretical evidence

for why (2) is appropriate or proper in respect of the argumentation of
“TCP friendliness”.

But also if one have a good understanding of the actual difference in
between (1) and (2), then this may serve as input for such an argumentation.

Finally of course then safe deployment of (2)/CUBIC is another way to back
the appropriateness of the function.

BR, Karen

*Sent:* 29. marts 2016 19:24

Hello Karen,

Sorry for the late reply. I see your questions now. You are right. Our goal
is not to very accurately estimate the window size of reno, and we did not
rigorously prove that our implementation has the same average as reno even
in a short interval.

Thanks
Lisong

Hi Lisong,

Thanks.

BR, Karen

Hi Karen,

Have a good weekend!
Lisong

HI Lisong,

Thanks.

Please see below.

BR, Karen

Hi Lisong, Neal, All,

When the cubic

QUESTION:

When the cubic

Many Thanks.

Lisong

Thanks !

BR, Karen

*Tieto Denmark A/S*

R&D, Telecom & Media

www.tieto.com

---

From: Lisong Xu <[email-masked]>
Date: Wed, 30 Mar 2016 09:15:43 -0500

Hi Karen,

I guess I need to clarify that the code segment that we were discussing 
is only part of the "TCP friendliness".

There are two parts of TCP friendliness.

1) make sure that CUBIC does not starve Reno in high BDP (bandwidth 
delay product) networks, and achieves a similar rate as Reno in low BDP 
networks.  This is achieved mainly by the parameters of CUBIC. This is 
the typical and more important "meaning" of TCP friendliness.

2) make sure that CUBIC average rate is never lower than Reno in any 
networks.

What we were discussing is only about part 2).

Thanks
Lisong

On 3/30/2016 3:47 AM, Karen Elisabeth Egede Nielsen wrote:
> between (1) and (2), then this may serve as input for such an argumentation

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 30 Mar 2016 16:49:46 +0200

Hi Lisong,

Yes I understand that we are not speaking part 1). We are speaking the CUBIC
operation in TCP Friendly region only

As far as I have understood the argumentation behind 2) you are making sure
that CUBIC CWND is never lower than TCP Reno CWND.
But perhaps this has been a misunderstanding and you aim instead - as you
say right below -  is to make sure that the _average_ CUBIC window is not
lower than Reno ?
Either way the theoretical argumentation based on average window of AIMD
alone does not hold, but empirics may tell that it is ok.

Please note that I am not trying to "kill" CUBIC at all. On the contrary we
are working to implement the algorithm. But still we want to make sure to
understand the aims right.

BR, Karen

> -----Original Message-----
> From: Lisong Xu [mailto:[email-masked]]
> Sent: 30. marts 2016 16:16
> To: Karen Elisabeth Egede Nielsen <[email-masked]>; draft-ietf-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: TCP friendly formulation in CUBIC-draft ?
>
> Hi Karen,
>
> I guess I need to clarify that the code segment that we were discussing is
> only part of the "TCP friendliness".
>
> 1) make sure that CUBIC does not starve Reno in high BDP (bandwidth delay
> product) networks, and achieves a similar rate as Reno in low BDP
> networks.
> This is achieved mainly by the parameters of CUBIC. This is the typical
> and
> more important "meaning" of TCP friendliness.
>
> > So what we have is an argumentation of the TCP friendliness function
> > which follows
> >
> > beta ) would give
> > I think that it is substantially more straightforward to make a
> > theoretical argumentation for why (1) is the right thing to do, than
> > for why (2) is an appropriate thing to do.
> >
> > The theoretical arguments for (1) is in the CUBIC draft and in the
> > CUBIC papers.
> >
> >
> >
> > for why (2) is appropriate or proper in respect of the argumentation
> > of “TCP friendliness”.
> >

---

From: Lisong Xu <[email-masked]>
Date: Wed, 30 Mar 2016 10:02:04 -0500

Hi Karen,

The equivalence between (alpha=1, beta=0.5) and 
(alpha=3*(1-beta)/(1+beta), beta) is explained in the following paper. 
Equation (9).

http://www.icir.org/tfrc/aimd.pdf

Thanks
Lisong

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 31 Mar 2016 12:50:50 +0200

Hi Lisong,

Many thanks.

This is still average considerations and the carryover of the argument to
the TCP friendly sub-domain of CUBIC
does not follow straightaway.

I would suggest, in section 3.2 of the CUBIBC draft,  not to make something
that looks like a mathematical argument for that
AIMD(3*(1-beta)/(1+beta), beta) is a good approximation for TCP New Reno in
the TCP friendly region. But rather refer to that based on the
evaluations of [FHP00], showing the general approximation (and fairness) of
AIMD(3*(1-beta)/(1+beta), beta) compared to TCP New Reno,
this AIMD profile is used to define the TCP Friendly region and this profile
is used as a replacement of the CUBIC window in this region.
In whatever way you want to formulate this...

But I will stop pressing this point. Thanks for the patience ! :-)

BR, Karen

> Sent: 30. marts 2016 17:02
> The equivalence between (alpha=1, beta=0.5) and (alpha=
 is explained in the following paper.
> > Yes I understand that we are not speaking part 1). We are speaking the
> > CUBIC operation in TCP Friendly region only
> >
> > As far as I have understood the argumentation behind 2) you are making
> > sure that CUBIC CWND is never lower than TCP Reno CWND.
> > But perhaps this has been a misunderstanding and you aim instead - as
> > you say right below -  is to make sure that the _average_ CUBIC window
> > is not lower than Reno ?
> > Either way the theoretical argumentation based on average window of
> > AIMD alone does not hold, but empirics may tell that it is ok.
> >
> > Please note that I am not trying to "kill" CUBIC at all. On the
> > contrary we are working to implement the algorithm. But still we want
> > to make sure to understand the aims right.
> >
> > BR, Karen
> >
> >> To: Karen Elisabeth Egede Nielsen <[email-masked]>;
> >> draft-ietf- [email-masked]
> >> Cc: [email-masked]
> >> I guess I need to clarify that the code segment that we were
> >> discussing is only part of the "TCP friendliness".
> >>
> >> delay
> >> This is achieved mainly by the parameters of CUBIC. This is the
> >> typical and more important "meaning" of TCP friendliness.
> >>
> >>> (2): Make CUBIC CWND be no less than what AIMD( 3*(1-beta)/(1+beta)
> >>> , beta ) would give
> >>>
> >>>
> >>>
> >>> Not knowing so much about this from a general research perspective,
> >>> I wonder if there exists theoretical evidence
> >>>
> >>> But also if one have a good understanding of the actual difference
> >>> in between (1) and (2), then this may serve as input for such an
> >>> argumentation

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 31 Mar 2016 10:03:21 -0700

> the TCP friendly region. But rather refer to that based on the
Somewhat irrelevant to the discussion, but I can't resist to point out that
TCP NewReno (RFC 6582) really is NOT a new or better congestion
control over TCP Reno.

New Reno is merely a loss detection heuristic for multiple losses in a
window before SACK was invented. It is hardly a congestion control. In Linux
NewReno is never used when SACK is negotiated.

So if you are thinking of AIMD, it is Reno. NewReno does not make that
part newer :-)

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 31 Mar 2016 19:24:00 +0200

HI Yuchung,

I refer to RFC5681 & RFC6675 as Reno (or New Reno) for TCP with SACK.

For TCP without SACK we can discuss the differences of Reno or New Reno, in
regard to whether RFC6582 is implemented or not,
but I was not thinking about non-SACK here at all.

The term in the CUBIC draft is "applicable to all Reno style TCP standards
and their
   variants, including TCP-RENO [RFC5681], TCP-NewReno [RFC6582], TCP-
   SACK [RFC2018], SCTP [RFC4960]"

I did question earlier on the list why there is no reference to RFC6675, but
I have not received any answer yet, I think.

Anyway the argument in the CUBIC draft and in prior CUBID research refers to
Reno or to standard TCP CC.

I would not have thought that standard TCP CC or that TCP New Reno (or Reno)
CC for TCP SACK
generally is perceived as referring to any AIMD with any alpha or beta
values or with any alpha or beta values that
gives the same average window as RFC5681&RFC6675.

BR, Karen

> From: Yuchung Cheng [mailto:[email-masked]]
> Sent: 31. marts 2016 19:03
> To: Karen Elisabeth Egede Nielsen <[email-masked]>
> Cc: Lisong Xu <[email-masked]>; [email-masked]; [email-masked]
> Extensions <[email-masked]>
> Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ?
>
> > This is still average considerations and the carryover of the argument
> > to the TCP friendly sub-domain of CUBIC does not follow straightaway.
> >
> > I would suggest, in section 3.2 of the CUBIBC draft,  not to make
> > something that looks like a mathematical argument for that
> > AIMD(3*(1-beta)/(1+beta), beta) is a good approximation for TCP New
> > Reno in the TCP friendly region. But rather refer to that based on the
> Somewhat irrelevant to the discussion, but I can't resist to point out
> that TCP
> NewReno (RFC 6582) really is NOT a new or better congestion control over
> TCP Reno.
>
> window
> before SACK was invented. It is hardly a congestion control. In Linux
> part
> newer :-)
> > evaluations of [FHP00], showing the general approximation (and
> > fairness) of AIMD(3*(1-beta)/(1+beta), beta) compared to TCP New Reno,
> > this AIMD profile is used to define the TCP Friendly region and this
> > profile is used as a replacement of the CUBIC window in this region.
> > > > Yes I understand that we are not speaking part 1). We are speaking
> > > > the CUBIC operation in TCP Friendly region only
> > > >
> > > > As far as I have understood the argumentation behind 2) you are
> > > > making sure that CUBIC CWND is never lower than TCP Reno CWND.
> > > > But perhaps this has been a misunderstanding and you aim instead -
> > > > as you say right below -  is to make sure that the _average_ CUBIC
> > > > window is not lower than Reno ?
> > > > Either way the theoretical argumentation based on average window
> > > > of AIMD alone does not hold, but empirics may tell that it is ok.
> > > >
> > > > contrary we are working to implement the algorithm. But still we
> > > > want to make sure to understand the aims right.
> > > >
> > > > BR, Karen
> > > >
> > > >> 2) make sure that CUBIC average rate is never lower than Reno in
> > > >> any networks.
> > > >>
> > > >>> So what we have is an argumentation of the TCP friendliness
> > > >>> function which follows
> > > >>>
> > > >>> (2): Make CUBIC CWND be no less than what AIMD(
> > > >>> 3*(1-beta)/(1+beta) , beta ) would give
> > > >>>
> > > >>>
> > > >>>
> > > >>> theoretical argumentation for why (1) is the right thing to do,
> > > >>> than for why (2) is an appropriate thing to do.
> > > >>>
> > > >>> The theoretical arguments for (1) is in the CUBIC draft and in
> > > >>> the CUBIC papers.
> > > >>>
> > > >>>
> > > >>>
> > > >>> Not knowing so much about this from a general research
> > > >>> perspective, I wonder if there exists theoretical evidence
> > > >>>
> > > >>> for why (2) is appropriate or proper in respect of the
> > > >>> argumentation of “TCP friendliness”.
> > > >>>
> > > >>> But also if one have a good understanding of the actual
> > > >>> difference in between (1) and (2), then this may serve as input
> > > >>> for such an argumentation
> >

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 31 Mar 2016 17:04:39 -0700

> I have not received any answer yet, I think.
It'd be nice to mention that indeed. RFC6675 and NewReno are two
distinct loss recovery algorithms for SACK and non-SACK respectively.
The former is much more faster. The latter takes N RTT to recover N
losses in a window.