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

[Ilpo Järvinen <[e-mail]>]

On Sat, 23 May 2020, Sebastian Moeller wrote:

> 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 what about the header files that in this case actually implement part 
of CoDel (rather than just containing some func signatures)?


-- 
 i.

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