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

[Benson Muite <[e-mail]>]

Hi Greg,

Thanks for the updates.

On 25/07/2024 00.42, Greg White wrote:
> 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
> 

The draft gives operators room to decide what levels of NQB traffic to
support.  The draft also gives guidance as to what traffic levels to
expect, but no strong guarantees which might make application
performance uncertain.  An end application might try to probe what it
can send as NQB traffic, and then adjust its behavior accordingly - this
is often done for video streaming, bu may not have been formalized.

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

Moving 500 kbps after the rate equation is fine.  3GPP is also
mentioned, so perhaps adding some numbers of what to expect for NQB in
this case could also clarify things.

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

This maybe helpful, though SCONEPRO is coming up with a charter.

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

These would resolve my comments.  However, as an end application
developer, I would likely probe what can be supported and give the end
user an option to use low bandwidth modes.

> Thanks,
> Greg
> 
> 
> 
>