From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mario.hock@kit.edu>
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de
 [141.3.10.81])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by lists.bufferbloat.net (Postfix) with ESMTPS id 3AF683B25E
 for <bloat@lists.bufferbloat.net>; Fri, 21 Oct 2016 04:27:25 -0400 (EDT)
Received: from i72t450mh.tm.uni-karlsruhe.de ([141.3.71.47])
 by iramx2.ira.uni-karlsruhe.de with esmtpsa port 587 
 iface 141.3.10.81 id 1bxVAX-0006wH-S1
 for <bloat@lists.bufferbloat.net>; Fri, 21 Oct 2016 10:27:13 +0200
To: bloat@lists.bufferbloat.net
References: <B706D9CB-DB33-4B12-AD01-DC2388607D86@gmail.com>
 <CADVnQymkhvkS1eL5sjnzgKZ4QfXO8h2c-_Kmq=9mbgL1J1oCDg@mail.gmail.com>
From: Mario Hock <mario.hock@kit.edu>
Message-ID: <2248e9b7-63f2-713d-5a35-746f75a93a9e@kit.edu>
Date: Fri, 21 Oct 2016 10:27:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CADVnQymkhvkS1eL5sjnzgKZ4QfXO8h2c-_Kmq=9mbgL1J1oCDg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de  esmtpsa 1477038434.
Subject: Re: [Bloat] [Cerowrt-devel] Comcast's NANOG slides re Bufferbloat
 posted (Oct 2016)
X-BeenThere: bloat@lists.bufferbloat.net
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: General list for discussing Bufferbloat <bloat.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/bloat>,
 <mailto:bloat-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/bloat>
List-Post: <mailto:bloat@lists.bufferbloat.net>
List-Help: <mailto:bloat-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/bloat>,
 <mailto:bloat-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2016 08:27:25 -0000

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