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

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Wed, 17 June 2020 14:19 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 8DC2B3A0863 for <tsvwg@ietfa.amsl.com>; Wed, 17 Jun 2020 07:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, 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 47qDpu-o25kg for <tsvwg@ietfa.amsl.com>; Wed, 17 Jun 2020 07:19:19 -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 7A4E53A0826 for <tsvwg@ietf.org>; Wed, 17 Jun 2020 07:19:19 -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 05HEJCrE085551; Wed, 17 Jun 2020 07:19:12 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 05HEJClG085550; Wed, 17 Jun 2020 07:19:12 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202006171419.05HEJClG085550@gndrsh.dnsmgr.net>
In-Reply-To: <2DC5C89B-C979-4354-98D7-BBDBC78A42B1@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Date: Wed, 17 Jun 2020 07:19:12 -0700 (PDT)
CC: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.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/sXsLt-y4NL7ozs8rz5vcJEAb9w0>
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: Wed, 17 Jun 2020 14:19:21 -0000

> > On 17 Jun, 2020, at 4:20 pm, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
> > 
> > Given all the input sofar my impression is that It is difficult to say how serious issue 16 really is. 
> > Surely there is a possibility that L4S flows can get an potentially unfair advantage over a congested node that is  RFC3168 capable (and ECN enabled). The question is here when things are deemed as unfair and when starvation is a fact, opinions differ. 
> > Another question is to how large extent there will be legacy RFC3168 ECN capable (and ECN enabled ) bottlenecks that will "never" be updated or replaced. This question is currently difficult to answer. 
> 
> When questions such as these are "difficult to answer", the correct design choice is to assume pessimistically, unless and until the question can be answered more definitively.  Therefore, the L4S design must account for the possibility of RFC-3168 AQMs in the network, and actively avoid unfairness in that case.
> 
> > Yet another aspect is how successful it will be to implement RFC3168 bottleneck detection e.g. in TCP Prague, I am quite confident that these will not always be successful.
> 
> I think we can safely say that the detection mechanism currently in TCP Prague is not successful.  David Black also pointed out that this would always be a fragile mechanism, difficult to implement correctly, and thus likely to be implemented wrongly by other transports even if a workable version was somehow developed.
> 
> With these facts established, I do not see how L4S can proceed without changing the signalling mechanism it uses.  This is something we intuitively realised more than a year ago, when the SCE project was started, but now we have actual evidence to back up that intuition.

And I would like to add to that, this is evidence the L4S team itself
should of identified, characterized and docuemented years ago.  I
see no reason that it took team SCE to disect the failure modes
of L4S so that they could be addressed.

IMHO the fact that L4S is years into the process and only done
positive test results presentations leads one to believe it
is simply being pushed through the process with little to no
care about the actual internet community.

The proponents seem to genuily be a) unwilling to acknowledge
that there a problems they should be working on, and b) presenting
that L4S is ready for internet deployment inlight of the fact
that data showing clear and present problems exist.

>  - Jonathan Morton
-- 
Rod Grimes                                                 rgrimes@freebsd.org