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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 24 May 2022 07:43 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4F2C157B4B; Tue, 24 May 2022 00:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.756
X-Spam-Level:
X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2-nRGi5D0Fp; Tue, 24 May 2022 00:43:40 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 78CDCC157B49; Tue, 24 May 2022 00:43:38 -0700 (PDT)
Received: from [192.168.1.64] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 021411B0007D; Tue, 24 May 2022 08:43:21 +0100 (BST)
Message-ID: <4a2b0971-1159-fe25-c31c-fcfe42c285f6@erg.abdn.ac.uk>
Date: Tue, 24 May 2022 08:43:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
To: "tcpm@ietf.org Extensions" <tcpm@ietf.org>, Lars Eggert <lars@eggert.org>
Cc: tcpm-chairs <tcpm-chairs@ietf.org>
References: <CAAK044R12B3f+=2mR1ZK15Zkno5n0YvsjGy64LBiBgBN+9n71A@mail.gmail.com> <CAK6E8=fZs--fR+5Rie1NgtrA4cviatVW=Aw+qkeuqstk9DB0Hw@mail.gmail.com> <CAAK044S3RnvbTzOSHR+B26XCFEiT=YbiNGqQUH4zV4T8c9ZfgA@mail.gmail.com> <864B7333-A8EA-4C9F-A4A7-5DAB49AA4245@eggert.org> <CAAK044TGaTBYwDYU=_JC_MEH4u3Ln4T60BFzXJe681cX6eZjpg@mail.gmail.com> <CAAK044TjuQyQzyHmJCyfuOTUJ5VnyPSVn+EDzdKxLPZ6uahShg@mail.gmail.com> <CAK6E8=feYY-rznoYOokRpphSRDb07MTELKPS02w9N1kwar5k4Q@mail.gmail.com> <CAAK044SHORdqn8+CpwhmJaQoHB+1EqHKjD44CD++N+8JrZ3BLw@mail.gmail.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
In-Reply-To: <CAAK044SHORdqn8+CpwhmJaQoHB+1EqHKjD44CD++N+8JrZ3BLw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/eb-9QEI0Srfr_D5Pb_dCqFhZrxY>
Subject: Re: [tcpm] Proceeding CUBIC draft - thoughts and late follow-up
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2022 07:43:42 -0000

I'll start by saying again that I think it is important to see this 
published as a PS (as others have noted), but I still think it needs 
additional text to say the process differs from the recommended IETF 
process and evaluation. I don't see how this will proceed without that 
text in some form as discussed at the IETF-113 meeting.  Alas, I also do 
not think highlighting this only in the Shepherd write-up, just 
postpones this as a discussion item to the IETF-LC, which can't be a 
useful thing to do.

I promised suggested text - but was unable to work on this after the 
meeting - sorry - so here goes, this is what I suggest:


"RFC 5033 provides the current BCP guidelines for the community, 
describing what type of evaluation is expected by the IETF to understand 
the suitabiliuty of an alternate congestion control, and the process to 
enable a specification to be approved for widespread deployment in the 
global Internet. The present document does not update that IETF BCP.

However, in the case of Cubic, there has been widespread deployment 
experience over a considerable period (4 years since publication of RFC 
8312). This experience was thought to be sufficient to allow this 
publication as an IETF standards-track specification.

There are areas in which the specified method differs from the 
previously method specified in published RFCs, some of which have been 
highlighted in this document. As a part of maintaining the congestion 
control document, future IETF work is expected to evaluate these 
differences and will if necessary update the relevent specifications."


This is not aimed at changing anything in the cubic algorithm, but it is 
aimed at explaining why this spec did not conform to the process, and 
seeking to avoid setting a precedent for future methods - which I really 
think do continue to need to be evaluated in public both by researchers 
and developers at the IETF.

Whether in future the IETF updates the BCP represented by RFC 5033 is 
another topic;-).

Best wishes,

Gorry