From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 1D4163B2A0 for ; Mon, 26 Sep 2016 15:03:01 -0400 (EDT) Received: by mail-oi0-x232.google.com with SMTP id w11so218569093oia.2 for ; Mon, 26 Sep 2016 12:03:01 -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; bh=6tvXE0Lz9ypr9RkeoTCqBHGBkzFP4Nd+A14m7JY6fkQ=; b=UTvE3GnRXo9IJkXArxWCLOaR5kkuclX7nNJ+YLiNL1fnwTwkOc/X+liDN1app5lI+e B6zoIc4XNWbswikKf6u9GeikBQMle0ctR7BADxW7Kz7OGaLaI2pN6ancMQAbzq0YheUj 4nnpC+1Mx5sT42dOKB2tueUMEWaFiHiYgpPB6zyjSjJdu/Ys3qby1hX9yyEfKn++MS08 PX4jvOVg6w/nUxtG8uL5enBrCaBmCatdMgKDDwDJnun4R2JWapK8tIOpGHkSqLKoBK4z t2WQOn9whujq8v1Kojig80mOtb8JT3M8WFLUbu5wMxfeObchiMIKnusgPhpkIa+oHvNr af1Q== 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=6tvXE0Lz9ypr9RkeoTCqBHGBkzFP4Nd+A14m7JY6fkQ=; b=Cao16QOEeBmiKFBOv79BVO9rn66vCHx7wLxRWg4t1YddhV1b+231QmvQjPdomPbuYk L9lB2YBB3CxSdnHRAE+egnwemp5WYOFY5pUx290gu5CqlyvseepsAQGn+qgMq3qONaJn F8chaMaaAwEj5X4XlNf0t1xruhdu/gNeUDKmMqbFPW0KHbnc64QWAKEemk+JZuEH5Prw 5GyKHLyMouvc3zkJLX1ZcG/OhhG/wI+eG1iF2pA0aPuB0Twkh9orrGqOhhEktA/QWCg6 2j8uLtIU2ImWyS4ExADNxRqirdMklmuuwLqLLRA/JrB+zpZArb0lWhEaaBM/8GGIxLow QSFg== X-Gm-Message-State: AE9vXwPXW9R31+trGzluCUQ+j2ZLgxBKC1paspxMye/IGSiC8B0eCTa9pB7BQQ0KlO5TfQ60UTWCuiu/7EIwN7NW X-Received: by 10.202.56.136 with SMTP id f130mr26775703oia.33.1474916580400; Mon, 26 Sep 2016 12:03:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.182.65 with HTTP; Mon, 26 Sep 2016 12:02:30 -0700 (PDT) In-Reply-To: References: From: Neal Cardwell Message-ID: To: Alan Jenkins Cc: BBR Development , Mikael Abrahamsson , bloat , cerowrt-devel@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 20 Oct 2016 12:34:06 -0400 Subject: Re: [Bloat] [bbr-dev] Re: taking apart BBR's behaviors in flent 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: , Date: Mon, 26 Sep 2016 19:03:01 -0000 X-Original-Date: Mon, 26 Sep 2016 15:02:30 -0400 X-List-Received-Date: Mon, 26 Sep 2016 19:03:01 -0000 On Thu, Sep 22, 2016 at 8:09 AM, Alan Jenkins wrote: > On Wednesday, 21 September 2016 20:25:32 UTC+1, Dave Taht wrote: >> >> > Looking at cake_flowblind_noecn, BBR1 and BBR4 just kills both CUBIC >> > flows. >> > Same with PIE. >> >> Yep. The single queue AQMs expect their induced drops to matter to all >> flows. BBR disregards them as noise. I think there's hope though, if >> BBR can treat ECN CE as a clear indication of of congestion and not >> filter it as it does drops. > > > Extra credit assignment: get the next version of DOCSIS PIE to turn on ECN? > > https://tools.ietf.org/html/draft-ietf-aqm-docsis-pie-02#section-4.7 > >> >> But cake/fq_codel is just fine with different cc's in the mix, and I'm >> dying to look at the captures for what happens there. > > > Very glad to see that, I can keep using fq_codel :). > >> > So it seems my intuition was wrong, at least for these scenarios. It >> > wasn't >> > CUBIC that would kill BBR, it's the other way around. > > > So (from the other thread) BBR is designed to use the traditional > recommendation of 1 BDP's worth of buffer. In the absence of other CC's, it > would limit itself to that. Understandable for bottlenecks in end-site > modems or wifi. I mentioned this in another thread this afternoon, but will mention it here as well, since it's an important point: Yes, the current behavior where of creating a ~1*BDP queue when bulk BBR flows share a bottleneck is something we are actively working on improving. The current behavior is not the end goal, but rather the place where the current code arrives due to some subtle trade-offs. We want the number of packets in flight to be allowed to potentially be ~1*BDP beyond the pipe BDP, in order to handle delays that are due to link-layer or receiver effects that cause delayed, stretched, or aggregated ACKs (these are very common for wifi, cellular, and cable systems). But ideally we don't want more packets in flight if the delays are simply due to competing flows, since that can lead to the ~1*BDP of queue you can see in these tests. So we are working on improving the behavior (reducing the queue) in the case with competing BBR flows. neal