On Fri, Jul 3, 2015 at 10:42 AM, Bob Briscoe <[email protected]> wrote: > Simon, > > Y, if you're going to start autoadjusting a hard-coded parameter, you have > to first question whether it was right to choose that parameter to hard-code > in the first place.
In codel, target was never a hardcoded parameter. It has always been specified as "5-10% of the interval", with a default of 5% (which equals 5ms on an interval of 100ms. In retrospect I really wish we had made it be an actual percentage in the code and configuration, and on other days wish we had only exposed interval as a parameter). We have always thought target in the case of wifi especially needed to be a function of "active stations". This is sort of where cake is going. Target is merely a delay that codel *aims for*. When it hits a drop rate (or the flow slows down) enough - it turns off, and the algorithm goes into behavior that only goes on again after the delay exceeds target for the current computed interval. It is good to have some new thinking on this, of course, and codifying how to modify the target - or work on different curves on various other algorithms, is wonderful. I like bob's other piece on smaller cwnds to keep "the tcp signal strength up", but am not as allergic as he to reducing mss in such cases. One of these days, perhaps, someone will successfully write up and explain the 3 modes of codel. People look too hard at the ramp up portion of the algo and not at what happens when you are at or near steady state. I would like to develop a model that shows what is going on in all the queues, all the time, and presents it graphically, somehow. > Bob > > > On 03/07/15 18:34, Simon Barber wrote: >> >> Hi Bob, >> >> Very interesting to see this. I had just recently privately proposed an >> extension to Codel - to auto tune the target parameter. The proposal is to >> observe the characteristics that are exhibited when target is too large or >> too small, and make adjustments appropriately. i.e. if you make a single >> drop during an interval, and the response of the flow is to go idle (even >> momentarily) then perhaps it was because target is too small. Using some >> rule you could increase target. Conversely you can heuristically identify >> when target is likely too large, and reduce it. >> >> Simon >> >> On 7/3/2015 5:20 AM, Bob Briscoe wrote: >>> >>> AQM chairs and list, >>> >>> 1) Delay-loss tradeoff >>> >>> We (Koen de Schepper and I) have designed an AQM aimed at removing the >>> need for low delay QoS classes, initially as a cost/complexity reduction >>> exercise for broadband remote access servers (BRASs). One of the >>> requirements given to us was: >>> * As background load increases, delay-sensitive apps previously given >>> priority QoS treatment (e.g. voice, conversational video) should continue to >>> get the same QoS as they got with Diffserv. >>> >>> We found that AQMs with a hard delay threshold (PIE, CoDel) have to drive >>> up loss really high in order to maintain the hard cap on delay. The levels >>> of loss start to cause QoS problems for voice, even tho delay is fine. >>> Indeed, we found that the high levels of loss become the dominant cause of >>> delay for Web traffic, due to tail losses and timeouts. >>> >>> Everyone has been focusing on delay, but we've not been noticing >>> consequent really bad loss levels at high load. >>> >>> Once you know where to look, the problem is easy to grasp: As load >>> increases, the bottleneck link has to get each TCP flow to go slower to use >>> a smaller share of the link. The network can increase either drop or RTT. If >>> it holds queuing delay (and therefore RTT) constant (as PIE and CoDel do), >>> it has to increase drop more. >>> >>> We found that by softening the delay threshold a little, at high load we >>> don't need crazy loss levels to keep delay within bounds. >>> BTW, the implementation needs fewer operations per packet than RED, PIE >>> or CoDel. >>> >>> Conversely, at low load, a hard queuing delay threshold also means that >>> delay will be /higher/ than it needs to be. >>> >>> I've written up a brief (4pp) tech report quantifying the problem >>> analytically. >>> <http://www.bobbriscoe.net/projects/latency/credi_tr.pdf> >>> >>> Koen and colleagues have since done thousands of experiments on their >>> broadband testbed with real equipment. It's looking good, even before we've >>> explored varying what we call the 'curviness' parameter (which varies how >>> hard the target it). We have a paper under submission with all the results, >>> which we'll post as soon as it's not sub judice. >>> >>> >>> 2) Does Flow Aggregation Increase or Decrease the Queue? >>> >>> Something else had been bugging me about how queue lengths vary with >>> load: The above argument explains how more TCP flows /increase/ the queue. >>> But queues are meant to get /smaller/ at higher levels of aggregation. >>> >>> The second half of the above tech report explains why there's no paradox. >>> And it goes on to explain when you have to configure an AQM with different >>> parameters for higher link capacity, and when you don't. It gives the >>> formula for how to set the config too. >>> >>> Writing this all down cleared up a lot of nagging doubts I had in my >>> mind. I hope it helps others too. >>> >>> >>> >>> Bob >>> >>> PS. Note my new interim email @. >>> >>> >>> >>>> >>>> >>>> -- >>>> ________________________________________________________________ >>>> Bob Briscoe http://bobbriscoe.net/ >>> >>> >>> _______________________________________________ >>> aqm mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/aqm >> >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm -- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
