* Saku Ytti <saku@ytti.fi>
Why I said it won't be a problem inside DC, is because low RTT, which means small bursts. I'm talking about backend network infra in DC, not Internet facing. Anywhere where you'll see large RTT and speed/availability step-down you'll need buffers (unless we change TCP to pace window-growth, unlike burst what it does now, AFAIK, you could already configure your Linux server to do pacing at estimate BW, but then you'd lose in congested links, as more aggressive TCP stack would beat you to oblivion).
But here you're talking about the RTT of each individual link, right, not the RTT of the entire path through the Internet for any given flow? Put it another way, my «Internet facing» interfaces are typically 10GEs with a few (kilo)metres of dark fibre that x-connects into my IP-transit providers' routers sitting in nearby rooms or racks (worst case somewhere else in the same metro area). Is there any reason why I should need deep buffers on those interfaces? The IP-transit providers might need the deep buffers somewhere in their networks, sure. But if so I'm thinking that's a problem I'm paying them to not have to worry about. BTW, in my experience the buffering and tail-dropping is actually a bigger problem inside the data centre because of distributed applications causing incast. So we get workarounds like DCTCP and BBR, which is apparently cheaper than using deep-buffer switches everywhere. Tore