Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <2CC63847-707F-4B50-8F44-CFC6CD22F9B0@eggert.org>
Date: Thu, 12 Mar 2020 13:45:14 +0200
Cc: Wesley Eddy <wes@mti-systems.com>,
 tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <58F65740-81FE-4AC3-ABD3-CA54E6F2BB4C@gmail.com>
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>
 <2CC63847-707F-4B50-8F44-CFC6CD22F9B0@eggert.org>
To: Lars Eggert <lars@eggert.org>
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/tsvwg/zMNS-sZVWcO7TAH4FFwAB-9owkM>
Subject: Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at
 tsvwg interim
Precedence: list

> On 12 Mar, 2020, at 10:18 am, Lars Eggert <lars@eggert.org> wrote:
>=20
> I'd much rather see some short answers on some basic questions, such =
as:

I think the question posed by David Black's slides (as presented and =
briefly discussed at the interim meeting) is intended to elicit relevant =
answers to these sorts of questions.  But since you asked, I'll have a =
go at answering them standalone, for the SCE proposal.

> Is the solution incrementally deployable?

Yes.  Each component of SCE is inherently safe to deploy into an =
existing network, and will have no detrimental effect on conventional =
traffic.  SCE flows traversing an existing network will behave =
conventionally and in an RFC-compliant manner.  This is not merely =
aspirational, but baked fundamentally into the design.

> Is it simple?

Yes.  I could summarise the technicalities on two slides - or one, if I =
really had to.  Implementing SCE also does not require very intrusive or =
extensive changes to existing network stacks; a year ago, we got a basic =
proof of concept running in about a man-week.

> Does it offer better performance, to participating and ideally =
non-participating flows?

Yes - adding SCE to an existing ECN network usually improves throughput, =
peak latency and jitter for SCE flows, and improves total link goodput =
when at least one SCE flow is present.  Adding SCE to a dumb-FIFO =
network also brings significant benefits to conventional traffic, as any =
good AQM deployment would.

> Is it at worst a no-op, or can it degrade performance for =
non-participating flows?

Non-SCE flows see only an RFC-3168 compliant AQM on the path, and ignore =
the SCE signals.  SCE flows at worst have a tendency to defer to =
existing traffic - the opposite to what you fear - but with a =
well-designed bottleneck qdisc, this effect is limited or eliminated.  =
The SCE proposal presents several such qdiscs as examples.

> Can a partially deployed solution be rolled back?
> Can it stay deployed but become a no-op if a different mechanism wins =
out in the end?

This is probably the most complex question to answer.  Un-deploying an =
experiment is always more difficult than deploying it in the first =
place, since it's harder to prove a negative.

SCE consumes the spare ECN codepoint and one spare TCP header bit, =
without explicitly negotiating for them (beyond what is normal for =
RFC-3168 ECN), and adds a permitted ECN codepoint transition in =
middleboxes: ECT(0) -> ECT(1).  As far as conventional ECT flows are =
concerned, ECT(1) is semantically identical to ECT(0), and the spare =
header bits are ignored if received, so conventional traffic would not =
be affected.  The question is really about how to free up these consumed =
header resources, should that be necessary.

Reversing an SCE deployment thus means removing all sources of this new =
usage, which means both middleboxes and endpoints.  The reference =
implementation leaves SCE functionality switched off by default, but it =
is easy to automate switching it on and potentially then forget about =
it.

The following probes can be used to seek out latent deployments, and ask =
their operators to disable them.  This does not require a new kernel to =
be compiled or installed, nor any downtime, only that the SCE =
functionality is configured off at runtime, eg. through a sysctl or the =
iproute2 tc utility.

SCE enabled middleboxes are easy to detect, by passing ECT(0) traffic =
through it and seeing if ECT(1) marks appear alongside (or before) CE =
marks.  If CE marks or an AQM-like (or tail-drop-like) pattern of drops =
appears but ECT(1) does not, it's not an SCE enabled middlebox.  This is =
probably sufficient to reclaim the spare ECN codepoint.

SCE enabled TCP receivers are also easy to detect, by probing them with =
ECT(1) traffic and seeing if the corresponding TCP header bit is used to =
echo them.  Some other transports may have ECT(1) feedback designed into =
them, which is not affected by SCE per se, and these can be ignored.  =
This is probably sufficient to reclaim the TCP header bit.

SCE enabled senders are a little more difficult to detect unambiguously. =
 An indication can be obtained by probing them with the TCP header bit =
artificially set in all acks, and seeing if the resulting throughput is =
markedly less than if that is not done.  SCE senders behave essentially =
identically to normal ECN senders when the corresponding TCP header bit =
remains cleared in acks, so their continued presence is mostly benign, =
unless the header bit starts being used in some other experiment in a =
way that confuses the SCE sender.

If considered necessary by the WG, it would be possible to associate SCE =
with an experimental-series DSCP, and require that DSCP be present for =
SCE functionality to be enabled.  This would however limit experiments =
to networks that do not bleach or otherwise disrupt that DSCP, which may =
inhibit exploration of behaviour on longer Internet paths (which we =
think SCE is much better suited for than L4S).  The upside would be =
easier reclamation of the header resources upon termination of the =
experiment.

Our proposed use of DSCP is instead an optional addition, using SCE as =
part of providing a low-latency Diffserv PHB, but not requiring any =
particular DSCP to support SCE.

 - Jonathan Morton