From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 17F033B29D for ; Mon, 8 Mar 2021 20:18:24 -0500 (EST) Received: by mail-il1-x135.google.com with SMTP id g9so10687946ilc.3 for ; Mon, 08 Mar 2021 17:18:24 -0800 (PST) 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 :cc:content-transfer-encoding; bh=J/mbG2Tsd9g82wP0DnDRuJrlPk9MRtTgSvAONAxm65Q=; b=NvU920F/15CRKRxGQGy+FRUTvcRpMKjzbhrqUr19qoipi6lEQMTsn9UQGseSHns2u4 Cl2OkXaDJDlBQpd/yErYr0rpdhEIZMvHHjAZA0iF1TPGeSs+jIXcJzJClHDDMmXXFrmx 9ddphPp12lZkdSRCft4ZG8pC0UUG9XNiexk59K0hKLaYkq6Pdd0eV34jpIStzu7yqy4N QCL3EDWWO2yN17J6SXvSNckSJsdJH3GleF4Z2HuXlMbqUGsgQrSzZzVtO8C1R+GasU5H HLT4GjJTaUSkmBT24TTI7REfn59TZVMGFEPgbbecEqKGxrr1SXO7KHPlMjhXIf7PmNu4 aN/A== 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:content-transfer-encoding; bh=J/mbG2Tsd9g82wP0DnDRuJrlPk9MRtTgSvAONAxm65Q=; b=qaTc7eVVNDaPFbTR+325FtqjcPJfXf/zVqh22J/9P3q+uMicVcVXt29515vqtrbZjq XCRhM828I7DzRF7tI29f6Dc9XjjFQWfIAUp5uo+of2//8SbTMBtYWW1sJ7JcmQClSN9U n4njf8MqSKHjDH2FhC36P89vWmIJ1+DV4enbdcAIvr3Mqn/qdlB90mNgho293q/X4aUQ qSg+ch0Cb0Lg0ubm9SOAq4Js6B1PaEGy8wcJOgWBDCR1U5SWaen3viuwkgwlPt+4f1j7 JqouBueEjN2RF3DnM8QzZAiU+iCVP3pp1QuiHF5ser8pw8IQ6vYoQERsuh6W/M+36oaz XLUA== X-Gm-Message-State: AOAM5339H7mlqmxOsoLV2j3nK0eG/eSkXW/3Y4cSFYl2AewcJv2YZuCV PlOsEbjLMvRHB4EQruHx+KHW1pjOxXApcfj9HeQ= X-Google-Smtp-Source: ABdhPJyopblg+hxvo8RhhqH/3M8SiI5P0lnEVQOc3CfXhZCqUhMPZHdFKEVSNXMHWUD2PYQqrXMwplhOLm/qxFuOjhY= X-Received: by 2002:a05:6e02:f06:: with SMTP id x6mr20744426ilj.287.1615252703361; Mon, 08 Mar 2021 17:18:23 -0800 (PST) MIME-Version: 1.0 References: <9d65a6d19123a881dc14436f6e4d0bd30434b062.camel@heistp.net> In-Reply-To: <9d65a6d19123a881dc14436f6e4d0bd30434b062.camel@heistp.net> From: Dave Taht Date: Mon, 8 Mar 2021 17:18:11 -0800 Message-ID: To: Pete Heist Cc: ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecn-sane] ect(1) queue selector question 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, 09 Mar 2021 01:18:24 -0000 I am of course much happier interacting here than over on tsvwg. I would like very much A large scale bit twiddling test from the larger providers of fq_codel and cake based hw and middleboxes. extensive testing on lte and wifi transports. even emulated. the sce patches polished up and submitted for review to netdev as what we call there, an RFC the ability to test both SCE and L4S on openwrt (backport thereof) I know there's been a lot of work on other qdiscs than cake, but haven't paid much attention. netdev review would be nice. A simple internet-wide test of say bittorrent, or using an adserver method like what apnic uses. Most of all I'd really like someone to take a stab at RFC3168 support for BBR. And by that, I don't mean a reduction by half, but to institute an RTT probe phase. A fixed rate reduction per RTT is simply not going to work IMHO, period, on lte and wifi. I'm sure dave miller would accept such a patch, and this would also lead towards better ecn support across the internet in general... at least from the perspective of the one provider I have an in with, dropbox. SCE support for BBRv2 would be nice also. And I know, a pony, all sparkly and stuff. I find it very difficult to summon the cojones to do a drop of work in this area, and I keep cheering you on - especially on the bug fixing and wonderful scripts and data you've provided so far, and I do wish I could find some way to help that didn't cause so much ptsd in me. I wish I merely knew more about how dctp was configured in the data center. So far as *I* know its on dedicated switches mostly. I would vastly prefer a dscp codepoint for this, also. On Mon, Mar 8, 2021 at 4:36 PM Pete Heist wrote: > > Sorry for reviving an old thread as I haven't been on this list in a > while: > > > > SCE proposes to use ect(1) as an indicator of some congestion and > does > > > not explictly > > > require a dscp codepoint in a FQ'd implementation. > > Pretty much. I do think that a demonstration using an > > additional DSCP to create a similar HOV lane for SCE would have gone > > miles in convincing people in the WG that L4S might really not be as > > swell as its proponents argue, IMHO it won the day more with its > > attractive promise of low latency for all instead of what it > delivers. > > On that, I don't think any of us knows how things will end up or how > long it will take to get there... > > I do agree that the interim meeting leading up to the codepoint > decision could have gone better. Everything went great until it came to > how to deploy SCE in a small number of queues. We had dismissed the > idea of using DSCP, because we thought it would be panned for its poor > traversal over the Internet. That may still have been the case, but it > also may have worked if sold right. We thought that AF alone might be > enough to get past that part, but it wasn't. > > We already implemented a two-queue design that uses DSCP, but either > there wasn't much interest, or we didn't sell it enough. Plus, for > those who demand a two queue solution that requires no flow awareness > at all, DSCP alone may not get you there, because you still need some > reasonably fair way to schedule the two queues. So that might have been > the next line of criticism. Scheduling in proportion to the number of > flows each queue contains is one effective way to do that, but that > requires at least some concept of a flow. Perhaps there's another way > that doesn't introduce too much RTT unfairness, but I'm not sure. > > In our defense, there was already a lot of support built up for L4S, > and stepping in front of that was like stepping in front of a freight > train no matter what we did. I think we've made a decent argument in > the most recent version of the SCE draft that ECN is a "network > feature" which carries higher risks than drop-based signaling, and > warrants the requirement for unresponsive flow mitigation, for > starters. That of course requires some level of flow awareness, which > then makes various queueing designs possible. And, there may still be > deployment possibilities with DSCP, as Rodney mentioned. > > Anyway, there's progress being made on SCE, with some new ideas and > improvements to testing tools coming along. > > Pete > > > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane --=20 "For a successful technology, reality must take precedence over public relations, for Mother Nature cannot be fooled" - Richard Feynman dave@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729