From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 0E5EA3B25E for ; Thu, 20 Oct 2016 10:44:38 -0400 (EDT) Received: by mail-yb0-x229.google.com with SMTP id g68so25107651ybi.0 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=AYebl4di/5YADDKKRInkjbA63+YFrop3VUFNpqaEnkUE+sHmv2NyHh3CiHjQNwvka0 UQsjTfl4MdjU5Y3J6vNglDdZIGd5zbUH+cv1l3buvoJ0uHCIG45weq56uj4m7FM5WjNY zJo4SzaDdsLdnLFzOHM8R7ygovBYF5xZTU7Q9x9xdD3QFJMJLTNXTi2s/V2EZ84jREbG M/H3EY+H0wHIHyoqx/9On4u3QcTdCtG7S30E6LUGD0oYRRtPhp5dwP3E7/FH3oU6Uord VEtY9KYbRTiqoWybT8b9jWNvHCF+1rrKoQDdbEt4Z8XnZ9FIlSIcDvbfS2+ARpnZgBvG tyOQ== X-Gm-Message-State: ABUngvfy6KZaMj0RUvmsBzQcKN1WFQo/XPWfXJVEdc06n1foXStTExfJVi+kbxHol25nP0423KHhuTDkKVPaUBGR 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 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: Mon, 28 Nov 2016 08:47:10 -0500 Subject: Re: [Make-wifi-fast] [Cerowrt-devel] Comcast's NANOG slides re Bufferbloat posted (Oct 2016) X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 20 Oct 2016 14:44:39 -0000 X-Original-Date: Thu, 20 Oct 2016 10:44:06 -0400 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