Subject: [tcpm] Comments for draft-ietf-tcpm-rfc8312bis-02

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 1 Jun 2021 01:35:09 -0700

Hello, I have the following comments on this draft.

1: While this draft focuses on only TCP,  CUBIC can actually be applied to
other transport protocols
    such as QUIC, SCTP. Do we want to mention it in the draft or is it out
of scope?

2: Section 3.1 "After a window reduction in response to a congestion event
is

     detected by duplicate ACKs or Explicit Congestion Notification-Echo
     (ECN-Echo, ECE) ACKs [RFC3168
<https://datatracker.ietf.org/doc/html/rfc3168>], CUBIC remembers the
congestion window..."

   I think the events detected by RACK (or PTO for QUIC) can also be
included here.

3: Section 4.1.1

    It seems that the text version of the draft uses b_cubic and
a_aimd, while the pdf version of the

    draft uses different names. But, I prefer to use the same names in
both versions to avoid confusion.

4: Section 4.2  I personally prefer to refer the equations in the
draft as 'Equation' rather than 'Figure'  if there's

    no strong reason for it.

5: Section 4.3  It seems to me that there are two meanings for a_aimd
in this section.

    One is the additive factor for CUBIC and the other is a generic
parameter for AIMD() function.

    This looks a bit confusing to me.

6: Section 4.3  The description for P is required for Figure 3.

7: Section 4.3  I think The analysis in [FHP00] doesn't include
delayed ACK factor. So, the AIMD TCP model here

   can be a bit aggressive compared to a TCP that doesn't enable ABC
and uses delayed ACK.

  This is fine, but I think it might be good to clarify it.

8: Section 4.3  I am not very sure why segments_acked is used rather
than byted_acked here. What is the benefit of it?

    How do we calculate when the acks are split?

   Also, I think it should be clarified that cwnd is expressed in
segments here in this case.

9: Section 4.3  "Note that once _W_est_ reaches _W_max_, that is,
_W_est_ >= _W_max_, ..."

   I might miss something, but I'm not sure why  a_aimd can be set to
1 to be compatible with AIMD TCP.

   Does this mean b_cubic is also updated? If not, why this can be compatible?

10: Section 4.5: " The convex profile ensure that the window increases
very slowly at the beginning.."

   I am wondering how much this part is accurate. Because of Principal
2,  even though cwnd is increased

   through convex profile, I think it will be overridden by linear
growth by AIMD.

11: Section 4.7: "we update w_max as follows, before the window
reduction as described in section 4.6"

   I am wondering if reducing w_max is the right approach here.
Because if we reduce w_max, CUBIC

   can exit from convex region earlier than the case where fast
convergence is not used.

   It seems to me that keeping w_max and reducing only cwnd (using
smaller value than b_cubic)

   look more conservative.

12: Section 5.2 and Section 5.3. Do these results are based on the
algorithms and the parameter values

   described in the draft?  If there're differences, I think it should
be described.

   Thanks,

--

Yoshi

On Thu, May 13, 2021 at 1:19 AM Yoshifumi Nishida <[email-masked]>
wrote:

> Hi,
>
> Sorry. The link for the draft was not correct. Please use this one.
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis-02
> --
> Yoshi
>
> On Thu, May 13, 2021 at 12:57 AM Yoshifumi Nishida <[email-masked]>
> wrote:
>
>> Hello everyone,
>>
>> This e-mail initiates the WGLC for
>> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis-01
>> Please send your feedback to the ML.
>> This WGLC runs until * Monday Jun 6 *
>>
>> The intended status of the draft is Proposed Standard.
>> We appreciate your cooperation.
>>
>> Thanks,
>> --
>> tcpm-chairs
>>
>>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 1 Jun 2021 12:18:23 +0300

Hi,

many thanks for the review!

On 2021-6-1, at 11:35, Yoshifumi Nishida <[email-masked]> wrote:
> 1: While this draft focuses on only TCP,  CUBIC can actually be applied to other transport protocols
>     such as QUIC, SCTP. Do we want to mention it in the draft or is it out of scope?

I've opened https://github.com/NTAP/rfc8312bis/issues/61 for this.

Note that we did discuss CUBIC for QUIC in https://github.com/NTAP/rfc8312bis/issues/45.

> 2: Section 3.1 "After a window reduction in response to a congestion event is
>      (ECN-Echo, ECE) ACKs [
> RFC3168], CUBIC remembers the congestion window..."
> 
>    I think the events detected by RACK (or PTO for QUIC) can also be included here.

I opened https://github.com/NTAP/rfc8312bis/issues/62

> 3: Section 4.1.1
>     It seems that the text version of the draft uses b_cubic and a_aimd, while the pdf version of the
>     draft uses different names. But, I prefer to use the same names in both versions to avoid confusion.

The PDF is actually corrupt, due to a Unicode bug in the datatracker PDF generation. See https://github.com/NTAP/rfc8312bis/issues/46.

> 4: Section 4.2  I personally prefer to refer the equations in the draft as 'Equation' rather than 'Figure'  if there's
>     no strong reason for it.

With kramdown-xml2rfc2629, it's unfortunately not possible to change this. We would need to add an RFC Editor Note instructing them to manually make the change. Opened https://github.com/NTAP/rfc8312bis/issues/63

> 5: Section 4.3  It seems to me that there are two meanings for a_aimd in this section.
>     One is the additive factor for CUBIC and the other is a generic parameter for AIMD() function.

Opened https://github.com/NTAP/rfc8312bis/issues/64

> 6: Section 4.3  The description for P is required for Figure 3.

Opened https://github.com/NTAP/rfc8312bis/issues/65

> 7: Section 4.3  I think The analysis in [FHP00] doesn't include delayed ACK factor. So, the AIMD TCP model here
>    can be a bit aggressive compared to a TCP that doesn't enable ABC and uses delayed ACK.

Opened https://github.com/NTAP/rfc8312bis/issues/66

> 8: Section 4.3  I am not very sure why segments_acked is used rather than byted_acked here. What is the benefit of it?
>    Also, I think it should be clarified that cwnd is expressed in segments here in this case.

Opened https://github.com/NTAP/rfc8312bis/issues/67

> 9: Section 4.3  "Note that once _W_est_ reaches _W_max_, that is, _W_est_ >= _W_max_, ..."
>    I might miss something, but I'm not sure why  a_aimd can be set to 1 to be compatible with AIMD TCP.

Opened https://github.com/NTAP/rfc8312bis/issues/68

> 10: Section 4.5: " The convex profile ensure that the window increases very slowly at the beginning.."
>    I am wondering how much this part is accurate. Because of Principal 2,  even though cwnd is increased
>    through convex profile, I think it will be overridden by linear growth by AIMD.

Opened https://github.com/NTAP/rfc8312bis/issues/69

> 11: Section 4.7: "we update w_max as follows, before the window reduction as described in section 4.6"
>    I am wondering if reducing w_max is the right approach here. Because if we reduce w_max, CUBIC
>    can exit from convex region earlier than the case where fast convergence is not used.
>    It seems to me that keeping w_max and reducing only cwnd (using smaller value than b_cubic)
>    look more conservative.

Opened https://github.com/NTAP/rfc8312bis/issues/70

> 12: Section 5.2 and Section 5.3. Do these results are based on the algorithms and the parameter values
>    described in the draft?  If there're differences, I think it should be described.

Opened https://github.com/NTAP/rfc8312bis/issues/71

Thanks,
Lars

---

From: Vidhi Goel <[email-masked]>
Date: Tue, 08 Jun 2021 00:27:25 -0700

Hello Yoshi and folks,

As we are addressing the below issues raised by Yoshi, for one of the issues (https://github.com/NTAP/rfc8312bis/issues/64 <https://github.com/NTAP/rfc8312bis/issues/64>), it would be great if you could take a look and provide opinion about whether using alpha_aimd as a variable and then assigning a constant value to it for Cubic in the draft is confusing or not.

And, of course, you are welcome to look at other issues and provide your input.

Thanks,
Vidhi

> On Jun 1, 2021, at 2:18 AM, Lars Eggert <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Vidhi Goel <[email-masked]>
Date: Thu, 10 Jun 2021 18:51:33 -0700

Hello folks,

As we are in the WGLC for rfc8312bis, I would really appreciate your feedback on this issue (https://github.com/NTAP/rfc8312bis/issues/64 <https://github.com/NTAP/rfc8312bis/issues/64>). Please let us know latest by Jun 15th if you have any input/thoughts on it. After that, the issue will be closed with no action.

Thanks,
Vidhi

> On Jun 8, 2021, at 12:27 AM, Vidhi Goel <vidhi_goel=[email-masked]> wrote:
> 
> Hello Yoshi and folks,
> 
>> On Jun 1, 2021, at 2:18 AM, Lars Eggert <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>> 
>> On 2021-6-1, at 11:35, Yoshifumi Nishida <[email-masked] <mailto:[email-masked]>> wrote:
>> I've opened https://github.com/NTAP/rfc8312bis/issues/61 <https://github.com/NTAP/rfc8312bis/issues/61> for this.
>> 
>> Note that we did discuss CUBIC for QUIC in https://github.com/NTAP/rfc8312bis/issues/45 <https://github.com/NTAP/rfc8312bis/issues/45>.
>> 
>> I opened https://github.com/NTAP/rfc8312bis/issues/62 <https://github.com/NTAP/rfc8312bis/issues/62>
>> 
>>> 3: Section 4.1.1
>> The PDF is actually corrupt, due to a Unicode bug in the datatracker PDF generation. See https://github.com/NTAP/rfc8312bis/issues/46 <https://github.com/NTAP/rfc8312bis/issues/46>.
>> 
>> With kramdown-xml2rfc2629, it's unfortunately not possible to change this. We would need to add an RFC Editor Note instructing them to manually make the change. Opened https://github.com/NTAP/rfc8312bis/issues/63 <https://github.com/NTAP/rfc8312bis/issues/63>
>> 
>> Opened https://github.com/NTAP/rfc8312bis/issues/64 <https://github.com/NTAP/rfc8312bis/issues/64>
>> 
>> Opened https://github.com/NTAP/rfc8312bis/issues/65 <https://github.com/NTAP/rfc8312bis/issues/65>
>> 
>> Opened https://github.com/NTAP/rfc8312bis/issues/66 <https://github.com/NTAP/rfc8312bis/issues/66>
>> 
>> Opened https://github.com/NTAP/rfc8312bis/issues/67 <https://github.com/NTAP/rfc8312bis/issues/67>
>> 
>> Opened https://github.com/NTAP/rfc8312bis/issues/68 <https://github.com/NTAP/rfc8312bis/issues/68>
>> 
>> Opened https://github.com/NTAP/rfc8312bis/issues/69 <https://github.com/NTAP/rfc8312bis/issues/69>
>> 
>> Opened https://github.com/NTAP/rfc8312bis/issues/70 <https://github.com/NTAP/rfc8312bis/issues/70>
>> 
>> Opened https://github.com/NTAP/rfc8312bis/issues/71 <https://github.com/NTAP/rfc8312bis/issues/71>
>> 
>> Thanks,
>> Lars
>> 
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 13 Jun 2021 20:23:57 +0300

> On 11 Jun, 2021, at 4:51 am, Vidhi Goel <vidhi_goel=[email-masked]> wrote:
> 
> As we are in the WGLC for rfc8312bis, I would really appreciate your feedback on this issue (https://github.com/NTAP/rfc8312bis/issues/64). Please let us know latest by Jun 15th if you have any input/thoughts on it. After that, the issue will be closed with no action.

I left a comment on the Github issue, suggesting a possible way to clarify the section at issue.  Currently the use of the various alpha and beta symbols is a bit convoluted and could cause confusion; though a careful reading does reveal the correct interpretation, this may be difficult for some readers and could result in inadvertent mistakes.

The essence of what I suggest is:

1: Where alpha and beta are used as parameters to a formula, write them without suffixes in the formula's definition, particularly AVG_AIMD(alpha,beta).

2: Use the "aimd" suffix to refer solely to the alpha and beta parameters from Reno.

3: Consistently use the "cubic" suffix for the alpha and beta parameters of CUBIC.

4: Explain the calculation of alpha_cubic in terms of equalising the values of AVG_AIMD(alpha_aimd, beta_aimd) and AVG_AIMD(alpha_cubic, beta_cubic).

I believe the above approach to will improve clarity noticeably without increasing the number of symbols in play.  I will leave the fine details of wording and formatting to the authors and editors.

 - Jonathan Morton