Re: [tsvwg] links to Canary methods for roll-out of new transport features

Jonathan Morton <chromatix99@gmail.com> Fri, 30 July 2021 10:21 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 D85623A24F1 for <tsvwg@ietfa.amsl.com>; Fri, 30 Jul 2021 03:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 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] autolearn=unavailable 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 dYj024Hy78Yh for <tsvwg@ietfa.amsl.com>; Fri, 30 Jul 2021 03:21:16 -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 EA3FC3A24E8 for <tsvwg@ietf.org>; Fri, 30 Jul 2021 03:21:15 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id u3so16875100lff.9 for <tsvwg@ietf.org>; Fri, 30 Jul 2021 03:21:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:in-reply-to:references:content-transfer-encoding :date:message-id:mime-version; bh=UznCf3R+ywqhKa6MSpKL17CrTIAbU7+YrAkiPZ2vhWw=; b=ky+ta9vcb1f7YtiC8X91uacMzV4hLxI+XcWBifLqcTysTl0dVpE8Z2OrkWzZYKcE/6 Kt+w5RuNB/yChI7gV3pyyEQgnuU3hHKRfHtuEB6mrr1k+jnx8VSRiVvvqK4MDp3wrQJL mlYBbUNSqrkqRN+U6lk6civEHu2NfcfvsQYevOHG2CKlodbCoxkz2TVS1DbwO6grETma 28NRgO8sHcG/QE/fgcebDCQxC20Z4udN17I0N4xQnr3j91B9YspMflUwUw5ZtchwmnpR bwbPIpFnOgIbQf3QdyIdoriLrnFF5gPRhyz+02sUvHmhM9l3paOg5mqOEryvTip3yIUm 7igw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:in-reply-to:references :content-transfer-encoding:date:message-id:mime-version; bh=UznCf3R+ywqhKa6MSpKL17CrTIAbU7+YrAkiPZ2vhWw=; b=XXqtpjXm5sRamHLqra8ZMFAncOzgcfr5+ifmHw3vLuFFwuKywp7EWp/oJpmPsFaZWi 58GiBfxvcFySaWceWNV5He+mZjSeRBCGNTyVBOPeu3IxE0+sY08EJEao1bq1Cu50R/QO AY4JyLGnd6WWAC0YS4OuUYdEQxu8xJ6VV/iVzDkQJfxE5CXTEXzSRJZQv3r6ciuTWMdz MPVpL6Tv8dIeMmcP0WDsipZyS87YtYgQMNyaJEcQCuHBprvjxcFprL4XqtcMuii4c78y KX6sEMO7GGJ8h3UtdZkMGnj8mALuq478QbOxZRpIa2aQhim250KLxwwdXRHWj7O//F6L ++Mg==
X-Gm-Message-State: AOAM530yEVjRrdTJNxvDBnkkD0KA1sCtk5WGDudPykcqqPJ4y+/oigZj 57xDlJ7v0ios8yyHz4VhGmMUOWtA1d8=
X-Google-Smtp-Source: ABdhPJw9IdNYLy1XjrYcOOPcBK5tosr22GbVcLaoq38a/OEp/NWR5DZ1tifdBirKG5x9L0OzWd/4fg==
X-Received: by 2002:ac2:4105:: with SMTP id b5mr1375183lfi.153.1627640468904; Fri, 30 Jul 2021 03:21:08 -0700 (PDT)
Received: from ?IPv6:2001:14bb:c2:7e5f:f973:90bd:97d:5f36? (d4l-g-0nxwc0tw-m-h4-4.rev.dnainternet.fi. [2001:14bb:c2:7e5f:f973:90bd:97d:5f36]) by smtp.gmail.com with ESMTPSA id p16sm112659lfr.122.2021.07.30.03.21.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Jul 2021 03:21:08 -0700 (PDT)
X-Priority: 3
To: gorry@erg.abdn.ac.uk, jholland=40akamai.com@dmarc.ietf.org
Cc: tsvwg@ietf.org
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <232F9BFA-0D05-48C5-807E-FA2A7904754A@erg.abdn.ac.uk>
References: <AF731D2C-B796-4B20-973D-6DB496DB1228@akamai.com> <232F9BFA-0D05-48C5-807E-FA2A7904754A@erg.abdn.ac.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Fri, 30 Jul 2021 10:21:05 +0000
Message-ID: <eg5mzk.qx1zf8.0-qmf@smtp.gmail.com>
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/-kPmMIvVf6L_v_CmoW7PuH8VaaQ>
Subject: Re: [tsvwg] links to Canary methods for roll-out of new transport features
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: Fri, 30 Jul 2021 10:21:21 -0000

On Friday, 30 July 2021, Gorry (erg) wrote:
> I am not sure though, I think many CC- related topics can have potential collateral damage, and we have managed to deploy these gradually and improve the transport were necessary. So, what is different here to exploring methods such as larger Initial Window, BBR, Hystart, etc.

Hystart makes a transport strictly less aggressive, by exiting the exponential growth phase early and continuing with much slower linear or polynomial growth.  There is no possibility of collateral damage except in case of implementation bugs.  This is an excellent use case for canary testing, and I would endorse its use with Hystart++.

Large IWs do have potential for collateral damage, but the conditions that would trigger it (small buffers) result in effects (high loss to IW) that are easily noticed by the transport employing it.  This is therefore also suitable for canary testing.

BBR is not so clear a case.  I am pleased that Google is taking a relatively cautious approach to deploying it in an Internet facing context, has designed it with standards-track CC coexistence in mind, and seeks to improve it when problems are reported and verified.  However, the ECN response introduced with BBRv2 is not standards-track compatible, and the likely collateral damage when operating in a shared AQM bottleneck is not easily noticed by the BBR transport itself, especially when those circumstances arise only infrequently.  Canary testing is thus an incomplete solution there.

The entire problem here is that L4S is likely to cause *externalised* collateral damage which is not easily noticed by the L4S transport itself.  Unless great care is taken to watch for such problems, canary testing will therefore fail to find them.

What is more, canary testing has as a prerequisite the confidence of correct operation and design gained though lab testing.  Lab testing of L4S has not given any of that confidence, thus progression to canary testing would be inappropriate.

 - Jonathan Morton