Roland,
I share your concern about cc-specific AQMs. But that is not a good
characterization of what we're doing.
On the current Internet, everything is meant to be somewhat "friendly"
to the original TCP cc (now spec'd in RFC5681). All sorts of cc's work
alongside that, with slightly different "fairness" properties, and only
one AQM is needed to cover them all. Nonetheless, Reno is the "lamest",
so everyone has to try to "Do (not much) Harm" to the lamest.
*Is any AQM CC-neutral?**
*Note rule 5 <https://tools.ietf.org/html/rfc7567#section-4.5> in the
AQM Guidelines [RFC7567]
"AQM algorithms SHOULD NOT interpret specific transport protocol
behaviors."
In general, the advice in that section is sound, but I don't think we
realized at that time just how subtle this issue is.
Since then, I discovered that the autotuning parameter table in the PIE
algorithm is designed very precisely around the 1/sqrt(p) rule of Reno
(see Fig 5 in the PI^2 paper <http://www.bobbriscoe.net/pubs.html#PI2>).
Similarly, the sqrt control law in Codel claims to be dependent on Reno
{Note 1}.
The point is that these AQMs still work fine with Cubic, Compound,
Westwood, etc, because all these ccs were designed to interwork with
Reno. {Note 2}
The idea of L4S (and specifically the DualQ Coupled AQM and the L4S ID
spec) is to enable a shift to a completely different "norm", but still
coexist with all the 'Classic' cc's that coexisted around the old
"norm". The new norm is intended to be just as fuzzy as the old norm
{Note 3}. The idea is two fuzzy clouds of congestion controls, around an
old and a new norm that are related together.
*BBR**
*I believe BBR attempts to be 'friendly' to loss-based flows when
competing in the same queue. But it's still research, and we don't yet
know how good it is at that in all scenarios, although we do have code
to test now. Given BBR currently sets Not-ECT, it would classify itself
into the Classic queue of a DualQ AQM, and if it coexists with Reno it
/should/ coexist with L4S traffic in the other queue. See Koen's recent
posting
<https://www.ietf.org/mail-archive/web/tsvwg/current/msg14771.html>
about this.
There would be nothing to stop someone designing a variant of BBR that
coexisted in the L4S queue with Scalable CCs like DCTCP (the point being
that if the bottleneck was not DualQ it would keep delay low and if if
the bottleneck was DualQ it would benefit even more from the lower
queuing delay there). However, it would have to be a bit more careful
about its whole round trip of queue probing, to avoid increasing the
delay in the L4S queue. You'll see that I suggested to Neil Cardwell
that they consider probing with a few packets rather than a whole
window, e.g. the chirping
<http://www.bobbriscoe.net/pubs.html#chirp_impl> technique that Mirja
and I looked into back in 2010 was designed to find the same knee
between rate increase and delay increase, with far fewer packets. I
thought of a better way of using chirping a few weeks ago, so I will be
returning to that too.
*Specs**
*There is no statement that all L4S cc's MUST adhere to a 1/p rule. The
L4S ID draft says:
"The inverse proportionality requirement above is worded
as a 'SHOULD' rather than a 'MUST' to allow reasonable flexibility
when defining these specifications."
I hope that 'SHOULD' is fuzzy enough - I suspect adding more words would
make it less fuzzy. But I would welcome wording to make it even more
fuzzy if you would like to engage in wordsmithing.
Nonetheless, we are trying to steer a path between a rock and a hard
place. Because, to shift to a much calmer waters beyond the rocks, we
have to define some number to relate L4S to Classic. I am wary because
when ECN was specified, there were attempts to define ECN as different
to drop. However, ECN originally ended up "the same as drop" because
no-one could muster enough backing behind any particular number to
relate the two, so the number '1' won by default (ie. ECN = 1 * drop^1 ).
Bob
{Note 1} I have never got a good answer to my questions on aqm@ietf as
to why a sqrt that controls the shrinkage of the spacing between dropped
packets has something to do with the steady state law of Reno,
particularly because the law leads to linear growth in p over time.
{Note 2} Actually, I don't believe PIE would work that well with Cubic
at v high BDP, once it was far from Reno-friendly, but that's only
intuition from the stability analysis, not from actual testing.
{Note 3} Indeed, at the moment, when DCTCP is on its own in the L4S
queue of the DualQ AQM as coded now, it hits up against a step
threshold, which makes it behave as 1/p^2, not 1/p. For now, that's just
because we didn't want to change too much about DCTCP at one time. But
it's also got some nice properties. This will all need to be discussed
as the DualQ AQM is specified more deeply.
On 21/11/16 14:27, Bless, Roland (TM) wrote:
Hi Bob and all,
see below.
Am 01.11.2016 um 01:02 schrieb Bob Briscoe:
A few people have been working away to specify and document all the
aspects of the new Low Latency, Low Loss, Scalable throughput (L4S)
service, which held a successful BoF in Berlin. As the decision was to
try to work across multiple WGs, I thought it would be useful to give ...
Thanks for putting this together.
* Dual Queue Coupled AQM
o With Curvy RED for Linux (access available shortly)
o With PI2 for Linux <https://github.com/olgabo/dualpi2> [*UPDATED*]
I'll repeat my concerns that I already expressed at the L4S BOF in Berlin:
While I agree that we probably need to separate low-delay congestion
control schemes from traditional "queue-filling" congestion schemes,
I strongly suggest to avoid putting a congestion control-specific
coupling scheme into the network (a classic case for applying the
"end-to-end arguments in system design").
The current Dual queue coupled AQM proposal has got a coupling based on
a congestion control specific dropping law p_C=(p_L/2)². So if
congestion control schemes change then this coupling needs to be
adapted. For example, the currently proposed scheme may fail if that
vast majority of TCP traffic is using BBR other some other forthcoming
CC scheme instead of Cubic, Reno, Compound etc. The same applies to
draft-briscoe-tsvwg-ecn-l4s-id, section 2.5, where the dropping
likelihood is defined.
Regards,
Roland
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
