Re: [tsvwg] plan for L4S issue #29

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 29 September 2020 16:04 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 4D9C13A0EE7 for <tsvwg@ietfa.amsl.com>; Tue, 29 Sep 2020 09:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 d-I7UsmZXqVb for <tsvwg@ietfa.amsl.com>; Tue, 29 Sep 2020 09:04:52 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 594123A0EE1 for <tsvwg@ietf.org>; Tue, 29 Sep 2020 09:04:52 -0700 (PDT)
Received: from ERG-research.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 62F991B00226; Tue, 29 Sep 2020 17:04:19 +0100 (BST)
To: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>, Mikael Abrahamsson <swmike=40swm.pp.se@dmarc.ietf.org>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <202009291549.08TFnvFV068509@gndrsh.dnsmgr.net>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <c7080365-233c-5f1e-ef5c-1f42c969042a@erg.abdn.ac.uk>
Date: Tue, 29 Sep 2020 17:04:17 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <202009291549.08TFnvFV068509@gndrsh.dnsmgr.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/6_5OeD6tz-s-cak7lmGqDLX5ciE>
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 16:04:54 -0000

See below.

On 29/09/2020 16:49, Rodney W. Grimes wrote:
>> 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?
Yes.
>> 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.

Still possible, if the WG as a whole decides that.

> 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
Gorry