Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <b0fdf995-964f-33cc-a7ea-3ecba803a672@bobbriscoe.net>
Date: Sun, 8 Mar 2020 20:52:58 +0100
Cc: tsvwg IETF list <tsvwg@ietf.org>,
 Steven Blake <slblake@petri-meat.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C3C0870B-1E4B-4D9C-9B77-7128CAEE938E@gmx.de>
References: <7409b3a3-ba14-eb6d-154b-97c9d2da707b@bobbriscoe.net>
 <451679EC-B6F7-4176-B497-8189D238AF03@gmx.de>
 <dac8179d-1c39-b308-2c0a-4a6d0b43ddd6@bobbriscoe.net>
 <B3163D46-F211-4AF8-8A14-AF9AB26ADA33@gmx.de>
 <b0fdf995-964f-33cc-a7ea-3ecba803a672@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/tsvwg/llGuknnXFunVr1xghrRqQK13qTo>
Subject: Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at
 tsvwg interim
Precedence: list

Hi Bob,

more below in-line.

> On Mar 8, 2020, at 19:27, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>=20
> Seabstian,
>=20
> On 08/03/2020 15:34, Sebastian Moeller wrote:
>> Hi Bob,
>>=20
>> More below.
>>=20
>> On March 8, 2020 3:23:39 PM GMT+01:00, Bob Briscoe =
<ietf@bobbriscoe.net> wrote:
>>> Sebastian,
>>>=20
>>> On 07/03/2020 19:16, Sebastian Moeller wrote:
>>>>> Anyway, if user B's downstream is the bottleneck for user A, even =
if
>>>>> ISP
>>>>> B doesn't bleach Diffserv, the DSCP is still no use if ISP A =
bleaches,
>>>>> or if an intermediary does.
>>>> 	[SM] That really just would show that there is a business case =
for
>>>> ISP A and B to connect directly in a DSCP conserving fashion....
>>> This is a misunderstanding of the sequencing of adoption incentives. =
If
>>>=20
>>> something new doesn't work in the scenarios of interest, it will =
never
>>> take off, and never affect anyone's business cases for doing =
anything.
>> [SM] That might pass as a cogent argument, but for the fact that ISPs =
(and CDNs) already use SLAs to define their interactions, e g. for VoIP =
traffic. The incremental effort to also include a LL-type traffic =
class/dscp seems pretty minor to me.
> Companies don't just do these things lightly,

[SM] Which does not really matter, if the companies already have a SLA =
in place. If L4S offers something the market desires it will be included =
into the SLAs otherwise if not even those parties that could maximally =
profit (even from the systematic sharing failures) are willing to put in =
a modicum of effort it tells us something about L4S.


> especially not for applications that might not be possible any other =
way (both low latency and capacity-seeking high bandwidth has =
traditionally been considered impossible).

	[SM] The bigger point is IMHO, is greedy and low-latency =
actually a desirable combination of features?


> It took decades to drag companies, kicking and screaming, into the =
VoIP models you see now.

	[SM] Yes? What is your point?

> Technical ability was never the problem. I have a VHS video somewhere =
of a multi-party voice conference over ARPANET, including a radio link, =
and a leg from a public call box. I've been involved in interconnect QoS =
(economics and technology) for longer than I'd care to say (not as far =
back as ARPANET I should add!).

	[SM] Bob, this are nice anecdotes but at best tangentially =
related to the L4S/ECT(1) fiasco in the making.

>=20
> But my point was different. No-one has working technology until we =
have ECT(1) in an RFC. If we add DSCPs as yet another barrier to =
deployment, it appears flakey and the experiment fails.

	[SM] Failure of the L4S experiment is exactly my prediction, but =
due to its own internal inconsistencies and short-coming, nothing =
related to dscps,, but I would really hate it if L4S flame-out would =
both spoil ECT(1) for the immediate future and discredit 1/p type =
congestion signaling.=20

> Then it never gets near to any commercial considerations, 'cos it =
doesn't exist.

	[SM] Slightly different prediction, no commercial considerations =
because it does not nearly deliver what it promises.

>=20
>>=20
>> I also strongly believe that the only incentive for an ISP to =
roll-out L4S would be if that additional work/expense can be monetized, =
and the most viable route for that I can see, is to discrimination-free =
sell L4S access to the deploying ISP's eyeballs to all interested =
content suppliers, be it directly or via CDNs. In that case an SLA is =
not only not going to be a stumbling block, but rather a mandatory =
component of making this work. What kind of deployment are you =
realistically expecting where this is going to be an issue?
> I don't think anyone at the IETF should be expecting Internet =
businesses to adopt one particular business model.

	[SM] Exactly, the IETF should judge the L4S proposal on its =
