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. On Jan 17, 2014, at 3:51 PM, David Collier-Brown <dave...@rogers.com> 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 > dav...@spamcop.net | -- Mark Twain > (416) 223-8968 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
