What is the upper bound on application data rate to be compliant to NQB sending behavior?

[gwhiteCL]

https://mailarchive.ietf.org/arch/msg/tsvwg/W7NNUE-sEb3hOJC5k0V41Nvzj1c/

1. The definition of “low-rate data-rate, application-limited traffic flows” is still problematic for me. The text later describes this (in more than one place) as /relatively low data rate applications/ … which I am less sure about what that means? how relative is this? Can we be more concrete?

[GW] Section 4.1 describes an upper bound using a rate equation, where the rate R is described as 'about 1 percent of "typical" network path capacity' and further provides that today that works out to 1 Mbps. Would it help if we provided that definition earlier on in the document? Or, it your concern that even this definition is not concrete enough?

[GF2] Hmmmm.... This needs to be handled well in the spec. At this moment, it linked to 4 and 13 below.

4. I agree with the desire that they are “such that they are highly unlikely to exceed the available capacity of the network path between source and sink.”, but reading this left me feel really uncomfortable with respect to operators and networks offering less than 100 Mbps - I am not sure I like the idea of the IETF projecting a minimal service rate, so I'd encourage much more care in how this is all framed.

[GW] The intent wasn't to project a minimal service rate in general for the Internet. But, the ability to deliver on the promise of the NQB PHB does depend on the relative rates between the applications sending NQB-marked traffic (in aggregate on a link) and the link rate where the PHB is supported. We could enable the benefits of the NQB PHB to extend to more networks by setting this application rate guidance lower, but that would then limit the applications that could take advantage of it. This is a judgement call, but 1% of "typical" capacity (1 Mbps today) to me seems like a reasonable place to draw the line and provides some headroom in cases where the capacity is less than typical. I think setting it to 500 kbps would be ok, but I don't think we would want to go a lot lower than that.

[GF2] It is judgment call, and a lower rate would ease the pain with respect to objections (including mine). I'd expect we'll find more comfort with more experience, but I'm going to continue to query if a 1 Mbps rate is low enough.

13. /At the time of writing, it is believed that 1 Mbps is a reasonable upper bound on instantaneous traffic rate for an NQB-marked application, but this value is of course subject to the context in which the application is expected to be deployed./

• This is an IETF PS, and needs to have IETF consensus: I’ve argued this is high in the past for a PS designed for the Internet as a whole, and I will argue again the same. Although I can see that in some regions this value would be legitimate, I fear in other places it would not. I think this is something I where I would like to see a strong consensus.

[GW] Per my comment above I think if we reduce it too much it won't provide a benefit for very many applications. Do you have a number in mind?

[GF2] Aha - I wonder can we find a rate low enough to be happy? I'm guessing an agregate of 1 Mbps might be nearer, which might really be a small share of many paths? I think we will need to return to point 13 after we finish others.

[gwhiteCL]

As stated above, I am ok with changing this to 500kbps if that resolves the issue.

[gorryfair]

I can not say "solves", but it certainly reduces the concern, please do this.

[gwhiteCL]

Ok, I made this change in https://github.com/gwhiteCL/NQBdraft/commit/db4ff5de2a0935e7437be33d75bc8cba033d29c9

In that commit, I also added a cross-reference to the "lower rate links" subsection.