From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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 ; Fri, 21 Oct 2016 10:27:13 +0200 To: bloat@lists.bufferbloat.net References: From: Mario Hock 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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