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

[Jonathan Morton <[e-mail]>]

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

There are definitely limitations in comparing implementation complexity by lines of code, especially as implementing certain algorithms in hardware requires more complexity than others, despite needing only similar lines of C.  But as long as we're doing this, let's compare apples to apples and use the nearest equivalents in SCE:

net/sched/sch_cnq_codel_af.c -  926 lines
net/sched/sch_lfq_cobalt.c   - 1049 lines

net/ipv4/tcp_dctcp_sce.c     -  224 lines
net/ipv4/tcp_reno_sce.c      -  223 lines
net/ipv4/tcp_cubic_sce.c     -  655 lines

The qdiscs above contain private copies of their AQMs and all relevant algorithms.  So from this we can assemble a simple SCE implementation with 926+224 = 1150 lines, or a more sophisticated one with 1049+655 = 1704 lines.

The latter includes such niceties as HyStart, improved scaling to high BDPs, flow isolation, and queue overload protection in addition to the basic AIMD and HFCC functionalities, for only a few more lines of code relative to the combination of DualQ and TCP Prague, which lack all of those additional features.

We could also include net/sched/sch_cake.c, which at 3143 lines represents an FQ-AQM system that is definitely more complex than anything previously mentioned in this thread, but has nevertheless been deployed in practice in its intended role.  Of course, nobody sensibly expects Cake to be deployed in high-speed core networks, but that's not what it was designed for.

 - Jonathan Morton