Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt

Jonathan Morton <chromatix99@gmail.com> Wed, 10 March 2021 12:20 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 5A9703A003E for <tsvwg@ietfa.amsl.com>; Wed, 10 Mar 2021 04:20:30 -0800 (PST)
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 Vsg_V9sAssrx for <tsvwg@ietfa.amsl.com>; Wed, 10 Mar 2021 04:20:28 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 911BD3A0045 for <tsvwg@ietf.org>; Wed, 10 Mar 2021 04:20:28 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id p15so25270894ljc.13 for <tsvwg@ietf.org>; Wed, 10 Mar 2021 04:20:28 -0800 (PST)
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=RMNNoTrmYygT+UXsl/dfJosCQrGMa3R0cn0wsKLGqWc=; b=jB4hFc6QaUJoe750ngMfznzBQDZ3wY/Qpgl2X8he+i8GhBVQI6H7gefpXPN4EfRwYc fUakap1r6W4xVrodDf0fhaWz5KQzH52hZkNO0qXKxYg0DuuFPBevnVVidNl1Y2Waqlct 5r2wkW7YN0jwtW+JRvTjubJ1Mvtg+NJRPbHxhQ5/hrt33bSaTGXO0kzkiM6LE/yXPPtx pzEGlDuKPmsls1WCCx9gNnuGQTRk2HpzpeME1oW+HZ5yIkbNbkVhjxYabhDhlqoul3Kr ygD2l27iNcauqsQT+cYMTl8HlnfBWOqPPjhhtsSNH0SWo5963nNEYu5epwKq1TFSxXEx dGog==
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=RMNNoTrmYygT+UXsl/dfJosCQrGMa3R0cn0wsKLGqWc=; b=lNJMGvIlLlgWr5NK+qO3ibh9TovoZEUOXLe19hzKw+ltQj61krydcNscsviTKGst8M ua7rygFRPE2LbDNb9MsohORPgAIG4pzDpLQoYK2CWX8XmZFdrj+aqIQDUxQ0vD25B8r6 ZEQGjlyhLhFzBBZTXZkDQ+uhQGufh9DXF6dEH0ymnmbLdByaZh3Y1obV3Qc46jPPDjzi 2IKUHOG4F64YyH4vTbqtWT4KMp4f+xE/cj0pNNfjB7OsTbrRkzDG5zEa7qmR3La8kXhL axbWXx3i4csIi2CIGqs69cjusk/dTANy2/0h+ClufMcQENILGHmTkIIXOQjYQajugSMu pQsw==
X-Gm-Message-State: AOAM532GvUkAZRC3a5fvIy41a6kQrIeYaBwiNrZyYS0VNS8qQWeKSYjz KwYNEsaRUlxnzLK5RZbw/0IBQK7uBP9rIA==
X-Google-Smtp-Source: ABdhPJwVOJgYWGviqtx4uwa8286x3gqKxWXgoVKoVfCXToC87pMWgQwroXgziD1uultIorW6jmFqfA==
X-Received: by 2002:a2e:6816:: with SMTP id c22mr1693572lja.59.1615378825151; Wed, 10 Mar 2021 04:20:25 -0800 (PST)
Received: from jonathartonsmbp.lan (176-93-29-60.bb.dnainternet.fi. [176.93.29.60]) by smtp.gmail.com with ESMTPSA id k18sm2834249lfg.167.2021.03.10.04.20.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Mar 2021 04:20:24 -0800 (PST)
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: <HE1PR0701MB2299513F1AA89FCB79FC8121C2919@HE1PR0701MB2299.eurprd07.prod.outlook.com>
Date: Wed, 10 Mar 2021 14:20:22 +0200
Cc: "alex.burr@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F6E85760-1184-4A0B-A2BA-D4763C648A66@gmail.com>
References: <161519742798.12373.8424747645620734074@ietfa.amsl.com> <4cc306ea278dab68741b0c27713bfb7c84522e11.camel@heistp.net> <72467bfe9a38edee74c4ab8e12ec350e23315ec9.camel@heistp.net> <ce2c8397-1bb9-8634-7822-88b9ba6d3b22@bobbriscoe.net> <0F3DBF89-9DA3-401C-9793-5F0F2C72ED5E@gmx.de> <22CD0890-346C-4A43-AE20-DCED78E99FEA@gmail.com> <HE1PR0701MB22993B8CE19FD0F077917AADC2929@HE1PR0701MB2299.eurprd07.prod.outlook.com> <414FE1AC-50BD-4929-9731-B5EBDD4A820A@gmail.com> <264638c5-f579-2b0a-cd10-f9995f738d1e@erg.abdn.ac.uk> <374EDDB9-118C-4387-9C44-2B5C471C49A1@gmail.com> <9310b37c-8b82-1ce4-446d-a494c81e0602@erg.abdn.ac.uk> <1653123300.623993.1615307583540@mail.yahoo.com> <04B5AEDC-32EB-476E-A933-A306FEDBDCD0@gmail.com> <HE1PR0701MB2299513F1AA89FCB79FC8121C2919@HE1PR0701MB2299.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/9Tx1DOCu1Zo0MkjrNH2pfDfnJ1k>
Subject: Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt
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: Wed, 10 Mar 2021 12:20:30 -0000

