http://yuba.stanford.edu/~appenz/pubs/sigcomm-extended.pdf

Anyone care to comment on this paper? I find that it confirms my beliefs and gut feeling I have had since 2000 or so, and my real life experiences with L3 switches with just a few ms of packet buffer.

I believe buffering is rather evil in a core network. A core network should be designed such that very little buffering occurs. Vendors should provide sufficient buffer to keep the link full at all times during congestion. Of course the previous sentence is chock full of permutations and the size of the buffer also depends on the amount of time you plan on spending congested. If you are willing to deal with the delay you can shoot for some protocol specific queuing strategies based on your customers needs. I suspect that cost is another factor in the equation where a circuit may cost more than the line card over the long run. Interestingly enough, this equation has started to change with the fiber glut. If it is cheaper to run your line cards at 100% all the time, instead of purchasing additional capacity, then a well developed set of buffers and queuing mechanisms would be appropriate (some traffic is not very sensitive to jitter/delay after all). I would beware the heavy reliance on TCP in this paper. I did not see much mention of high throughput UDP/GRE/RTP for that matter. There are some rather large and long lived non-TCP based flows nowadays. Many times the flows are not nearly as friendly as TCP is. Some of the flows can be very sensitive to buffering (RTP for VoIP for example). Unfortunately, predicting where those flows will turn up is a difficult proposition It would be interesting to find out if larger buffers help with DDOS issues. I can see how we could assure traffic during short lived DDOS attacks with the use of buffers but long lived attacks may not be dealt with as readily. Regards, Blaine