From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 16DE23B25E for ; Mon, 26 Sep 2016 15:03:01 -0400 (EDT) Received: by mail-oi0-x22e.google.com with SMTP id t83so218693461oie.3 for ; Mon, 26 Sep 2016 12:03:00 -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=loNn48yAYBtZkGbRZ70uqk+NcJxw95OjMcA4eVY2/sGhxo4NPWQsbroX6/WhKjuVpi 5cleXy76qr1GxxYg9/OtKFjhhrMEnITJnmra3dURs5aeKJDNdMVmkflr+c/Lxv+zaxLm Gbx57npqtj2sxmrmg6rU41mQjRpcoMF2II08a4af/oWgqs77+5tU4QJjB2UKZnI3Mwgh hiRrpxROhb0pHPzVAK19xpUll4Etc7wLj49+kYTwXBtKXV5E2AjJV5CukqqnivX3QLhk qy6WfnQdy7foN89bmqu+YOiDp6qk0yGmrZC/ugw6PxqBA/H28rUXwDQb3vzlVUVskb5Z 8iDA== X-Gm-Message-State: AE9vXwM5GI/qJaWkM5sSkQYj/YuAXGNYMRQeAWZnggJIOgQWHiC2eSnIJjWgNNzyqmHM57jS3egBOZX8k8HyXm0P 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 Date: Mon, 26 Sep 2016 15:02:30 -0400 Message-ID: To: Alan Jenkins Cc: BBR Development , Mikael Abrahamsson , bloat , cerowrt-devel@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Subject: Re: [Cerowrt-devel] [bbr-dev] Re: taking apart BBR's behaviors in flent X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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