From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 3B7203B2A4 for ; Tue, 9 Mar 2021 15:53:56 -0500 (EST) Received: by mail-wr1-x42f.google.com with SMTP id j2so18463002wrx.9 for ; Tue, 09 Mar 2021 12:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=GfWsG3+GUwUcht09M7uO2iPfgykOMyfkCI9qOv9YtgI=; b=P7x7f3D9uTHJSZuYlenuWJT0GsBE02tNU4dKtwKestsByDI74NN7CCSZeR8wA7y1jo NnKt34u7d0PvQjKSAzcGzT+fYnV1vduBq8unIMe0woVa+9mVBFlz8exowplK7h4h0IbM IjOjLqhmbwv40BGY7VXIEJXtR+H+PZD6BA/QJ1AZzVuBfBlns5VyWYKyF0MtZJXv0gBo qBbxIvuz4fIN28bz6SHZHnioq93oHegVBwtIEGryExTNvL63pYCV3l8zKLCOyJdYozYs MRr373DIgridshjD8DjjDHg4IjyBMx17Q4gNiVLsa9xigEuoSgFT4eztqpbiwdXnknpD NPCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=GfWsG3+GUwUcht09M7uO2iPfgykOMyfkCI9qOv9YtgI=; b=KuZnWw7as7moEMPrZlqZlElFC189/CMFwEAEl/6VMNyB9lfXe1Dv9IiNL2UTYsBPaM WB1F0RzgELRXjEdUsfpkcr5BJxx6TkWL04EklEHjh6Hw5XUs1R9KQC50/2c9GU1O/z55 +C5wyzTu65CRZu4aS1BREQ5y+kbx1I6MqEOJPxoY/zI1h8pgMxytSX+v8yxrUShyTyr6 bx8Uuk78lYu3gTkcv0tKBApLSwdRtyLd1M7j3r++dQoGdXGHa8HZVsAltN6JpnsG3MDn Clb5juUbF9XFDIUgsBZ0x64JHMda7bdIbBejjZ9oWHwKl+VftLOIelP2uVw5F3kWA3QS 9leQ== X-Gm-Message-State: AOAM532pupq06IM+Wj2ZoRQ41pGR5Nm+CORocVSCkXYbRfNWWIUwAAsO 96xBI9BUzDI0QRH2PDYFYvqDIA== X-Google-Smtp-Source: ABdhPJzq5lx1LuoOWBi0xcvz9SR2PajfVZ60/znY+CMB5hIhoq4E+J8mJ0KGxArGCXqzm95GX2qtZg== X-Received: by 2002:adf:f351:: with SMTP id e17mr30125384wrp.416.1615323235348; Tue, 09 Mar 2021 12:53:55 -0800 (PST) Received: from [10.72.0.88] (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id z3sm25482590wrw.96.2021.03.09.12.53.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Mar 2021 12:53:55 -0800 (PST) Message-ID: <23f6401ff8cf342d9b03f425f3d8c174f4515a29.camel@heistp.net> From: Pete Heist To: "Holland, Jake" Cc: ECN-Sane Date: Tue, 09 Mar 2021 21:53:54 +0100 In-Reply-To: <50EBED98-7DCB-4EA0-9188-D396931F890F@akamai.com> References: <7ff9063df5c5e05420ef47245becb77a2de80f2f.camel@petri-meat.com> <1cb500b5cff9a570f71a9b92096f5f279f4a27e7.camel@heistp.net> <0B2ABDF5-A4B0-418B-A6C3-90FE8E4F20BC@gmail.com> <7d423efd8a380e91ae5bdf2922d38ae3c5a243a8.camel@petri-meat.com> <9cbf2c365c0ad635b6f08311d35e0681aa173af7.camel@petri-meat.com> <5044a75f097ab4c737a59c084e863ff89e97741c.camel@heistp.net> <50EBED98-7DCB-4EA0-9188-D396931F890F@akamai.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 20:53:56 -0000 On Tue, 2021-03-09 at 19:51 +0000, Holland, Jake wrote: > On 3/9/21, 10:13 AM, "Pete Heist" wrote: > > On the one hand, the argument is that 3168 is *not* widely deployed > > when it comes to safety with existing AQMs, and on the other hand, > > it > > *is* widely deployed when it comes to selection of the identifier. > > I > > think this finally needs bringing up, maybe tomorrow. > > I think they rephrased section B.2 to match up with this. > > Although B.5 probably does need some editorial work, I think the > technical explanation is mostly the same as what's covered in B.2, > so bringing this up probably has limited utility. Ok, I'll trust that. I think they mainly meant there that they didn't want Apple devices polluting their green field L queue. > I won't deny that there's some weird shifting of the purported > reasoning behind stable conclusions, but I'll suggest that IMHO > you're better off keeping the focus on the real crux of the issue, > which I think is correctly articulated as harm to bystanders by > deploying a new codepoint assignment for ECT(1) without first proving > it can be used effectively without harm by most traffic under the > prior meaning of that codepoint. > > (I'm less sure about the tunnels, which seem to be considered both > so common that FQ can't address their latency and also ignorable wrt > harm from sharing classic 3168 and TCP Prague traffic.  Raising > this point might at least bring them around on the idea that tunnels > could be split by flows when it's useful, but probably also has > limited utility overall.) These are good points. It's true that when we've tried to present arguments in teh past that waiver from these fundamental safety issues, they've almost never landed and end up being better left unsaid, or just written on the list. > > We had a conversation late last year around instead making a > > discontinuous upgrade to ECN/SCE by redefining ECT(0) to be the > > identifier, and I spent some time thinking about it. It's not > > without > > issues, but I wouldn't mind hearing other's thoughts on it before I > > pollute it with mine. > > They did at least update the draft to speak to this point in > l4s-id B.3.  I think the biggest objection on their side was that > it's > not a good classifier with chained aqms, and this problem gets worse > as deployment increases. > > I still kinda like it as the least harmful, mostly only helpful > option (assuming endpoints who negotiate support will also do better > RACK-like support for reordering and switches will stop trying to do > it).  While it doesn't provide a great classifier, it at least > provides a crappy one that doesn't hurt that much when you're wrong. By now I think of that idea as B.Jake. While I understood their loss of classification argument, it's a definite improvement on flow starvation. :) > -Jake > >