Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at tsvwg interim

[Bob Briscoe <[e-mail]>]

Seabstian,

On 08/03/2020 15:34, Sebastian Moeller wrote:
> Hi Bob,
>
> More below.
>
> On March 8, 2020 3:23:39 PM GMT+01:00, Bob Briscoe <[e-mail]> wrote:
>> Sebastian,
>>
>> 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
>>
>> 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, 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). It took decades to drag companies, kicking and screaming, 
into the VoIP models you see now. 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!).

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. Then it never gets near to 
any commercial considerations, 'cos it doesn't exist.

>
> 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.
I believe our goal should be to produce technology over which all 
different business models can be built.

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}

Diffserv is starting from the pit of the valley in this respect. It is 
expected to be wiped unless otherwise agreed.

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}

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.


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.



Bob

{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).

{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.


>
> 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....
>
> Regards
>          Sebastian
>
>
>>
>>
>> Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/