From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hedgehog.birch.relay.mailchannels.net (hedgehog.birch.relay.mailchannels.net [23.83.209.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C13683B29D for ; Mon, 8 Mar 2021 23:06:20 -0500 (EST) X-Sender-Id: totalchoicehosting|x-authuser|slblake+petri-meat.com@pawpaw.tchmachines.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 47D79921A23; Tue, 9 Mar 2021 04:06:19 +0000 (UTC) Received: from pawpaw.tchmachines.com (100-96-17-38.trex.outbound.svc.cluster.local [100.96.17.38]) (Authenticated sender: totalchoicehosting) by relay.mailchannels.net (Postfix) with ESMTPA id 14374921A00; Tue, 9 Mar 2021 04:06:17 +0000 (UTC) X-Sender-Id: totalchoicehosting|x-authuser|slblake+petri-meat.com@pawpaw.tchmachines.com Received: from pawpaw.tchmachines.com (pawpaw.tchmachines.com [208.76.80.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.17.38 (trex/6.0.2); Tue, 09 Mar 2021 04:06:19 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: totalchoicehosting|x-authuser|slblake+petri-meat.com@pawpaw.tchmachines.com X-MailChannels-Auth-Id: totalchoicehosting X-Shelf-Blushing: 780028a2708410bd_1615262778710_1556361237 X-MC-Loop-Signature: 1615262778710:4003615540 X-MC-Ingress-Time: 1615262778709 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=petri-meat.com; s=default; h=Content-Transfer-Encoding:MIME-Version: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XIqy7ENDySbxQmZPQigyfuDfd9TKK9A0HdnbuUEzdc4=; b=2gEDObKWdlh4nVtqVFdQFR3OmZ eZs7PvaQZOZBJDG0raKe4eJGFO6TKDQ2IrzrlpuLh8r0yGlvtFprAG/erlUtA1yytv/le+PfWpqEQ iSFW9U7XpQEqXFDPH7YT7sfZa; Received: from [136.56.88.61] (port=57790 helo=axion.home.arpa) by pawpaw.tchmachines.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lJTdQ-0001Qg-Cm; Mon, 08 Mar 2021 23:06:16 -0500 Message-ID: <7ff9063df5c5e05420ef47245becb77a2de80f2f.camel@petri-meat.com> From: Steven Blake To: "Holland, Jake" Cc: ECN-Sane Date: Mon, 08 Mar 2021 23:06:15 -0500 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-AuthUser: slblake+petri-meat.com@pawpaw.tchmachines.com Subject: Re: [Ecn-sane] IETF 110 quick summary 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 04:06:21 -0000 If I'm a random network operator, not participating in any L4S experiments, and L4S traffic traversing my network hits a bottleneck, what happens? Consider all of the cases (no AQM tail-drop, AQM-drop, AQM-classic ECN). My understanding was that TCP-Prague's classic bottleneck detection code wasn't fully baked. On Tue, 2021-03-09 at 02:13 +0000, Holland, Jake wrote: > The presentations were pretty great, but they were really short > on time. In the chat a person or 2 was surprised about the way > L4S will impact NECT competing traffic when competing in a queue. > I agree some of the people who have tuned out the discussion are > learning things from these presentations, and I thought Jonathan's > slot was a good framing of the real question, and Pete's study was > also very helpful. > > I seem to recall a thread in the wake of Apple's ECN enabling about > one of the Linux distros considering turning ECN on by default for > outbound connections, in which one of them found that it completely > wrecked his throughput, and so it got tabled with unfortunately > no pcap posted. > > Any recollection of where that was? I was guessing it might be > one of the misbehaviors from the network that Apple encountered. > > I also thought Apple had a sysctl to disable the hold-downs and > always use ECN in spite of the heuristics, did that not work? > > -Jake > > On 3/8/21, 3:57 PM, "Dave Taht" wrote: > > Thx very much for the update. I wanted to note that > preseem does a lot of work with wisps and I wish they'd share more > data on it, as well as our ever present mention of free.fr. > > Another data point is that apple's early rollout of ecn was kind of > a failure, and there are now so many workarounds in the os for it as > to make coherent testing impossible. > > I do wish there was more work on ecn enabling bbr, as presently > it does negotiate ecn often and then completely ignores it. You can > see this in traces from dropbox in particular. > > > > On Mon, Mar 8, 2021 at 3:47 PM Pete Heist wrote: > > Just responding to Dave's ask for a quick IETF 110 summary on ecn- > > sane, > > after one day. We presented the data on ECN at MAPRG > > ( > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-heist-tsvwg-ecn-deployment-observations/__;!!GjvTz_vk!AsneqOLeLWeNxzyWItOxlVbVQYefAMLslNpK4U9NEHw0dfUI0vDG7O07G3f1kzw$ > > > > ). It basically just showed that ECN is in use by endpoints (more > > as a > > proportion across paths than a proportion of flows), that RFC3168 > > AQMs > > do exist out there and are signaling, and that the ECN field can be > > misused. There weren't any questions, maybe because we were the > > last to > > present and were already short on time. > > > > We also applied that to L4S by first explaining that risk is the > > product of severity and prevalence, and tried to increase the > > awareness > > about the flow domination problem when L4S flows meet non-L4S flows > > (ECN or not) in a 3168 queue. Spreading this information seems to > > go > > slowly, as we're still hearing "oh really?", which leads me to > > believe > > 1) that people are tuning this debate out, and 2) it just takes a > > long > > time to comprehend, and to believe. It's still our stance that L4S > > can't be deployed due to its signalling design, or if it is, the > > end > > result is likely to be more bleaching and confusion with the DS > > field. > > > > There was a question I'd already heard before about why fq_codel is > > being deployed at an ISP, so I tried to cover that over in tsvwg. > > Basically, fq_codel is not ideal for this purpose, lacking host and > > subscriber fairness, but it's available and effective, so it's a > > good > > start. > > > > Wednesday's TSVWG session will be entirely devoted to L4S drafts. Regards, // Steve