From: Sebastian Moeller <moeller0@gmx.de>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 12 Mar 2020 08:52:42 +0100
References: <7409b3a3-ba14-eb6d-154b-97c9d2da707b@bobbriscoe.net>
 <fe1b3c14f94d1fdd46b99d4fb057d093525310f0.camel@petri-meat.com>
 <0206bfc0-2c1b-64af-9fc4-ecb38e83be45@bobbriscoe.net>
 <E3D0E6F7-E7C2-4E7A-8283-283A447DBD29@gmx.de>
 <6f051485-30d7-b025-8dc4-1ca97694e29c@mti-systems.com>
To: tsvwg IETF list <tsvwg@ietf.org>,
 Wesley Eddy <wes@mti-systems.com>
In-Reply-To: <6f051485-30d7-b025-8dc4-1ca97694e29c@mti-systems.com>
Message-Id: <C80E0F87-D28F-4500-B5D4-53E060EE3117@gmx.de>
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/tsvwg/DV9_c6NnGjSfgm0lzW49zgbpVXU>
Subject: Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at
 tsvwg interim
Precedence: list

Hi Wes,

Thank you! More below in-line....=20

On March 11, 2020 4:50:01 PM GMT+01:00, Wesley Eddy =
<wes@mti-systems.com> wrote:
> On 3/9/2020 4:10 AM, Sebastian Moeller wrote:
>> QUESTION @Chairs: What are the conditions and aims for the TSVW WG in
> deciding to grant an RFC like L4S experimental status? I would love to
> get a clarification please.
>=20
>=20
> There are 3 chairs, and I only speak for 1, but the bottom-line is=20
> simply "WG rough consensus" (decently described in RFC 7282).

	[SM] Oha, that RFC was in equal parts interesting, enlightening, =
and unhelpful ;)=20

>=20
> Beyond that, I don't think we are adding or removing any explicit=20
> criteria.  The RFCs on congestion control evaluation cover things that=20=

> have traditionally been of interest/concern to the community in=20
> developing consensus that technologies were safe enough for
> experimental=20
> deployment on the Internet.  In the case of the technologies that are=20=

> proposing to use ECT(1) for experiments today, I don't think this is
> any=20
> different.

	[SM] I guess then I want to start a discussion about the =
starvation issue. RFC2914 about CC principles indicates strongly, that =
starving-out flows is unacceptable and equitable sharing of bandwidth =
(modulo some conditions) is desirable. But I will try to start that =
discussion in a separate thread about whether or not the current L4S =
implementation and design meets these principles sufficiently.


>=20
> As a chair, when sending to the IESG for recommended publication, I
> also=20
> want to see that:
>=20
> (1) There is wide interest in deploying the technology.
>=20
> (2) The concerns with it are understood well enough to be considered =
by
>=20
> people deploying it, and they are aware of what they might want to=20
> measure or what means are possible to mitigate problems.

[SM] Quite measured and convincing arguments.


>=20
> Sometimes the "experiments" don't clearly succeed (global deployment)=20=

> nor fail (nil deployment), but wind up very useful in some cases, and=20=

> not of interest in others.  In the case of ECT(1) (considered by =
itself
> without any DSCP-scoping), there probably should be some bit of a plan=20=

> or analysis around what happens if the technology persists in pockets=20=

> where it's useful, but doesn't have 100% deployment over the Internet.=20=

>=20
> We will need to consider the status of the ECT(1) codepoint, and how =
it
> can be used in the future whether these experimental specs are=20
> successful (widely deployed), partially successful (deployed in=20
> pockets), or failed (not deployed, or found defective and eventually=20=

> un-deployed).

[SM] That seems to acknowledge the fact that even a failed L4S =
experiment might spoil ECT(1) for a long time. This IMHO is supporting =
the idea that the experiment should only be started with mechanisms in =
place that allows a quick abort and recovery of ECT(1) on failure (given =
that there is an alternative proposal for ECT(1) usage in front of the =
WG). What are the technical arguments against rolling-out L4S =
experimentally in a cautious, measured safe and un-do-able way? The =
biggest arguments I hard so far were convenience (don't want to do more =
work than necessary) and easy of internet-wide deployment. IMHO the =
first is understandable but weak, while the second seems rather =
pre-mature given that L4S experiment and L4S as a a standard can be =
deployed using quite different methods and restrictions (so experiment =
under strict control and safety mechanisms and on success deployment =
under relaxed conditions seems like the obvious strategy).
Especially since the core questions L4S as an experiment is supposed to =
answer are a) will the positive lab-results also transfer into and =
materialize in the real-world  internet (functionality) and b) will they =
do so in a safe and compatible way with the existing internet (safety).=20=


Best Regards
         Sebastian