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; i/nstead, 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: 1. 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 2. 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: o speed differences, which are pretty static, plus o 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
