Sufficient Buffer Sizes

Wed Jan 3 09:02:03 UTC 2024

Threads like this are why I subscribe to this.

On Wed, Jan 3, 2024 at 12:27 AM Saku Ytti <saku at ytti.fi> wrote:

> On Wed, 3 Jan 2024 at 01:05, Mike Hammett <nanog at ics-il.net> wrote:
>
> > It suggests that 60 meg is what you need at 10G. Is that per interface?
> Would it be linear in that I would need 600 meg at 100G?
>
> Not at all.
>
> You need to understand WHY buffering is needed, to determine how much
> you want to offer buffering.
>
> Big buffering is needed, when:
>    - Sender is faster than Receiver
>    - Receiver wants to receive single flow at maximum rate
>    - Sender is sending window growth at sender-rate, instead of
> estimated receiver-rate (Common case, but easy to change, as Linux
> already estimates receiver-rate, and 'tc' command can change this
> behaviour)
>
> Amount of big buffering depends on:
>     - How much can the window grow, when it grows. Windows grow
> exponentially, so you need (RTT*receiver-rate)/2, /2 because if the
> window grows the first half is already done and is dropping in at
> receiver-rate, as ACKs come by.
>
>
> Let's imagine your sender is 100GE connected, and your receiver is
> 10GE connected. And you want to achieve a 10Gbps single flow rate.
>
> 10ms RTT - 12.5MB window size, worst case you need to grow 6.25MB and
> -10% off, because some of the growth you can send to the receiver,
> instead of buffering all of the growth, so you'd need 5.5-6MB.
> 100ms RTT would be ~60MB
> 200ms RTT would be ~600MB
>
>
> Now decide the answer you want to give in your products for these. At
> what RTT you want to guarantee what single-flow maximum rate?
>
> I do believe many of the CDNs are already using estimated
> receiver-rate to grow windows, which basically removes the need for
> buffering. But any standard cubic without tuning (i.e. all OS) will
> burst at line-rate window growth, causing the need for buffering.
>
> --
>   ++ytti
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240103/599c22b7/attachment.html>