IETF Logo Mail Archive

Re: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.txt

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Thu, 25 February 2021 13:54 UTC

Return-Path: <ietf@gndrsh.dnsmgr.net>
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 E0D723A15A6 for <tcpm@ietfa.amsl.com>; Thu, 25 Feb 2021 05:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level:
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhDbj9iwQ5a5 for <tcpm@ietfa.amsl.com>; Thu, 25 Feb 2021 05:54:21 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570F93A19EA for <tcpm@ietf.org>; Thu, 25 Feb 2021 05:54:20 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 11PDsBCg025846; Thu, 25 Feb 2021 05:54:11 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 11PDsBsn025845; Thu, 25 Feb 2021 05:54:11 -0800 (PST) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202102251354.11PDsBsn025845@gndrsh.dnsmgr.net>
In-Reply-To: <3B032C7A-6C01-4AF7-94A2-C8AD9D08DDDB@eggert.org>
To: Lars Eggert <lars@eggert.org>
Date: Thu, 25 Feb 2021 05:54:11 -0800
CC: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, tcpm IETF list <tcpm@ietf.org>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/YhklIpXH6OB_qvQpqW6EkuqDxaQ>
Subject: Re: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 25 Feb 2021 13:54:23 -0000

Hello Lars, WG members,
	One comment inline below marked [RWG]

> Hi,
> 
> On 2021-2-24, at 20:47, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
> > 1/ Version -02 was submitted 2 days ago and at least I *always* read drafts
> > entirely before any formal action. A large number of drafts was submitted in
> > the last days as well, i.e., my reading list is not empty. And at least I do
> > have a day job, too.
> 
> understood. I did make the same request when -01 was posted already, hence I was wondering if it had fallen through the cracks.
> 
> > 3/ I am not sure whether we have to seriously discuss *whether* to adopt a
> > widely implemented specification. But there could be some questions on the
> > *how*. For instance, would ICCRG have to be in the loop?
> 
> They could, but I don't know if they have to. IIRC we run new CC schemes by them for review, but this isn't really one of those.
> 
> > How about use beyond
> > TCP, e.g., would a syncing with the QUIC WG make sense (you may actually have
> > a better understanding on that than me)?
> 
> We have https://github.com/NTAP/rfc8312bis/issues/45 open for that. It not clear at this time whether any additional text is needed to explain more about how QUIC would use CUBIC, a bunch of changes were made already to this purpose.
> 
> > And are there any TCP RFCs that
> > assume that only a single standard congestion control exist and that would
> > perhaps have to be updated?
> 
> I'm sure there are a bunch of TCP specs that only cite NewReno, but that's probably OK? I'm not sure if finding and updating them just to say "you may also use CUBIC" is all that worthwhile. Also, we didn't do this for 8312 (or any other experimental/informational CC scheme) so it's not clear why we'd do so for 8312bis.

 [RWG] I think the difference here that may warrant at least some updates to some RFC's is that CUBIC is moving to a PS.  So any existing STD or PS that is affected by the fact there is now a new CC at PS level should be updated to reflect that availability.

Regards,
Rod

> Thanks,
> Lars
> 


> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
Rod Grimes                                                 rgrimes@freebsd.org

v2.23.0 | Report a Bug | By Email