Jonathan,
On 20/03/2019 23:51, Jonathan Morton wrote:
On 21 Mar, 2019, at 1:29 am, Bob Briscoe <i...@bobbriscoe.net> wrote:
But more importantly, the L4S usage couples the minimized latency use
case to any possibility of getting a high fidelity explicit congestion
signal, so the "maximize throughput" use case can't ever get it.
Eh? There's definitely a misunderstanding or a difference in terminology
between us here. The whole point of using a congestion controller like DCTCP is
so that flow rate can scale indefinitely with capacity. Van Jacobson actually
noted that the original TCP was unscalable in a footnote to the tech report
version of the SIGCOMM paper.
The high fidelity congestion signal of what we call scalable congestion
controllers (like DCTCP) is inversely proportional to the window. So as window
scales up, the congestion signal scales down, so that their product remains
constant. That means the number of ECN marks per RTT is scale-invariant. So the
control signal remains just as tight at any scale.
If you'll indulge me for a moment, I'd like to lay out a compromise scenario
where a lot of L4S' stated goals are still met.
There is no dualQ. There is an AQM at the bottleneck link, of unspecified
type, which implements SCE. Assume that it produces CE marks like a
conventional AQM, and also produces SCE marks like an L4S AQM produces CE.
A sender implements DCTCP-SCE, which is essentially Paced NewReno modified to
subtract half of all acked data that was SCE-marked from its cwnd. (This is
equivalent to the DCTCP algorithm with g=1 and an arbitrarily small measurement
window, but acting on SCE instead of CE.) Any SCE mark also kicks it out of
slow-start.
The means by which SCE information gets back to the sender is left vague for
now; it's an orthogonal problem with several viable solutions.
What is missing from this scenario, from L4S' point of view? And why have I
been able to describe it so succinctly?
My goal is also to tighten the EWMA parameter, g, in DCTCP to 1 (or 2).
That is why we have recommended a queuing-time-based ramp AQM for the
Low Latency queue, which so far works equivalently to the step with g
set to its current default of 1/16. We have been doing experiments on
this for some time. But it is important to assess each change one at a
time.
Congestion controls are tricky to get stable in all situations. So it is
important to separate ideas and research from engineering of more mature
approaches that are ready for more widespread experimentation on the
public Internet. Our goal with L4S was to use proven algorithms, and put
in place mechanism to allow those algorithms to evolve.
As regards the desire to use SCE instead of the L4S approach of using a
classifier, please answer all the reasons I gave for why that won't
work, which I sent in response to your draft some days ago. The main one
is incremental deployment: the source does not identify its packets as
distinct from others, so the source needs the network to use some other
identifier if it wants the network to put it in a queue with latency
that is isolated from packets not using the scheme. The only way I can
see to so this would be to use per-flow-queuing. I think that is an
unstated assumption of SCE.
In contrast, L4S works with either per-flow queuing or dualQ, so it is
more appropriate for a wider spread of scenarios. Again, in that same
unanswered email, I described a way L4S can use per-flow queuing, and
Greg has since given pseudocode. There are other problems with doing the
codepoints the SCE way round - pls see that email.
There has been a general statement that the SCE way round is purer.
However, that concept is in the eye of the beholder. The SCE way round
does not allow the ECN field to be used as a classifier, so you don't
get the benefit above about support for per-flow-queueing and dual
queue. You also don't get the benefit of being able to relax
resequencing in the network, because the network has no classifier to
look at. For these, the SCE codepoint would need to be combined with a
DSCP, and I assume you don't want to do that.
The L4S way round signifies an alternative meaning of the ECN field,
which is exactly what it is. The problem of having to guess which type
of packet a CE used to be has been roundly discussed at the IETF in TCPM
and TSVWG WGs and it has been decided it is a non-problem if it is
assumed to have been ECT(1) even if it was not - as written up in
draft-ietf-ecn-l4s-id. And that discussion assumed TCP with 3DupACK
reordering tolerance, not the more liberal use of RACK (or a RACK-like
approach in other transports). With a RACK-like approach, it becomes
even less of a problem.
Bob
- Jonathan Morton
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
