From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 E548E3B2A4 for ; Tue, 9 Mar 2021 13:13:29 -0500 (EST) Received: by mail-wr1-x434.google.com with SMTP id d15so17566060wrv.5 for ; Tue, 09 Mar 2021 10:13:29 -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=sC3X3jny+A7UD82DBMlrAX4EcIh0/LAa6HFY7+5zBcw=; b=QSFvkK1GF143geIvxY13D/zbknvCC6aI5nistX71FG0cvWN4wOxh1bUQvCCT0qtjOP 8OsQ85Rdb9qodnT6JYsGF5Tm68tUJscZwYT9NmIJyAyM1wM/LPFLunm65Zyh9Yk6LH50 9jaqNwVp1X1BANRppCVfMNB4OfgtTzwjtilZf06hcQPjR9xf0KZxU9M/dP0ApYOrCQoi jr/jRsNGRYFYBmdcxr0EyOZPE9hA4Qf7Pae0gSAK8iJV7R84paBBK0bmSBkhELVBg6L4 0wPXpjAmILN8DngT6KwOwxm6G7nUmT7ThiPMvrhhFA8jDaA0PrBYDuZlDMEX9qFGWA/b SmnA== 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=sC3X3jny+A7UD82DBMlrAX4EcIh0/LAa6HFY7+5zBcw=; b=AuO1W13VeGgb7JfSaYULmK0M2rBSv3E5aZx96ncuHWpb9H7BubXKjwbT1T6T/n53Oj qwiTSW9Qvz7mYfNpk9onimgo98B/9+vOX3j3OPMQ9iScwQACiEKGxup7b/q12388yTMF ZYg+8hlNRFMEKheWYfernA6cHPgeFuUTmYxeW9iNyd/XY6I1gY7IYcHsCjwzrDWuE1wj m3XVWvcjdoDcq3/WDzQOgfQh8puqkGUYnc5pbibKhW24qw7IdswjxNgu9w3QMx3mfe9Y Xr0igGNr82a8QECicidoHzMCcd7KvpawzCdy5Bz39CI1XUY2bKlkeTALKJ2xo/pTystM iHQg== X-Gm-Message-State: AOAM533hWs4J6rUK8sAYjz0z4r6pt7fu+3xfr8EXsS3eZQ9vuCVZkJgS 5x5I+fRUmhJS/bKc2G/xBxTE9h/7Vn651w== X-Google-Smtp-Source: ABdhPJwAmvJjvz8l4YXAox1qMLzUH1gmaFxmc9PzPAcbUs/eZ1azyHNHVHJCY5XCO4VM4fvafQfp0g== X-Received: by 2002:a5d:4708:: with SMTP id y8mr16513279wrq.382.1615313608476; Tue, 09 Mar 2021 10:13:28 -0800 (PST) Received: from [10.72.0.88] (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id c18sm6857453wmk.0.2021.03.09.10.13.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Mar 2021 10:13:28 -0800 (PST) Message-ID: <5044a75f097ab4c737a59c084e863ff89e97741c.camel@heistp.net> From: Pete Heist To: Steven Blake Cc: ECN-Sane Date: Tue, 09 Mar 2021 19:13:26 +0100 In-Reply-To: <9cbf2c365c0ad635b6f08311d35e0681aa173af7.camel@petri-meat.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> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 18:13:30 -0000 On Tue, 2021-03-09 at 12:50 -0500, Steven Blake wrote: > On Tue, 2021-03-09 at 12:31 -0500, Steven Blake wrote: > > > Their whole safety plan depends on the claim that Classic RFC 3168 > > ECN > > is not deployed (except in fq_codel on the edge; who cares? they can > > patch their code). If that were the case, it would make more sense > > for > > them to try to move classic ECN to historic and redefine ECT(0) to > > signal L4S traffic (ala DCTCP). > > Actually, that is the ideal outcome. ECT(0) signals ECT-Capable, ECT(1) > and CE signal two levels of congestion. In other words, SCE everywhere. > > Maybe that is an argument that you can throw at them: if it is safe to > ignore classic ECN, might as well move straight to SCE with non-ECT > traffic shunted off to a separate queue(s). You've hit on what IMO is a serious inconsistency in section B.5 of the L4S-ID draft, which at one point explored that option: ----- B.5. ECN capability alone This approach uses ECN capability alone as the L4S identifier. It would only have been feasible if RFC 3168 ECN had not been widely deployed. This was the case when the choice of L4S identifier was being made and this appendix was first written. Since then, RFC 3168 ECN has been widely deployed and L4S did not take this approach anyway. So this approach is not discussed further, because it is no longer a feasible option. ---- 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. 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. Pete > Regards, > > // Steve > > > > > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane