From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 189113B29D for ; Mon, 8 Mar 2021 19:36:09 -0500 (EST) Received: by mail-wr1-x42e.google.com with SMTP id u16so13349669wrt.1 for ; Mon, 08 Mar 2021 16:36:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=message-id:subject:from:to:date:user-agent:mime-version :content-transfer-encoding; bh=lOLoCtimh6yQVAE/i+zEJp1xlCxnEhKahJdcSC1a6LY=; b=OtDAD1kbrjAvtGUIORQR8aEFR2QANMLnlaVz0cyfu+cNHbui33dGHkaJ0DGS08VhPo pXmquuRiEfOphN8VESORkyfc/YWOVDQsfhMH2Z3NV5bGHETunmLVirK5c9Zf2yuQEw2V G7JW+Hh7+F8wbQvqSX/K76HeSohqpRQOzn4XKMp/wFwZ2/qTPZldhqS8VhLRmOfy6I3v vpeKvdznZkseFx0BZF318nNQYivzvl1BhRtIhBrenPLPH/9bsV6w+DBUSXIKHNC0wrge JjYXdDyuMZ73CM+3CA6Cx0BBmLmCx/68/HEH73hy3zrzcF1f4Iw86vdM3XyLBT2w/vaI 3d3g== 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:date:user-agent :mime-version:content-transfer-encoding; bh=lOLoCtimh6yQVAE/i+zEJp1xlCxnEhKahJdcSC1a6LY=; b=l8NhrAGA75K1/DaKdk4k3nf+Fu+ckrFTKWrz1FF3bqOVyqYciL4fdl0EfQw+UH27Sz tAUvoO0zYAF9pwweO5ZoogEHI71mxq4WJSrHv/SmaHS6kIhFU7243iCB8A2vwom1P8X7 Fp7ZUXmOqSYrg1EoOIAMW3guFWs2qJxJLV9ohCv7TnbblapklQtCT9AdUku0+tzJFAmO YlIXpgP9EkxVGgj35wKWVjYghH2L6elAdB17iqIdFNe7EFRrkHgvkWsEHbUi9sJGo+g8 G9QikcIQfJZsvXVF3HXI4qYEtRnvQktYSViEoRqtTCorAPk96grjFcpTtxUcec1e9gZw 1fNQ== X-Gm-Message-State: AOAM533lYYpS8dK40KW+Uk0Nb2qa3lmMQFvC9BLAZPBM0lWloBS5dYtO mtShvzjEYI6UEgL05A90EEyZ7dJPWASsIA== X-Google-Smtp-Source: ABdhPJyeLNHkSnanNDdoei8309J3VCmnCfxTcBfCldqjzdsMkxtxuh7WDuov7emtMW5ABeikmibBeQ== X-Received: by 2002:a5d:400f:: with SMTP id n15mr24554338wrp.89.1615250167527; Mon, 08 Mar 2021 16:36:07 -0800 (PST) Received: from [10.72.0.88] (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id y8sm1247773wmi.46.2021.03.08.16.36.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Mar 2021 16:36:07 -0800 (PST) Message-ID: <9d65a6d19123a881dc14436f6e4d0bd30434b062.camel@heistp.net> From: Pete Heist To: ECN-Sane Date: Tue, 09 Mar 2021 01:36:05 +0100 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] 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 00:36:09 -0000 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