Date: Thu, 12 Mar 2020 13:19:43 +0000 (UTC)
From: "alex.burr@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk>
Reply-To: "alex.burr@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk>
To: Jonathan Morton <chromatix99@gmail.com>, Lars Eggert <lars@eggert.org>, 
 Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: tsvwg@ietf.org
Message-ID: <1925618794.2451915.1584019183412@mail.yahoo.com>
In-Reply-To: <62d04148-8024-e72e-fd29-00b729604be5@erg.abdn.ac.uk>
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>
 <58F65740-81FE-4AC3-ABD3-CA54E6F2BB4C@gmail.com>
 <62d04148-8024-e72e-fd29-00b729604be5@erg.abdn.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/tsvwg/5vVrl8oDBrDgP3n78R_xw0X8oKk>
Subject: Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at
 tsvwg interim
Precedence: list

Not to invite more growing of this thread, since Gorry has asked that this =
not happen, but I notice that L4S and SCE have taken
quite different approaches to defining their value proposition. Neither of =
these approaches are wrong, but his makes them hard to compare. Therefore w=
hen drafting materials for whatever meeting occurs, it would be good if the=
 parties could try to close this gap, perhaps with hints from the chairs on=
 how to do so. In particular:
=C2=A0
- L4S has been very clear about what the end goal is (it's in the name). Ot=
her considerations, like the present state and limitations thereof, require=
 a lot more work to understand.
- SCE has focused on the benefits shown in tested examples with the existin=
g codebase. They have been cautious about commenting on how universal such =
benefits could become at different deployment stages.

Alex

=C2=A0







On Thursday, March 12, 2020, 12:48:03 PM GMT, Gorry Fairhurst <gorry@erg.ab=
dn.ac.uk> wrote:=20




This was to be an important topic of the face-to-face meeting in=20
Vancouver, where we have been planning to allow time for different=20
viewpoints to be aired and the consensus of the group to be sought. We=20
still plan to do that, and are considering how best to proceed.

Comments in-line to show the expected direction of travel, but please do=20
avoid growing this discussion thread for a week or so, until we have a=20
plan to conclude it (see end of email).

On 12/03/2020 11:45, Jonathan Morton wrote:
>> On 12 Mar, 2020, at 10:18 am, Lars Eggert <lars@eggert.org> wrote:
>>
>> 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 brie=
fly discussed at the interim meeting) is intended to elicit relevant answer=
s to these sorts of questions.=C2=A0 But since you asked, I'll have a go at=
 answering them standalone, for the SCE proposal.
>
>> Is the solution incrementally deployable?
> Yes.=C2=A0 Each component of SCE is inherently safe to deploy into an exi=
sting network, and will have no detrimental effect on conventional traffic.=
=C2=A0 SCE flows traversing an existing network will behave conventionally =
and in an RFC-compliant manner.=C2=A0 This is not merely aspirational, but =
baked fundamentally into the design.
This is exactly one of the topics we need to seek thought upon.
>> Is it simple?
> Yes.=C2=A0 I could summarise the technicalities on two slides - or one, i=
f I really had to.=C2=A0 Implementing SCE also does not require very intrus=
ive or extensive changes to existing network stacks; a year ago, we got a b=
asic proof of concept running in about a man-week.
Yes, we should capture those two slides for SCE! We will also ask the=20
same for L4S.
>> Does it offer better performance, to participating and ideally non-parti=
cipating 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.=C2=A0 Adding SCE to a dumb-FIFO network =
also brings significant benefits to conventional traffic, as any good AQM d=
eployment would.
One slide on how SCE offers benefit will also be useful. Again we should=20
obtain the same for L4S.
>> Is it at worst a no-op, or can it degrade performance for non-participat=
ing flows?
> Non-SCE flows see only an RFC-3168 compliant AQM on the path, and ignore =
the SCE signals.=C2=A0 SCE flows at worst have a tendency to defer to exist=
ing traffic - the opposite to what you fear - but with a well-designed bott=
leneck qdisc, this effect is limited or eliminated.=C2=A0 The SCE proposal =
presents several such qdiscs as examples.
>
.... Or rewrite ECT(1),=C2=A0 as I understand for some existing=20
tunnels/encaps. I recall from the early L4S discussion that this=20
consideration was also be important, and hence we charted work to try=20
and improve ECN-marking in the IP layers.

>> Can a partially deployed solution be rolled back?
>> Can it stay deployed but become a no-op if a different mechanism wins ou=
t in the end?
> This is probably the most complex question to answer.=C2=A0 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, withou=
t explicitly negotiating for them (beyond what is normal for RFC-3168 ECN),=
 and adds a permitted ECN codepoint transition in middleboxes: ECT(0) -> EC=
T(1).=C2=A0 As far as conventional ECT flows are concerned, ECT(1) is seman=
tically identical to ECT(0), and the spare header bits are ignored if recei=
ved, so conventional traffic would not be affected.=C2=A0 The question is r=
eally about how to free up these consumed header resources, should that be =
necessary.
Yes. I would love such a brief understanding of how the experiment can=20
be managed if the IETF may wish in the future to terminate an=20
experiment, as was done for ECN-NONCE.
> Reversing an SCE deployment thus means removing all sources of this new u=
sage, which means both middleboxes and endpoints.=C2=A0 The reference imple=
mentation 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.=C2=A0 This does not require a new kernel t=
o be compiled or installed, nor any downtime, only that the SCE functionali=
ty is configured off at runtime, eg. through a sysctl or the iproute2 tc ut=
ility.
>
> SCE enabled middleboxes are easy to detect, by passing ECT(0) traffic thr=
ough it and seeing if ECT(1) marks appear alongside (or before) CE marks.=
=C2=A0 If CE marks or an AQM-like (or tail-drop-like) pattern of drops appe=
ars but ECT(1) does not, it's not an SCE enabled middlebox.=C2=A0 This is p=
robably sufficient to reclaim the spare ECN codepoint.
Probably worth writing down. I've found it hard to test for ECN-marking=20
on operational paths, but insight in this is always going to be welcome.

> SCE enabled TCP receivers are also easy to detect, by probing them with E=
CT(1) traffic and seeing if the corresponding TCP header bit is used to ech=
o them.=C2=A0 Some other transports may have ECT(1) feedback designed into =
them, which is not affected by SCE per se, and these can be ignored.=C2=A0 =
This is probably sufficient to reclaim the TCP header bit.
>
> SCE enabled senders are a little more difficult to detect unambiguously.=
=C2=A0 An indication can be obtained by probing them with the TCP header bi=
t artificially set in all acks, and seeing if the resulting throughput is m=
arkedly less than if that is not done.=C2=A0 SCE senders behave essentially=
 identically to normal ECN senders when the corresponding TCP header bit re=
mains 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 co=
nfuses 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.=C2=A0 This would however limit experiments to =
networks that do not bleach or otherwise disrupt that DSCP, which may inhib=
it exploration of behaviour on longer Internet paths (which we think SCE is=
 much better suited for than L4S).=C2=A0 The upside would be easier reclama=
tion of the header resources upon termination of the experiment.
>
> Our proposed use of DSCP is instead an optional addition, using SCE as pa=
rt of providing a low-latency Diffserv PHB, but not requiring any particula=
r DSCP to support SCE.
>
>=C2=A0 - Jonathan Morton


The TSVWG Chairs are now aware that we need to plan to make progress and=20
will be in touch in the next week or so, with a plan move forward in the=20
absence of an IETF face-to-face meeting.

Best wishes,

Gorry,

TSVWG Chairs