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

[Christian Huitema <[e-mail]>]

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:
>
> 	net.inet.tcp.cc.algorithm: 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