<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Dave,<br>
<br>
L4S is far from dead. It's merely been working differently from how
you're used to. Those working on an L4S AQM (at least those in the
cable industry) had to have a private WG for the last ~18 months,
but now we're allowed to publish and talk openly again. Similarly,
there's work under the covers on an L4S AQM in switch hardware. And
I see external signs of work under covers on DSL access equipment
(covers that I am not under any longer).<br>
<br>
Nonetheless, I think you will see updated Linux code for an L4S
DualQ Coupled AQM built against the mainline tree appear on netdev
list today.<br>
<br>
==In summary==<br>
<br>
The problem that the SCE draft identifies with TCP's sharp
multiplicative decrease is also the primary problem that L4S
identified. <br>
<br>
Like L4S, SCE requires changes to network, sender and receiver (see
comment later about the rcv-window approach hinted at in the SCE
draft). But SCE is just starting on its journey. Having to change
end systems and network together is really tough and takes many
years. <br>
<br>
It seems you're trying to do the same thing as L4S, but by slightly
different means. Before splitting the people involved in this into
two factions, can you say what you didn't like about the L4S
approach in the first place? We've been very careful to specify L4S
broadly enough so that it can encompass many different approaches
within it.<br>
<br>
The only thing stated against L4S I can find is that it's taking a
long time. Starting an identically difficult approach now is going
to restart the clock, and take a lot lot longer.<br>
<br>
==2 output values vs. 2 input values.==<br>
<br>
We considered schemes where the AQM can use a second marking as a
lower strength /output/ (like VCP, my own QV and now SCE). But we
worked out that there were a wider range of advantages and much more
significant performance improvements from the sender using a second
marking to distinguish how it will behave (i.e. a second /input/ to
the classifier in front of the AQM). <br>
<br>
Don't get me wrong. It's useful that you guys are putting the work
in on SCE. Then everyone can compare the two approaches (again), as
a check on whether that decision was correct. That's important, cos
ECT(1) is the last useful codepoint in the IP header. See:
"Notification of Less Severe Congestion than CE" at <a
class="moz-txt-link-freetext"
href="https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#appendix-C.2"
moz-do-not-send="true">https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#appendix-C.2</a>
where we've written:<br>
<pre class="newpage"> Before assigning ECT(1) as an identifer for L4S, we must carefully
consider whether it might be better to hold ECT(1) in reserve for
future standardisation of rapid flow acceleration, which is an
important and enduring problem [<a href="https://tools.ietf.org/html/rfc6077" title=""Open Research Issues in Internet Congestion Control"" moz-do-not-send="true">RFC6077</a>].
</pre>
<br>
==FQ-only vs. FQ or DualQ==<br>
<br>
One of the problems with the 2 outputs approach (SCE etc.) is that
it is only possible with per-flow queuing. I doubt you'll get the
last useful codepoint in the IP header for just that. It's sort-of
obvious that, if you try to implement SCE in a FIFO, you can only
have one queue length for all the flows. Then legacy TCP flows that
don't understand SCE would push the queue deeper to the CE
threshold, ruining it for the flows that support SCE. <br>
<br>
We worked out that the 2 inputs approach (L4S) is more generic - ie.
it can be used with FQ or DualQ (multiple or just 2 queues). <br>
<br>
For instance, you can modify fq_CoDel for senders that uses ECT(1)
to indicate that they support a small multiplicative decrease (L4S
senders). You only need the following: Include the last bit of the
ECN field with the flow ID when you do the classification for sfq.
Then in the queues with ECN==X1, you instantiate a shallow threshold
ECN AQM. This could be CoDel with a shallow 'target', but you also
want it to respond immediately (zero 'interval'), so even a simple
step at about 1ms will work, but a random RED-like ramp on the
/instantaneous/ queue is much better. <br>
<br>
==Re-purposing the Receive Window?===<br>
<br>
Receiver congestion control using the receive window may seem like a
useful stop-gap, but it runs counter to how nearly all today's
transport protocols are intended to work (except, I know of a
LEDBAT-like example from Microsoft Research). So you will have your
work cut out proving that it is stable and that the two ends don't
fight, etc. if you think L4S is taking years, you will find that
takes longer. There is current research on this that I can point you
to, if you want.<br>
<br>
That's why we chose an approach that had a pre-existing widely
deployed existence proof (DCTCP) to start from. <br>
<br>
IETF groups like rmcat explicitly decided early on to require the
approach where the receiver is a dumb reflector, then new sender
congestion control algorithms can be deployed unilaterally. The
argument was that the feedback function can be thought of as a
sub-layer below the congestion control function. The ongoing
addition of accurate ECN feedback to TCP and to QUIC also take the
dumb reflector approach. And RTCP already does it that way.<br>
<br>
==ECN feedback problems===<br>
<br>
Over the last decades, we've made sure that the ECN feedback schemes
for TCP, QUIC, RTP (but not SCTP yet) can all feed back ECT(1) as
well as CE, in case a scheme like SCE came along. <br>
<br>
However, the solution in the TCP case [draft-ietf-tcpm-accurate-ecn]
is still problematic for SCE if you're impatient. The base scheme
overloads 3 bits in the TCP header, which it uses to feed back CE
only. To feed back ECT(1) we had to add a TCP option. That's not
going to get through middleboxes for many years. The TCP option is
also optional to implement. Two of the main TCP developers are
currently saying they will probably not implement it, at least not
initially.<br>
<br>
==Tunnels and lower layers==<br>
<br>
Over the years I've maintained a fairly lonely activity to make sure
that the ECN propagation behaviour of tunnels and layer 2 protocols
will treat ECT(1) as either a stronger output signal (as in SCE) or
as an alternative input signal to an AQM (as in L4S). Theoretically,
this allows either the SCE or the L4S approach. <br>
<br>
HOWEVER, you would probably not be surprised at how many people read
the spec [RFC6040], and say "Ah, no router alters ECT(0) to ECT(1)
today, so I'm not going to implement that unnecessary extra line of
code in my tunnel decap."<br>
<br>
==Wider benefit: Relaxing link ordering==<br>
<br>
By overloading the ECT(1) marking to mean "the sender uses time for
loss detection" a link can relax the reordering requirement on
ECT(1) packets today. You can do that with L4S, cos the sender is
selecting the marking. You can't do that when the AQM is selecting
the marking (as with SCE).<br>
<br>
If transport protocols detect loss in time units without tying it to
any marking (as in RACK on its own), a link cannot use this to relax
the ordering requirement until it is sure that all the legacy
non-RACK transports have decayed out of the network. That would be
measured in decades. <br>
<br>
HTH<br>
<br>
<br>
<br>
Bob<br>
<br>
<div class="moz-cite-prefix">On 11/03/2019 10:11, Dave Taht wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAA93jw5TS1haVk_nF8O79eQOdSu1FovSNrKyzU8Z5bfPdTUgxg@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Everybody, calm down. I put this out merely to get comment before we
submitted the first of several drafts. That draft is now submitted and
we've asked for a talk slot in the tsvwg for it. I cc'd the world to
get quick initial feedback, and I want to shut this overbroad
conversation down and move it to just the ecn-sane mailing list.
The l4s mailing list is dead, and the debates on the AQM mailing list and here,
unhelpful - for decades. So, back in august I started a new working
group here, under house rules that I thought would be more productive,
and asked that people that wanted to debate ecn more sanely, join. few
did.
And jon and I have been working for months (and largely not on the
list) to try and create a compromise proposal of which y'all just saw
the first output. There's more in the bufferbloat-rfcs repo.
The rules for joining the ecn-sane list are simple - take the time to
step back and write a write a short position paper, and join (or
create) a team. You needn't do that immediately. If you disagree with
the rules of operation of the ecn-sane working group, submit a pull
request or file a bug on the web site. where we can discuss it.
Ironically our ssl cert just expired and I don't remember how to fix it.
Please join the ecn-sane mailing list for discussing this stuff and
stop cc-ing the whole bufferbloat.net world on it, please.
_______________________________________________
Bloat mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bloat@lists.bufferbloat.net" moz-do-not-send="true">Bloat@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/bloat" moz-do-not-send="true">https://lists.bufferbloat.net/listinfo/bloat</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
________________________________________________________________
Bob Briscoe <a class="moz-txt-link-freetext" href="http://bobbriscoe.net/">http://bobbriscoe.net/</a></pre>
</body>
</html>