Re: [tsvwg] The state of l4s, bbrv2, sce?

Dave Taht <> Fri, 26 July 2019 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14C39120019 for <>; Fri, 26 Jul 2019 08:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1WsdecTAHaQ9 for <>; Fri, 26 Jul 2019 08:45:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0D90120044 for <>; Fri, 26 Jul 2019 08:45:43 -0700 (PDT)
Received: by with SMTP id h6so19152291iom.7 for <>; Fri, 26 Jul 2019 08:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TNxGzdEQv+DFS+gztgDOowiIe7MJXwpAobWfMgAs/SY=; b=a2uHIHKue5959pSDcsNnNOTgB15dnOfjvaKJ/xHqC83ZueMXTIxxx8co/qxhjt9EAW ASQja4KXFW2H6llFxIIb0b1nfhNmjqWtnUzB3SFExPjQ9bwqPV0tE7Jl4VU6JOnpL2ml FNUrxOgcY6tfJeSZxqwiUXI5W9lxTrMJ4wugy6WMYIMYtnS3k2jTBtZLV/tJj9OXaDVl AlRUHXAV3WYj0i3IxsRN/ziQhrGdkTQw3TfxQE1le0n3I4vZTG71xJ12fuAiBaCqbx00 sIIqX8OBqc2JSem6O+KcBy/yuKLUSqhVu7g2lHfct8vEkNLJh1OdysDyJqYA50d4UjMs st+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TNxGzdEQv+DFS+gztgDOowiIe7MJXwpAobWfMgAs/SY=; b=DqWxjdeYxO9ZqATwWXK0kqYEPOYnDe58d72nlDAxk3RwPesC6cj2iSpZFEXyXgK+2G QZ+z8gPdobGpw5ZVflLbR7ANNPgG7MGao4T7w8uwhYZRVHC6PJtpmkejhdZnHcuQYPCl iJ5HELI7YcO3lLPHpgLA3MhfK0E099BFoJhzl9Gi0siP6yNuWcHyJCMeAJ1VtSFxMR+X 8sW+/WE/gGgjklklwX0FvWe4KntnuRdCqejWnnZTm1oDtMzqMTc180K1Tz80IgALlG/D vBcZLQcUJEdxCCRyhjF7wMSG/wlnwRqsLybs0KFB9xsFNZpL0du4pMgxAK6jpxUJXrXW DPnA==
X-Gm-Message-State: APjAAAUXT2BNdb8vfkySBRFCQLyd3ZeqlvrxoIdmkDMD4mEfRAkRpsb+ X+EH7fruGD6lgwhvPESvit6GFOfDWrYRd0lW7N0=
X-Google-Smtp-Source: APXvYqwfHG/+0W/JvBBSice6ethSviXRUVigKwNLRrJ2p0Tr9LDdEmBWifI2fw6emYw784SvL6zm+//G8VBMebG2AMA=
X-Received: by 2002:a6b:dd17:: with SMTP id f23mr74480413ioc.213.1564155943157; Fri, 26 Jul 2019 08:45:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Dave Taht <>
Date: Fri, 26 Jul 2019 08:45:30 -0700
Message-ID: <>
To: Neal Cardwell <>
Cc: Pete Heist <>, "De Schepper, Koen (Nokia - BE/Antwerp)" <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] The state of l4s, bbrv2, sce?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Jul 2019 15:45:46 -0000

On Fri, Jul 26, 2019 at 8:37 AM Neal Cardwell <> wrote:
> On Fri, Jul 26, 2019 at 11:05 AM Dave Taht <> wrote:
>> 1) BBRv2 is now available for public hacking. I had a good readthrough
>> last night.
>> The published tree applies cleanly (with a small patch) to net-next.
>> I've had a chance to read through the code (lots of good changes to
>> bbr!).
>> Although neal was careful to say in iccrg the optional ecn mode uses
>> "dctcp/l4s-style signalling", he did not identify how that was
>> actually applied
>> at the middleboxes, and the supplied test scripts
>> (gtests/net/tcp/bbr/nsperf) don't do that. All we know is that it's
>> set to kick in at 20 packets. Is it fq_codel's ce_threshold? red? pie?
>> dualpi? Does it revert to drop on overload?
> As mentioned in the ICCRG session, the TCP source tree includes the scripts used to run the tests and generate the graphs in the slide deck. Here is the commit I was mentioning:
> So you can look at exactly how each test was run, and re-run those tests yourself, with the v2alpha code or any experimental tweaks you might make beyond that.
> To answer your particular question, the ECN marks were from a bottleneck qdisc configured as:
>   codel ce_threshold 242us limit 1000 target 100ms

thx neal! I missed that!

> I'm not claiming that's necessarily the best mechanism or set of parameters to set ECN marks. The 20-packet number comes from the DCTCP SIGCOMM 2010 paper's recommendation for 1Gbps bottlenecks. I just picked this kind of approach because the bare metal router/switch hardware varies, so this is a simple and easy way for everyone to experiment with the exact same ECN settings.


>> Is it running on bare metal? 260us is at the bare bottom of what linux
>> can schedule reliably, vms are much worse.
> I have tried both VMs and bare metal with those scripts, and of course the VMs are quite noisy and the bare metal results much less noisy. So the graphs are from runs on bare metal x86 server-class machines.

Good to know. On the cloud I use (linode) 1ms was the best I could
hope for, and even then, dang jittery. (it was much worse 8 years
back when xen underneath could be in the 10-20ms range!).

There are major jitter issues on lower end hardware but I don't know
how bad they are post spectre fixes, been afraid to look.

containers are a huge improvement over vms but still break things like tsq.

> neal


Dave Täht
CTO, TekLibre, LLC
Tel: 1-831-205-9740