From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 C08063B2A4 for ; Tue, 9 Mar 2021 14:42:04 -0500 (EST) Received: by mail-lj1-x233.google.com with SMTP id m11so22286442lji.10 for ; Tue, 09 Mar 2021 11:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CXFM66vqji3Un1LRMfhbcS2cbkX2vkQTiuhXrFWIzKo=; b=C0kxVgjs2saVa8RgPoxnVJOykXFyzheLV2W7xwpotAH0eH4WVXfWWrNQw25XE3E6Kg 7l/u8m1husaO7OOaQRCup1ZSIgnIwN7P2LS3xE6dsi6+9C4Sps+oyK4Uhmmg0p0c9UW3 NYGkBNyMFYAZhGpKu3+Wxi/qs95I4vS3rRqyM9Bw8G2lcaUcWaan/h0r+DnfpCeNSuBY Xzt9T4ejQO/3YKxOWDYLPlPS8+0+RyXbd3ZHu4hmU16BE4ciqGBSATkJDs4eqI1Rulgr viLUVDbhgtbmBcnsP7q1PCnKuoeEE416G9SXo1hst4v3rjpCUZjvF2WjJow8YBUrY/cY GRhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CXFM66vqji3Un1LRMfhbcS2cbkX2vkQTiuhXrFWIzKo=; b=hFfyNnriCn5CyWuwOms0GXSpWm74v6eRaR1AEIlQtiv7n9W5Biq/xiOoOlXLwef77d JTX46EQl9rI2ztz/iJGoHXaQS8FXrO7ixawCp7/gtXUP8TzklBRFdyk7JDhk57bSktET sUzfGzUHNydiu2+0U2qRaCoXAC5EHslIoEBf/mJYu+NEuVgn4JczjszrkE2+LwPvv/gB Mhxgy7/j5k2AldY5J+O7yzX95U8m9DPXIo/SCLr/zRepd2d5JJwaaVRQX0tMOqaJMyCF tONmcRWeu/fY6NoOBTO4Ffvt4ThDCt/qldwCl2iF6FLfUlV1VEkm52dGwC8Kl0/5v+JO +HOA== X-Gm-Message-State: AOAM532XcMAbipTuEDxlLvGoFrmdCRz/1kENWUEGaT1qTmxwwWO6IjZp AmIu5rRXoesYVCroKQWlDkgIBQ5wi8I= X-Google-Smtp-Source: ABdhPJySTatEsg3t+8Yssmf+DDyWrX5HYbpROKtdowxGrN+ppqvKUVmgo3Y1zAfNnpOdhLoYvH31pA== X-Received: by 2002:a2e:3a17:: with SMTP id h23mr17805125lja.158.1615318923575; Tue, 09 Mar 2021 11:42:03 -0800 (PST) Received: from jonathartonsmbp.lan (176-93-29-60.bb.dnainternet.fi. [176.93.29.60]) by smtp.gmail.com with ESMTPSA id b25sm2077777lff.268.2021.03.09.11.42.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Mar 2021 11:42:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jonathan Morton In-Reply-To: Date: Tue, 9 Mar 2021 21:42:01 +0200 Cc: Steven Blake , ECN-Sane Content-Transfer-Encoding: quoted-printable Message-Id: <693A9941-6E5C-4873-A676-CEAE6F4A64F4@gmail.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> To: "Holland, Jake" X-Mailer: Apple Mail (2.3445.9.7) 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 19:42:04 -0000 > On 9 Mar, 2021, at 9:27 pm, Holland, Jake wrote: >=20 >>> =E2=80=A6classic ECN traffic will not respond as quickly as L4S=E2=80=A6= >>=20 >> I know it wasn't you making this claim, Jake, but I have to point out = that it's completely false. Classic ECN transports actually respond = *more* quickly to a CE mark than L4S transports. >=20 > Here I meant to talk about an SCE-style low-congestion signal (in > either 1->0 or 0->1 direction), which would be ignored by a classic > endpoint but which a high-fidelity endpoint would respond to. >=20 > So I'm not referring to a CE mark here, but rather an SCE mark, as > I thought Steve was proposing with this bit: >=20 >>> 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). >=20 > Sorry for any confusion there, I'm not in favor of talking past each > other and I think we probably agree here if I've understood correctly. >=20 > What I was trying to say is that an SCE response (specifically > including an L4S-using-SCE response, though I think you had some > intriguing alternate ideas to reduce the effect) would be faster > than a classic response that ignores SCE and waits for a CE. Okay, that does make more sense. I probably wouldn't use "faster" or = "not as quickly" to describe that, however. Such a description only = makes sense if you pre-suppose a queue depth that rises monotonically = over time. AIMD and HFCC responses do tend to need different operating points to = work efficiently. HFCC can settle on a steady-state cwnd that is quite = close to the true BDP. AIMD needs the peak queue depth to be = significantly higher, to accommodate the deep sawtooth without losing = too much goodput. So it entirely makes sense to set the thresholds for = the two types of signalling accordingly. > I do agree with your explanation that a classic CC responds faster to > a CE mark than TCP Prague, that's just not what I was trying to talk > about. Sure. But the phrasing sounded so much like arguments that have indeed = come from the L4S team - I'm sure you remember all the marketing BS that = had to be cut out of their drafts, and there's still a lot of stuff = there which I think is not supported (at best) by the data. - Jonathan Morton=