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

[Sebastian Moeller <[e-mail]>]

HI Ilpo,


> On May 23, 2020, at 23:36, Ilpo Järvinen <[e-mail]> wrote:
> 
> 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)?

	[SM] Let me cite myself 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...."

I was not so much trying to offer an academically correct complexity comparison, but to show that Bob's approach was/is a waste of everybody's time and not useful at all, and that it is rather simple to do a bit better, by at least comparing real code instead of pseudocode...


But sure if we want to go that unproductive route here are some missing headers:

164 lines: https://github.com/L4STeam/sch_dualpi2_upstream/blob/sch_dualpi2/include/net/codel.h
255 lines: https://github.com/L4STeam/sch_dualpi2_upstream/blob/sch_dualpi2/include/net/codel_impl.h
74 lines: https://github.com/L4STeam/sch_dualpi2_upstream/blob/sch_dualpi2/include/net/codel_qdisc.h

724+310+164+255+74 = 1527

versus 746 for the dualq, but that uses its own private PIE version, let's see how/if that survives upstreaming into the linux kernel.

Best Regards
	Sebastian

P.S.: I assume you actually had a look at the relevant files yourself and just omitted the numbers to keep things concise.


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