From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 E62E53B25E for ; Thu, 27 Oct 2016 14:14:41 -0400 (EDT) Received: by mail-qt0-x22f.google.com with SMTP id q7so29519684qtq.1 for ; Thu, 27 Oct 2016 11:14:41 -0700 (PDT) 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:content-transfer-encoding; bh=Y9Q4eaYslxwZhQJMlwvvmBF/yOh8lGo6drRoaeXcqg8=; b=W2BcfCrMgJV7E1l9hHzZhBh94a403e4EiKVtTcm0WaSbQJqHziLN7n6811QwZpqhYY X1tQ2H+6zvez3W1UYYt8uD6B4909HQw+vWmFC8kvYGXC5I8QpkgcHqB0vWfAcj3mb7sB aKlFLWEoim51y2mmfwx6Npl5/67jnCE34xLSC3xKgUNiVU9/RsOhLrqw8lyC1c1al5Oo KTvkWSGGuYgwQdEiJPw018zKvqPUSdrItmxZFA+hZCC4rj9xmPt3COAC66iJAmjbp9bi qFch/CfIxyf9ydQ0Ze1MGtNBX5P4TIYrrWrNm4zZ8r1vBj1zL6PdflAmGfvh9NJgPAXf wEuA== 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=Y9Q4eaYslxwZhQJMlwvvmBF/yOh8lGo6drRoaeXcqg8=; b=HGrPc2QmUxFp5RCl3UjjhH5dilQBv8CQpYokys7FRsjCOsviJSSo0n7mcYE4XEPo83 5M5Hlnh0cXlmAUbhtbUWWiU1zW7zpmg+6+XwkXwIMwznoj5HiA5hgWIk9mFHiiV5Jf4K xz+jUq09abGcIkMPiAQ3Y9K7AZLetTk8h8fzUQKwwKEEav8VbeA+lHigv7wClrFWdyhj q5kaZbIyRtwArsng9IGnRbow3zEKWRE3Qgu9Uoz0dROrYueg+z//Gd6qieJxrw6j5mHs zVGqpB+zZ0dzvpa8R8ubQ44d0IvJ3JZD/M4t8dD8VlFCuVudyx2oOfPK4UstsF4a1fN4 x63g== X-Gm-Message-State: ABUngveBd3dTtbZ1tqCt52D8z6lbpgYrezRYGPPAjxowR9LCDp7Fb78Q9SOZCHMqvRYJjMjVmsiG0cPBqUdHYA== X-Received: by 10.237.61.210 with SMTP id j18mr4256390qtf.137.1477592081423; Thu, 27 Oct 2016 11:14:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.146.164 with HTTP; Thu, 27 Oct 2016 11:14:40 -0700 (PDT) In-Reply-To: References: <20161021084726.GA1913@sesse.net> <20161027170447.GA28383@sesse.net> From: Dave Taht Date: Thu, 27 Oct 2016 11:14:40 -0700 Message-ID: To: Yuchung Cheng Cc: "Steinar H. Gunderson" , bloat , BBR Development Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] "BBR" TCP patches submitted to linux kernel 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, 27 Oct 2016 18:14:42 -0000 On Thu, Oct 27, 2016 at 10:57 AM, Yuchung Cheng wrote: > On Thu, Oct 27, 2016 at 10:33 AM, Dave Taht wrote: >> On Thu, Oct 27, 2016 at 10:04 AM, Steinar H. Gunderson >> wrote: >>> On Fri, Oct 21, 2016 at 10:47:26AM +0200, Steinar H. Gunderson wrote: >>>> As a random data point, I tried a single flow from my main server in .= no >>>> to my backup server in .nl and compared CUBIC (with sch_fq) to BBR (na= turally >>>> also in sch_fq) on the sender side. The results were quite consistent = across >>>> runs: >>> >>> Another datapoint: A friend of mine had a different, worse path (of abo= ut 40 ms) >>> and tested with iperf. >>> >>> CUBIC delivered 20.1 Mbit/sec (highly varying). BBR delivered 485 Mbit/= sec. >> >> I mostly live in a world (wifi) where loss is uncommon, unless forced >> on it with a AQM. >> >> At the moment my biggest beef with BBR is that it ignores ECN entirely >> (and yet negotiates it). BBR is then so efficient at using up all the >> pipe that a single queued aqm "marks madly" and everything else >> eventually starves. Watch "ping" fade out here... >> >> http://blog.cerowrt.org/flent/bbr-comprehensive/bbr_ecn_eventually_starv= ing_ping.png > > Thanks Dave for this issue. We design BBR with CoDel in mind b/c Van > co-designs both :) It works pretty darn good with codel without ecn. I'm pretty darn happy wit= h it. fq_codel is even more lovely, especially when competing with cubic. There are issues with single queued aqms with BBR vs cubic http://blog.cerowrt.org/flent/bbr-ecncaps/bandwidth-share-creaming-cubic-fl= owblind-aqm.svg > We have tested BBR with CoDel before and it works. Well, against cubic on the same link in single queue mode, even without ecn, life looks like this: http://blog.cerowrt.org/flent/bbr-ecncaps/bandwidth-share-creaming-cubic-fl= owblind-aqm.svg but fq_codel is fine, so long as there is no ecn vs nonecn collission http://blog.cerowrt.org/flent/bbr-ecncaps/bandwidth-share-ecn-fq.png > Could you share your tcpdump traces with us (maybe > you already did but no sure) or suggest how to reproduce this. > > This is 2 bbr flow or bbr + ecn-cubic? (I am guessing based on caption > in your graph) That's two BBRs with ecn enabled, going through cake in the single queue aqm mode "flowblind". I have similar plots with pie and codel with ecn enabled somewhere. The emulation is 48ms RTT, 20Mbit down, 5Mbit up. Regrettably I'm on a couple deadlines (a talk tomorrow, and next thursday), and can't look harder, I do have caps comparing ecn vs noecn here http://blog.cerowrt.org/flent/bbr-ecncaps/ > >> >> somewhat conversely in fq_codel, this means that it ignores codel's >> marking attempts entirely and BBR retains it's own dynamics, (while >> the non-BBR flows are fine) which is kind of neat to watch. >> >>> /* Steinar */ >>> -- >>> Homepage: https://www.sesse.net/ >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >> >> >> >> -- >> 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 --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org