technical merits alone, and there L4S simply is lacking.

> I believe our goal should be to produce technology over which all =
different business models can be built.
>=20
> For that, I believe a strongly end-to-end technology (i.e. signal) =
needs to be the foundation, but different networks can derive different =
commercial offerings from it in different ways, without interfering with =
the underlying signal. {Note 1}

	[SM] But here is the rub, the L4S architecture makes in unduly =
hard to separate low-latency queueing from 1/p-type congestion control, =
as I fully agree these are ORTHOGONAL to each other, so artificially =
coupling them, e.g. by making ECT(1) both denote a 1/--typre response to =
CE AND requestimg admission to the LL-queue is exactly the wrong thing =
to do. Glad that you agree.

>=20
> Diffserv is starting from the pit of the valley in this respect. It is =
expected to be wiped unless otherwise agreed.

	[SM] Well, in practice probably yes, but according to =
RFC2474DSCPs seem intended for "end-to-end or intra-domain" use. But in =
a sense an all wiped until agreed otherwise will give an additional =
safety mechanism for the roll-out of something new.

>=20
> In contrast, ECN starts from the high ground, starting from strongly =
e2e semantics. Any operator that wants to wipe or block an ECN signal =
from their competitors has to justify messing with e2e congestion =
control. {Note 2}

	[SM] Again you seem to argue for convenience over technical =
merit.

>=20
> The distinction is between a technology that ISPs can use to degrade =
their competitors (race to the bottom), vs one they can only use to =
enhance themselves.

	[SM] As so often you are charmingly naive about what is =
possible: all an ISP needs to do is to upmark a high volume (ideally =
non-responsive bursty) flow going to a competitor's network all ECT(1): =
"mischief managed". In the other directions we do not go as far, just =
pipe an L4S flow into a single queue RFC3168 AQM an watch the fire-works =
(and with your approach to L4S first, even your 3168 detection will in =
all likelihood cause transient queueing and hence increased latency for =
all other flows traversing that node).

>=20
>=20
> You only have to look at my publications pages over the last 20 years =
to see how much I've thought about the integrity of congestion signals =
as a basis for economic models.

	[SM] I perused a fair share of your prose in the last two years, =
but I buy into very little of your conclusions, as I believe you are =
working mostly from premises I do not agree with/share (the biggest one =
being the idea a congested node had any reliable information about the =
relative value of different packets it can use to optimize the =
assignment of bandwidth in any meaningful way, but I digress). That =
seems all irrelevant to L4S though, and especially why gauarding L4S use =
of ECT(1) with a bespoke DSCP would hinder EXPERIMENTAL roll-out of L4S =
in any meaningful way. As far as I can tell, you seem to think about how =
to deploy L4S as a standards RFC, but how about first making sure there =
is a viable path to it becoming a standard first?

Best Regards
	Sebastian

>=20
>=20
>=20
> Bob
>=20
> {Note 1}: E.g. initially some might only classify ECT1 into the L =
queue for business customers, or as a product for a higher tier of =
customers, or solely for the operator's own services (if allowed in =
their jurisdiction). Other ISPs, like you say, will want to use it as a =
differentiator for their whole regular service (see =
draft-ietf-l4s-arch).
>=20
> {Note 2}: Of course, certain ISPs might pervert the ECN signal, but I =
think that's less likely, 'cos they can only access to traffic in their =
own network, which inherently hits the e2e congestion control of their =
own customers. If we think that's a possibility, L4S senders could cover =
the least significant bit of the ECN field with integrity protection to =
raise the bar against network interference, by tying it to the integrity =
failure of each whole packet.
>=20
>=20
>>=20
>> And especially for the scope of the experimental deployment? The =
experiment is required to make sure that L4S can deployed in a safe and =
backward compatible fashion and that it can deliver it's promises under =
real-world conditions.
>> The experiment is NOT about how to deploy something in a fashion that =
offers the least part of resistance/the highest adoption rate. As a rule =
of thumb, I would assume the IETF be interested in the technical aspects =
and not the marketing side....
>>=20
>> Regards
>>         Sebastian
>>=20
>>=20
>>>=20
>>>=20
>>> Bob
>=20
> --=20
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/