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

Vidhi Goel <vidhi_goel@apple.com> Mon, 07 February 2022 23:32 UTC

Return-Path: <vidhi_goel@apple.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5223A0F09 for <tcpm@ietfa.amsl.com>; Mon, 7 Feb 2022 15:32:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.675
X-Spam-Level:
X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dunv2lK0Mesz for <tcpm@ietfa.amsl.com>; Mon, 7 Feb 2022 15:32:43 -0800 (PST)
Received: from rn-mailsvcp-ppex-lapp34.apple.com (rn-mailsvcp-ppex-lapp34.rno.apple.com [17.179.253.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723983A0F2E for <tcpm@ietf.org>; Mon, 7 Feb 2022 15:32:43 -0800 (PST)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp34.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp34.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 217NFYBr010547; Mon, 7 Feb 2022 15:32:41 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=i73DVC4qbwqACy5VBSk9tvvVtJvlSr6pfq7XHWbZcPA=; b=UyuLOa/rl13pXrOPxvev6+MJOTlWfpKn5+kv4Olm2S2B2ATpipK6JYrqpOloyFzEzzqV zgmBpNLt0Hcue1RDoQuYh4bnQsVp1dvL6f+gcXo6/dT5+aItS5tPr1xSxFiT7Xnn2rR0 dg0U4X6al7Uj9fXux8Yb+b3ftnZaxp48Y5IjfGJmUqIoUghVcW8b07gKNNX7donl4dhc 8UxRQPsjtuDZ8AaFho2Fw3Nl8s62Vk0WA4a6e9v7bezuAOQAv6ZDA2/cQgW6mXUIE5yS OMuorAzP8FTjLd4CGwaT5SGQMtS0qVeVS6T+hzBgR+QQuzTkXId1o9TlX6IO1DSYlvuV hQ==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp34.rno.apple.com with ESMTP id 3e26b3we9t-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 07 Feb 2022 15:32:41 -0800
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R6Y004M2K2HMP30@rn-mailsvcp-mta-lapp01.rno.apple.com>; Mon, 07 Feb 2022 15:32:41 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R6Y00M00JY8GL00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Mon, 07 Feb 2022 15:32:41 -0800 (PST)
X-Va-A:
X-Va-T-CD: 201b35371ed429fb4e4fc3ed10b3bd6f
X-Va-E-CD: 749c6e7503a1c30456497a36735b331a
X-Va-R-CD: 59a455eaeb25ffef4add4d7c725dcf79
X-Va-CD: 0
X-Va-ID: 0f6a47c3-8b75-41e0-bf63-ebc77df376f3
X-V-A:
X-V-T-CD: 201b35371ed429fb4e4fc3ed10b3bd6f
X-V-E-CD: 749c6e7503a1c30456497a36735b331a
X-V-R-CD: 59a455eaeb25ffef4add4d7c725dcf79
X-V-CD: 0
X-V-ID: 12f0c5f6-74e8-416a-8fda-188b19408506
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-02-07_07:2022-02-07, 2022-02-07 signatures=0
Received: from smtpclient.apple (unknown [17.234.14.73]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R6Y00WKEK2GGM00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Mon, 07 Feb 2022 15:32:41 -0800 (PST)
From: Vidhi Goel <vidhi_goel@apple.com>
Message-id: <492FC264-2D3C-4D3D-B7C2-D547593E4A7D@apple.com>
Content-type: multipart/signed; boundary="Apple-Mail=_45C2D04E-78BF-4827-A84D-52F7F454FFD1"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\))
Date: Mon, 07 Feb 2022 15:32:39 -0800
In-reply-to: <CAAK044R6B7HT0mdSDwHU=FhvN=A=M-8pxYb8wGfwxczwtCT-yw@mail.gmail.com>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
References: <164318837039.21788.17451980682651967578@ietfa.amsl.com> <EEA435EC-AAAC-4899-8E94-2D54EDE5F72E@eggert.org> <CAAK044S9HQXvfvgM6mBuvOWJPHtCaa6xo6CoP2r8Vq61tKaY5g@mail.gmail.com> <CAAK044R6B7HT0mdSDwHU=FhvN=A=M-8pxYb8wGfwxczwtCT-yw@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.100.0.2.11)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-02-07_07:2022-02-07, 2022-02-07 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/vGlc5AML1jX01Ugg08QOh8dXaAI>
Subject: Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 23:32:48 -0000

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 <nsd.ietf@gmail.com> 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 <nsd.ietf@gmail.com <mailto:nsd.ietf@gmail.com>> 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 <lars@eggert.org <mailto:lars@eggert.org>> 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, internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> 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
> > tcpm@ietf.org <mailto:tcpm@ietf.org>
> > https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org <mailto:tcpm@ietf.org>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm