Re: [tcpm] Proceeding CUBIC draft - thoughts and late follow-up

Christian Huitema <> Wed, 22 June 2022 05:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73E09C157B3F for <>; Tue, 21 Jun 2022 22:27:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.786
X-Spam-Status: No, score=-8.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vcxvuRcj6k1c for <>; Tue, 21 Jun 2022 22:27:42 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id EB304C14CF06 for <>; Tue, 21 Jun 2022 22:27:42 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1o3stl-0008Ka-CO for; Wed, 22 Jun 2022 07:27:41 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4LSX2N6rqzz9hJ for <>; Tue, 21 Jun 2022 22:27:24 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1o3stg-0006aG-RU for; Tue, 21 Jun 2022 22:27:24 -0700
Received: (qmail 19043 invoked from network); 22 Jun 2022 05:27:24 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 22 Jun 2022 05:27:23 -0000
Message-ID: <>
Date: Tue, 21 Jun 2022 19:27:21 -1000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: "Rodney W. Grimes" <>, Martin Duke <>
Cc: Vidhi Goel <>, Markku Kojo <>, " Extensions" <>, tcpm-chairs <>
References: <>
From: Christian Huitema <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yjTC8Fov82/EJuxz8FihBPKj/EwzSHE5FGYwwjsNRPCPG5 DABYaEGtvhnfpDaPHiHmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imca44amlqA1DMizheOpkPv9TBQ6V51u76v35b1wNe/MvdLK0iWX QXXTLFLETKH72XTe2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7hMIABpqqRGKyDs8xujM3cqBeOl1vvorVlRuGVSovFiMT6PNOGYhx//Mh1O7Zz7Lb9B vrdwbx5ARUIUDng4r6LvEnFzsC48bTEFY06/YbB87Ww8G0LoS8V3Mt1pta8qAcLtCB3G1CwpaI3Z 4ESkMWDVJEenxBoIht3V0nekAoxXAkA7P3c4WY86nkWU4oetU5qyuLfHqAnAj7rgKH7+eCmmW30C 0MMX4yoyt+KqxmKvEFShcA6Xvva2QAVEjpqzANap+28aWyCRVT7YkY7LckVcbBfg1My+R4LLvB1X HQXYtr13qFZSq8Fx+9otn0aqja8VKPqpdskk5LxBR/9t1zMMkdu6/R2FM84kxYRFSvC1IDg1BRW7 hzp8w3iHcOwbVtsmWfnQGGis4EvbR3jXsI0ESXwhBU2hwt/J18C+HygJl/jEzm1SsR8v3aJbN/NZ fa8pHhHaz+HPa0HAgEx4sWDF
Archived-At: <>
Subject: Re: [tcpm] Proceeding CUBIC draft - thoughts and late follow-up
X-Mailman-Version: 2.1.39
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, 22 Jun 2022 05:27:43 -0000

On 6/21/2022 12:54 PM, Rodney W. Grimes wrote:
>> In the case of Cubic, it is *extremely widely* deployed. Whether or not
>> doing damage to Reno connections was justified, we have already sped
>> through (2) and have landed on (3). Cubic is the default and users
>   [rwg]
> Default where?  As far as I know FreeBSD, and I believe other BSD's
> use newreno as the default:
> newreno
> And from the mod_cc(4) manual page of FreeBSD 12.x:
>       The default algorithm is NewReno, and all connections use the default
>       unless explicitly overridden using the TCP_CONGESTION socket option (see
>       tcp(4) for details).  The default can be changed using a sysctl(3) MIB
>       variable detailed in the MIB Variables section below.
> I doubt there is a bunch of userland code calling with TCP_CONGESTION
> socket options.

That may be true for FreeBSD, but Cubic is now the default in Linux and 
in Windows.

As Lars said, what is gained by not recognizing CUBIC as a standard? I 
cannot tell, systems deploying Cubic are certainly not going back to 
Reno. (They might switch to BBR, but that's another discussion.) What I 
can tell is what is *lost* by not recognizing CUBIC as a standard: the 
credibility of the IETF. It would be yet another coat for painting it as 
hanging to obsolete old things rather than acknowledging how the 
Internet actually works.

>> As for RFC 9002: this was an expedient choice; QUICWG needed a standard
>> congestion control, was not chartered to create a new one, and there was
>> only one on the shelf to choose from. If Cubic had been standards-track,
>> the WG may very well have chosen that one. In the real world the most
>> important production QUIC implementations are not using Reno.

+1. Actual deployments of QUIC use Cubic or BBR.

-- Christian Huitema