Re: [tsvwg] What TCP to target in TCP-friendly [was:A word for "does not have a significantly negative impact on traffic using standard congestion control"?]

Bob Briscoe <> Mon, 22 March 2021 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5F9E3A1720 for <>; Mon, 22 Mar 2021 07:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.774
X-Spam-Status: No, score=0.774 tagged_above=-999 required=5 tests=[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.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bv6m-70BrM7q for <>; Mon, 22 Mar 2021 07:51:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E53163A1718 for <>; Mon, 22 Mar 2021 07:51:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=3lkID+GRveTt+2YARlCcukff6uYeru63+SZ6ecKQtT8=; b=MJOYf5y1oQLkI/Hrq8AstbbqY ngZbzc5mAr3pPLsorqZ5VNH5+eMLuYCAW2cVvZrQQp7fkfD6asWHcoHhcvPpG/RDpHyy2UefiN2M+ TtYfB+8JBcTqFdUmeijtFeq5Qy6kgqxbixtgnG1r1kJl+l52IYdqlaIRWmGgqHjaW1T+YC2GtazoN SWDVk892yizYsE/vGl0+bQZ/RYDfxab4al21E4Iqj4RQ7f9wUTzwTmBluKvuwmQ8DWeQQSSk1v0O1 KTg3i8M2Rzbit0x3zuHGBVJkoS/FRjlvOQKfSqgDkA3JnAq2f/hgTCYjwWRAL6jPdCuZnM2k+gCM/ ubF63Z3pg==;
Received: from ([]:46106 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1lOLtt-0004bg-Q4; Mon, 22 Mar 2021 14:51:25 +0000
To: Gorry Fairhurst <>, Sebastian Moeller <>
Cc: tsvwg IETF list <>
References: <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Mon, 22 Mar 2021 14:51:24 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------81C552975C0787E8D7874A84"
Content-Language: en-GB
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: [tsvwg] What TCP to target in TCP-friendly [was:A word for "does not have a significantly negative impact on traffic using standard congestion control"?]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Mar 2021 14:51:30 -0000


In my original question on this thread, this wasn't about which TCP to 
compare against (when Sebastian said that, I didn't correct him). My 
original question was about how to describe the fall back behaviour in 
response to a loss. The draft currently says:

       ...a scalable congestion
       control MUST react to packet loss in a way that will coexist
       safely with a TCP Reno congestion control [RFC5681  <>] (see
       Section 1.2  <>  on Terminology for definition of Reno-Friendly and
       Appendix A.1.3  <>  for rationale)

When I wrote that I had no intention of it meaning "Fall back to Reno." 
I had in mind that Cubic is considered Reno-Friendly, so I had figured 
that choice of words would not preclude falling back to something like 

However, a number of survey respondents were concerned that it might 
preclude their favourite congestion response, with less sensitivity to 
loss than Reno. Hence the quest for a clearer form of words.


On 16/03/2021 12:14, Gorry Fairhurst wrote:
> On 16/03/2021 09:39, Sebastian Moeller wrote:
>> Dear All,
>> in the cited response Bob proposes to define TCP Reno as the 
>> reference TCP all TCP-friendly protocols need to be compatible with. 
>> I had a quick look at what TCP CCs are actually in use, and according 
>> to wikipdia, all major operatig systems, Windows10 (since 1709, 
>> 2017), MacOs (since Yosemite, 2014), Linux (since 2.6.19, 2006) 
>> converged on CUBIC as the default TCP congestion control algorithm.
>> Given that data, I propose to not enshrine YCP Reno's behavior as the 
>> current applicable reference, but instead TCP CUBIC.
>>     For the L4S drafts that does not change much, because the dualQ's 
>> unfairness towards non-L4S-CCs does not seem to care for the exact 
>> way a CC is NOT L4S,
> <snip>
>> Best Regards
>>     Sebastian
> This seems an editorial matter that we should simply get correct. The 
> IETF has a PS specification for Reno. RFC 8312 is informational, but 
> TCPM recently adopted draft-ietf-tcpm-rfc8312bis-00, targeting 
> Informational status.
> My own (personal) suggestion is that we use text that says a "CC 
> specified in a standard's track RFC" and give refs to both Reno and 
> Cubic as examples, although I'd be interested in others views also.
> Gorry

Bob Briscoe