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

[Sebastian Moeller <[e-mail]>]

Hi Ilpo,

I just realized, that the dualQ alone is not really worth comparing to fq_codel, as it requires TCP Prague for proper functionality, so add at least 892 lines (https://github.com/L4STeam/linux/blob/testing/net/ipv4/tcp_prague.c) to the dualq ledger:
fq_codel: 724+310+164+255+74 = 1527
duaQ: 746+ 892 = 1638


I hope you agree that there is no clear significant complexity difference between L4S and fq_codel if measured by lines of code. I am not claiming that that is an ideal measure, but it sure beats lines of pseudocode.

Best Regards
	Sebastian



> On May 24, 2020, at 00:00, Sebastian Moeller <[e-mail]> wrote:
> 
> 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....
>