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

Lars Eggert <lars@eggert.org> Tue, 01 June 2021 09:18 UTC

Return-Path: <lars@eggert.org>
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 0851D3A0D3F; Tue, 1 Jun 2021 02:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=eggert.org
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 J3l9ThnTNVgp; Tue, 1 Jun 2021 02:18:37 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272143A0D3E; Tue, 1 Jun 2021 02:18:34 -0700 (PDT)
Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 5723F600315; Tue, 1 Jun 2021 12:18:24 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1622539104; bh=XbyJuwxHEKoL1Q0CIzSXpbFRg0X6ngxc40+J9Ui7geY=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=e39SrRQhNG7gyV/OPbKQQS+Vy0st1gztBBH2W9TuQIUv5BOFMWn43Jt+xuMLMHoeS LfY67hTA0XOB5lvRHeXaltQcB69TacLBTiZN4wycrkMHarEfpL++jafQ0fZ58MJF9+ 8MmWIYUXOcqgx/qys5+Bn35DmOa+w9AUb6uc0/VI=
From: Lars Eggert <lars@eggert.org>
Message-Id: <8DEC1E1C-B8DD-4199-AA49-F6AB7EC7C35E@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_34BA0137-614B-4143-B281-A10864F5E1C0"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Tue, 1 Jun 2021 12:18:23 +0300
In-Reply-To: <CAAK044QSo-0E_QHWDqrDE2VLEzOFEA4SxnHSX9DSKvSg-8y+pg@mail.gmail.com>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>, draft-ietf-tcpm-rfc8312bis@ietf.org
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
References: <CAAK044Q6Xy72-xsNdJ5yP0PDdo08N9zmAWickf13788E4u8cJw@mail.gmail.com> <CAAK044TxNs1B3VA1NzEgXyCRXSb8MHSNKkXeac2UFstQu7e8Mg@mail.gmail.com> <CAAK044QSo-0E_QHWDqrDE2VLEzOFEA4SxnHSX9DSKvSg-8y+pg@mail.gmail.com>
X-MailScanner-ID: 5723F600315.A0584
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ICfFRLECYnb_2cR9h0Zr_h9rrHQ>
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: Tue, 01 Jun 2021 09:18:42 -0000

Hi,

many thanks for the review!

On 2021-6-1, at 11:35, Yoshifumi Nishida <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 for this.

Note that we did discuss CUBIC for QUIC in 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

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

> 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

> 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

> 6: Section 4.3  The description for P is required for Figure 3.

Opened 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

> 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

> 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

> 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

> 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

> 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

Thanks,
Lars