From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 B4A3F3B2A2 for ; Fri, 2 Dec 2016 14:15:42 -0500 (EST) Received: by mail-oi0-x236.google.com with SMTP id b126so276684812oia.2 for ; Fri, 02 Dec 2016 11:15:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qL5dLq5qDtE3zzqJ+cd9SsdjmrGYJIMNVDiZu/pHH8A=; b=vrjjoTJDNcirLDGEgJrHUptSzTvberRm32MuBUDNm8JA2L+TBkA5lsiJgfMT+KAR2M H5K4H68g83mCUFB83nAPZieWJE2VbmnqyvhbBu1TEj+iWPv77sXSF6dmjnJv1QOMYKVM g2dQFIUbQy7w1Afc7zFgtle6X7MwG18m+BtLNyMrHJH/IxppYECpRHrQDEJ8S6zGP2tt auyzkjz6e3Y1eTdMWqvF6KpmI14HWgr7p5hKHZlNVmHWERpL4vq5k9I//yD+8aoZdkVt vz1hDZOoK8VX9IaKgOMBFtguxnD41lVmTs1W2GuoMQuTWWq2mFiTAf1Lmf2g4G4RgUuH J8hw== 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; bh=qL5dLq5qDtE3zzqJ+cd9SsdjmrGYJIMNVDiZu/pHH8A=; b=PGplJMhwAN00mCrcTh/weT9Y1qNoVMHOJDKtwMiTXcmeTH+e8BTkAYNFDaiKOXxcn9 P9TtgCVIoJPx3rEBjxkT2//zj2noJ/N0cBm/OuuZn+V4ZjNWc4psmwZ+tjAuHb80fNyP OjFW+JCpQvjfNau93edWbuZlhd1jSPDBR/xs8uGUFvYA3N1nJNblZn8LtulPuE+fZhGZ MBlpXxMEMKzngVhpVK8DC68+l3od2m6rZRklGwacVNbsQxsveB2nbXI+ou/imuQeoBTd Py/cWAVWNfgm2VFj24/G3wZ5xPaQ6Kdm+zYLKPqt5YkJHyq+I9QXn1SpJ7oLxMHikv2e sFyg== X-Gm-Message-State: AKaTC03EaDyTpal2bA2Bxcc9uYOiil9SwatZMXUCN7/Ff3AnWTFxG7FJd//+shHbpWdQxzpXX/7QnQA/iKbbsw== X-Received: by 10.202.71.131 with SMTP id u125mr23823419oia.170.1480706141968; Fri, 02 Dec 2016 11:15:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.28.9 with HTTP; Fri, 2 Dec 2016 11:15:41 -0800 (PST) In-Reply-To: References: From: Aaron Wood Date: Fri, 2 Dec 2016 11:15:41 -0800 Message-ID: To: Dave Taht Cc: bloat , "aqm@ietf.org" Content-Type: multipart/alternative; boundary=001a113e54f69bde970542b1c3af Subject: Re: [Bloat] TCP BBR paper is now generally available 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, 02 Dec 2016 19:15:42 -0000 --001a113e54f69bde970542b1c3af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is really fascinating reading. The following made me stop for a second, though: "The bucket is typically full at connection startup so BBR learns the underlying network's BtlBw, but once the bucket empties, all packets sent faster than the (much lower than BtlBw) bucket fill rate are dropped. BBR eventually learns this new delivery rate, but the ProbeBW gain cycle results in continuous moderate losses. To minimize the upstream bandwidth waste and application latency increase from these losses, we added policer detection and an explicit policer model to BBR." So, how is this likely to be playing with our qos_scripts and with cake? Given we have people from both Google and qos_scripts/cake development here, do we need to compare some notes on how these interact? Are there settings in the HTB setup used by qos_scripts that will make it play more nicely with BBR (smaller quantums, smaller burst sizes, etc)? -Aaron On Fri, Dec 2, 2016 at 7:52 AM, Dave Taht wrote: > http://queue.acm.org/detail.cfm?id=3D3022184 > > -- > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --001a113e54f69bde970542b1c3af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is really fascinating reading.

The= following made me stop for a second, though:

&quo= t;The bucket is typically full at connection startup so BBR learns the unde= rlying network's BtlBw, but once the bucket empties, all packets sent f= aster than the (much lower than BtlBw) bucket fill rate are dropped. BBR ev= entually learns this new delivery rate, but the ProbeBW gain cycle results = in continuous moderate losses. To minimize the upstream bandwidth waste and= application latency increase from these losses, we added policer detection= and an explicit policer model to BBR."

So, h= ow is this likely to be playing with our qos_scripts and with cake?

Given we have people from both Google and qos_scripts/cak= e development here, do we need to compare some notes on how these interact?= =C2=A0 Are there settings in the HTB setup used by qos_scripts that will ma= ke it play more nicely with BBR (smaller quantums, smaller burst sizes, etc= )?

-Aaron


On Fri, Dec 2, 2016 at 7:52 AM,= Dave Taht <dave.taht@gmail.com> wrote:
http://queue.acm.org/detail.cfm?id= =3D3022184

--
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
ht= tp://blog.cerowrt.org
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
https://lists.bufferbloat.net/listinfo/bloat

--001a113e54f69bde970542b1c3af--