On Thu, Jan 23, 2014 at 1:10 AM, Fred Baker (fred) <[email protected]> wrote: > No, you're not blowing smoke. I'm not sure I would compare the behavior to > PMTUD, as in that the endpoint is given a magic number and manages to it, > where in this case, it is given the results of its behavior, and it manages > to improve that. > > But this is what I have rambled on about in threads relating to the size of > a buffer. Folks would really like to have a magic way to calculate the > buffer size (an amount of memory) they need to install in a router or > switch, and it isn't that easy, because it has a lot to do with where in the > network a system is located and how it is used by the applications that use > it. But AQM, in the end, isn't about buffer size. It is about buffer > occupancy. In the ideal case, if there are N sessions active on the > bottleneck link in a path, we would like each to obtain 1/N of the > bottleneck's capacity, which is to say that it should be able to maximize > its throughput, while keeping an average of zero packets standing in the > queue (minimizing both latency and variation in latency). If you know your > math, you know that the ideal goal isn't actually achievable. But that > doesn't stop us from trying to asymptotically approach it.
I prefer to think of the goal as to keep a minimum of 1 packet in the queue, not as an average of 0. > > On Jan 17, 2014, at 3:51 PM, David Collier-Brown <[email protected]> wrote: > > I've been reading through the internet-drafts, and one paragraph struck me > as very illuminating. This is therefor a sanity-check before I go full-hog > down a particular path... > > The comment is from Baker and Fairhurst, > https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ and the > paragraph is [emphases added] > > The point of buffering in the network is to absorb data bursts and to > transmit them during the (hopefully) ensuing bursts of silence. This is > essential to permit the transmission of bursty data. Normally small queues > are preferred in network devices, with sufficient queue capacity to absorb > the bursts. The counter-intuitive result is that maintaining normally-small > queues can result in higher throughput as well as lower end-to- end delay. > In summary, queue limits should not reflect the steady state queues we want > to be maintained in the network; instead, they should reflect the size of > bursts that a network device needs to absorb. > > All of a sudden we're talking about the kinds of queues I know a little > about (:-)) > --- > > I'm going to suggest that these are queues and associated physical buffers > that do two things: > > hold packets that arrive at a bottleneck for a long as it takes to send them > out a slower link that they came in on, and > hold bursts of packets that arrive adjacent to each other until they can be > sent out in a normal spacing, with some small amount of time between them > > > In an illustration of Dave Taht's, the first looks something like this > > -------------------------+ > |X| |X| +------------------- > |X| |X| |XXX| |XXX| > |X| |X| +------------------- > -------------------------+ > > At the choke-point there is a buffer at least big enough to give the packet > a chance to wheel from line into column (:-)) and start down the smaller > pipe. > > The speed at which the acks come back, the frequency of drops, and any > explicit congestion notifications slows the sender until they don't overload > the skinnier pipe, thus spacing the packets in the fatter pipe out. > > Various causes [Leland] can slow or speed the packets in the fat pipe, > making it possible for several to arrive adjacent to each other, followed by > a gap. The second purpose of a buffer is to hold these bursts while things > space themselves back out. > > They need to be big enough at minimum to do the speed matching, and at > maximum, big enough to spread a burst back into a normal progression, > always assuming that acks, drops and explicit congestion notifications are > slowing the sender to the speed of the slowest part of the network. > --- > > If I'm right about this, we can draw some helpful conclusions > > buffer sizes can be set based on measurements: > > speed differences, which are pretty static, plus > observed burstyness > > drops and ECN can be done to match the slowest speed in the path > > The latter suddenly sounds a bit like path MTU discovery, except it's a bit > more dynamic, and varies with both path and what's happening in various > parts of it. > > To me, as a capacity/performance nerd, this sounds a lot more familiar and > manageable. My question to you, before I start madly scribbling on the > internet drafts is: > > Am I blowing smoke? > > --dave > > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > [email protected] | -- Mark Twain > (416) 223-8968 > > _______________________________________________ > > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > > > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
