<div dir="ltr">Hello<div><br></div><div>What is the best current practice for buffer size? For customer facing ports, core network ports and transit links?</div><div><br></div><div>We have a buffer problem, discovered by a customer that moved their servers to a cloud service some distance away. That resulted in a drastic reduced transfer speed between their office and the cloud service. Nothing much could be done since we, like so many others, have switches with extreme fast port speeds (48x 10G, 4x 100G) with a tiny shared 12 MB buffer.</div><div><br></div><div>Now the time has come to upgrade that hardware to something that does have plenty of buffer capacity, so I am planning out what the settings should be.</div><div><br></div><div>I have read this paperĀ <a href="http://web.stanford.edu/class/cs244/papers/sizing-router-buffers-redux.pdf">http://web.stanford.edu/class/cs244/papers/sizing-router-buffers-redux.pdf</a> which claims not much buffer is needed at all. And I think they are completely wrong. In the paper they assume we are trying to get as much throughput on a congested core or transit port. But we always make sure those are not congested, so that misses the mark completely. For core ports we are concerned about microbursts and for customer ports we do care about a single TCP session being able to get the max throughput. The paper assumes there will be a lot of TCP sessions sharing the bandwidth, but that is not always the case with customer ports. It might be a guy downloading an ISO image with him being the only guy at the office.</div><div><br></div><div>The common wisdom is to set the buffer size to one bandwidth-delay product. And also that bigger buffers than this is harmful. But that raises the question of what distance do I tune for? Amsterdam is 10 ms away. East coast USA is 100 ms.</div><div><br></div><div>Also the new hardware (Juniper ACX710) does support more than one queue per port. Would it be possible to have that ISO download go into a queue for heavy streams and allow smaller streams to skip the line, so we do not see the downside of a heavy buffer (buffer bloat)? It is no longer just a simple matter of buffer size.</div><div><br></div><div>What are others doing to deliver the best possible performance to customers with regards to buffering?</div><div><br></div><div>Regards,</div><div><br></div><div>Baldur</div><div><br></div><div><br></div><div><br></div></div>