Subject: Re: [tcpm] Fwd: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt

From: "Agarwal, Anil" <[email-masked]>
Date: Mon, 28 Sep 2015 13:28:13 +0000

Just saw a bug fix for CUBIC in the Linux kernel code, contributed by Google -
https://github.com/torvalds/linux/commit/30927520dbae297182990bb21d08762bcc35ce1d

It appears that CUBIC does not specify any special rules for handling TCP cwnd increase after an idle period. There is no feedback (packet losses or ECN) during the idle period which makes the cwnd increase algorithm unnecessarily aggressive after an idle period, especially if cwnd is not reset during the idle period.

Question - where is the CUBIC specification documented? How will it be updated? Is there an RFC on CUBIC?

Anil

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 28 Sep 2015 13:32:42 +0000

TCPM currently works on that:

https://tools.ietf.org/html/draft-ietf-tcpm-cubic-00

Note that this is work in progress. Some inaccuracy between the document and the Linux code have already been mentioned on the list (see list archive) and will be fixed in the next versions.

Michael

From: tcpm [mailto:[email-masked]] On Behalf Of Agarwal, Anil
Sent: Monday, September 28, 2015 3:28 PM
To: tcpm IETF list
Subject: Re: [tcpm] Fwd: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt

Anil

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 28 Sep 2015 13:34:59 +0000

Hi,

> Question - where is the CUBIC specification documented? How will it be updated? Is there an RFC on CUBIC?

there is https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/. 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 :-)

Lars

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 28 Sep 2015 13:23:12 -0700

> 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 t…
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://patchwork.ozlabs.org/patch/518918/
https://patchwork.ozlabs.org/patch/516122/
https://patchwork.ozlabs.org/patch/516123/

HTH

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

---

From: "Agarwal, Anil" <[email-masked]>
Date: Mon, 28 Sep 2015 22:35:11 +0000

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.

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:
> 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=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&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:

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.

https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_518918_&d=BQIBaQ&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=gpOIxBF_PNjCo7ij5xixz0eqOB-Xt_ddmiwbeQmW7lI&s=-40xAglDVsZhZJ3Cd5PncmRKZue4vz4V5sA3iTqYafo&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_516122_&d=BQIBaQ&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=gpOIxBF_PNjCo7ij5xixz0eqOB-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-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=gpOIxBF_PNjCo7ij5xixz0eqOB-Xt_ddmiwbeQmW7lI&s=M-8Jum-_SDW0fVKKsSHmUto0Cw3DajRYRhxo0cdjOYw&e= 

HTH

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_tcpm&d=BQIBaQ&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06f
> Pk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=gpOIxBF_PNjCo7ij5xi
> xz0eqOB-Xt_ddmiwbeQmW7lI&s=FbVX6NYOKMRF5mIg0Z5WW4mBHmMudm1VvExLtmTkfpc
> &e=
>

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 28 Sep 2015 16:28:01 -0700

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