Re: [tsvwg] Review comments on a careful read of the L4S ID (#4. rules)

Bob Briscoe <ietf@bobbriscoe.net> Fri, 14 May 2021 11:48 UTC

Return-Path: <ietf@bobbriscoe.net>
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 AD6863A3027 for <tsvwg@ietfa.amsl.com>; Fri, 14 May 2021 04:48:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.432
X-Spam-Level:
X-Spam-Status: No, score=-1.432 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 cwuj6Nf0fjhg for <tsvwg@ietfa.amsl.com>; Fri, 14 May 2021 04:48:43 -0700 (PDT)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.85.90]) (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 0FF8A3A2FF7 for <tsvwg@ietf.org>; Fri, 14 May 2021 04:48:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:Cc:To:From:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hM5TDQEonaJyMXh+REeKNqHFVWCnihQ0nOnmVXEVi0M=; b=A3Q7l9D213bKsUtEobmGOsZC2C HPP0b/ZDKQWSUOEgvBUZ0jUHfZx8VU2tBAFbtwwfJ3TdRlgcxP0VddsiMlZh6DDD/Z5p49m4P1qxg sqJCMUnggFNJlZVPOIb19GW/+Z1fEHfOzM/QtJoMWz4GDDc3Igr1Kd9uZSUM3aw8s8dPeqFJQfuDh muxmInFiPnRV6LkgUlWhwbEtWBUVe/q3uOgEj3C3gx2DUgUri8NBtpEbZ93moxqo6z8yttSf2juv4 ax8GNHPFIXIQBoitT+tQRx0xdJJ1Dkn0zhMv1pMAwUkZ9zyI8ooP9aIAnUQ4ltPJ8AWen8+PrrkkI fJzz3OJQ==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:53170 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <ietf@bobbriscoe.net>) id 1lhWJ9-0003rE-O0; Fri, 14 May 2021 12:48:42 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
References: <634676ca-272d-d616-c352-b38446cf7aab@erg.abdn.ac.uk> <12d2f8b4-d439-9ed0-ef32-c193ee207308@bobbriscoe.net>
Message-ID: <2dd54692-d839-c537-5476-733d42cb6d6d@bobbriscoe.net>
Date: Fri, 14 May 2021 12:48:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <12d2f8b4-d439-9ed0-ef32-c193ee207308@bobbriscoe.net>
Content-Type: multipart/alternative; boundary="------------2E0E3E6EA3D78136C6802B64"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/-hB7ceyDWrCfQATnV4lsLmOW_VM>
Subject: Re: [tsvwg] Review comments on a careful read of the L4S ID (#4. rules)
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, 14 May 2021 11:48:48 -0000

tsvwg list,
see [BB2]

On 13/05/2021 21:49, Bob Briscoe wrote:
> See [BB]
>
> On 06/05/2021 07:52, Gorry Fairhurst wrote:
>>
>> =================================================================
>> *4. Please be careful with the words here.*
>>
>> This text:
>> “It gives an incremental
>> migration path so that suitably modified network bottlenecks can
>> distinguish and isolate existing traffic that still follows the
>> Classic behaviour, to prevent it degrading the low queuing delay and
>> low loss of L4S traffic.This specification defines the rules that
>> L4S transports and network elements need to follow_to ensure they_
>> _neither harm each other's performance nor that of Classic traffic_.“
>> ⁃I suggest removing _"to ensure they_
>> _neither harm each other's performance nor that of Classic traffic"_
>>
>> =================================================================
>>
>>
>
> [BB] What is the concern here? Cutting off the sentence like this 
> disconnects its meaning from the previous sentence, which it was 
> intended to follow on from.
>
> Surely this is not a concern about making claims, because this 
> sentence describes the document's role: setting requirements.
> Perhaps you think the document defines more rules than just those to 
> do with harm. It does in some minor cases, but the core purpose of the 
> document is about preventing harm (mostly to latency).
>
> Proposed resolution: Pending further guidance.

[BB] Gorry took this off list to reduce noise, and explained that the 
concern was the word 'ensure' which has been resolved as below.
For the record:

“It gives an incremental
migration path so that suitably modified network bottlenecks can
distinguish and isolate existing traffic that still follows the
Classic behaviour, to prevent it degrading the low queuing delay and
low loss of L4S traffic.This specification defines the rules that
L4S transports and network elements need to follow_with the intention 
that L4S flows_
neither harm each other's performance nor that of Classic traffic."__


[GF] Yes: For me stating an "intention" would be fine. It's actually 
good to know why you should follow something.
"ensuring" is something quite different, and harder to prove.

Gorry

>
>
>
> Bob
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/