Re: [tsvwg] Dual-Q Polcing

Sebastian Moeller <moeller0@gmx.de> Mon, 25 May 2020 09:00 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 AA3013A0788 for <tsvwg@ietfa.amsl.com>; Mon, 25 May 2020 02:00:11 -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 y_4q3kprrqPO for <tsvwg@ietfa.amsl.com>; Mon, 25 May 2020 02:00:10 -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 DB93C3A053E for <tsvwg@ietf.org>; Mon, 25 May 2020 02:00:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1590397208; bh=9M9yiDInjxy+VTuACFjjgEZjo613GJ6+pJxoc5IV9zE=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=X5K1MQisfusF9n4gJFIkx0BqzqCK0H5oPFDlZ1okA9VW6dmsHnFChpFcjQSqVYszq T1zze2w3wD6Jg2OK0YxgZZahLIE+r8lYTLeBv/Sq0eZQhpYbSK/KkZmUJmzH3OvdBa UKsw55/ayvtg6ywiVEHG2DN7kgLwT1AUB+f4vf2E=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.16] ([134.76.241.253]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mf0BM-1j5Tpa222c-00gana; Mon, 25 May 2020 10:54:56 +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: <e944f4ec-afe8-7842-57d0-5ef86be2d18c@erg.abdn.ac.uk>
Date: Mon, 25 May 2020 10:54:54 +0200
Cc: tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B15F964-8BEC-4E20-AE1F-A97F2B98FF92@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>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3445.104.14)
X-Provags-ID: V03:K1:OaoGcs6Wv7jqzHgvQHL5TxMX7GM7qQ+qiVeWFhu2dxDiyCAAzPL SixHwYtbz2jvZPuQGTGEcm5aPVkHmC5NcGYcqrgORHLFe3jHb4aXTFfjAP75ErT5SM7Vo/8 C+CS85cisqbKjN079ULV0N4p+14aJveWa6uxvvHOk8jnKtM/XUmmqad0l0Ogf6ABQCqjDk0 9vP9njT3smUlYcqliv8lA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:spiZGlRIPHA=:CQjS3oSzMo2vmbGFzAEnz2 zCkrfT2uzLkDyL2w2Vytg5SMIBWL1WNcj5UsJWnFR/XtMxw+odcEzuIXPmbKILiKUaImybx57 XkGE6KI+Lpqf6Hdud9pYpOTSOuEQYPMcJ0hHifqEMJWNkKG3Mlt7+BRU3DgdTDzYRjMhfwiDU bqb76G7cOndzdTtblCtEw3GNCuE9v08Ed97Gw3uxOcN8dp/6kv3CiepY4Ys1UB3kmL783lLSl kgSq6jNEfoVm5i/6xUJgUa2+Ukc1cccJyYult6+QarET/3nve4aO+RvMwoNiZhIBXD47oPj8+ rNSCAHGVtiHFaSrQVe+lfTp223E2w3hSejT0vepjZyU+UxOVhErLCd9KZ01uYtou1G/gbwp7D c8JiSO4hGGAtXq5fDyFBbSdCHFLsuBexspePoo8Zo9oVqEpN1gBIMWGgWZKQ3XD2VZ0UlueNO iQtyhi0XdGOaf5/+1nf+/lL3I2OrqlOvwm76qF0KIYiqtY8/+1QWX4KCGOU+I+NFstXxM5M+G FixT90whwNtV5rZHbLejZd8lAzONCGrC1nMhw4BKpGqLSQIFO5VRligrIGhMaqJaNAu+iuE+S QYi7O2LH/GGHeQ2+dEufbBjt5yTd5zlnooXjScDm1cnF1+sd8v6tObguJZBquWyNIWc5+GQ4A 4f8LFC7vHQ/w09vYEWq4MrAUrmRjW/BdWYEHMEp+9pm3l8OkLBpawi6vMs4AE1xP04ZPH1NxY dG9L471EUKDgQbCegQlx4Dfb0t/MEzHtBi4ewxhG/DectsHBSIFlpkPtJ2d37tS2kINY94Tf1 s758aPl0T3WhwsAZaK+cRTviGPprVCzdBoDkf8D6qjem64u5TtF2MqDstlD92AkMtB7AiLY50 HX73VdK+80sPOUFYVJTyL6QA7R7JDzUee8nvrTXfd+GFpppnAgSSVn+HNy5hdkCRgEEWHvl+O Hi84fPoaiJ/bEiwWXkz2Wiu4sVVdT8rtZrJ0HIyVWhy6wjNCNtTE5gmLdyv1JQuKYIcYNPSSZ Xx4BnvZz1PWZEzN6wziebsUPAo5JvdbfwU9mdRQrK2rsG+igzOfBNNGI6k707kd8GVwQzo3Jb iLBMP4+q6CH83tMtLdzF9WdkqOVTGUG1UlMYuJ/hAMEBkmeG1uC7G0z7KUlruQgIqJSFH0c/W tB6BGBgy/A9eLWBy+A5Lww6I/vnue9Gk4cT/83IXqwpTrZlSWsxTR5GfdveMGTKLcpfaFTRBe wlOSQ7FkvJC9FsgvG
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/VwFqbmPuwzeiNoVyto1Bc8uKpAw>
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: Mon, 25 May 2020 09:00:12 -0000

Hi Gorry,


> On May 25, 2020, at 10:39, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> 
> So, this was your comment in Dual-Q:
> 
> On 25/05/2020 09:13, Sebastian Moeller wrote:
>> https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-11#page-21
>> :
>> "Where the interests of users or flows might conflict, it could be
>>    necessary to police traffic to isolate any harm to the performance of
>>    individual flows.  However it is hard to avoid unintended side-
>>    effects with policing, and in a trusted environment policing is not
>>    necessary."
>> 
> The general security considerations across section 4 seems reasonable to me.
> 
> Did you have issues with that text wrt security considerations?

	[SM] Yes, certainly I have issues with that. The use of the subjunctive "could" indicates a purely hypothetical concern, or rather that this issue was not actually tackled empirically, yet. Now, Bob argues* that experimental roll-out is required to test that hypothesis but at the same time fights nail and tooth to even add a MUST implement for his intended counter-measure against such a failure mode, the queue protection. As is this is safety-by-wishful-thinking, and that IMHO is not a solid basis for any IETF condoned experiment or standard. 
	Initially the L4S argument was, abusing L4S signaling is self-defeating and hence will not happen, due to lack of incentives to do so. As far as I understand that position was retracted (or at least not publicly repeated on the list) based on the discussion, but it has not been replaced with anything else explaining why safety mechanisms can and/or should stay optional, besides hopes and wishes.


Best Regards
	Sebastian


*) Bob: "I can understand that many operators will be cautious with a new approach, which is why I agreed to design per-flow QProt for Low Latency DOCSIS, even though I do not believe it will eventually prove necessary. That, to me, is one of the open questions that only an Internet-wide experiment can answer, so please refrain from giving your opinion again - we have all heard it many times already."

Note again, Bob's position is based on "believe" instead of harf cold numbers.


> 
> Gorry
> 
> 
>