From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 133E03B2A2 for ; Thu, 20 Oct 2016 10:44:38 -0400 (EDT) Received: by mail-yb0-x234.google.com with SMTP id f97so19942756ybi.1 for ; Thu, 20 Oct 2016 07:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PbMf27gNIN7iyd3jQQ6etstrQ7svL2OgSkzf+8U5fMI=; b=O+xUTL8tbhCyvi9KOt+jioq6RU3c8fiMkAtn40YT011oq/aIv1W3+/lwe7LVLBddgg XyrIu7BzT195GXveajzG8Mt+xg/NKCGX552tfbW+SrtYrz955yPN6gvhX/2P3y+HUhx1 4JyEVJaTw37m+bon1pLr6ub93k0CsEAhqoQloHqiGAw0aAsYV3ZrZO1ij5yCnM0nXWP+ juDtriaRTjueW6Bvr+RqxdJGpxBr3tlcRqShsoU2nRUw97jDjSW8SAisN0dgxgfATUmw sV3W9TN4KPR4cESPPWozFE2keJ5WdkxFkdcHxM3NKWzsKO2+wRTqvW6WcTRDuC3K7/Z8 2qsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PbMf27gNIN7iyd3jQQ6etstrQ7svL2OgSkzf+8U5fMI=; b=AFjqQtG6HsUBgK0nBzazZUicr3J+QRLRC8Nv/rscXUvjfy7zdd4H0lm/VDedDD5T8k tahobgfxRrf0e40bL1F2JI+MStsG1QqPlUrxa3+vD4LQRMMmLkwcA3+aooZmiz+p+COT rgAesnzE07sclexo8GNSbvRXALdn/ZhtN32zFNIsyQ8u8AViiU+iH9wV3eyeRoHg1Mok r2JmggRaEmEX0hk5LP2MxMjEHs3INI0slPlUdu4IQCeGlAfm5TPIanAJd3+olzt0EAS2 ya+Hp+2pwgmGySFZ6rC4LQ94xLh2GoZaeaMLNXfPvHiVfnQCfeRUgXL/bbmL9K4XVuZr OLzw== X-Gm-Message-State: ABUngvcTX2lyZXN/DHjXD9eSGwkSdXAOTTFnD/RHmx/H6aUba6vLpcGO49wfOxysHSKxKV9fxEvTYbU9z+LFmCcB X-Received: by 10.157.41.205 with SMTP id g13mr419935otd.160.1476974677451; Thu, 20 Oct 2016 07:44:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.193.5 with HTTP; Thu, 20 Oct 2016 07:44:06 -0700 (PDT) In-Reply-To: References: From: Neal Cardwell Date: Thu, 20 Oct 2016 10:44:06 -0400 Message-ID: To: Rich Brown Cc: bloat , make-wifi-fast@lists.bufferbloat.net, cerowrt-devel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 20 Oct 2016 12:34:06 -0400 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: Thu, 20 Oct 2016 14:44:39 -0000 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 =E2=80=9Csweet spot=E2=80=9D where latency is noticeably reduced, while the impact on throughput is negligible What happens next? .... Fixed buffer size setting impractical for scaled usage I would agree that there is a delay/throughput "sweet spot", one that varies across network scenarios. BBR congestion control is specifically designed to dynamically estimate the bandwidth and delay characteristics of the path, to estimate where that "sweet spot" is, and operate near it. The BBR paper ( currently on the ACM Queue site - http://queue.acm.org/app/ ) has a diagram and discussion related to this non-linear delay/throughput trade-off that the presentation mentions. neal