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

[Paul Vixie <[e-mail]>]

bob,

On Friday, 22 May 2020 22:44:04 UTC 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.
> > 
> >> ...

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.

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

in the context of that thread to that point, the operators and vendors who had 
spoken in favour of the input model had used short-RTT ("microseconds rather 
than milliseconds") examples, and had spoken extensively of switches 
specifically as handling these signal patterns not routers. this excludes the 
heterogeneous global WAN as a use case, and i believe this exclusion was 
deliberate, because so many local policies are already in place that new 
congestion related signalling can be expected to have a near-infinite tail in 
that environment.

tellingly, this means no operator or vendor will speak for the global WAN as a 
use case, because no operator or vendor makes most of their revenue that way; 
there is no value-add they can offer their customers that would have that 
reachability domain. that voice was by definition absent from the recent poll, 
other than random bit-heads like dave taht who seem to think that a rising 
tide could lift all boats. (that's not a compelling argument, as you saw.)

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

i'm not sure you meant to beg that question, but here it is. why isn't cake or 
fq-codel adequate, and can you answer using heterogeneous wide area examples?

also: noting that the L4S concept predates the bufferbloat project and its 
results such as modern age-based queue management at the endpoints, how has 
the L4S approach evolved to take advantage of this new situation and to focus 
on remaining unsolved problems -- which gets us back to: what are those?

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

are you aware of the logical fallacies you're invoking here? that is, are you 
trying to use debate tricks, or have you been misled? (hint: L4S isn't 
simpler, and theoretic possibility does not speak to adoption likelihood.)

-- 
Paul