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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 30 July 2021 11:24 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 EBFA33A26C9 for <tsvwg@ietfa.amsl.com>; Fri, 30 Jul 2021 04:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 f9FNsyCFh6L9 for <tsvwg@ietfa.amsl.com>; Fri, 30 Jul 2021 04:24:22 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id EC4543A26CE for <tsvwg@ietf.org>; Fri, 30 Jul 2021 04:24:21 -0700 (PDT)
Received: from GF-MBP-2.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A66031B001CF; Fri, 30 Jul 2021 12:23:46 +0100 (BST)
To: Jonathan Morton <chromatix99@gmail.com>, jholland=40akamai.com@dmarc.ietf.org
Cc: tsvwg@ietf.org
References: <AF731D2C-B796-4B20-973D-6DB496DB1228@akamai.com> <232F9BFA-0D05-48C5-807E-FA2A7904754A@erg.abdn.ac.uk> <eg5mzk.qx1zf8.0-qmf@smtp.gmail.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <de1017ec-d437-4c61-9f9c-7d237eee8fcb@erg.abdn.ac.uk>
Date: Fri, 30 Jul 2021 12:23:40 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <eg5mzk.qx1zf8.0-qmf@smtp.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/LrErTnCiEwoZUqYclTcQxpbpBQI>
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 11:24:25 -0000

On 30/07/2021 11:21, Jonathan Morton wrote:
> 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

I was responding to a request to provide references to canary approaches.

Gorry