Re: [tsvwg] Dual-Q Polcing

Sebastian Moeller <moeller0@gmx.de> Wed, 27 May 2020 20:25 UTC

Return-Path: <moeller0@gmx.de>
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 71C1D3A0BC0 for <tsvwg@ietfa.amsl.com>; Wed, 27 May 2020 13:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 h_4OV0Yc_KK0 for <tsvwg@ietfa.amsl.com>; Wed, 27 May 2020 13:25:20 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45433A0B77 for <tsvwg@ietf.org>; Wed, 27 May 2020 13:25:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1590611115; bh=Dec23CMlZnVe5Un24B3DohY8Znlo+l1VFlK0tS6el/o=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=jyY7q81SreC6s4w0NqVUY3VRYGwLqhE1Gwo8FCFIHJh+gZeTd8bnPVVlKKuCYTIp/ WBDcrmyBJIKfA+dC3IRSW5UPDIqQtxe6x9HbmEJKbyKmxeT5H5rmk3sxJmwdtAlSxQ bL6kPibmpmF8iR6iZldJOyElQOzy8qJRQSslXtsY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([95.116.247.138]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MQMuR-1jR4Ch3cif-00MJz1; Wed, 27 May 2020 22:25:14 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <e3dfef11-3f86-3761-e76c-4c760b3595bb@erg.abdn.ac.uk>
Date: Wed, 27 May 2020 22:25:14 +0200
Cc: tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D1B4873D-ED2F-41FA-8C0A-4BF023EE2D27@gmx.de>
References: <dbc71da6-70f1-7369-1d2d-f08fb3b08b69@erg.abdn.ac.uk> <21483444.sDhFMENYeD@linux-9daj> <a85600da-e69f-9190-7ca1-d23a7e7246f9@bobbriscoe.net> <3267993.nvHYsSR2bi@linux-9daj> <dd8e3896-2951-537f-e3d1-9954c93348dd@bobbriscoe.net> <67CBAA42-BD37-4A19-B650-68F511FC244A@gmx.de> <af3e6272-c04d-9e81-763c-e690ed521749@bobbriscoe.net> <1565A7C1-1DF1-4C6A-AC37-14331AC87508@gmail.com> <25e34532-5a33-3ca1-5cba-b7f857874ced@erg.abdn.ac.uk> <2605AA63-8225-4585-AA7B-49ACBF3B07EB@gmx.de> <259b9730-58ba-c2f1-6318-3c4717aa6b7e@erg.abdn.ac.uk> <9B51C652-D734-4EF8-BAFF-690A475AD83E@gmx.de> <e944f4ec-afe8-7842-57d0-5ef86be2d18c@erg.abdn.ac.uk> <7B15F964-8BEC-4E20-AE1F-A97F2B98FF92@gmx.de> <fcfdb230-eba9-3605-2a20-682ab6c19463@erg.abdn.ac.uk> <61F585DE-C67A-4AE8-9FCE-878D3C335B3F@gmx.de> <1df40b13-2024-7528-b074-c112940d5e69@erg.abdn.ac.uk> <0A4BA88A-2D30-4DB2-982A-E40B546848C1@gmx.de> <e3dfef11-3f86-3761-e76c-4c760b3595bb@erg.abdn.ac.uk>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3445.104.14)
X-Provags-ID: V03:K1:yxlTqdEWTfP8wWiMOZGVpCWvbN51/9hNgcS2jgkUzq84842Q3Ab ou1hxcmATT5L56Yrnw8UaRgYNKcCcIk2x17Vz97GjeBfmE8P24CXtWaDX7qZ5i5pXPzlwml b26EJgYzJN1HvP5Ismz0ljt51QpzJqLsbQsux59lJBYI6RMU9KqLRytvyoiV05AAwD7oeDY hDjotO6CqX/nH4WuqW6JA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:1HlQVz2jqLY=:UXt1vbeSk2sp3Gy9vUdN2J z2PWHxFh3mt3gJPkApqSUXvwPHaVZ9vKAhLm1SoSBkWwwEZtO++g5jE2jkTXFnlZ3kuwtjGsa dBXF9STojISxpbYvc6igJo2SlWZmk6brpJVXpL++dlVP8MBC5S1i6vtDwr161glNh7LTe49n4 0pV3M8oRuwdWgS6niao22YyhAvYQwRFClKmg543h6Il3e0eJuE0pscYd+EwjakZFA4WJ325bc su4fwXtLlw4j3ce0HoaDcKguBzhbnGpB/3Tbmtxe8+AzMAe/C7nHQTsmUatOp+HZDCOXYqAkn zaYBhQ6rJzykIpS2yp3fKh1dKPj3o/0HskiORs9FiKFskYpOsTqkY1afbNtnDR6uEmZEbGoGy pwMY7H1eSrLdFQPTiaaXEBqt+H5ybr99ENNGMrnmFDi2ZGMoCSLmPgkPa5cYVRrz+rDX96pv1 59c9IIHPOokT1e/nPoCoCF8/MCx2eCzR5zBxKElpbeINVUQ2cv7QH0Yyd7ipDs8LpALmZBIs8 Sa8fQ6t8dQWfsi8FQYao/eQjx9qfWdZs3FLJGtpwCijuKSqpqoubY7zbSk/M0NvyCwR0cjQqk z7ZWW7sUhjkjfmv30BAw3DL0ohMrPK91KAY2qfYZs6dktmNaxlwf9l5nxCKjkc7Y1TX8WtiZF arjN1WjKBUwPo8JwLIhDiaZ+WVTblyFMXoLlXbQnJGN4aPn5sv8KwY2iMJJ9A64ZhCMPUwpNW Ho6eT7G7Ty2SegUVCdvUVR0g+nyM+2N9sg2dgIv+3ZUg8jpPmvaGFpOti/2rRS+UE9SLuBcYp 2HttAjTV+pU7GCCo5oacWbFyePMAs+Cuyx5Fw+Hv71mRL5SCRNvXjB54ZQ0ABca+sx7ppTazQ qET8dMLyDoaRiq61tCR/NclMWooZBeRIe9peLV8bfV+VUKUmEzP/KX0GeluG/Znz5RKxS0jeS anbXgstMno1rE6JhHJM/hBaXwrvm0wTYtvewahEnzqobIx18kN3fyjkB1N3A7mGaev8MUxOHk xwCfTpZNgHNPywSaysw+q7CFCcyRhRKM0LFo5ofPDosmRZ8W+lK7UUZRoQU7jc7XpWZQhwx3J eEiu7KvKFOl5RxdKJaMj9L7RFxMlo7+vzFfJ/W5tEwdqmjwGnoDdhSb0UDvKFeVEZEbXVYt6J P1bO8u02x9tdpEv2Z4he2mExUtChixr44D5OlkPuAJK+AWfawAhmQaLu/RwKl+b9wXlAlNFNL 1wAF0zYf99cPvjKAy
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/rGuGOQdHki2H2Mjves7erFOrDps>
Subject: Re: [tsvwg] Dual-Q Polcing
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, 27 May 2020 20:25:26 -0000

