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

[Vidhi Goel <[e-mail]>]

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=[e-mail]> wrote:
> 
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi,
>> 
>> many thanks for the review!
>> 
>> On 2021-6-1, at 11:35, Yoshifumi Nishida <[e-mail] <mailto:[e-mail]>> 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 <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>.
>> 
>>> 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], 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 <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 <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 <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.
>>>    This looks a bit confusing to me.
>> 
>> Opened https://github.com/NTAP/rfc8312bis/issues/64 <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 <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.
>>>  This is fine, but I think it might be good to clarify it.
>> 
>> Opened https://github.com/NTAP/rfc8312bis/issues/66 <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?
>>>    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.
>> 
>> Opened https://github.com/NTAP/rfc8312bis/issues/67 <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.
>>>   Does this mean b_cubic is also updated? If not, why this can be compatible?
>> 
>> Opened https://github.com/NTAP/rfc8312bis/issues/68 <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 <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 <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 <https://github.com/NTAP/rfc8312bis/issues/71>
>> 
>> Thanks,
>> Lars
>> 
>> 
>> _______________________________________________
>> tcpm mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/tcpm
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm