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

[Vidhi Goel <[e-mail]>]

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)

> 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?

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

I have opened an issue in GitHub https://github.com/NTAP/rfc8312bis/issues/143 <https://github.com/NTAP/rfc8312bis/issues/143>. We can continue the discussion there.


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] <mailto:[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/ <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] <mailto:[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] <mailto:[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/ <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 <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 <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] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> 
> _______________________________________________
> tcpm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm