Re: [tsvwg] Comments on L4Sops [was Adoption call for draft-white-tsvwg-l4sops ...]

Jonathan Morton <chromatix99@gmail.com> Tue, 16 March 2021 11:37 UTC

Return-Path: <chromatix99@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB943A0990 for <tsvwg@ietfa.amsl.com>; Tue, 16 Mar 2021 04:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJeMdsJUm8p8 for <tsvwg@ietfa.amsl.com>; Tue, 16 Mar 2021 04:37:08 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2DC03A098C for <tsvwg@ietf.org>; Tue, 16 Mar 2021 04:37:07 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id t18so14122466lfl.3 for <tsvwg@ietf.org>; Tue, 16 Mar 2021 04:37:07 -0700 (PDT)
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=ykWlXWijLVQ1Y3RHWMSWe5MneyX1fu1AGNLiMbPMqY0=; b=N/bGBanqOwDeyEvEvsruwQ4LkNMuS7dE+sQxHZCxhCR2A8i2+XhDPZ3UPPu2zK+E9I LxR4ylrGHxqs0i5qD7EPrqn+SUEEpqc73Gb4NbGgJfSPCu6UHQ425w4NBQ1noBcdshnX xErmDQJfewQjEWfmgw7Tbsn53L37spKCx1KyrCmiH92Syix08OBgZkIab9dY9/yuYuLa mHKhgwCHzx4tIT8/t9JK4xByLG6KcaQB2i+XJVWmWiXv5nCwvS95pPKazBOQ5TPZlWCc odNUynPsm918Ur207TGeiTnVeNzpQ4LhAIjdcIU/gG4/gfPFvD1a0ct1/lqcq3FRJo5k qN+A==
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=ykWlXWijLVQ1Y3RHWMSWe5MneyX1fu1AGNLiMbPMqY0=; b=B+SS3tgj13Ys1nctEjdDO+h5sb+bpNX19wk7Fk8CtoJsZ3VQg7Zs7G+50YJpmcUXUT WnloppQKV36t8iprAkybJSxQvowz+HA3TmCv+QdPWcff63uvILQWfLfolBXwTfAkpHuI wVSJuI2gu91RK2BA2d5Zp4aPoRteJ39LdOXsZBPbsBUC5sCi9DNYQXOGlEgye7DRRGAZ V+yA34jku+6UA0nVbHNs1lkGxWD8s5YS03a5FCd0D0NgrV9K6n5gI8yAeGxJud0Pz0Q9 lVA1fxZ7mdJcoVPMF3jQ06YZ90U34TivAQDSjmK9n+qP/epfX7pEHdNalzOtYdIyvyeg VBNA==
X-Gm-Message-State: AOAM531Fy6QRRTp468i51fgTYpM9sTxhuAZhJgCwGSopx8aKOKNL/txX PdTmt3kSPOi5LDJsbH5etn8=
X-Google-Smtp-Source: ABdhPJxZPMclaJ7HmqPGnEtJNiBvFuFmn9H8ozI1WBUlXm/Fooga0nUAVVJPcUPE2WeoNQhfx4MVyw==
X-Received: by 2002:a19:9144:: with SMTP id y4mr11264374lfj.219.1615894623948; Tue, 16 Mar 2021 04:37:03 -0700 (PDT)
Received: from jonathartonsmbp.lan (87-93-215-52.bb.dnainternet.fi. [87.93.215.52]) by smtp.gmail.com with ESMTPSA id l5sm3207010lja.87.2021.03.16.04.37.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Mar 2021 04:37:03 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <7b58524d41c222878a79655195e6e052372f5999.camel@heistp.net>
Date: Tue, 16 Mar 2021 13:37:01 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6587EE65-767A-4487-8520-CB759D144E86@gmail.com>
References: <FC0AE9F0-0F85-441E-B555-51A5B6A6A009@cablelabs.com> <7b58524d41c222878a79655195e6e052372f5999.camel@heistp.net>
To: Pete Heist <pete@heistp.net>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bx_uc29TagmkssYS-S_3DMGUF0s>
Subject: Re: [tsvwg] Comments on L4Sops [was Adoption call for draft-white-tsvwg-l4sops ...]
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Mar 2021 11:37:09 -0000

> On 16 Mar, 2021, at 1:06 pm, Pete Heist <pete@heistp.net> wrote:
> 
> [PH] I think Jon was referring here to end users as opposed to network
> operators. End users are "innocent bystanders" because they may be
> using a 3168 AQM without knowing it.

Not "as opposed to", but "as well as".  It is the end users who will first notice the problem, to be sure, but the burden of mitigating the problem falls on the network operators, since the end user cannot do anything to evade the problem themselves.  In many cases they will not even observe the L4S traffic, which is causing the problem at some intermediate mutual bottleneck on their intersecting, but otherwise independent paths.

> Examples:
> 
> * Their ISP uses fq_codel in its network.
> * They bought a WiFi AP that has fq_codel in the driver.
> * They're using a public WiFi AP that has fq_codel in the driver.
> * They enabled an AQM in their home router.
> 
> The draft can't immediately help those users, because it will take
> years for the existing AQMs to be updated, reconfigured or undeployed.

Correct, though I would also include the four types of network node above, and the people responsible for their installation or firmware updates, as "innocent bystanders".  They have a reasonable expectation that new protocols or algorithms, which they have not opted into in any way, are compatible with the existing RFCs as commonly implemented and deployed, and which hitherto have been associated with a noticeable improvement in service quality.

The fq_codel AQM explicitly conforms to at least three distinct but related RFCs: RFC-3168, RFC-8289, RFC-8290.  None of these contemplate the need for an AQM to treat ECT(1) traffic differently from ECT(0) traffic.  Indeed, the final version of RFC-3168 explicitly *added* handling ECT(1) equivalently to ECT(0), relative to an earlier version of ECN, and there is discussion of the incremental deployment of middleboxes that respect that, phasing out the older spec.  (That was 20 years ago, so can reasonably be expected to have been completed to within epsilon by now.)

 - Jonathan Morton