Re: [aqm] [tcpPrague] L4S status update

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/