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

[Bob Briscoe <[e-mail]>]

Paul,

On 22/05/2020 23:44, Bob Briscoe wrote:
> 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.

[BB]
PV's argument: 15 lines.
BB's argument: 18 lines.

PV's response:

your arguments may fail by being too detailed and overlong, so whatever merits
it had are not never noticed. brevity is the soul of relevance. in the old
days we called this "proof by vigorous reassertion", but, we were joking.




Bob

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