From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 9C64A3CB37 for ; Fri, 26 Jul 2019 11:37:31 -0400 (EDT) Received: by mail-ot1-x332.google.com with SMTP id s20so55737725otp.4 for ; Fri, 26 Jul 2019 08:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p2wHehMJrtRgYJYaa4/6XEq6BErL4+Kf/TDNsMxM+eA=; b=Z2TFOv66hZb6RyI2AmZH5EZwsW9IjfQra8VVyC97vMAsQgKH8qJ3ZXXxlYxfkjbjCm UaMxhu9msyoNDScGBrOo/ARX8vktGsJ4o3ANXd+Zl+wxCx/qBr3kpYslBh9/aZidjQDN bxnXpqcLdEbHAUfOHN38/TnM2gvbcFZ4xZ7tSijM5SbYLp9cPBB9wDQdzP4MTIItDAsg z5lm3zcRYjID4FVWHjfPsB9cWnaav4YuFzGpg10NCeIeNvmoRmobEb26dg0d5QYyeQ9i rWlydPn+XhHvr1aC5Te/XAQ+afc7HTNB0wReEuXzIGsdGq4rwfTr4RQDKCxQ5zYlTGMA ta1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p2wHehMJrtRgYJYaa4/6XEq6BErL4+Kf/TDNsMxM+eA=; b=fIxIvthUIyTzU4Y1DVNGsbc+Js3Dex+jnbBWjHO7GVt9AHf+4eDFD49YbTO5WukvZd Ux4HnMKjIFhRCwweHcT2Plfs6fpzxSR7FxPbdmDjrt4qVWmuI9GAdisXnUDkS2uQXSRs vBlFVYAzhryBGqgsfuzsTjS1FlmXv5c81Y88hEqMNy303zXdC7y4P3JSFqfC6nUDDsZ4 Vg4mfBQD4Apre6IXdFUVS4a1SubuCxEsNxgef98rfukyW0EBawRXWbfUs2HxYekVS8JW mprZbef9hwMQgSzXXfAMBoeEBX0q6RLf5IL9K3AqjTu5OM7mq7ubFQ0Q0k+zAoInW7/v 8LBQ== X-Gm-Message-State: APjAAAVzKwllKkb//37O5kQg233fuxdV+4xq52KPuW9FaWJGUmeLZfPk fwhZ4IsTe3nAu83qjHcPE7tmWkA3vg36a6CmSKBlzg== X-Google-Smtp-Source: APXvYqyqtEcqmnZwH4E446zsyyPTr8Yx+2Qy0VY/CyzT6jvxeBelbwl+1XAnTdSSHh5qBWtYlEJ7Bl6uiV6BJIoyWsg= X-Received: by 2002:a9d:5cc1:: with SMTP id r1mr64811747oti.341.1564155450666; Fri, 26 Jul 2019 08:37:30 -0700 (PDT) MIME-Version: 1.0 References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> <0079BC6B-4792-48ED-90D3-D9A69407F316@gmx.de> <22af0671-fdd0-0953-fc96-55b34beb0be9@bobbriscoe.net> <3EB0D59D-69A7-4730-BCDF-10E5C61EF987@heistp.net> In-Reply-To: From: Neal Cardwell Date: Fri, 26 Jul 2019 11:37:13 -0400 Message-ID: To: Dave Taht Cc: Pete Heist , "De Schepper, Koen (Nokia - BE/Antwerp)" , "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="000000000000033b37058e975229" Subject: Re: [Ecn-sane] The state of l4s, bbrv2, sce? X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 15:37:31 -0000 --000000000000033b37058e975229 Content-Type: text/plain; charset="UTF-8" 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: https://github.com/google/bbr/commit/e76d4f89b0c42d5409d34c48ee6f8d32407d4b8d 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 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. neal --000000000000033b37058e975229 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 26, 2019 at 11:05 AM Dave Tah= t <dave.taht@gmail.com> wr= ote:
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?<= br> dualpi? Does it revert to drop on overload?

=
As mentioned in the ICCRG session, the TCP source tree includes the sc= ripts 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 h= ow each test was run, and re-run those tests yourself, with the v2alpha cod= e or any experimental tweaks you might make beyond that.

To answer your particular question, the ECN marks were from a bottle= neck qdisc configured as:

=C2=A0 codel ce_threshold 242us limit 1000 target 100ms=

I'm not claiming that's necessarily t= he best mechanism or set of parameters to set ECN marks. The 20-packet numb= er comes from the DCTCP SIGCOMM 2010 paper's recommendation for 1Gbps b= ottlenecks. I just picked this kind of approach because the bare metal rout= er/switch hardware varies, so this is=C2=A0a simple and easy way for everyo= ne to experiment with the=C2=A0exact 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 grap= hs are from runs on bare metal x86 server-class machines.

neal

--000000000000033b37058e975229--