Re: [tsvwg] Gorry Fairhurst Individual thoughts on choosing whether/how to advance ECN work.

[Bob Briscoe <[e-mail]>]

Paul,

On 15/05/2020 21:18, Paul Vixie wrote:
> On Friday, 15 May 2020 16:49:10 UTC Joseph Touch wrote:
>>> On May 15, 2020, at 7:54 AM, Gorry Fairhurst <[e-mail]> wrote:
>>>
>>> Alas, I don’t see how we can do all using just the current ECN field, and
>>> that’s why I say we have a shortage of bits.
> +1.
>
>> I agree with Gorry on the point above.
>>
>> I also haven’t quite seen a brief summary of the utility of these bits as a
>> signal in either direction (endpoint to net; net to endpoint) given the
>> assumption that “everybody lies”.
>>
>> IMO, lying is part of why DSCPs are useful only where either redundantly
>> validated on network ingress or inside managed networks.
>>
>> So my questions - not really experiments (as per one of the options) are:
>>
>> 	- assuming endpoints lie and/or network nodes lie (either by what
>> they indicate or what they rewrite), are either of these options still safe?
>>
>> 	- assuming everybody lies (as above), are either of these options
>> still useful? (i.e., more than just safe)
> on a cost:benefit analysis, if ECT(1) is defined to be an output from the
> network the risk (to first and second parties) of lies when is higher, and the
> benefit (to the third) is lower. therefore if this WG were to assign meaning
> to the ECT(1) bit based on risk of lies to good guys and benefit of lies to
> bad guys, the output choice would prevail.
>
> as an output that is intended to serially convey a changing fraction of path
> congestion, the benefit to a liar of lying about it would be to cause lower
> network utilization for affected flows. since the lie would have to be told by
> an on-path actor, this might even be within their established purview. here,
> the network is pressing for different endpoint behaviour.

[BB] I don't think any of the above is materially relevant to whether 
there should be one output or two. The number of outputs doesn't affect 
the network's ability to lie about one or both of them.

>
> as an input that is intended to select DCTCP-style shallow queues for some
> traffic, the benefit to the liar of lying about it would be to cause the
> liar's flows to be able to better compete against inside-the-DC flows. this is
> a denial-of-service vector at worst, and a nonconstructive competition form at
> best. here, the endpoint is pressing for different network behaviour.

[BB] The sender's congestion control (or lack thereof) is about 
behaviour. Misbehaviour and lying are orthogonal. So all this about 
lying or not is irrelevant to congestion control behaviour (as Gorry 
explained).

In Jonathan's example, an L4S sender sets ECT0, but behaves more 
aggressively in response to feedback (as if it was setting ECT1) which 
gives it more capacity share. Even if L4S had never existed, any sender 
can set ECT0 and behave more aggressively to attain more capacity share.

A sender can also set ECT1 to get classified into the L4S queue, and 
still behave more aggressively than other L4S sources to get more 
capacity share than them.

In summary, attaining capacity share is nothing to do with the truth of 
a codepoint, because capacity shares aren't determined by whatever 
codepoint the sender tells the network. Capacity shares aren't even 
determined by the network at all. They are determined by the sender's 
behaviour, irrespective of what codepoint it sets.

>
>> If not - and partly based on Gorry’s observation above, my inclination is
>> not to define these bits for such uses at all.
> enshrining the riskier design (ECT(1)-as-input) in all IP flows because it
> helps datacenter efficiency as long as that datacenter bleaches on ingress,
> strikes me as a poor tradeoff of cost and benefit for the last IP TOS bit.

[BB] Can you explain what made you say the second of these three lines, 
so we can try to unpick what's in your mind. There's surely some 
misconceptions behind these words. Where have you seen anything about 
helping datacenter efficiency? And what's this condition about bleaching 
on ingress to a DC?


>
> perhaps the smart edge, dumb core model doesn't work perfectly for datacenter
> networks. but as fq_codel shows, it works extremely well for edge networks,
> who are vastly more numerous and which provide an at least equal share of the
> "network effect" value of internetworking.

[BB] Again, there seems to be some misunderstanding that L4S is about 
data centre networks. What's all this about?

It might be worth reading 
https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-06#section-6.3 
where I think you'll see that the primary deployment use-case for L4S is 
similar to that of FQ-CoDel. Nonetheless, being simpler, it is being 
picked up by those operating the downstream bottleneck in to the access 
link (the BNG, metro node, CMTS, etc), not just the upstream bottleneck 
(home gateway).

It's also simple enough for other possible bottlenecks, e.g. peering 
points, DC ToRs, hypervisors, DC access links, campus access links, and 
so on.



Bob



>
> so, i am +1 to joe's inclination as quoted above.
>


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