Re: [Bloat] [Cerowrt-devel] Comcast's NANOG slides re Bufferbloat posted (Oct 2016)

[Mario Hock <mario.hock@kit.edu>]

Hi altogether,

Am 20.10.2016 um 16:44 schrieb Neal Cardwell:
> On Thu, Oct 20, 2016 at 8:15 AM, Rich Brown <richb.hanover@gmail.com> wrote:
>>
>> https://www.nanog.org/sites/default/files/20160922_Klatsky_First_Steps_In_v1.pdf
>
> Regarding these passages from the slide deck:
>
>    What do the results suggest?
>    ....
>    There may be a tradeoff between upload latency
>    and upload throughput, and that tradeoff is
>    not necessarily linear: there may be a “sweet spot”
>    where latency is noticeably reduced, while the
>    impact on throughput is negligible
>
>    What happens next?
>    ....
>    Fixed buffer size setting impractical for scaled usage

Opinions may vary in what one considers as "sweet spot", but if it is 
the minimal buffer size that results in full throughput for a single TCP 
flow, the buffer size must be:

1.0 * Bandwidth-Delay-Product for TCP Reno and
0.43  * Bandwidth-Delay-Product for Cubic TCP

with Bandwidth-Delay-Product as base RTT (i.e., RTT without queuing 
delay) * bottleneck capacity.

This means that the required buffer strongly depends on your base RTT to 
the server (resp. the other end-point).

For a formula and a proof see:

W. Lautenschlaeger and A. Francini, "Global synchronization protection 
for bandwidth sharing TCP flows in high-speed links," 2015 IEEE 16th 
International Conference on High Performance Switching and Routing 
(HPSR), Budapest, 2015, pp. 1-8.
doi: 10.1109/HPSR.2015.7483103

Best Regards,

Mario Hock