Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis

[Yoshifumi Nishida <[e-mail]>]

Hi Vidhi,

Thanks for the comments.

On Mon, Feb 7, 2022 at 3:32 PM Vidhi Goel <[e-mail]> wrote:

> Thanks Yoshi for reviewing the draft.
>
> So, it seems one PS doc mentions not to use cwnd, while another PS doc
> mentions using cwnd is fine (with RFC7661).
>
> RFC5681 is conservative in its approach to use FlightSize and will result
> in very low throughput in scenarios when the congestion event occurs at the
> tail of send window (when flight size could be very small)
>

Yes. I agree.


>
> I am not sure which can cause this situation yet, but in any case, does
> this mean there is no concern on
> "some implementations may incidentally increase well beyond rwnd" in cubic?
> Is this because this is an old implementation bug or are there other
> reasons?
> I am wondering if we might want some clarification on this point.
>
> If an implementation uses RFC7661, there is no concern about increasing
> cwnd beyond rwnd as RFC7661 tracks bytes acknowledged in a RTT which means
> that `rwnd` check has already been performed.
> Usually cwnd doesn’t grow beyond rwnd  (ACK-clocking increases cwnd which
> means the sender already checked `rwnd` before sending out the data).
>
> But there could be implementations that may want to keep `rwnd` even
> smaller than initial `cwnd`. In those cases, RFC7661 would make the cwnd
> invalidated when the number of acknowledged bytes is much lower than the
> current cwnd.
>
> Do you have any suggestions on how to make it more clear?
>

I think it will be fine as long as the draft clarifies we can safely
override what's written in RFC5681 when we have some mechanisms such as
RFC7661.

> Also, I am wondering if we might want to use "MAY be used" here instead of
> "can be used"
>
> Yeah, we can make this change.
>

Thanks!
-- 
Yoshi


>
>
> Thanks,
> Vidhi
>
> On Feb 6, 2022, at 3:01 AM, Yoshifumi Nishida <[e-mail]> wrote:
>
> Hi,
> I just have one more comment on the draft.
> In RFC5681, it mentions in Section 3:
> ''
>
>    Implementation Note: An easy mistake to make is to simply use cwnd,
>    rather than FlightSize, which in some implementations may
>    incidentally increase well beyond rwnd.
>
> "
>
> while this draft mentions in Section 4.6:
> "
>
>    To avoid suboptimal performance with such applications,
>
>    the mechanisms described in [RFC7661 <https://datatracker.ietf.org/doc/html/rfc7661>] can be used to mitigate this
>    issue as it would allow using a value between _cwnd_ and
>    _flight_size_ to calculate the new _ssthresh_ in Figure 5.
>
> "
>
> So, it seems one PS doc mentions not to use cwnd, while another PS doc
> mentions using cwnd is fine (with RFC7661).
>
> I am not sure which can cause this situation yet, but in any case, does
> this mean there is no concern on
> "some implementations may incidentally increase well beyond rwnd" in cubic?
> Is this because this is an old implementation bug or are there other
> reasons?
> I am wondering if we might want some clarification on this point.
>
> Also, I am wondering if we might want to use "MAY be used" here instead of
> "can be used"
>
> Thanks,
> --
> Yoshi
>
> On Mon, Jan 31, 2022 at 11:43 PM Yoshifumi Nishida <[e-mail]>
> wrote:
>
>> Hello,
>>
>> After some discussions among chairs, we decided to run the 2nd WGLC on
>> draft-ietf-tcpm-rfc8312bis in consideration of the importance of the draft.
>> We'll be grateful if you could send your feedback to the ML. The WGLC
>> runs until *Feb 11*.
>>
>> If interested, you can check in-depth past discussions in the following
>> URL.
>> https://github.com/NTAP/rfc8312bis/
>>
>> Thank you so much!
>> --
>> tcpm co-chairs
>>
>>
>> On Wed, Jan 26, 2022 at 2:50 AM Lars Eggert <[e-mail]> wrote:
>>
>>> Hi,
>>>
>>> this -06 version rolls in all the changes requested during (and after)
>>> WGLC ended.
>>>
>>> I'll leave it up to the chairs to decide if another WGLC is warranted or
>>> the document can progress as-is.
>>>
>>> Thanks,
>>> Lars
>>>
>>>
>>> > On 2022-1-26, at 11:12, [e-mail] wrote:
>>> >
>>> >
>>> > A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> > This draft is a work item of the TCP Maintenance and Minor Extensions
>>> WG of the IETF.
>>> >
>>> >        Title           : CUBIC for Fast and Long-Distance Networks
>>> >        Authors         : Lisong Xu
>>> >                          Sangtae Ha
>>> >                          Injong Rhee
>>> >                          Vidhi Goel
>>> >                          Lars Eggert
>>> >       Filename        : draft-ietf-tcpm-rfc8312bis-06.txt
>>> >       Pages           : 35
>>> >       Date            : 2022-01-26
>>> >
>>> > Abstract:
>>> >   CUBIC is a standard TCP congestion control algorithm that uses a
>>> >   cubic function instead of a linear congestion window increase
>>> >   function to improve scalability and stability over fast and long-
>>> >   distance networks.  CUBIC has been adopted as the default TCP
>>> >   congestion control algorithm by the Linux, Windows, and Apple stacks.
>>> >
>>> >   This document updates the specification of CUBIC to include
>>> >   algorithmic improvements based on these implementations and recent
>>> >   academic work.  Based on the extensive deployment experience with
>>> >   CUBIC, it also moves the specification to the Standards Track,
>>> >   obsoleting RFC 8312.  This also requires updating RFC 5681, to allow
>>> >   for CUBIC's occasionally more aggressive sending behavior.
>>> >
>>> >
>>> > The IETF datatracker status page for this draft is:
>>> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/
>>> >
>>> > There is also an HTML version available at:
>>> > https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-06.html
>>> >
>>> > A diff from the previous version is available at:
>>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc8312bis-06
>>> >
>>> >
>>> > Internet-Drafts are also available by rsync at rsync.ietf.org
>>> ::internet-drafts
>>> >
>>> >
>>> > _______________________________________________
>>> > tcpm mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>