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

Jonathan Morton <chromatix99@gmail.com> Tue, 16 March 2021 05:17 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 02AFC3A1A5C for <tsvwg@ietfa.amsl.com>; Mon, 15 Mar 2021 22:17:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 VLCLYwrtHtNg for <tsvwg@ietfa.amsl.com>; Mon, 15 Mar 2021 22:17:54 -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 EF3D93A1A59 for <tsvwg@ietf.org>; Mon, 15 Mar 2021 22:17:53 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id v9so60493173lfa.1 for <tsvwg@ietf.org>; Mon, 15 Mar 2021 22:17:53 -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=c5GqxsjgVoBpNzwpdzFR6Hv49X5f+Wz3gULQHMW3Qc0=; b=Za+0JvtBYG4AbeihuukA5SkU1CBwBDcsxVojuUpuQHeXklovZlMkD8FGUQXbuVkPkv SU+u/W1NeoT9EqSdtHcoQ6Z3hCj+VI9Qg5jSpxUvtkBVg93TWG6NJjCEKZywT4NPxUel GtINsmjuAZUCaN2iD8KHxCZJ79VrjN6VPIk9izzXr4+y84aWcPQPBKmi6Y3WH83aEard v8QCUr9SrDQrXBdGGPZFyyK2o5DFF+qM1iueDABhJeYBM52Da+mpBR5Zc7ybw1wNthJ1 IlRSbLN2FAJaER1L+5SbU06b4G4nSaD95Atzgr9ny+SU34135FgRAjkHMXzHKgtqPBG/ rPQw==
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=c5GqxsjgVoBpNzwpdzFR6Hv49X5f+Wz3gULQHMW3Qc0=; b=qKx+JiT/hah0IAQiLJI08dY9dMZVAJV3wZOOBQlqpEQEWj28VMbv8PQU41r5rT4UuG yls97XDH8FKUvTkDGuf7g4duepYHH3bkxbfZlKcNvwmGmcea9o4tHQzViLiUGjU2HeKp 3R2TfzDt2uuMiJct5t3bU6xFashW3kIrD0O6JO/1qoMhtVMU5TiNNdpTrm6Oiofvbzpf EOhYAeMlix/F1gM8JdLkW71jB+/01fXA+qRFk5Xc+eEqiNJ6LoalZwVkWwdAbjedrfcf isv90iQrzHt8h/sSi5s7vUshqr1Q178LOrS4jUsClaZ6xeW4be+pDXN4mQZtBxazVbfm U9Ng==
X-Gm-Message-State: AOAM533LQux10z/tYHKO8k+0HEKxImJuOMfCx/e8HAkcE1Br1zrccs0z H6n8dLI/X7U1sqBKlGCVlTs=
X-Google-Smtp-Source: ABdhPJw8sY4Af5wl7Of8/zdzD6sdAKYmdaRPpYbCrsO3KliIsYVZq4WrX2cMyCcGngnkDCBFmAcaWg==
X-Received: by 2002:a19:c755:: with SMTP id x82mr10289068lff.149.1615871870773; Mon, 15 Mar 2021 22:17:50 -0700 (PDT)
Received: from jonathartonsmbp.lan (87-93-215-52.bb.dnainternet.fi. [87.93.215.52]) by smtp.gmail.com with ESMTPSA id a16sm3094159ljj.124.2021.03.15.22.17.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Mar 2021 22:17:50 -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: <FC0AE9F0-0F85-441E-B555-51A5B6A6A009@cablelabs.com>
Date: Tue, 16 Mar 2021 07:17:46 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D76DD02F-F747-45D7-BEEE-941C93693524@gmail.com>
References: <FC0AE9F0-0F85-441E-B555-51A5B6A6A009@cablelabs.com>
To: Greg White <g.white@CableLabs.com>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/UThzptFEh4zx8TiJuf28xKFZPQ4>
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 05:17:56 -0000

