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

Lars Eggert <> Tue, 01 June 2021 09:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0851D3A0D3F; Tue, 1 Jun 2021 02:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J3l9ThnTNVgp; Tue, 1 Jun 2021 02:18:37 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 272143A0D3E; Tue, 1 Jun 2021 02:18:34 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5723F600315; Tue, 1 Jun 2021 12:18:24 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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 <>
Message-Id: <>
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.\))
Date: Tue, 1 Jun 2021 12:18:23 +0300
In-Reply-To: <>
Cc: " Extensions" <>,
To: Yoshifumi Nishida <>
References: <> <> <>
X-MailScanner-ID: 5723F600315.A0584
X-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [tcpm] Comments for draft-ietf-tcpm-rfc8312bis-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Jun 2021 09:18:42 -0000


many thanks for the review!

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

Note that we did discuss CUBIC for QUIC in

> 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

> 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

> 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

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


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


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


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


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


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


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


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