Application limits vs. video limits

[mjoras]

Our most recent variant of the charter, compared to the previous iterations, has more or less dropped any specifics around the signal being exclusively used for video traffic. It still offers video as a motivating example, but refers to the limits as "application limits".

There was unstructured discussion around this during the BoF, but I wanted to start some discussion here to get people's thoughts on this distinction. Is it useful to frame these as generic "application limits" which non-video applications could use? Is that overly generic? Does opening this up to more than video make it less useful for operators to manage their networks?

[gorryfair]

For me: If we can make this framing work, it could be useful. This would then be providing a max rate for traffic that is responsive - i.e. congestion-controlled - and expects to use the capacity. That does include video in various forms as the current major traffic.

[mjoras]

@Kevsy would you like to give some thoughts here? I think it is also related to your thoughts on the problems with "application limits".

Another thought I had was that we keep it to "application" but we introduce the word "throughput", so basically everywhere we say "application limit" would become "application throughput limit".

Thoughts?

[Kevsy]

Sure - I can certainly see this being useful for e.g. games, virtual and augmented reality as well as video

Regarding 'application limits', to summarise my point from the Charter PR review:

I feel the term "application limits" could be misinterpreted as meaning "the limits for this particular application", and hence risk pushback from national regulators who are concerned with applications being treated differently by networks (i.e. net neutrality). I think the network rather signals "throughput limits", based on the user connection state, which an application can decide to account for. IMO 'application limit' is exclusive and does not name factors that applies to all applications, namely network congestion and end-user context (especially relevant on cellular). Hence my preference for "throughput limit" encompasses all the factors.

"Application throughput limit" still includes "application" which, per the above, is to me potentially contentious, and technically misleading. I can't think of any case where the entity using the network between endpoints is not an application, so it's arguably a redundant term in this context.

On reflection, 'throughput limit' on its own does not convey whether that limit is what the network is specced for - i.e what it can achieve, aka its bandwidth - or what is the throughput limit on that shared network, for that application endpoint, for that user, at the time of packet marking. Maybe one of 'Session throughput limit' / 'Current throughput limit' / 'Available throughput' best captures that?

[danwing]

'cooperative throughput limit' might be a reasonable term. Today's speed test shows the uncooperative throughput limit.

[Kevsy]

'cooperative throughput limit' might be a reasonable term. Today's speed test shows the uncooperative throughput limit.

I like that Dan - or 'collaborative throughput limit' , as collaborative is working together, whereas cooperative could imply acceding to another's demands - which is what we are trying to avoid (i.e. network provides a hint, not an instruction).

Or 'common throughput limit' , if we want to make it easier to say out loud :)

[gorryfair]

Is "throughput advice" a good name, because it avoids suggesting that someone has limited something?

[SpencerDawkins]

@mjoras, @ihlar, and @SpencerDawkins like "throughput advice" best, of the suggestions to date.

[Kevsy]

+1 for throughput advice 👍

[mjoras]

109 makes the change to "throughput advice".

[ihlar]

Closed by #109