> On 10 Mar, 2021, at 10:20 am, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
> 
> I most certainly hope that we don't spend valuable meeting time on
> discussing the real or imagined merits with SCE. 
> 
> If you find that specs are unclear as to how enable L4S support in Linux
> kernels and elsewhere, including how to navigate around the RFC lingo, then
> please point out where to fix this. A good starting point is the L4S Ops
> draft.

We have already been running tests using the published L4S kernel, as was discussed at previous meetings.  Here are some results we added recently, and mentioned in my talk on Monday:

	https://github.com/heistp/l4s-tests/#harm-to-flow-completion-time

> Like things are now my only interpretation of the situation is that you
> place your bets on that L4S will fail and you do your best to make this
> failure happen. For instance you point out a problem with fq-codel and L4S
> but show little interest or even oppose solutions to have this issue
> remedied. Please prove me wrong.

The reason we oppose L4S is because we believe it constitutes a danger to the Internet.  That was the thrust of my talk on Monday, supported by data collected recently by Pete and previously by Jake.

The reason I, personally, will not attempt to take pre-emptive actions to "enable" L4S deployment is because I have no desire to make that danger more likely to occur, nor to make deployment of less harmful alternative more difficult.  I consider it likely that upstream kernel maintainers would also reject such actions, were I to propose patches, on the grounds that they reduce compliance with existing published RFCs.  I have already explained this clearly.

We have proposed two methods of eliminating the problems with L4S.  One of them is SCE, first introduced almost exactly two years ago, which has running code that is ready to try out (in the lab) by anyone so inclined.  The other one is similar to SCE, but preserves the "classifier" input in the ECN field; it will require more handshake negotiation than SCE as a result, and has not been developed in detail.

The major benefit of both these proposals is that they shift the risk from "innocent bystanders" to "involved participants" by explicitly prioritising compatibility with existing networks, and only triggering the new congestion responses when a new-type AQM explicitly identifies itself as controlling the bottleneck on the path.  This benefit is not identified or discussed in the L4S drafts' appendices discussing these proposals, which is what prompted the topic of my talk on Monday.

Yet both of these proposals have been rejected outright by the L4S team and their allies, and there has been very little net technical change in L4S since we appeared on the scene.  This is despite changes in the existing Internet environment apparently refuting some of the assumptions that drove certain L4S design decisions.

Honestly, we believe the WG is wasting its time with further discussion of L4S per se, but it's up to the Chairs and the WG at large to make that determination.  I will read the l4s-ops draft again and see whether it approaches adequacy.  If it does not, then I will oppose its adoption and explain why.  It's the only ethical thing I can do here.

 - Jonathan Morton