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

[Bob Briscoe <[e-mail]>]

Paul,

On 23/05/2020 04:10, Paul Vixie wrote:
> bob,
>
> On Friday, 22 May 2020 22:44:04 UTC Bob Briscoe wrote:
>> Paul,
>>
>> On 15/05/2020 21:18, Paul Vixie wrote:
>>> 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.

[BB] Data center had not been mentioned on that thread.
(And no operator or vendor had spoken on that thread.)
Whatever...

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

[BB] Nearly all the 35 operators and vendors that agreed to be listed in 
the recent interim mtg are planning to deploy L4S for access networks, 
mostly cable or mobile:
https://datatracker.ietf.org/meeting/interim-2020-tsvwg-03/materials/slides-interim-2020-tsvwg-03-sessa-3-ect1-slides.pdf#page=13


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

[BB] I see you hand out unprovoked unpleasantness to others as well. 
That's reassuring (not).
I will filter you out if you don't stop tho.

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

[BB] For your FAQ, I recently prepared this answer:
http://bobbriscoe.net/presents/2004ietf/202005L4S-brief.pdf#page=4

Briefly, L4S has order of magnitude lower tail delay than FQ_CoDel, 
which is important for real-time interaction, e.g. applications like 
gaming, remote interaction and control, or this cloud-rendered 
interactive video:
     https://riteproject.eu/dctth/#1511dispatchwg

Also, L4S enables deployment of solutions to the throughput scaling 
problem with TCP congestion control (the root cause of the problem 
FQ_CoDel mitigated).


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

[BB] I don't think anyone except you is arguing that FQ_CoDel is simpler 
than the DualQ (because it isn't). You can compare this pseudocode 
yourself, which also links to the Linux code:
https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-11#appendix-A.1

The Coupled DualQ solely classifies at the IP layer (ECN field). It 
consists of two AQM instances:
* one instance of an AQM for the Classic queue, with similar complexity 
to /one/ of the per-flow CoDel instances.
* one instance of a brain-dead-simple stateless AQM for the L4S queue.


I'm seeing that vendors of larger scale equipment /have/ implemented it 
and operators /have/ plans to adopt it, whereas they didn't adopt 
FQ_CoDel. I'm suggesting an explanation for that (based on what they've 
told me), not talking theoretic possibilities.

Another explanation is that L4S enables new interactive applications 
that are currently infeasible over the WAN.

Regards



Bob

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