The sqrt() in CoDel is *not* tuning it to TCP, it's scaling the drops to the right proportionality for controlling the queue. It's an artefact of happening to measure the square of what you really want. Nevertheless, CoDel's general behaviour is actually tuned to TCP, allowing a new flow to build queue for a while is only appropriate for TCP-like controllers.
I believe we need to standardise the signals from the network to the transport, so AQM designers at least know what signals and signal density they need to deliver (there's at least six signal paths... drops, ECN and arrival time, and their respective statistical distributions). Given that, we can then make sure that all the transport control systems deal with those signals sanely (and ignore those that are not helpful). That's quite a bit of work, and I expect it to need its own working group. It will also have a research dimension, so ICCRG will need to be involved. That WG should be in the transport area, of course. Andrew On Wed, Mar 13, 2013 at 4:34 PM, Roland Bless <[email protected]> wrote: > Hi, > > two things (not sure whether tsv-area or tsvwg is appropriate) > following today's AQM discussion in the tsvarea meeting: > > - IMHO AQM work is strongly related to the transport area > as transport protocols are affected (as Lars already mentioned) > and we also have ECN which is not working without AQM underneath. > > - it may be the case that it makes no difference which AQM algorithms > (codel, PIE, whatever) are actually deployed (as Matt Mathis pointed > out) - and I agree with Fred that it would be good to have the > flexibility to use different AQMs. > However, to me it's not quite obvious how consistent a system with > different heterogeneous deployed AQMs works. For instance, codel is > (somewhat) tuned to TCP's CC behavior by employing a sqrt() related > drop intensity, while other's are maybe not tuned to specific > transport protocols. > It may be interesting to study how a combination of different AQMs > along a path influences the transport protocol's behavior in > comparison to a more homogeneous AQM setting (maybe it doesn't > matter so much as long as the bottleneck location isn't moving)... > > Regards, > Roland >
