nanog mailing list archives

Re: External BGP Controller for L3 Switch BGP routing


From: Tore Anderson <tore () fud no>
Date: Mon, 16 Jan 2017 13:36:54 +0100

* 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


Current thread: