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

[Sebastian Moeller <[e-mail]>]

Hi Bob,

more below in-line.

> On Mar 8, 2020, at 19:27, Bob Briscoe <[e-mail]> wrote:
> 
> 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,

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

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

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

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

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

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

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

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

> 
> 
> 
> 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/