Mario,
On 24/11/16 16:57, Mario Hock wrote:
Hello Bob and Roland,
I followed your discussion and want to share my opinion, here.
(Comments inline).
Am 22.11.2016 um 20:09 schrieb Bob Briscoe:
*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 reason that the AQMs also work with these CCs is because the CCs
still have a lot in common with TCP Reno, like that they use a
congestion window, that they increase the CWnd up until packet loss
etc. Also the 1/sqrt(p)-law is still, more or less, applicable to them.
For newer CCs like BBR or PCC, the 1/sqrt(p) does not apply. They are
based i.a. on throughput vs. loss/delay probing. BRR, for example,
does not even use a congestion window (at least not in the same way as
the other CCs do).
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.
I agree with the general idea. But from that reasoning newer CCs, like
BBR, belong into the "new" queue, where L4S lives in!
[BB] That's not for you (or I) to say.
The designer of a new CC can choose to innovate within Classic queues or
L4S. Whichever they choose, they would set the identifier that
classifies their packets into the appropriate queue, and they would have
to coexist with the other behaviours in that queue.
We defined L4S as a framework to encourage innovation with new CCs in
the L4S queue (because it's easier to deploy very nice properties), but
please don't assume we were trying to mandate that! Also, if considering
defining a CC with respect to L4S, bear in mind that L4S is only aiming
for experimental status in the IETF at present.
L4S is not defined as "anything new must go here".
If they don't belong in the same queue as L4S, then the queues should
not be coupled in the way you propose. This coupling prevents any
innovation in the non-L4S queue.
[BB] Not at all.
*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.
I think L4S is not studied well enough, yet to be standardized in a
way that other low delay approaches must adjust to the L4S concepts.
[BB] They don't have to. L4S is aiming for experimental status at
present. Strictly, other low delay experimental protocols only have to
prove they coexist with standards track CCs (ie. Reno). In practice, any
new experimental CC also has to prove it co-exists with the deployed
base, whether standards track or not (e.g. Cubic, Compound etc). If L4S
becomes part of the deployed base, it will have got there on its own
merits, then other experiments that come along later will certainly have
to interwork.
But anyway, as explained above, this should be no more difficult than
interworking with Reno in the Classic queue, as if L4S was not there.
Then interworking with L4S should come for free.
There is at least BBR, PCC, nv (New Vegas) currently under development
that all bring in fresh ideas how congestion control could be made in
the future. Standardizing L4S as "the" new concept without intensively
study other approaches is just too soon.
[BB] I hope I've convinced you that L4S doesn't preclude any of these.
L4S is certainly different in that it is not a CC, rather it is a new
space for easier CC experimentation. Another difference from all the CCs
you mention above was the goal of persuading network operators of the
benefit of creating such a space; because L4S is about improving the
information flow between network and hosts. But none of that stops other
CCs using the old space for experimentation.
If we want to act now, we should focus on a solution that enables new
approaches in congestion control but is not tailored to either
Reno/Cubic or L4S/DCTCP. Otherwise more research is required how we
want the future of congestion control look like.
[BB] No-one is stopping you proposing something concrete.
You will, however, need an implementation, and proof that app
performance has significant benefits, and a group of people interested
in working on the idea, and .... This all takes work and time. Work on
what has become L4S first started in 2012, see:
1) Wu, H., Ju, J., Lu, G., Guo, C., Xiong, Y. & Zhang, Y., "Tuning ECN
for Data Center Networks," In: Proceedings of the 8th International
Conference on Emerging Networking Experiments and Technologies CoNEXT
'12 pp.25-36 ACM (2012)
2) http://www.bobbriscoe.net/present.html#1207tsvarea-dctcp
The choice of 1/p as a definition of the new L4S experimentation space
was not arbitrary. There are numerous benefits to the number of
congestion signals per RTT being * much higher and
* invariant with flow rate.
You will see further research that exploits these properties soon...
Cheers
Bob
Best regards,
Mario Hock
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
