Re: [tsvwg] path forward on L4S issue #16

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Tue, 23 June 2020 04:27 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 CCF093A093C; Mon, 22 Jun 2020 21:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=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 bPhd6Qq7S79T; Mon, 22 Jun 2020 21:27:15 -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 835943A091F; Mon, 22 Jun 2020 21:27:15 -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 05N4RDm7013645; Mon, 22 Jun 2020 21:27:13 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 05N4RCPD013644; Mon, 22 Jun 2020 21:27:12 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202006230427.05N4RCPD013644@gndrsh.dnsmgr.net>
In-Reply-To: <e76998a5-dbc5-375e-0cec-4d756b497b13@mti-systems.com>
To: Wesley Eddy <wes@mti-systems.com>
Date: Mon, 22 Jun 2020 21:27:12 -0700 (PDT)
CC: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>, "Holland, Jake" <jholland=40akamai.com@dmarc.ietf.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/Jm4XvXBheTIC9vmLiRY3xXkK-u8>
Subject: Re: [tsvwg] path forward on L4S issue #16
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: Tue, 23 Jun 2020 04:27:17 -0000

Hello Wes,

Excuse me, but L4S itself even defined DSCP as one of the
alternative mechansims to ECT(1).  Are you saying we should
remove those alternatives from the draft?

Further on several occasions David Black, and others have asserted that
DSCP is a viable path forward for L4S.

How are these solutions suddenly not to be included in the considerations
of what may be a way to address Issue #16?  These are solutions that
can be used today, though the global traversal is not a requirement
for them to be used, and they are infact being used to conduct SCE
experimentation.  I find it unsettling that L4S proponets would not
consider this as a way to produce data that might influence the WG.

No comments inline,
Regards,
Rod

> Hi Rod, I just have a short comment from what I have seen as the WG 
> interests.
> 
> I have not noticed much interest in DSCP global traversal, especially 
> from the parties that would need to support it.? Since that is also 
> explicitly against the DiffServ architecture that incorporates 
> re-marking, suggesting it is a rather big change to all of how DiffServ 
> has been defined, unless I misunderstand.? I believe any activity or 
> proposals on global DSCP traversal are very interesting and totally fine 
> to discuss, but can't be a gate for L4S.
> 
> 
> On 6/19/2020 11:14 PM, Rodney W. Grimes wrote:
> > Jake,
> > 	Thank you for spending the time to collect this
> > detailed summary.
> >
> > 	I believe you left out: (adding one to your last one and listing)
> >
> >   7.  Use a DSCP to seperate the experiment, leaving ECT(1) and CE as
> >       currently specified in the L4S draft.
> >
> >   8.  Use a DSCP to classify the traffic as L4S and leave ECT(1) unused,
> >       altering CE semantics.
> >
> >   9.  Use a DSCP to classify the traffic, and use ECT(1) as a 1/p signal,
> >       leaving CE semantics in place.
> >
> > 10.  Dropping L4S as over promising and short delivering with complexity
> >       that almost certainly sets it up for a failed deployment.
> >
> > Note that in all 4 of these solutions bleaching is unlikely to be
> > used if there are problems, and the experiment is rather trivial to
> > terminate if there are problems.  These also keep ECT(1) avaliable
> > for a future non-experiment version of L4S should the experiment work,
> > or something else should it fail.  7 to 9 can even be started today
> > without an IETF consenses and some real operational data created.
> >
> > On the side, IMHO, the work going into L4S would be better spent addressing:
> > a)  DSCP global traversal
> > b)  ack thinning being underspecified such that it creates protocol
> >      problems.  Specifically the fact it tosses out changes in reserved
> >      bits by thinning packets with different bit values.  This was
> >      identified years ago and left as a problem, it needs cleaned up.
> > c)  Revision to RFC6040 and other tunnel related drafts to clear
> >      the issues there.  Again, identified years ago and left to clean
> >      up.
> 
-- 
Rod Grimes                                                 rgrimes@freebsd.org