Subject: [tsvwg] regarding L4S

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Nov 2018 09:02:31 +0100 (CET)

Hi,

I find the concept of L4S interesting. However, I see this as spending the 
last bit combination in the IP header we still can realistically do 
anything statelessly with when it comes to queue management, so I want to 
make sure we get it right.

I would like to bring this to a wider audience in the operator community, 
but that would need some new material from the authors where they create 
an "introduction to L4S for network people" which focuses less on the 
congestion avoidance, but more on "what does the router need to do" and 
aspects such as "is this implementable on existing hardware with software 
update" (and this is specifically for NPUs etc today that might only 
implement WRED). This document should probably have a brief introduction 
to ECN as well. For me as a network guy dabbling in transport and queue 
management, the whole L4S combination of documents is quite hard to 
understand. I don't doubt it's correct, but it uses a lot of terms that 
wasn't immediately familiar to me (like the fact that ECT(1) was 01 in the 
TOS bit). If the authors could go to NANOG, RIPE or similar place and 
present (preferably where there is video of the presentation), that would 
be brilliant. I volunteer to review any material beforehand and advice on 
things that might help to be included.

I would like to see more test results for instance testing done with 
"flent" (https://flent.org/) so we can compare L4S with/without 
FQ_CODEL/FIFO as the second queue, different TCP algorithms, UDP real time 
flows etc. In the early days of BBF we saw starvasion issues that weren't 
obvious before this kind of testing was done. This is just one example. We 
need deployment suggestions, and I'd really like to see the authors 
implement L4S on for instance OpenWrt (the sqm framework provides way to 
combine qdisc:s that is easily deployable and testable). This in 
combination with flent would mean it's easy to do testing for people on 
their own.

I'd like to see comprehensible testing at lots of different access speeds, 
all the way from 1 megabit/s all the way up to 1000 megabit/s, with long 
and short RTT paths combined. Just to figure out where L4S is usable and 
not. Remember, we still have lots of people connected to ADSL lines with < 
1 megabit/s upstream speed.

There is text regarding putting CE marked packets into the L4S queue and 
causing reordering within the flow. I have doubts this text saying this 
reordering isn't really a problem. I'd like to see testing of this done in 
more real life scenarios (can be done with OpenWrt + flent for instance), 
with different TCP implementations and more. Do we have UDP 
implementations that use ECN that might not like this? I don't know. I'd 
like to get more eyes on it.

-- 
Mikael Abrahamsson    email: [email-masked]