Re: [tsvwg] plan for L4S issue #29

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Tue, 29 September 2020 15:50 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 043513A0ECC for <tsvwg@ietfa.amsl.com>; Tue, 29 Sep 2020 08:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.623
X-Spam-Level:
X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, 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 2DJyymHQqr10 for <tsvwg@ietfa.amsl.com>; Tue, 29 Sep 2020 08:50:14 -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 B11E73A0ECB for <tsvwg@ietf.org>; Tue, 29 Sep 2020 08:50:14 -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 08TFnw9x068510; Tue, 29 Sep 2020 08:49:58 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 08TFnvFV068509; Tue, 29 Sep 2020 08:49:57 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202009291549.08TFnvFV068509@gndrsh.dnsmgr.net>
In-Reply-To: <alpine.DEB.2.20.2009282110300.20021@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike=40swm.pp.se@dmarc.ietf.org>
Date: Tue, 29 Sep 2020 08:49:57 -0700
CC: "Gorry (erg)" <gorry@erg.abdn.ac.uk>, "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/v1DTqJPtNuHl2Q7KfNsqsBEY4r4>
Subject: Re: [tsvwg] plan for L4S issue #29
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, 29 Sep 2020 15:50:16 -0000

> On Mon, 28 Sep 2020, Gorry (erg) wrote:
> 
> > At some point the working group needs to publish the spec. - This final 
> > stage is taking longer than I would hope, and I do hope that will be 
> > seeing a WGLC soon.
> 
> Do we actually?
> 
> I still haven't ruled out that we decide not to use these bits, for now, 
> because we don't know enough how it will affect the entire Internet.

I can support the "we don't know enough" statement.

Sadly this was not presented as a choice during the "vote" on
ECT(1) input vs output, but it should have been.  In fact I thought it
was going to be.  Alisha Cooper clearly mentioned it during her suggestion
to NOT attempt to take a consensus call during the end of the virtual
meeting due to lack of time.  Yet what came out was a different
3rd option, which personally I just do not understand as it was
extremely narrow.  Further what was presented to SCE as a selection
between ECT(1) as an input or output without any concern over this
being L4S vs SCE was clearly NOT presented to the WG in that light,
but instead clearly presented as exactly that, L4S vs SCE.


> This means declaring failure and say "no" to both SCE and L4S until 
> further notice.

Given that SCE is not an adopted work this is more or less
the defacto state for SCE, as it only gets WG time if the
chairs so decide it is worthy of spending it.  On the other
hand L4S has consumed a large amount of not only TSVWG time, but
also of TCPM and ICCRG, and issues with it identified long ago
have not progressed.  Is it time to put L4S to bed as a failure?
Perhaps, it claims to have a large group of supporters, yet the work
on it seems to be proceeding at glacial speed, and only by a few
visible people.

> 
> I think both L4S and SCE has problems and I think proponents for both are 
> glossing over some of these problems.

I do not believe that SCE has glossed over any problems,
when we see one we have noted it and infact gone to great
efforts to find problems, characterize them and seek solutions.
It has been often that during that process we have identified
problems with L4S, characterized them and provided feedback
to the WG on what we have found.

We are well aware of the defects in SCE and continue to work
on resolving them.  We fully admit that SCE, as it is documented
today, is not ready for deployment at scale, BUT we argue at least
it is SAFE to deploy at scale.

I would ask that you please identify a problem that SCE
has glossed over, so that we might make certain it is on
our known issues list and that we might address it.

> What happened to the L4S issue # 16 discussion? It seems to have died in 
> June with no conclusion?

Someone else in the thread has commented on this.

> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se

-- 
Rod Grimes                                                 rgrimes@freebsd.org