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

[Greg White <[e-mail]>]

Hi Benson, 

I wanted to follow up on this last point to see what changes if any are needed in the draft.  See below [GW].

-Greg


On 7/9/24, 8:50 PM, "Benson Muite" <[e-mail] <mailto:[e-mail]>> wrote:
On 08/07/2024 20.45, Greg White wrote:
[snip]
> 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 <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. 

Benson> 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.

[GW] The intent of the current text is to be future-proof, with the 500 kbps number just being an example, and the "1% of typical" being the requirement. Having said this, in re-reading the text in https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-24.html#section-4.1, we have the following structure, which looks like it is actually ambiguous:

-we describe the data rate limit as "no more than about 1 percent of typical network path capacity"
-we give an example of 500 kbps
-we provide a rate equation R*T+ 1 MTU, where R is "the maximum rate described above"*
-we say microflows marked as NQB SHOULD comply with the description above
-we say microflows that exceed the rate equation SHOULD NOT be marked as NQB

* R was intended to refer to "1% of typical path capacity", rather than referring to "500 kbps", but both limits are "above" the rate equation in the text.    I'm going to suggest that we remove this ambiguity by moving the 500 kbps example *after* the rate equation.

Also, we didn't envision a network having the facility to advertise an NQB rate to applications, but perhaps that could be considered for a SCONEPRO type of mechanism in the future.   

Would the change above resolve this comment in your view, or are you asking for additional changes?

Thanks,
Greg