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

[Paul Vixie <[e-mail]>]

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.

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.

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

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.

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

-- 
Paul