From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 5E9573B2A2 for ; Fri, 2 Dec 2016 17:22:54 -0500 (EST) Received: by mail-oi0-x229.google.com with SMTP id b126so281736644oia.2 for ; Fri, 02 Dec 2016 14:22:54 -0800 (PST) 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; bh=WueH0k3mRIbWcDuFgllfEo0GumPWmtMmYDujODPRp5U=; b=E2ccCpAEYh4BjTkexy9no+dQ5CWZP1BRgt7YlkTNVaG4e6YFj4rgKG/F89Vzf2fKVc WZs8rJmhrXQcz7SS+GjJnsBx1mW7YjFgtyNjHatoYv7cVKD01b0dvOJ6eMfpw8wulptO Xzsa9gI5SRYrQZAVj4cBo3UttXzcBGYyz8CIJwLD5qi0UsR1CXkGqbyEAuakeS8dyPtU qgzmZ+MwH38G7cshhPfJwhwAovUUe+F+R9Wy/zRcbpb5oGagOpX62w9cVxgWSn50hwgD NFH9Z5Kp/p9ndr3PW0bNn5m1CmqVc+o5G0M/CKca+aljR87Q6IogVHf9hqHhvLlBhVxT sqlQ== 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=WueH0k3mRIbWcDuFgllfEo0GumPWmtMmYDujODPRp5U=; b=AKBCZZbA0uRjkBxguxkPWsNCRGtkRE0t9j2j85XSsaLT8sokczJJj77lLf80r6R79Y w/1s/+NsKJ8HlVCmuYrVb76ZDNJ/iWGLTO6QLxA7cydMor9UX+9saC8BstSifC21r87e sfM9beaiIcBeR6s8XFwxPMLLlsZFPYwmP8oLVF7OYqzHk+wkJF9caE7hDIxn9ZJSG8z5 YW3v4MmLzMEJqeYcGLKR10le1w6rH1XOXV9BpdjQdU0ro46XwxC33AQdfgigDkDBg3bg CJ9otHtSsUzUTPHN+JUrIZy+CuJutvLFxQZwypv09rYqMa2uHo7W8YSLHODE3LR+BMx6 YgKw== X-Gm-Message-State: AKaTC02FB/QOwBtjtYVLsvbel379W4rsAxVDvRuIku0Q37FqCnLjWyfjiw+XnZPDZsDXFUoF967gG56uda/rES1z X-Received: by 10.157.53.50 with SMTP id o47mr24199904otc.19.1480717373706; Fri, 02 Dec 2016 14:22:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.73.195 with HTTP; Fri, 2 Dec 2016 14:22:23 -0800 (PST) In-Reply-To: <56F6A3AB-3A47-4178-BEFF-04E3DC23B039@gmail.com> References: <56F6A3AB-3A47-4178-BEFF-04E3DC23B039@gmail.com> From: Neal Cardwell Date: Fri, 2 Dec 2016 17:22:23 -0500 Message-ID: To: Jonathan Morton Cc: Aaron Wood , bloat , "aqm@ietf.org" Content-Type: multipart/alternative; boundary=001a113d7e1812cd0a0542b461c4 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 22:22:54 -0000 --001a113d7e1812cd0a0542b461c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 2, 2016 at 3:32 PM, Jonathan Morton wrote: > > > On 2 Dec, 2016, at 21:15, Aaron Wood wrote: > > > > So, how is this likely to be playing with our qos_scripts and with cake= ? > > Cake=E2=80=99s deficit-mode shaper behaves fairly closely like an ideal > constant-throughput link, which is what BBR is supposedly designed for. Great. Yes, that's right: BBR's favorite case is a constant-throughput link or shaper, since that's the easiest to model. > I haven=E2=80=99t read that far in the paper yet, but it shouldn=E2=80= =99t trigger any > =E2=80=9Cbucket detection=E2=80=9D algorithms, because it doesn=E2=80=99t= have a =E2=80=9Cbucket=E2=80=9D. It is > capable of bursting, but only to the minimum extent required to reconcile > required throughput with timer resolution and scheduling latency; I=E2=80= =99ve > tested it with millisecond timers. > That's also good to hear. If it doesn't have a "bucket" or allow unsustainable bursts, then it should work well with BBR, and shouldn't trigger the long-term/policer model. Of course, if we find important use cases that don't work with BBR, we will see what we can do to make BBR work well with them. cheers, neal --001a113d7e1812cd0a0542b461c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 2, 2016 at 3:32 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
> On 2 Dec, 2016, at 21:15, Aaron Wood <woody77@gmail.com> wrote:
>
> So, how is this likely to be playing with our qos_scripts and with cak= e?

Cake=E2=80=99s deficit-mode shaper behaves fairly closely like an id= eal constant-throughput link, which is what BBR is supposedly designed for.=

Great. Yes, that's right: BBR's fa= vorite case is a constant-throughput link or shaper, since that's the e= asiest to model.
=C2=A0
=C2= =A0 I haven=E2=80=99t read that far in the paper yet, but it shouldn=E2=80= =99t trigger any =E2=80=9Cbucket detection=E2=80=9D algorithms, because it = doesn=E2=80=99t have a =E2=80=9Cbucket=E2=80=9D.=C2=A0 It is capable of bur= sting, but only to the minimum extent required to reconcile required throug= hput with timer resolution and scheduling latency; I=E2=80=99ve tested it w= ith millisecond timers.

That's also= good to hear. If it doesn't have a "bucket" or allow unsusta= inable bursts, then it should work well with BBR, and shouldn't trigger= the long-term/policer model.

Of course, if we fin= d important use cases that don't work with BBR, we will see what we can= do to make BBR work well with them.

cheers,
=
neal

--001a113d7e1812cd0a0542b461c4--