Re: [tcpm] Comments for draft-ietf-tcpm-rfc8312bis-02
Vidhi Goel <vidhi_goel@apple.com> Fri, 11 June 2021 01:51 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 D201D3A2329; Thu, 10 Jun 2021 18:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.794
X-Spam-Level:
X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 5ipK-pYucdkh; Thu, 10 Jun 2021 18:51:35 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.rno.apple.com [17.179.253.48]) (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 891AA3A232B; Thu, 10 Jun 2021 18:51:35 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 15B1m7E8021468; Thu, 10 Jun 2021 18:51:34 -0700
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=TpUCUVHjVxi34+XB5OmKAz/PGLVoZAmvqUDI1wvTbAk=; b=ALlcEsXRTTMuw56YcIKOarrKGQoJP6PQQN5vMXXgEM56Q+/kTqwNYYhme5aGT+6XbbxW /SduuyagH2uI5GLfoXJnPd0QbXeme5DrOs5KjPUHO2Ay9bfhIMYCX/4LAqm999YlfL8W mP5ibepoiWJqlaziqXQwE29X7pBDi6thXp/idCBZsyj+NrO9CUEnSjAmQstCN1/x6/Yw a8RmVqCv+GP5x7qQ0vq9LYEkSyI3G80+t8atLlEmgYpENE5OmQiE9KZuMmue4WNup+A+ Jg4lKzfkcx1BqRBAx5BKoZxlExXOwLHgKIEDjZpyPsWwAfXghcSPun75kbE3M2vS6Ksl Sg==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 393h32drws-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jun 2021 18:51:34 -0700
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QUI00P1UL5XI750@rn-mailsvcp-mta-lapp01.rno.apple.com>; Thu, 10 Jun 2021 18:51:33 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QUI00J00KVYWV00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 10 Jun 2021 18:51:33 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 27026555779e17329268b9b32e8b8690
X-Va-E-CD: 2e6d0a645fe3cddf8de77c8cd0c1fb6b
X-Va-R-CD: 3d9c06b14119c365e7637b357762e6ee
X-Va-CD: 0
X-Va-ID: a87d6de0-10a9-4121-ab14-03c4131dab99
X-V-A:
X-V-T-CD: 27026555779e17329268b9b32e8b8690
X-V-E-CD: 2e6d0a645fe3cddf8de77c8cd0c1fb6b
X-V-R-CD: 3d9c06b14119c365e7637b357762e6ee
X-V-CD: 0
X-V-ID: 66d98c57-1a27-4825-ae01-61cd197a0adf
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-10_14:2021-06-10, 2021-06-10 signatures=0
Received: from smtpclient.apple (unknown [17.11.81.219]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QUI003J5L5XNW00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 10 Jun 2021 18:51:33 -0700 (PDT)
From: Vidhi Goel <vidhi_goel@apple.com>
Message-id: <87F5FEC9-87CC-4B94-AF63-011CD3C6AEB1@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_2DED57FF-8B66-4DD1-BFE8-0CDFE13CDD1F"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\))
Date: Thu, 10 Jun 2021 18:51:33 -0700
In-reply-to: <E687289E-D807-4CAF-81F8-3CDEAB6E224D@apple.com>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>, Yoshifumi Nishida <nsd.ietf@gmail.com>, draft-ietf-tcpm-rfc8312bis@ietf.org
To: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>
References: <CAAK044Q6Xy72-xsNdJ5yP0PDdo08N9zmAWickf13788E4u8cJw@mail.gmail.com> <CAAK044TxNs1B3VA1NzEgXyCRXSb8MHSNKkXeac2UFstQu7e8Mg@mail.gmail.com> <CAAK044QSo-0E_QHWDqrDE2VLEzOFEA4SxnHSX9DSKvSg-8y+pg@mail.gmail.com> <8DEC1E1C-B8DD-4199-AA49-F6AB7EC7C35E@eggert.org> <E687289E-D807-4CAF-81F8-3CDEAB6E224D@apple.com>
X-Mailer: Apple Mail (2.3654.100.0.2.11)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-10_14:2021-06-10, 2021-06-10 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/dDZjSTaKhtc_vnF5gudKjrEElGc>
Subject: Re: [tcpm] Comments for draft-ietf-tcpm-rfc8312bis-02
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: Fri, 11 Jun 2021 01:51:40 -0000
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=40apple.com@dmarc.ietf.org> 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 <lars@eggert.org <mailto:lars@eggert.org>> wrote: >> >> Hi, >> >> many thanks for the review! >> >> On 2021-6-1, at 11:35, Yoshifumi Nishida <nsd.ietf@gmail.com <mailto:nsd.ietf@gmail.com>> 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 >> tcpm@ietf.org <mailto:tcpm@ietf.org> >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] WGLC for draft-ietf-tcpm-rfc8312bis-01 Yoshifumi Nishida
- Re: [tcpm] WGLC for draft-ietf-tcpm-rfc8312bis-01 Yoshifumi Nishida
- [tcpm] Comments for draft-ietf-tcpm-rfc8312bis-02 Yoshifumi Nishida
- Re: [tcpm] Comments for draft-ietf-tcpm-rfc8312bi… Lars Eggert
- Re: [tcpm] Comments for draft-ietf-tcpm-rfc8312bi… Vidhi Goel
- Re: [tcpm] Comments for draft-ietf-tcpm-rfc8312bi… Vidhi Goel
- Re: [tcpm] Comments for draft-ietf-tcpm-rfc8312bi… Jonathan Morton