From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 E48C03B2A4 for ; Tue, 6 Aug 2019 12:01:32 -0400 (EDT) Received: by mail-ot1-x32c.google.com with SMTP id n5so93821002otk.1 for ; Tue, 06 Aug 2019 09:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=//5aEshXCnXTwXdU8U0lU3UlCBGVNnRyocbpGSySLig=; b=iwttHW4NfNjYMq6Y4DwsA2IW/9c3HwhGlrtWj9NwMqBNDwB9mq8Aqrtqozuezrcqwv HIOzSgkInlBwtsp7Zjfr4nJbkPvFcWPca2XIXiwYKERGIQeZiglUr9KKES4F7H7lo6Hh J1qK//8jCnPxnviEE3XpqXeNGdfbset6xHRp8ow0lKXoXj31pDf2pvERphFeNKqSyJBw EySLQFxVZS6vxodW01CmBTI3104LLynDztN6ntKSpwqxnSgI+WP9nIMnlVYmheikUZRk uftDoGbIxKY3JA9bkV++QVIxgH9POFGatqUD2WuyDAleVroSo7coCjS+wSgbx2FsGlXo tiyw== 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:content-transfer-encoding; bh=//5aEshXCnXTwXdU8U0lU3UlCBGVNnRyocbpGSySLig=; b=bSre2JCZYOWIdScMd1+z71UwW/btr1wXu2iOxfpmpPYgsDS3xmWdrMo2Uz6E27srYW vWBbtJybTi0wleBcWk7djMICt30kXv0HgoZAAEliiHO/ExWRiL6uD0qgnmXatXeYCqOM Ebsp7WZSFLb6KqlE5/hFEAZyf4NwB1BHC4FWlWg/Tc5tTNEErMHF75XrfO0j4MdUSpGU Id4NAFMaRs0Aqs2O5y2DIW9ZyNq5o3hrZi8W+pLAc5oippjsT7YWttqLrRf+OWOq2ia2 9nuspbNKUEcnBjw1lk00RcwQ+tDhK5FZrYzfQu26AKTimciRPQtSh/eR6uqRp87z9REL SAxA== X-Gm-Message-State: APjAAAUTc/47YrH3rTsfQiSY6PXNc6+OVQrQUs8D7Tn49Wg3RNsUmYW8 kZfCIifOrwodWK0Xgy0wsV6vFjVIE98iUKCwhk4C1Q== X-Google-Smtp-Source: APXvYqySzimRC9pyKRULSCUE7A4rERG/+EavYB69tHhLp+trw1INeblejqnE0n/eJ3tGOigJmNAnduaKK+OfHg6OIps= X-Received: by 2002:a5d:9d42:: with SMTP id k2mr4491253iok.45.1565107291970; Tue, 06 Aug 2019 09:01:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Tue, 6 Aug 2019 09:01:20 -0700 Message-ID: To: ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecn-sane] Exploring L4S and SCE possible pathologies with ubuntu .debs 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: Tue, 06 Aug 2019 16:01:33 -0000 and... don't even try this build. On Mon, Aug 5, 2019 at 9:05 PM Dave Taht wrote: > > This build is a collection of possible pathological interactions > between the L4S and SCE concepts - as well as being primarily a means > fo me to catch up on the state of the code.... I wouldn't run it on > the internet, nor do I plan to run it much longer than to get a few > tests done and a few packet captures to look at. > > http://www.taht.net/~d/l4svsSCE/ > > It is based on net-next of commit: 9e8fb25254f76cb483303d8e9a97ed80a65418= fe > > In terms of *others* thinking up a repeatable test matrix and tools > for automating one, maybe this will "help". > > A ton of this code is totally untested by me, may have other bugs, > besides the logical ones, and if it breaks, you get to keep both > pieces. > Might not even boot! > > * sch_fq has been modified to turn ce_marks into sce_marks via ce_thresho= ld > * sch_fq_codel has both regular ecn and ce_threshold as ce_threshold > * sch_cake is sce with ramp and regular ecn > * sch_fq_codel_fast has sce threshold and also splits GSO/GRO packets > * dualpi is dualpi from the L4Sforupstream repo > > dctcp is *stock* which I hope now responds to loss properly > dctcp-sce is Jon's rewrite - but do we need a BSD client? > cubic is still stock cubic with RFC3168 CE > cubic-sce is Jon's SCE mods with RFC3168 still alpha testing > reno-sce is reno with SCE and RFC3168 responses enabled. > bbr is bbrv1 - no ecn support is in that at all - however if you > negotiate ecn, interesting things might happen > bbrv2 is bbrv2. dctcp-style ECN CE is available via a module parameter. > > As per the IETF conference, IW10 is paced, not burst. I thought about > making it IW4 as a burst. Certainly we see lots of IW10 or worse bursts. > > But wait! There's more! The mac80211 wifi drivers actually dynamically ch= ose > whether codel ecn on or off was a function of the rate, which is, well, d= ynamic, > and used really outrageous targets in the case of really low rates or > lots of stations. > > I made 'em be ecn always and reduced the target back to 6ms from 20ms, > and enabled sce_threshold. > > Wheeee! > > I was going to layer in fq_pie here also just for fun. Might do that if I= feel > an urge to build another release. > > This combination of conflicting options can be combined a whole ton of > bad ways and a few good ones, tied together with network namespaces, > run over your net, on your laptop, over your wifi, in a vm or three, > whatever. > > Also cpu impact should be measurable - in my case, prior to all this > starting, I'd been working on a faster version of fq_codel that was > more O(1), and wanted to measure it. Might as well measure dualpi & > cake too. > > I wouldn't draw any conclusions about bandwidth or latency from this > code without being very, very careful. I fact, if I were > you I'd not download, install it, and play with any of these options > at all. But I'm not you! Have at it. > > In wading through all this code I did make two conclusions. > > 1) If ce_threshold is being used in the field as a way of moderating > self congestion it's interesting. No matter which response to > self-congestion it does lower the load. I really wish we knew how many > used this today. > > As much as I wanted to retire ce_threshold I now feel we need a > separate API for sce. Which is OK, assuming the ramp thing is a thing. > It is just massively cleaner codewise to make sce an explicit thing. > > 2) I think the interaction between GSO'd behavior and non-GSO'd > behavior is going to be interesting. sch_fq releases 2 packets at a > time, the fq_codel deployment is often quantum 300. cake dynamically > sets the quantum. and then there's ack-filtering and wifi! > > Anyway: > > https://github.com/dtaht/tc-adv has the sch_cake and fq_codel_fast > support, the dualpi repo has the relevant tc support > > > -- > > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740