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

[Sebastian Moeller <[e-mail]>]

Dear Bob,


> On May 23, 2020, at 17:07, Bob Briscoe <[e-mail]> wrote:
> [...]
> [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

	I note that the fq-codel RFC contains zero lines of pseudocode, so by this measure it must be infinitely simpler than the dual queue coupled AQM, no?

But joking aside, it seems like an odd choice to compare the complexity of an qdisc in the main-line kernel with an out of line qdisc under active development, but if we attempt to do this, surely 724 lines for https://github.com/L4STeam/sch_dualpi2_upstream/blob/sch_dualpi2/net/sched/sch_fq_codel.c (plus 310 lines for https://github.com/L4STeam/sch_dualpi2_upstream/blob/sch_dualpi2/net/sched/sch_codel.c) and 746 lines for https://github.com/L4STeam/sch_dualpi2_upstream/blob/sch_dualpi2/net/sched/sch_dualpi2.c do not seem to support your hypothesis, unless we want to quibble over individual lines of code here. And yes the runtime cost for fq_codel probably is a bit higher than for dualq, but I would be amazed if we would talk about an order of magnitude (base2) here...

My point is, please refrain from completely unhelpful complexity comparisons by virtue of pseudeocode, especially if not both qdiscs to be compared actually exist in pseudocode in the first place....


> 
> The Coupled DualQ solely classifies at the IP layer (ECN field). It consists of two AQM instances:

	[SM] True, until it becomes obvious that without the optional queue protection mechanism dualq severely lacks behind fq_codel in real-world usefulness. Once you add the queue protection to the requirements, your are looking at L4 headers again. That said, there is absolutely no reason, why fq_codel could not look only at the IP header for its hashing needs, if you really want that (and interestingly cake offers such flow-definition modes).

> * one instance of an AQM for the Classic queue, with similar complexity to /one/ of the per-flow CoDel instances.

	[SM] +1; it just turned out in the real world that the performance of a single queue AQM simply does not deliver what the end-users actually want from an AQM so that nobody went for a single queue CODEL. I see absolutely no reason, why this should change now with L4S. Now, I only talk to end-users, ISPs might see this differently (but ultimately will need to convince their users that L4S is actually an improvement).


> * one instance of a brain-dead-simple stateless AQM for the L4S queue.

	[SM] Since the two AQMs are coupled, the required state is simply kept on the non-LL side, claiming that it is stateless seems a bit disingenuous, no?

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

	[SM] Interestingly, end-users interested in low-latency and sharing their access links between, say gaming and streaming, opted for fq_codel and cake. Even though this requires post-bottleneck ingress shaping and is computationally relatively costly. So the relevant market has spoken and adopted FQ_CODEL. 



> I'm suggesting an explanation for that (based on what they've told me), not talking theoretic possibilities.

	[SM] Good marketing of the L4S effort? Unless you kick the tires yourself and simply believe the claims in the L4S drafts it seems like the perfect solution, optimal performance for low computational effort. It is only after you realize that this performance is neither robust nor reliable that questions will arise.


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

	[SM To repeat myself, none such applications that are both unfeasible today and are suitable for being run over the best-effort internet have so far been proposed. I am not claiming that L4S might not improve upon the state of the art at all, but this specific claim of currently impossible novel interactive applications seems wishful thinking. Case in point google satia, nvidie gforce now, shadow cloud gaming, all offer interactive real-time reaction-time bound games over the existing internet. That is your market, right there, already working over the existing internet, what are you going to offer?

Best Regards
	Sebastian


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