Hi Gorry,

please see below.

> On May 27, 2020, at 16:41, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> 
> I'm going to leave others to pick-up on just a few details at the end.
> [...]
> 
> I would generally encourage people to separate security considerations from congestion control/traffic sharing issues.
> 
> Reducing claims about performance/features in drafts is always welcome. For the WGLC, we need to finally balance protocol design goals,

	[SM] Puzzled. L4S seems to offers no new protocol as part of the suite of RFC drafts. It does come with a few new requirements for protocols that want to get maximum ROI out of the L4S promises. Given that TCP Prague is not an RFC draft, what protocol design goals should we be concerned about here?


> against claims of what is offered,

	[SM] I am again puzzled, that very few members of this WG seem to have much issues with the L4S drafts promising the sky, while skimping on supplying robust evidence to support those claims.

> and doing this before WGLC is generally helpful.

	[SM] I would go further, it would have been helpful even before asking the ECT(1) as input or output question. Now, we are in the  weird situation, that L4S has basically gotten the "go" signal, with IMHO very little chance of not passing WGLC without any substantial changes to its core design. Verbiage, sure that might change a bit, but the core is by now pretty much accepted as set in stone (without sufficient evidence of it achieving its goals promises robustly and reliably).

> 
> The WG Chairs and ADs have been discussing what topics should best be included in which documents. My own suggestion would be to allow a few weeks for the document editors to digest this and then propose what needs to be done in the next steps to take this forward.

	[SM] Fair enough, IMHO there is no need to hurry any of this, or better no need to proceed at all before the requested robustness and reliability tests under to-be-expected conditions are performed, presented and evaluated, but I assume that that ship has sailed, and the process now will be based o the information and test results at hand?

Best Regards
	Sebastian


> 
> Gorry
> 
> G. Fairhurst, School of Engineering
>