> On 16 Mar, 2021, at 1:41 am, Greg White <g.white@CableLabs.com> wrote:
> 
> I think you've misinterpreted the intent of the draft a bit.  Maybe there is an opportunity for further clarification in the draft itself, but fwiw I'll try to explain it better here.  

Actually, thank you for confirming that I understood the intent of your draft quite accurately.  The problem is that your intent does not match what is actually required, and was called for by the WG Chairs about a year ago.  That is precisely why I do not think this draft should be adopted in its current form - because it misses the whole qualitative point.  That is different from a disagreement on some detail point, which could be considered quantitative.

> Accurate real-time, in-band detection of RFC3168 by an L4S congestion controller is what you are referring to in your first item labeled 1.  If such an algorithm were generally agreed to be simple and reliable, then it could be argued that there wouldn't need to be an L4Sops draft. The detection algorithm that was studied earlier was found to suffer false positives at low data rates or high RTTs (though the referenced 'fallback' paper does discuss another approach for in-band detection that warrants looking into).  While the draft intends to include in-band detection as a potential option, it recognizes that it isn't the only solution.  I think there is confidence that out-of band tests can be reliably performed that determine whether RFC3168 bottlenecks exist, and this information can be used to make decisions about deployment and use of L4S.

I agree that offline active probes of the network are capable of yielding useful information, but that is not sufficient to reduce the risks of harm that I am concerned about to an acceptable level.

Path characteristics can change more rapidly than you are probably willing to run active probes, particularly in terms of which node along a given path acts as the bottleneck.  Congestion at peering and other shared nodes tends to follow a diurnal and weekly pattern, which I'm sure you're familiar with, and can also feature disruption events due to equipment faults, newsworthy real-world events, etc.  This could easily shift the bottleneck dynamically from the last-mile link to the backhaul or the peering, and back again.  You cannot tell from a single probe at a single time whether *all* those potential bottlenecks are L4S-safe.

You may remember that one test we presented for SCE, at the Chairs' request, was a simulation of changing the bottleneck from one type of AQM to another and back again.  The results, as I recall, were quite satisfying.  I'm not sure that we included a switch from an AQM to a dumb FIFO, but the results in that case are also benign and easy to predict for SCE.  Have similar tests been run for L4S, with similarly satisfying results?

> Further, I don't agree that network operators are always "innocent bystanders" in your taxonomy.  Some might be, but others are definitely not.  I think it is totally appropriate to provide guidance to network operators that want to participate in L4S but have RFC3168 deployed in their networks.   

In other words, you intend l4s-ops to be a guide on how to prepare an "involved participant" or "interested observer" network to carry L4S traffic, under the assumption that the experimental traffic will not accidentally leak out of that network into an "innocent bystander" network.  But as I pointed out, there is no mechanism mentioned for reliably preventing such leaks from occurring, and there are reasonably obvious cases that could provoke that eventuality.

What the WG at large is *specifically* concerned about, however, is the potential harm to "innocent bystanders".  That is the central point of Issue #16, though I don't think the words "innocent bystander" are actually mentioned in it.  By definition, an innocent bystander cannot be expected to take extraordinary action to avoid the risk of harm to himself or his own interests - which means that the recommendations laid out in l4s-ops, as presently written, do not protect him.

I do recognise that some of my suggestions are potentially out of scope for l4s-ops, or completely impractical to actually implement, or both.  In particular the last method requires a rewrite of the *other* L4S documents, or else throwing them away and starting from scratch.  But I think you could reasonably consider the third method - that of containment - as a method of conducting the experiment safely and discovering whether the fourth method is, in fact, necessary.

>> I am not hugely optimistic that the l4s-ops draft will incorporate the above advice before the adoption call ends.  But unless and until it does, my position is that it SHOULD NOT be adopted.

Based on your response so far, I think the above paragraph was quite perceptive.

 - Jonathan Morton