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

[Benson Muite <[e-mail]>]

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)" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> Thanks for this review, see one comment below.
> 
> 
>> On 24 Jun 2024, at 05:14, Benson Muite via Datatracker <[e-mail] <mailto:[e-mail]>> 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)
>