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

"Scharf, Michael" <> Tue, 22 February 2022 10:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 733023A0C38; Tue, 22 Feb 2022 02:03:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_NONE=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 cL62eJxbMhBQ; Tue, 22 Feb 2022 02:03:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4ADE73A0C52; Tue, 22 Feb 2022 02:03:41 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 7B42A25A13; Tue, 22 Feb 2022 11:03:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1645524219; bh=rhIx6CO4g2itifNGy+B2D6RWyHA6gAm2cC45+GcJONQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=nZ95eJSFCNtAzjJF94exnpP9q4Ky0uGraa0CZ21nXZSksGfAxUX910iq0fHGYYe9j Kj7e28lu5GWje3p4R9fLN8DTQSS8gFtjYDORJ9TnWBWYTrytsVAK7OQ0QmfKZ0k2Qq Id/YaMyHDIqwcndslX9Hv+u4S2YpwPVMJKhdEQnc=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rWsZoVglDOaO; Tue, 22 Feb 2022 11:03:38 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Tue, 22 Feb 2022 11:03:38 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.18; Tue, 22 Feb 2022 11:03:38 +0100
Received: from ([fe80::aca4:171a:3ee1:57e0]) by ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2375.018; Tue, 22 Feb 2022 11:03:38 +0100
From: "Scharf, Michael" <>
To: Lars Eggert <>, Yoshifumi Nishida <>
CC: Markku Kojo <>, " Extensions" <>, tcpm-chairs <>
Thread-Topic: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis
Date: Tue, 22 Feb 2022 10:03:38 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 22 Feb 2022 10:03:49 -0000

Hi all,

As always in a discussion about EXP vs. PS, I suggest having a look at the definition of Proposed Standard, e.g., in RFC 7127:

   A Proposed Standard specification is stable, has resolved known
   design choices, has received significant community review, and
   appears to enjoy enough community interest to be considered valuable.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable and will
   usually represent a strong argument in favor of a Proposed Standard

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the

   A Proposed Standard will have no known technical omissions with
   respect to the requirements placed upon it.  Proposed Standards are
   of such quality that implementations can be deployed in the Internet.
   However, as with all technical specifications, Proposed Standards may
   be revised if problems are found or better solutions are identified,
   when experiences with deploying implementations of such technologies
   at scale is gathered.

As an individual contributor to TCP and congestion control research, I believe that a CUBIC specification can meet these requirements.

Maybe the "no known technical omissions with respect to the requirements placed upon it" could benefit from some text inside rfc8312bis to make clear what the requirements are, i.e., what the standard tries to achieve (and what not). But, at least to me, the current section 5 already covers that. I am not against adding some more text on the scope of rfc8312bis, but I'll certainly not insist in that.

Also, another repetition of what I wrote already in the past:

In my observation, TCPM is extremely conservative when it comes to standards track documents, as compared to other WGs in the IETF (also outside TSV, e.g., in RTG or OPS). Probably that is not a bug, but a feature in a standardization body. And at least I have not tried to change that thinking as chair in the last 10 years. Nonetheless, if a document can meet the bar for a PS, I believe TCPM should try to go for a PS.

Michael (not wearing any hat)

> -----Original Message-----
> From: Lars Eggert <>
> Sent: Monday, February 21, 2022 3:52 PM
> To: Yoshifumi Nishida <>
> Cc: Markku Kojo <>; Extensions
> <>; tcpm-chairs <>
> Subject: Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis
> Hi,
> first, as an editor (but not wearing other hats) I do object against reclassifying
> the document as Experimental or Informational, esp. this late in the process.
> CUBIC is not a new CC proposal. It's been ubiquitously deployed on the
> Internet for many years. All major TCP stacks use it by default. Given that, I
> don't see how the IESG statement on "Experimental Specification of New
> Congestion Control Algorithms" applies here.
> (As an aside, that statement was specifically written when CUBIC, Compound
> and Hamilton were all jostling for RFC publication. The community converged
> on CUBIC in the meantime.)
> CUBIC *is* the default CC mechanism used on the Internet and in other IP
> networks. It should be published on the standards track.
> Second, this is the second time that an individual raised a long list of issues
> after the WGLC has ended. We did try to work through all the issues that
> were raised after the first WGLC, but the individual often failed to participate
> in the discussion in a timely manner. I now see at least several of those same
> issues re-raised by the same individual. Before going down the same path a
> second time, I would actually ask the WG to confirm there is consensus that
> the raised issues are valid (and if they are valid, commit to contributing to a
> resolution in a timely manner.)
> Thanks,
> Lars