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

Bob Briscoe <> Wed, 23 February 2022 18:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EA2B3A117D; Wed, 23 Feb 2022 10:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.813
X-Spam-Status: No, score=-2.813 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KjdTMkv9OWBK; Wed, 23 Feb 2022 10:44:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 471483A11B9; Wed, 23 Feb 2022 10:44:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=k+IsnwCoNaXOqiiuW4kLI5BvO/E9e7A4gaDIGcq/Mr8=; b=CGXqCbGglrqeMye4VY3AWHZ3w0 ImhIX/iUZ4E52FjbMe8zj+DUQlUlfA+u39K+/fmquR3lma1JBpjRmkxQpHRCN21er/012zVM+jcgz gRkjGZcg2hoDT9GSKVKDsDcCRUbYtGC1+3rezYoDzzrKVK5CDXBWLW5LCfCv8BGMuskiNmitQrnlq yVW5O9U6KdcmFZORDTmSOMeBpcjKtYIUpWtV/yP9KAMgmoPd6fy+RS8fig3k5LMEaWsfE38lHhm9R C7mrbiE8TdYrtnHIUK+l+1SOBbZhnE8f5Yf5+Xn1lpOA1S+uhgSSC0XWUZDJPalpzjrQ7TYOwZTWF RZjiY97Q==;
Received: from ([]:55606 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1nMwcr-0001NM-Ks; Wed, 23 Feb 2022 18:44:28 +0000
Content-Type: multipart/alternative; boundary="------------h4IKHyF3ne24kFNzVgFQXRoX"
Message-ID: <>
Date: Wed, 23 Feb 2022 18:44:23 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-GB
To: "" <>
Cc: Yoshifumi Nishida <>, Markku Kojo <>, " Extensions" <>, tcpm-chairs <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
In-Reply-To: <>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis
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: Wed, 23 Feb 2022 18:44:37 -0000


On 23/02/2022 15:17, wrote:
> Hi, Bob (et al.),
>> On Feb 21, 2022, at 4:11 PM, Bob Briscoe <> wrote:
>> Yoshi, Markku,
>> Many of the technical points Markku raised were important omissions 
>> from the rfc8312bis draft. Whatever status we give the eventual RFC, 
>> they should be highlighted as areas that need further work, either 
>> known weaknesses or just areas where we don't have enough data to 
>> know whether they are weaknesses. I tried to help find useful 
>> references for experiments already done around those points, and I 
>> tried to help write such text.
>> However, I cannot agree with some of Markku's statements about process.
>>       #1: The rules can change
>> ...
>>       #2: There is no TCP-compatibility requirement
>> Yes, CUBIC is not TCP-compatible. But that's a feature, not a bug. 
>> Words like 'TCP-compatible' or 'fair' sound nice, but do not be 
>> fooled into thinking that an RFC recommends or requires you to behave 
>> in a certain way just because it has used a nice-sounding word for it.
>> For an RFC to recommend or require something, it has to say SHOULD or 
>> MUST. So when BCP 41 [RFC2914] defines 'TCP-compatible', and talks 
>> about what is necessary to be 'fair', it implies nothing about 
>> whether you should or must be TCP-compatible, or fair; unless it 
>> actually says you SHOULD or MUST be TCP-compatible, or fair. *No RFC 
>> says that.*
> RFC 5681 "*TCP Congestion Control**”***(standards-track) says 
> (emphasis mine below):
> 3 <>. 
> Congestion Control Algorithms
>     This section defines the four congestion control algorithms: slow
>     start, congestion avoidance, fast retransmit, and fast recovery,
>     developed in [Jac88  <>] and [Jac90  <>].  In some situations, it may be
>     beneficial for a TCP sender to be more conservative than the
>     algorithms allow; however, a T*CP MUST NOT be more aggressive than the following algorithms allow 
> (that is, MUST NOT send data when the value of cwnd computed by the 
> following algorithms would not allow the data to be sent)*.
> That looks like a MUST that defines fairness to me.

[BB] Nice point. I usually consider that requirements in an RFC mandate 
what implementers have to do to claim compliance with that RFC. But this 
one does indeed seem to be setting its reach much wider, to any 
implementation of the TCP protocol, not just implementations of this CC.

If that is how we are meant to read it, it contradicts BCP 133 [RFC5033] 
that I quoted earlier. So, I guess people will pick which one they prefer.

As far as implementation compliance is concerned, hardly any TCP 
implementation in use complies with this mandate any more. And even at 
the time it was published (2009), it already wasn't being followed by 
many/most Windows and Linux machines (Compound and Cubic were introduced 
in 2006). I notice this wording was added in RFC2581 (1999), so the 
non-compliance crept up on the IETF, and by republishing these words 
unchanged, I guess this looks like the IETF perpetuating a pious hope 
that TCPs will comply.

So, if we do make CUBIC PS, it will need to update this para in RFC5681.


> Joe

Bob Briscoe