External BGP Controller for L3 Switch BGP routing

Tore Anderson tore at fud.no
Mon Jan 16 12:36:54 UTC 2017

* Saku Ytti <saku at 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.


More information about the NANOG mailing list