Re: [tsvwg] planning to close L4S issue #21

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Tue, 09 June 2020 15:26 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 64CC63A0900 for <tsvwg@ietfa.amsl.com>; Tue, 9 Jun 2020 08:26:19 -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 9ArxvYZYKJM3 for <tsvwg@ietfa.amsl.com>; Tue, 9 Jun 2020 08:26:18 -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 3EDF03A093E for <tsvwg@ietf.org>; Tue, 9 Jun 2020 08:26:18 -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 059FQCg0051437; Tue, 9 Jun 2020 08:26: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 059FQCos051436; Tue, 9 Jun 2020 08:26:12 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202006091526.059FQCos051436@gndrsh.dnsmgr.net>
In-Reply-To: <HE1PR0701MB2876395046B6EC58B6A1E9A0C2850@HE1PR0701MB2876.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Date: Tue, 9 Jun 2020 08:26:12 -0700 (PDT)
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>, "wes@mti-systems.com" <wes@mti-systems.com>, "ietf@gndrsh.dnsmgr.net" <ietf@gndrsh.dnsmgr.net>, "chromatix99@gmail.com" <chromatix99@gmail.com>
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/zonL8xwJ_BppKvaOcxiZplnuHJc>
Subject: Re: [tsvwg] planning to close L4S issue #21
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, 09 Jun 2020 15:26:19 -0000

Ingermar,

> Hi
> I have now read #16, #17 and #21 several times and my conclusion is that #21
> can be closed. 
> 
> /Ingemar

I am having difficutly here with the lack of any
rational for your conclusion.

Regards,
Rod

> 
> > 
> > > On 5 Jun, 2020, at 5:20 pm, Wesley Eddy <wes@mti-systems.com> wrote:
> > >
> > > If there's a specific aspect of #21 that justifies keeping it separate,
> that's
> > what I'm hoping someone will bring up.  This is without any regard to
> > engineering philosophy or workload optics.
> > 
> > Referring back to notes I took for the Montreal meeting, which IIRC was
> > where these issues were first drawn up, each issue corresponds roughly to
> a
> > line item on some slides provided by the Chairs, then referred to by a
> letter
> > code.  I recall standing up and talking specifically about a linked group
> of four
> > such points:
> > 
> > F: RFC-8311 does not in itself modify RFC-3168 to permit the redefinitions
> of
> > ECT(1) and CE that L4S demands.  Instead it refers to a requirement for
> > specific IETF approval before that may be done, specifically with respect
> to
> > Congestion Response Differences.  This is essentially issue #21.
> > 
> > No such approval with respect to CE has been given to date, as far as I
> know.
> > Even if we accept the recent decision to go forward with development of
> > ECT(1) as an input (which, incidentally, I do not), that cannot be taken
> as an
> > explicit confirmation that the alternate response to CE proposed by L4S is
> > also accepted.  By contrast the modified Multiplicative Decrease response
> > specified by RFC-8511 *has* been officially approved, by publication in an
> > RFC, on the grounds that it is sufficiently compatible with existing
> practice.
> > 
> > G: Incremental deployment requires compatibility with RFC-3168 AQMs,
> > which (still) has not been demonstrated satisfactorily.  We had serious
> > theoretical concerns which we had been able to validate by experiment,
> > partly at the Montreal Hackathon.  Of course we have refined those results
> > further since then.  I think this may refer to issue #22.
> > 
> > A: This was essentially issue #16.
> > 
> > B: This was essentially issue #17.
> > 
> > It is clear that there's a lot of common ground between the above four
> > points, which is why I addressed them together in a single narrative at
> > Montreal.  It might have been sensible to combine them into a single issue
> > for tracking at that time, but I think the points that were substantiated
> at that
> > meeting were just mechanically transcribed into the issue tracker.
> > 
> > Philosophically you could regard issue #16 (at least) as subordinate to
> #21, in
> > that the latter essentially causes the former.  Solve #21 by adopting a
> > different, non-ambiguous signalling mechanism for the high-fidelity
> > congestion signal, and it seems likely (especially given our practical
> evidence
> > to that effect) that issue #16 will also be solved.
> > 
> > Alternatively, we could regard #16 as the essential problem that must be
> > solved, and #21 as the most likely culprit.  This would make #21 the more
> > specific issue, and #16 the more general one, the reverse of what was
> > suggested.
> > 
> >  - Jonathan Morton
> > 
> > 
> > 
> > End of tsvwg Digest, Vol 194, Issue 4
> > *************************************

-- 
Rod Grimes                                                 rgrimes@freebsd.org