Re: [Ecn-sane] [tsvwg] Comments on L4S drafts

[Wesley Eddy <wes@mti-systems.com>]

Hi Dave, thanks for clarifying, and sorry if you're getting upset.

When we're talking about keeping very small queues, then RTT is lost as 
a congestion indicator (since there is no queue depth to modulate as a 
congestion signal into the RTT).  We have indicators that include drop, 
RTT, and ECN (when available).  Using rate of marks rather than just 
binary presence of marking gives a finer-grained signal.  SCE is also 
providing a multi-level indication, so that's another way to get more 
"ENOB" into the samples of congestion being fed to the controllers.

Marking (whether classic ECN, mark-rate, or multi-level marking) is 
needed since with small queues there's lack of congestion information in 
the RTT.

To address one question you repeated a couple times:

> Is there any chance we'll see my conception of the good ietf process
> enforced on the L4S and SCE processes by the chairs?

We look for working group consensus.  So far, we saw consensus to adopt 
as a WG item for experimental track, and have been following the process 
for that.

On the topic of gaming the system by falsely setting the L4S ID, that 
might need to be discussed a little bit more, since now that you mention 
it, the docs don't seem to very directly address it yet.  I can only 
speak for myself, but assumed a couple things internally, such as (1) 
this is getting enabled in specific environments, (2) in less controlled 
environments, an operator enabling it has protections in place for 
getting admission or dealing with bad behavior, (3) there could be 
further development of audit capabilities such as in CONEX, etc.  I 
guess it could be good to hear more about what others were thinking on this.


> So I should have said - "tosses all normal ("classic") flows into a
> single and higher latency queue when a greedy normal flow is present"
> ... "in the dualpi" case? I know it's possible to hang a different
> queue algo on the "normal" queue, but
> to this day I don't see the need for the l4s "fast lane" in the first
> place, nor a cpu efficient way of doing the right things with the
> dualpi or curvyred code. What I see, is, long term, that special bit
> just becomes a "fast" lane for any sort of admission controlled
> traffic the ISP wants to put there, because the dualpi idea fails on
> real traffic.

Thanks; this was helpful for me to understand your position.


> Well if the various WGs would exit that nice hotel, and form a
> diaspora over the city in coffee shops and other public spaces, and do
> some tests of your latest and greatest stuff, y'all might get a more
> accurate viewpoint of what you are actually accomplishing. Take a look
> at what BBR does, take a look at what IW10 does, take a look at what
> browsers currently do.

All of those things come up in the meetings, and frequently there is 
measurement data shown and discussed.  It's always welcome when people 
bring measurements, data, and experience.  The drafts and other 
contributions are here so that anyone interested can independently 
implement and do the testing you advocate and share results.  We're all 
on the same team trying to make the Internet better.