[tsvwg] Re: WGLC for A NQB PHB for Differentiated Services (draft-ietf-tsvwg-nqb) to end 27th May 2024.

[Sebastian Moeller <[e-mail]>]

Hi Michael,



> On 20. May 2024, at 20:16, Overcash, Michael (CCI-Atlanta) <michael.overcash=[e-mail]> wrote:
> 
> I also support adoption of this document. We have been testing DOCSIS Classifiers utilizing the proposed DSCP value of 45 and have seen positive results in our testing.

[SM] Could you be a bit more explicit, what exactly did you test, what was posiztive and did yu also look for side effects?

I ask, because in combination with DualQ and mapping NQB in the L-queue what you are essentially testing is priority scheduling of NQB traffic and it is zero surprise that that works in making NQB traffic experience less queueing delay. (DualQ is what CabkeLabs calls a conditional priority scheduler with a weight ratio between L and C queue around 9:1 in most configurations, so unless the NQP traffic exceeds ~90 of bottleneck capacity you might have simply tested a priority scheduler).

Regards
	Sebastian

>  --
> Michael Overcash
> Principal Architect, CPE Premises Engineering
>  I strongly support this document. We at Comcast have tested NQB PHB via field trials in our network and it is working as expected. We have succeeded in getting this to work across domain boundaries with peer networks. It is also working inside customer premise equipment (CPE) - per document section 7.1 (DOCSIS Access Networks) on a trial basis and we expect to begin production deployment of this feature in CPE very soon. In cases where WiFi is integrated into a Comcast-administered CPE, we have also deployed WiFi support per document section 7.3.1 (Interoperability with Existing Wi-Fi Networks). 
>  
> During our trial we have detected no negative performance effects or stability issues. 
>  
> Jason
>  
>  
> On 5/20/24, 03:42, "Gorry Fairhurst" <[e-mail] <mailto:[e-mail]>> wrote:
>  
>  
> This email starts a 3 week WG Last Call to determine if the following 
> TSVWG ID is ready:
>  
>  
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/__;!!CQl3mcHX2A!FWohtjRdHXOD8IRDNdxTV3MgR-pD0Fd9D9Vlv8y60c6ufohI9kffW64gXhxRKIC013YGB5gR10kyQ2KJrVtXc6SZGA$ https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/__;!!CQl3mcHX2A!FWohtjRdHXOD8IRDNdxTV3MgR-pD0Fd9D9Vlv8y60c6ufohI9kffW64gXhxRKIC013YGB5gR10kyQ2KJrVtXc6SZGA$ 
>  
>  
> This document targets: PROPOSED STANDARD.
> The document shepherd will be: Gorry Fairhurst.
>  
>  
> The WGLC will end at midnight UTC on 10th June 2024 (2024-06-27)
>  
>  
> Please do read the draft, and please send any comments/concerns to the 
> TSVWG mailing list, including notes on whether these are ready to 
> publish (or send an email directly to the chairs<[e-mail] <mailto:[e-mail]>>).
>  
>  
> Best wishes,
> Gorry and Marten
> (tsvwg co-chairs)
>  
>  
> —
>  
>  
> The IETF WG Last Call process is described in RFC 6174.