Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-06.txt

Bob Briscoe <ietf@bobbriscoe.net> Thu, 29 July 2021 20:39 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 1C5453A0A4D for <tsvwg@ietfa.amsl.com>; Thu, 29 Jul 2021 13:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_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=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 16vf0ff5kmPc for <tsvwg@ietfa.amsl.com>; Thu, 29 Jul 2021 13:39:24 -0700 (PDT)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [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 D79533A09BE for <tsvwg@ietf.org>; Thu, 29 Jul 2021 13:39:23 -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:Cc:References: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=dZ/J5N2s84HXkNtCsQExIzoo/6SspOo3jbr4dc1gqg8=; b=R6DgDUAoJ/Tzx3hmt+sXklbOLj MmLGFsXieuJvkFfItX60VesnFabffqlppMfPpPDsSmWUWeRXKbIyjZ8MJHOgZuMHfZyW0SOcM4mGs r9KfkJSd8sCwr1aTSGqQPpehP/3W+qDN7TKwavJAjK/jTubSKsgahh3KBZV+oXOkAUAetzO0Zajhr ffP1IrJ/CLW+/bzPiSsxY6Ku2CbQMtI/T3j4lc+7VZmsjLlA/hy3ED1qrQLIqcVygndtz0JX2epvg AlOHUu/dyFguCyLasW9OQ97huH9Yi+8Ax4ii66mOIlXvL4Gj2gl8umC+8lzcucNdPdF7UtzhAAchv ihCtwKXQ==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:47130 helo=[192.168.1.10]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <ietf@bobbriscoe.net>) id 1m9CoS-0001AD-RS; Thu, 29 Jul 2021 21:39:22 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: Greg White <g.white@CableLabs.com>
References: <162612278784.28797.8827422020954778635@ietfa.amsl.com> <7CABA804-0F08-411D-89EC-5B6182C1B827@cablelabs.com> <50aad7c4-729b-5c80-3481-0b2bbf8e6896@bobbriscoe.net> <471CC6A4-3D5D-47A4-AC01-F493B35DA355@cablelabs.com> <13a3590c-dfaf-cffb-c833-a46839b27b64@bobbriscoe.net>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Message-ID: <6d051f2d-766e-7d9b-6999-2aa60bb9e235@bobbriscoe.net>
Date: Thu, 29 Jul 2021 21:39:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <13a3590c-dfaf-cffb-c833-a46839b27b64@bobbriscoe.net>
Content-Type: multipart/alternative; boundary="------------4B7EBCF59834F4BF09BE0E9B"
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.hostinginterface.eu
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.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ntGanYqcGP8GqlgzCPSQ1W6rg1U>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-06.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: Thu, 29 Jul 2021 20:39:29 -0000

Greg,

Following up my own reply - see [BB2]

On 29/07/2021 15:06, Bob Briscoe wrote:
>
>> o"If the application's traffic exceeds more than a few packets per 
>> RTT, or exceeds approximately 1 Mbps on an instantaneous 
>> (inter-packet) basis, the application SHOULD NOT mark its traffic 
>> with the NQB DSCP."
>>
>> §If this were 'MUST NOT' it would be too prescriptive as the Internet 
>> scales. But perhaps it's better to say 'MUST NOT' and allow more 
>> flexibility in the quantification. For instance, instead of 'a few' 
>> and 'approximately 1 Mbps', explain how these numbers might scale as 
>> the Internet scales.
>>
>> [GW] I understand your point.  But am going to hold off on making 
>> this change.  It isn’t immediately clear to me how to structure this 
>> as a MUST NOT.  Maybe we can discuss this in the WG.
>>
>
> [BB] I agree that it would probably be impossible to come up with a 
> MUST NOT here. But with a SHOULD NOT, I still think the quantified 
> requirement will become outdated unless it is somehow explained how it 
> will scale in the future. Yes, for WG discussion.

[BB2] I was thinking that none of the proposed metrics change much over 
the years as link capacity scales. So are none of these in the right units?
* "a few packets per RTT"
* 1Mb/s instantaneous data rate
* one 1250B packet every 10ms

Straw man:
I think the real requirement here is that there's a lot of space between 
the packets, relative to the time the packets spend serializing. That's 
what ensures they add very little to queuing.

You have to know the link rate to know the serialization time. But, in 
general an application or transport doesn't know the bottleneck rate of 
its path, and certainly not the available rate. So, I think the numbers 
in the draft are perhaps unconsciously related to what the authors 
consider to be the average bottleneck link rate at the time of writing. 
But this will not be a useful guide in 2031.

Current global average access bandwidth according to speedtest.net's 
global index https://www.speedtest.net/global-index are:
     fixed    down 107Mb/s up 58Mb/s
     mobile down 55Mb/s up 13Mb/s
[To anyone tempted to dispute that: Please let's not debate how 
selective/biased/correct those numbers are. I'm just looking for a 
ball-park]

So 1Mb/s consumes about 2-10% of each RTT for the lowest of these 
averages (mobile upstream). Yes, there is wide variation around those 
averages. But that's why the figure is in the single digit percentages.

So perhaps "an instantaneous packet rate that is no more than a single 
digit percentage of the global average access link capacity at the 
time," Then give an example for the time of writing.

Equivalently, "the packet serialization times consume no more than a 
single digit percentage of each RTT". But I think that's unnecessarily 
obscure.

Cheers


Bob

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