Re: [tsvwg] Review comments on a careful read of the L4S ID

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Fri, 07 May 2021 12:23 UTC

Return-Path: <ietf@gndrsh.dnsmgr.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23903A1EA2 for <tsvwg@ietfa.amsl.com>; Fri, 7 May 2021 05:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 bH1zD3dpt-n8 for <tsvwg@ietfa.amsl.com>; Fri, 7 May 2021 05:23:12 -0700 (PDT)
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 5A5263A1ECA for <tsvwg@ietf.org>; Fri, 7 May 2021 05:23:12 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 147CN4vD048942; Fri, 7 May 2021 05:23:04 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 147CN328048941; Fri, 7 May 2021 05:23:03 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202105071223.147CN328048941@gndrsh.dnsmgr.net>
In-Reply-To: <1323d4b6-326e-f35d-b481-4921d5f52b8e@erg.abdn.ac.uk>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Date: Fri, 07 May 2021 05:23:03 -0700
CC: "Black, David" <David.Black@dell.com>, Tom Henderson <tomh@tomh.org>, "tsvwg@ietf.org" <tsvwg@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/tsvwg/VrHGMYwSNZEwl8JkE7HukYNSiPQ>
Subject: Re: [tsvwg] Review comments on a careful read of the L4S ID
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2021 12:23:17 -0000

Gorry, 

> Tom/David,
> 
> Aha - I see now. Another possibility could be something like:
> 
> "Explicit Congestion Notification (ECN) Protocol for Ultra-Low Queuing Delay (L4S)" ??
                                          ^^^^         ^^^^
May I remind you that you have rejected the use of the word/phrase
"Ultra-Low" as marketing hype  and also rejected this draft as a Protocol
spec.

Stealing this from RFC 3168:
	"The Addition of Explicit Congestion Notification (ECN) to IP"

I derive this:

	"The Modification of Explicit Congestion Notification (ECN) in IP"

As far as I descern here L4S signalling is a modification of the
Internet Protocol (IP), as it has been modified by RFC3168, ECN.

Another might be:
	"The Redefinition of the Explicit Congestion Notification (ECN)
	Congestion Experienced (CE) signal"

For me this last one is more precise about what this draft is attempting,
but is a bit long..

Regards,
Rod
> 
> Gorry
> 
> 
> On 06/05/2021 21:30, Black, David wrote:
> > Tom,
> >
> > I'm the source of pushback here.  In my view, L4S is an interesting mix, as the L4S ID draft does not define a complete protocol - rather, it specifies the ECN marking mechanism and places requirements on the endpoint congestion control response without specifying that response in detail (e.g., to implement TCP Prague congestion control based on L4S, one also needs to also go look at a TCP Prague spec).
> >
> > I'd be happy with "mechanism" or "functionality" but I don't see a fully implementable "protocol" here.  What do you think?
> >
> > Thanks, --David
> >
> > -----Original Message-----
> > From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Tom Henderson
> > Sent: Thursday, May 6, 2021 1:19 PM
> > To: Gorry Fairhurst
> > Cc: tsvwg@ietf.org
> > Subject: Re: [tsvwg] Review comments on a careful read of the L4S ID
> >
> >
> > [EXTERNAL EMAIL]
> >
> > On 5/5/21 11:52 PM, Gorry Fairhurst wrote:
> >> =================================================================
> >>
> >> *5. Please be careful with the words here.*
> >>
> >> **
> >>
> >> This text:
> >>
> >> ?This specificationdefines _the protocol to be used for_ a new network
> >>
> >> service called low latency, low loss and scalable throughput (L4S).?
> >>
> >> **
> >>
> >> ?This document does not define a protocol, so the words "_the protocol
> >> to be used for" _should be removed.
> > Gorry, on this point, I made the original suggestion to call this a
> > protocol document during the -13 review (email to the list on March 7);
> > please see below my original comment regarding this.
> >
> > - Tom
> > Explicit Congestion Notification
> >   > (ECN) Protocol for Ultra-Low Queuing Delay (L4S)
> >
> >   >
> >   > Title
> >   >
> >   > The title of this draft suggests that the scope is narrowly defining
> >   > the identifier of L4S semantics, but the draft covers much more than
> >   > this; in fact, it perhaps it could more accurately be described as an
> >   > L4S protocol specification.  At the end of the abstract, the draft
> >   > states "This specification defines the rules that L4S transports and
> >   > network elements need to follow...", i.e. a protocol.  It also gets
> >   > into operational considerations and open questions for experimentation.
> >   >
> >   > Perhaps a broader title such as "" would better match
> >   > the contents.
> >
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org