Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021

Jonathan Morton <chromatix99@gmail.com> Mon, 22 March 2021 23:08 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 699AD3A1579 for <tsvwg@ietfa.amsl.com>; Mon, 22 Mar 2021 16:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.052
X-Spam-Level:
X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[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 cLdeoS8T0H-U for <tsvwg@ietfa.amsl.com>; Mon, 22 Mar 2021 16:07:58 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 9037A3A1575 for <tsvwg@ietf.org>; Mon, 22 Mar 2021 16:07:58 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id a198so23848700lfd.7 for <tsvwg@ietf.org>; Mon, 22 Mar 2021 16:07:58 -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=xV+VfbSzI5urpxvnEJ/NSoQz6/xkIk66IuymC5RewCw=; b=i0c8wB+9Dgw2f4f0FJDpDHwVb8fP+QUpU+KQ7ds7LocX8eQN5UqQOxyI/Fy0P2VQBb L+h2A9aQLl/lgJHiFcdEhFO23uavMddf8+qe6wV2SARpm2z/vW1hm8HfZ2of/K/Zgpb/ HNropvNu8V5cvNtTusHA780yQKjPDAK975EOU/Mwgkx4ccEHeGSq/rkY8zCe29ciSD8I cYwyBVoua0AoisSSCmlPpcKPLcj5S9xyHm9cMqxMBv94k6C63aeRfr2rnJ44PKpcphuZ oKXefhbvKj2gpJk79UGkf3ttLCPCcIreH+oZBkx0tTN5tI/7YyoNSivTUQjVzdspuO9L ymTg==
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=xV+VfbSzI5urpxvnEJ/NSoQz6/xkIk66IuymC5RewCw=; b=eJtjx1f2sTHxruAlsySIUUzZHE1AOKQ+2K5vD0CdZsRyQxFNAJFB0rU8/fMDDjEDuF jQr9wINXlGtmkAnSeb/wG6gx2ZkdEEcT4p0Es+PvoflAQSr9h5MkCCxEfWBaZqkpz1oR 6/5zTX+4rvKoVwQ/+61s0Px5N3+Pns0d31FiOD0qL9LVY+elke55E+Mn+kx+fXzZH3ft wXEQvL9zU315M1GArwnEPxO5fuj2XiemY3xwEpHZlGv/bT3rfAsRZef9DzMbxtqTOYHF BPf4m0BRpfixWp2rmUVOhi2M/CYhr0TmjwMC8y3Fj1TZpBpAIHbPwvCraKzN8D2O4nIr 1qOg==
X-Gm-Message-State: AOAM533dGy6pUeg3yCpC/d06syfb2Hlwzw57OV8B+HgF7Mg9fi7lDosL 2ul3h3EBAhRisiGbHgxHmEQ=
X-Google-Smtp-Source: ABdhPJx5xtP7LWEgtDMqHAwxtxIAB/V8BnVhYealQz3ZKq0nqnc6Qq69SDi8yJNCmnMltlajexQIBQ==
X-Received: by 2002:ac2:5604:: with SMTP id v4mr843647lfd.107.1616454475191; Mon, 22 Mar 2021 16:07:55 -0700 (PDT)
Received: from jonathartonsmbp.lan (178-55-25-11.bb.dnainternet.fi. [178.55.25.11]) by smtp.gmail.com with ESMTPSA id i8sm1689551lfc.115.2021.03.22.16.07.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Mar 2021 16:07:54 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <DCB5719F-CBB5-4F91-9839-5F468C0158EF@akamai.com>
Date: Tue, 23 Mar 2021 01:07:53 +0200
Cc: Sebastian Moeller <moeller0@gmx.de>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E4DAE09D-35F1-4DE0-8A21-7C35E84BC049@gmail.com>
References: <e9da704b-7705-baf9-a82c-39d4fe4e7ef1@erg.abdn.ac.uk> <CAA93jw5+OOpFEWYXD2xTDw6+mDNx_foqn1JpR7j3v9VxWwY7qw@mail.gmail.com> <8fd946f0-0744-dbbd-d806-0c044674499b@erg.abdn.ac.uk> <FB077630-CA92-4CF0-8B87-826A880459DE@gmx.de> <d72f71a6-f96d-83a5-9570-6a0c18731553@erg.abdn.ac.uk> <37CEF935-EECB-4DDF-BC72-EB3201CD9475@gmx.de> <DCB5719F-CBB5-4F91-9839-5F468C0158EF@akamai.com>
To: "Holland, Jake" <jholland=40akamai.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qa5fhqf4UjIRFt_V7-aqOuNitfA>
Subject: Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021
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: Mon, 22 Mar 2021 23:08:03 -0000

> On 22 Mar, 2021, at 11:40 pm, Holland, Jake <jholland=40akamai.com@dmarc.ietf.org> wrote:
> 
> Meanwhile, the L4S proponents raised a few well-founded objections to
> SCE with ECT(1) as output, for instance that in a shared queue the
> high fidelity congestion-responsive flows will necessarily be subjected
> to latency spikes driven by classic flow competition.  This was borne
> out in the SCE testing, e.g. in [3]--although it represents a substantial
> overall improved latency profile relative to the classic flow without a
> high-fidelity signal response, you can see the green spikes for the SCE
> latency in the shared queue tests, and how this limits the potential to
> stay within in a tight latency budget, even under favorable conditions.

This is not an insurmountable problem, but one to discuss in another thread at another time.  It refers to a particular prototype qdisc which was deliberately designed to show reasonable coexistence between SCE and conventional traffic in a single queue - which it actually succeeds at.  More sophisticated approaches are possible, in particular FQ, or using Diffserv classification for that rare class of traffic that can't even tolerate 5ms of jitter.

Ultimately, though, SCE is intended not as an "ultra-low-latency at any cost" mechanism, but as a congestion control signal that strikes a better balance between throughput and latency, by eliminating the sawtooth oscillation inherent to AIMD and settling at a cwnd close to the actual BDP.  Any performance achieved beyond that basic standard is gravy - nice to have, but not considered essential.

It's actually strange to me that some people consider this nit a show-stopper while ignoring the horde of angry Japanese Hornets on their own turf.

> There remain some fair questions to ask here, most notably IMO the
> same one you've raised, which I'll phrase as "is it appropriate to
> assign ECT(1) to this when the only known safe deployments would be
> known-path scenarios that could almost equally well use a local DSCP
> assignment for classification?"  I think several others have tried to
> ask roughly the same question, but it has so far been dismissed by
> the authors for the reasons given in Appendix B.4 of l4s-id [5].

I believe those arguments do not apply to the scenario, so are invalid - they are predicated specifically on allowing end-to-end L4S over the global Internet.  But without some significant technical changes to L4S, that is simply not going to happen, and all such technical changes have been rejected outright by L4S draft authors.  Editorial changes, some of which have gone through, do not improve the technical content.

> To me the key conclusion at this stage is that the operational
> considerations draft needs to share fate with the rest of the L4S
> drafts.  This is true regardless of whether L4S ultimately gets
> dropped, gets substantially changed, or achieves consensus and moves
> forward as-is, since as it stands today, the operational considerations
> is a key part of the safety story for avoiding damage to bystanders.
> Given that the other L4S drafts are currently adopted, this means to
> me that the operational considerations also needs to be in the same
> state, IMO.

A reasonable argument, but…

> But IMO, given that there are proponents looking to move forward with some
> form of deployment of the technology in hopes of getting the benefits
> shown in lab, it's important to document the precautions necessary to do
> so safely in deployment, and as far as I can tell, this is currently the
> intended role of the operational considerations draft.  And in that context,
> as RFC 7221 puts it, the pragmatics to consider here are "Initial, not final",
> and "Adoption, not approval", so while it's great that feedback is being
> generated and hopefully considered carefully, it's not (IMO) helpful to put
> off adopting a doc when we have a strong belief that other currently-adopted
> docs can't be deployed safely at scale without considering the advice that's
> in-scope for that doc.

This presupposes that the draft is expected to be refined after adoption, which in turn requires that the author is receptive to constructive feedback.  If I had some assurance that my detailed feedback so far was being taken seriously by this draft's author, I might change my stance.  Since it has simply been dismissed without adequate explanation, objection to adoption is the only voice I have, and I won't apologise for using it.

 - Jonathan Morton