Subject: Re: [tcpm] Cubic (was Re: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt)

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 11 Nov 2015 16:08:39 +0100

HI,

I (also) was a bit surprised by the CUBIC fault presented in tcpm as I
would have assumed that CUBIC would be implemented in the framework of
RFC5681 for how to handle idle situations and also possibly in the
framework of RFC7661/2861
(or this mechanism in which ever from it takes in Linux).
Anyway I think that it would be great and best if the CUBIC paper would
describe a CUBIC solution
following these principles, but then I also see that we might derivate
from existing implementations,
so that is of course an issue (Though see below on pacing).

In terms of how to handle CUBIC after idle situation or other where the
CUBIC algorithm need
to be re-calibrated, then I wonder if the situation is so simply that one
would re-calibrate the
CUBIC W(t) formula so that t=0 corresponds to re-start of transmission and
K is adjusted so
That W(0) gives the present CWND (whatever it has been left at now) - just
a naīve thought ?
Perhaps you have already designed a different solution ?

Something else - more general:

* at the tcpm session, Lars mentioned that also Hystart should be
described in this document. Is that correctly understood ?
Personally I think that sounds very good.

* Pacing has been recognized as a necessity and I believe even more a
necessity when running CUBIC than New Reno,
as CUBIC CWND increase at large RTTs may clock out large bursts. Is it
valid to describe CUBIC CC (as implemented in Linux) without describing
pacing ?

Thanks.

BR, Karen

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Yuchung Cheng
> Sent: 29. september 2015 01:28
> To: Agarwal, Anil <[email-masked]>
> Cc: Jana Iyengar <[email-masked]>; tcpm IETF list <[email-masked]>
> Subject: Re: [tcpm] Cubic (was Re: New I-D: draft-briscoe-aqm-dualq-
> coupled-00.txt)
>
> On Mon, Sep 28, 2015 at 3:35 PM, Agarwal, Anil <[email-masked]>
> wrote:
> > Yuchung,
> >
> > You wrote -
> > "If the TCP implementation follows RFC 5681 or RFC 2861 to reduce cwnd
> after idle, the issue is masqueraded".
> >
> > Would it be more appropriate to state that - If the TCP implementation
> > follows RFC 5681 or RFC 2861 to reduce cwnd after idle, the TCP
slow-start
> cwnd increase algorithm should get used, not CUBIC.
> That'd be fine w/ me if the draft considers Cubic is only effective when
cwnd
> >= ssthresh.
>
> Jana would present the troubleshooting and results in the next mtg.
> the bug was initially discovered in QUIC (which uses Cubic).
>
> >
> > Thanks,
> > Anil
> >
> > P.S. Sorry about the confusion created by not editing the subject line
> > correctly
> >
> >
> > -----Original Message-----
> > From: Yuchung Cheng [mailto:[email-masked]]
> > Sent: Monday, September 28, 2015 4:23 PM
> > To: Eggert, Lars
> > Cc: Agarwal, Anil; tcpm IETF list; Zimmermann, Alexander
> > Subject: Re: [tcpm] Cubic (was Re: New I-D:
> > draft-briscoe-aqm-dualq-coupled-00.txt)
> >
> > On Mon, Sep 28, 2015 at 6:34 AM, Eggert, Lars <[email-masked]> wrote:
> >>
> >> Hi,
> >>
> >> On 2015-09-28, at 15:28, Agarwal, Anil <[email-masked]>
wrote:
> >> >
> >> > Question - where is the CUBIC specification documented? How will it
be
> updated? Is there an RFC on CUBIC?
> >>
> >> there is https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtcpm-
> 2Dcubic_&d=BQIBaQ&c=jcv3orpCsv7C4ly8-
> ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSh
> eSGz1Jvq4&m=gpOIxBF_PNjCo7ij5xixz0eqOB-
> Xt_ddmiwbeQmW7lI&s=b18CZjGX71Lsmel9s4E-8R8aFY1-
> 71uvwem3J6QnMOg&e= . The goal was that this would document the Cubic
> code currently implemented by Linux.
> >>
> >> This has been a slow effort, and it's getting slower since both
> >> Richard and Alex probably won't have cycles in the foreseeable future
> >> to work on this. So I think we're looking for someone else to take
> >> over the pen (hi, Yuchung & Google folks :-)
> >>
> > Sorry I won't be able to help co-authoring the draft. But the fix is
not that
> complicated. A new subsection on section 3 should suffice.
> > Something like:
> >
> > 3.x Dealing with application idle
> >
> > Cubic determines how fast to grow the window based on how long ago the
> last loss event was. An oversight in the original design is that idling
periods
> can make Cubic arbitrarily aggressive: after an idle period, the delta
of (t - k)
> as well as the slope of cwnd increase become arbitrarily large in
Section 3.1.
> In some implementation (e.g., Linux) the maximum increase is capped to
be
> as fast as slow start.
> >
> > If the TCP implementation follows RFC 5681 or RFC 2861 to reduce cwnd
> after idle, the issue is masqueraded. But if the TCP implementation does
not
> reduce cwnd after idle (i.e., RFC2861 or RFC5681), Cubic will slow start
> without a reduced cwnd and likely to induce losses quickly.
> >
> > To address this issue Cubic algorithm SHOULD offset the (t - k) in
Section 3.1
> by the amount of idle time. One approach (e.g., Linux) is to record the
send
> time of the last packet, and calculate the idle time when the amount of
> inflight becomes positive again when sending the next packet after idle.
> >
> >
> > These are the Linux patches for reference.
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__patchwork.ozlabs.
> > org_patch_518918_&d=BQIBaQ&c=jcv3orpCsv7C4ly8-
> ubDob57ycZ4jvhoYZNDBA06f
> >
> Pk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=gpOIxBF_PNj
> Co7ij5xi
> > xz0eqOB-Xt_ddmiwbeQmW7lI&s=-
> 40xAglDVsZhZJ3Cd5PncmRKZue4vz4V5sA3iTqYafo
> > &e=
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__patchwork.ozlabs.
> > org_patch_516122_&d=BQIBaQ&c=jcv3orpCsv7C4ly8-
> ubDob57ycZ4jvhoYZNDBA06f
> >
> Pk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=gpOIxBF_PNj
> Co7ij5xi
> > xz0eqOB-Xt_ddmiwbeQmW7lI&s=aA3H-aoHtcUBnfA-
> 7s85Nu4oxArwhmM2N8tT1fV9uy0
> > &e=
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__patchwork.ozlabs.
> > org_patch_516123_&d=BQIBaQ&c=jcv3orpCsv7C4ly8-
> ubDob57ycZ4jvhoYZNDBA06f
> >
> Pk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=gpOIxBF_PNj
> Co7ij5xi
> > xz0eqOB-Xt_ddmiwbeQmW7lI&s=M-8Jum-
> _SDW0fVKKsSHmUto0Cw3DajRYRhxo0cdjOYw
> > &e=
> >
> > HTH
> >
> >
> >> Lars
> >>
> >> _______________________________________________
> >> tcpm mailing list
> >> [email-masked]
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mai
> >> l
> >> man_listinfo_tcpm&d=BQIBaQ&c=jcv3orpCsv7C4ly8-
> ubDob57ycZ4jvhoYZNDBA06
> >> f
> >>
> Pk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=gpOIxBF_PNj
> Co7ij5x
> >> i
> >> xz0eqOB-
> Xt_ddmiwbeQmW7lI&s=FbVX6NYOKMRF5mIg0Z5WW4mBHmMudm1VvExLt
> mTkfp
> >> c
> >> &e=
> >>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm