[tsvwg] Re: Intdir early review of draft-ietf-tsvwg-nqb-23

Benson Muite <benson_muite@emailplus.org> Wed, 10 July 2024 03:50 UTC

Return-Path: <benson_muite@emailplus.org>
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 38B5FC1840DC; Tue, 9 Jul 2024 20:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.461
X-Spam-Level:
X-Spam-Status: No, score=-2.461 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_FROM=0.001, NICE_REPLY_A=-0.355, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=emailplus.org header.b="qtgtrGuI"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="KLsLT2i3"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fBKWg3-bZTm; Tue, 9 Jul 2024 20:50:50 -0700 (PDT)
Received: from fout1-smtp.messagingengine.com (fout1-smtp.messagingengine.com [103.168.172.144]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33DEC1840C6; Tue, 9 Jul 2024 20:50:49 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfout.nyi.internal (Postfix) with ESMTP id 6ABD71381499; Tue, 9 Jul 2024 23:50:48 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 09 Jul 2024 23:50:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emailplus.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm2; t=1720583448; x=1720669848; bh=c53ETmYCQjoi1IMKRVuA5Rg3RFsRenet 6CCPLPb4iZI=; b=qtgtrGuIzOPdWDX2FE8l3frqKYA6+T/SzYx97MUOv+fRPUGM Uejd5pwgGtiPIRmVaXqT3+Z3oJdKYqNzrgrc/fQWLjhyYgkR8OQTMvan4R44KBUH uF0ShknawSHKEbeNpeFZjnHOuI22GtdXwdVERFwQXdTGswcppxaVw++wtftdAJOT oQup3oTFW0EdLMG6KOlms54qVK/nzFEkb5np7W+0Ipr0CuguJCDTief9SB8GVQ4j +1uRBKYoR2XUKEAle4114Frz2q2NWg98qBXLFJwj5HOZoqR0a9ht+Yco4eSLu/P4 v/dZ6fULgTccTqt5hqon5SlrNgM02hOauEYM8A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1720583448; x= 1720669848; bh=c53ETmYCQjoi1IMKRVuA5Rg3RFsRenet6CCPLPb4iZI=; b=K LsLT2i3cH6VeFOXGaUUIvrSmvLBcDMGXBlXv0unE2bj9wE3Y5aGDMA8es0O9+UPp PLaaY7m4oe4R1TvWzP5ncWE6HcgsLCt+Vl4XthZnGnYcWzVwJkgwv7B8y/J/rhPw 1hoXk6BrQ7xx6an5VRvgZ2Hr4JE9weqtUcTMpj67RYVcMJiijq8u6FXHCZ6bFkeu QSWlZ74abqbpSO1Vm011iahBnMljmFZEpXEUbaLRzpNlrH7PYFRBMfR4+NUaNklj r4yriWuYaFS153AE5AJ3ysvn4gx2Ku5Lq3KWDMCPE532Fq0zp8QeY04/iJ/DIL3d D2SvaMIwzl31w8CX2VpAg==
X-ME-Sender: <xms:FgWOZoSUR3XQEf86oa1HNLwH4JsP0o9yRNP3HvSfahetKLhnRT4zlw> <xme:FgWOZlzwjugt46ovBHZT-dAFnyek0-ANgz9X68EG9KXRLyifr9CNkWnqVGLOg2vIh yi19EcNKHjN-FGu>
X-ME-Received: <xmr:FgWOZl1X_8RHKRt9tQDgt4izOgLsbvb7wI4-llc4D2Podp_aie6ZdLiYz8KG6V1bbg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrfedtgdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuuegrugftvghpuhhtqdffohhmrghinhculddutdejmd enucfjughrpefkffggfgfvvehfhffujggtgfesthekredttdefjeenucfhrhhomhepuegv nhhsohhnucfouhhithgvuceosggvnhhsohhnpghmuhhithgvsegvmhgrihhlphhluhhsrd horhhgqeenucggtffrrghtthgvrhhnpeejveeljeeuveeggeeftdffteegheffieegfeeg vdeuieeuvefhleetleehvdduvdenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivg htfhdrohhrghenuceurggutfgvphhuthffohhmrghinhepvghmrghilhhplhhushdrohhr ghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsvg hnshhonhgpmhhuihhtvgesvghmrghilhhplhhushdrohhrgh
X-ME-Proxy: <xmx:FgWOZsAs1b2IpAxGV_toEXkyOdh2reqcHS0lhW3ZggEBso8zWBiHgQ> <xmx:FgWOZhhSPFdSZJxe8b2vQx9fJ4WCQCpaE4yNDJxOrkhdnOmxIFkXxw> <xmx:FgWOZoogd1XeaRqaSAF0M34rd3zrXNrUfxagj7Ua5QyMCXSPEcwPWw> <xmx:FgWOZkhoyohl1wLl3kbroVoUFlmghY3SFlfvsX6X8a_GHwS728hIsQ> <xmx:GAWOZvYBwU0gpSgS-AxDMPZ1MujjHY_i8tc_QQFWz5dsBttrjC2Xsqcr>
Feedback-ID: ic1e8415a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 9 Jul 2024 23:50:44 -0400 (EDT)
Message-ID: <82c86068-9576-1af4-4d12-a8ab036c8229@emailplus.org>
Date: Wed, 10 Jul 2024 06:50:40 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
To: Greg White <g.white@CableLabs.com>, "Gorry (erg)" <gorry@erg.abdn.ac.uk>
References: <171920247226.220645.10853473013004281722@dt-datatracker-ff65ff8f7-whn7d> <F58216D1-D9A1-4914-86A5-D2B00607D5F1@erg.abdn.ac.uk> <3AD19641-5CF4-4BCA-A2E2-EACBE8509BBC@CableLabs.com>
Content-Language: en-US
From: Benson Muite <benson_muite@emailplus.org>
In-Reply-To: <3AD19641-5CF4-4BCA-A2E2-EACBE8509BBC@CableLabs.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: CCK52OSSHUZ7QWW6O7BZ65KPEGLATKZN
X-Message-ID-Hash: CCK52OSSHUZ7QWW6O7BZ65KPEGLATKZN
X-MailFrom: benson_muite@emailplus.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "int-dir@ietf.org" <int-dir@ietf.org>, "draft-ietf-tsvwg-nqb.all@ietf.org" <draft-ietf-tsvwg-nqb.all@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] Re: Intdir early review of draft-ietf-tsvwg-nqb-23
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/BvtWCOuEu7yNshgGaLqWsDxOF_0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>

On 08/07/2024 20.45, Greg White wrote:
> Thanks Benson & Gorry,
> 
> I've made updates to address two of the three specific comments via:
> https://github.com/gwhiteCL/NQBdraft/commit/487742ffe32e8723596041ad013e6c69ccd728b8
> https://github.com/gwhiteCL/NQBdraft/commit/ab8e742c6db983e3bce2a9b8384fdb8b0ec3e090
>  

Thanks for the updates.

> On the comment about the example rate of 500 kbps given being quite high for 4G networks, that is noted.  There was a fair amount of discussion in the WG around how to craft the sender requirements, and the recommendation for 1% of "typical" path capacity was the result. The two instances where 500 kbps is mentioned both include caveats that could apply to the 4G scenario, in particular the reference to https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-6.1, which could be read as recommending that 4G network operators concerned about NQB traffic rates disable NQB support (i.e. don't provision a dedicated bearer for it).  While 50 kbps is likely sufficient for some IoT applications, packetized G.711 voice runs close to 100 kbps, and other applications that would benefit from NQB marking can be in the 200+ kbps range. 

1% of capacity is reasonable.  The range of applications that can
benefit from this will change as capacities improve. Perhaps it is
possible to signal what typical rate can be expected for NQB?  Periodic
revision of the rate and disabling NQB when such a rate cannot be
sustained is also fine.

> 
> -Greg
> 
> On 6/24/24, 8:39 AM, "Gorry (erg)" <gorry@erg.abdn.ac.uk <mailto:gorry@erg.abdn.ac.uk>> wrote:
> 
> 
> Thanks for this review, see one comment below.
> 
> 
>> On 24 Jun 2024, at 05:14, Benson Muite via Datatracker <noreply@ietf.org <mailto:noreply@ietf.org>> wrote:
>>
>> Reviewer: Benson Muite
>> Review result: On the Right Track
>>
>> I am an assigned INT directorate reviewer for <draft-ietf-tsvwg-nqb-24.txt>.
>> These comments were written primarily for the benefit of the Internet Area
>> Directors. Document editors and shepherd(s) should treat these comments just
>> like they would treat comments from any other IETF contributors and resolve
>> them along with any other Last Call comments that have been received. For more
>> details on the INT Directorate, see
>> https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/> .
>>
>> Based on my review, if I was on the IESG I would ballot this document as NO
>> OBJECTION.
>>
>> SUMMARY:
>> The draft introduces a differentiated services code point for traffic where
>> latency is important. The primary focus is for applications such as IoT and
>> video conferencing. However, the threshold for low bit rate assumes network
>> connectivity at least as good as provided by 5G mobile networks. Many places in
>> the world still have 4G and even 3G networks. Remote locations may only be
>> served by satellite. Many IoT applications are not latency sensitive, but are
>> low bit rate - for example environment recording applications - but it is
>> probably not good to differentiate these from latency sensitive low bit rate
>> applications such as sending remote terminal input. Many video conferencing
>> applications (for example Meetecho) offer possibilities to turn of video feeds
>> and just have audio and screen sharing. 6G is also being developed and when
>> deployed will likely take time to replace 4G and 5G, so some more thought on
>> thresholds for NQB PHB is needed.
>>
>> SPECIFIC COMMENTS:
>>
>> In section 4.1 500Kb/s is quite high on 4G mobile networks, typically what is
>> used for video conferencing and can saturate end point link bandwidth. Would
>> expect this to also be high for satellite links. For IoT applications and voice
>> probably 50Kb/s is sufficient.
>>
>> Informative reference [SA-5G] is an ETSI document that has several versions,
>> possibly the latest version 18.5.0 is the one being referred to.
>>
>> Should there be references for Cubic and BBR in the introduction, perhaps
>> RFC8312 for Cubic and https://github.com/google/bbr <https://github.com/google/bbr> for BBR,as the draft
>> https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-02 <https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-02>
>> has expired.
> I will not comment here on the main points. However if it’s decided to use a reference to BBR, I do suggest using a reference to the I-D, this is still planned to be updated AFAIK, and is being used as a basis for other transport drafts.
> Best wishes,
> Gorry
> (Tsvwg Co-chair)
>