Qod profiles

[RandyLevensalor]

This adds a QoS Profile endpoint to create, list, update and delete QoS profiles. It's an attempt to address issue #7

With these attributes any of the 3GPP QoS Class Identifier (QCI) can be constructed as well as ones that apply to wireline networks. The 4 general QoS Profiles can't really be leveraged across multiple types of access networks.

The documentation still needs some work, but I'm hoping this PR is gather feedback on the APIs.

I apologize for such a large PR, but we wanted to have a baseline set of attributes and operations.

[hdamker]

@RandyLevensalor thanks for your PR.

Maybe we should have had some discussion about your proposal first within the issue or one of our calls.

At least my understanding of issue #7 is a different one: there are certain QoS profile a network can offer (defined by the network operator, based on the configuration of the network), and the discovery would allow to ask for the available profiles (including information about the paramaters as you described them), potentially limited to a concrete device under it's current network conditions. But actually I can't imagine to leave the definition and creation of a new QoS profile to an (external) API consumer, at least not shortterm.

But let's have the discussion now ... I will put it on the agenda for Friday and encourage all to comment here as well.

[eric-murray]

@RandyLevensalor I think your proposal is a different QoD use case, so actually a new API

Imagine I want to buy a suit. I go to my local department store, and they have suits in sizes S, M, L and E. I choose the one that fits best. It's not perfect, but it's OK, and the price is reasonable. That is the current API.

But I want a perfect suit, one that fits my requirements exactly. I have to go to a Savile Row tailor. I give them all my measurements and other requirements. No problem, they say. But then they quote me the price. It is 20 times what the department store would charge. Maybe I don't want that perfect suit so much after all.

And that would be the case for your proposal. A client would ask for their perfect QoS profile - minimum 20 Mb/s, maximum latency of 10 ms, maximum packet drop rate of 0.001%. How do we guarantee them that, given that we cannot control how they move around within the radio environment? We have to reserve the whole radio channel for them, and thus charge them for all the other revenue we would have got by sharing the radio channel with other users. And we need to factor in refunds when they take their device into the basement where there is no coverage and then complain that we did not meet our "guarantee". We quote them a price. It is way too high for them - maybe the default performance is not so bad after all, and they stick with that.

We need to allow mobile operators to be either department stores or Savile Row tailors, offering either a limited range of not perfect but affordable QoS profiles, or allowing the customer to customise their QoS profiles as you propose. But I suspect the possible revenue from, and hence business case for this second option is actually very limited.

[sfnuser]

@RandyLevensalor I agree with @eric-murray. This should be a new API. Would you like to share some thoughts on the use cases that is driving this effort?

[RandyLevensalor]

@eric-murray Thanks for the feedback and thoughtful reply.

I could see moving the management of the QoS Profiles to another API or a backend process, since it may not be available to all consumers of the QoD api. Though not having a complete CRUD API seems odd, but is possible. We did envision that the ability add new profiles could be limited to the operator and not all consumers of the API. That is why the QoS profiles are linked to the QoD sessions and the QoD session was expanded to allow for free form or bespoke QoS settings.

To extend you metafore, limiting the QoD to 4 sizes is like having a store that only sell 4 sizes of white undershirts. No men's, women's, or children's. No other colors, no other fits, no shorts and no other options. I can't imagine a store like that would stay in business very long. Gift shops and street vendors usually have more than 4 choices.

To be useful the QoD APIs need to provide the operator flexibility to offer 1 flavor or a 100 flavors, without adding a new API endpoint for developers. Plus there should to be a programmatic way to view the capabilities of each QoS profile. Most operators will not allow for these QoS profiles to be modified, but it could be a premium option.

Over time, I think that the ability to query QoS profiles for QoD should be extended to be based on subscriber and / or device. So it would only show the profiles that can be used based on network type and even subscriber plan.

[RandyLevensalor]

@RandyLevensalor I agree with @eric-murray. This should be a new API. Would you like to share some thoughts on the use cases that is driving this effort?

A low latency gaming service needs very little bandwidth with a low latency. Since only game state is shared 30 to 120 times per second. A cloud gaming or remotely rendered VR will need much higher downstream bandwidth a little upstream bandwidth with a guaranteed latency.

If you are an operator with both wireline and wireless backhaul, many of the mobile profiles won't make sense on all access networks.

This extension would allow for the QoD to follow the same model of cloud providers. You can start with a few QoS profiles and add or extend them over time.

[eric-murray]

@RandyLevensalor

I don't mind this being a new and separate API, but it should not replace the current API

I agree that there is a debate to be had about how many QoS profiles should be available for the current API and whether that number can be changed dynamically. But the QoS profiles themselves do not need to be static - the meaning can change over time and be different for different networks, and we just need a discovery mechanism so that the API consumer can see what the available QoS profiles currently map to in terms of performance.

I know that there is no way that Vodafone could manage a catalogue of 100 different profiles and have sensible pricing and enforcement of each, so a mid single-digit number feels about right. You have to remember that, despite all these internal QoS parameters being available for years, most customers are mostly happy with the single default profile we give them (two, if you include voice), so I'm not convinced that the demand for 10s or even 100s of different QoS profiles actually exists.

[RandyLevensalor]

@RandyLevensalor

I don't mind this being a new and separate API, but it should not replace the current API

What would the second API be QoD_Advanced and be a fork of the current api, that keeps merging updates from this API so that the fork is in sync for the common aspects?

I agree that there is a debate to be had about how many QoS profiles should be available for the current API and whether that number can be changed dynamically. But the QoS profiles themselves do not need to be static - the meaning can change over time and be different for different networks, and we just need a discovery mechanism so that the API consumer can see what the available QoS profiles currently map to in terms of performance.

Why not allow the number of QoS profiles be a business decision by each operator and not dictated by the API?

Given the scenario that you describe above, where the number of QoS profiles remain static, but the capabilities change over time. This update would provide an api to view the current attributes for that given policy.

Additionally, if you are only going to support 2 or 3 Qos Profile, that doesn't align with the current API either.

Nothing in this update prevents a service provider from supporting s,m,l and e QoS profiles. This would just add a machine readable approach to gathering their attributes. Since many app developers who will use this APIs will work with several service providers across several countries, the QOS_M profile from provider A, QOS_S from provider B and QOS_E from provider C. That would require specific knowledge from all of the service providers at the time the code is written and then monitoring and updating their code over time.

[eric-murray]

@RandyLevensalor

Nothing in this update prevents a service provider from supporting s,m,l and e QoS profiles

OK, but that's not how I interpreted it. It appears to let the API caller (maybe the mobile app, or application server) specify their own desired QoS profile by passing a parameterised QosProfile object in the session creation call, or separately create them using POST /qos-profiles. So our customers could request to create an arbitrarily large number of different "bespoke" QoS profiles, even if we only actually support a few "off the shelf" ones.

Remember that CAMARA APIs are intended to be called by the customer, and not for internal telco use. They will expect to be able to create their own profiles using this proposed specification.

You can explain how this is compatible with a limited number of pre-defined profiles in the meeting tomorrow. I would indeed be interested in evolving the current API to allow the list of available QoS profiles to be queried and varied over time (the QoS profile "discovery mechanism"), but not for customers to be able to create their own QoS profiles.

[RandyLevensalor]

@eric-murray

Nothing in this update prevents a service provider from supporting s,m,l and e QoS profiles

OK, but that's not how I interpreted it. It appears to let the API caller (maybe the mobile app, or application server) specify their own desired QoS profile by passing a parameterised QosProfile object in the session creation call, or separately create them using POST /qos-profiles. So our customers could request to create an arbitrarily large number of different "bespoke" QoS profiles, even if we only actually support a few "off the shelf" ones.

If the objection is including the POST, PATCH, DELETE and REPLACE calls are not appropriate here, then those can be removed very easily and just managed through proprietary APIs on the backend by the service provider.

The thinking with including these APIs is that you could return a 403 error if a user is not authorized to make changes to the QoS Profiles. Though if there was a business need, say 80% of you business is through one of the Hyperscalers, then that Hyperscaler could request new profiles through this API. I've also included a state in the profile, so a new profile could be requested and would require further action on the backend before it was activated.

To be honest, I went back on forth on weather to include the POST methods in the PR vs. created one PR for the GET methods and a second one for the POST. I'd say that I chose the wrong path here and really don't mind dropping the POST and related calls to manage the profiles.

The important parts of this PR are:

1. Allow for the operator to define the profiles, instead of an enum in the API.
2. Create a machine readable definition for the attributes associated with a given profile.

Even if we just include the change from enum to string included, it would allow us to use this API without modification.

My hope is that by providing developers access to these APIs, these profiles will be used more frequently. Just look at the growth in number of compute flavors offered by the hyperscalers over time. I don't see why we couldn't have similar growth. Especially if you look forward to 6G and increased adoption of network slices as 5G matures.

[eric-murray]

@RandyLevensalor Thanks for the updates.

I still don't understand the reason to allow the client to specify the full set of QosProfile parameters in the create session request. If they are restricted to one of the existing profiles, then surely the profile id is sufficient (assuming name is not necessarily unique). Is this intended as some sort of error check, where we compare supplied parameters against the profile parameters and flag an error if they don't match? That could be tedious for both sides.

And I still think that if we allow the client to specify the QosProfile parameters, then some will treat that as an invitation to try and specify their own requirements. Restricting CreateSession to only allow a qos_id to be specified (qosId for the camel case fans) would be better.

The two GET /qos_profiles paths are fine, though I would suggest allowing optional query parameters on GET /qos_profiles itself to allow filtering. See the Design Guidelines for details on how to do this. Even better, if a full set of QoS parameters are passed as query parameters, then the API could return the "best fit" profile even if the exact parameters themselves do not correspond to an existing profile.

There are some errors in your suggested API definition. The swagger editor (https://editor.swagger.io/) will help you find them.

[jlurien]

This is very interesting debate, but as suggested above, it would be better to open first some issues to discuss the requirements and use cases, and then we can decide how to take it to the API.

IMO, there are 2 different topics that have been discussed in the thread that it is convenient to differentiate:

• QoS profiling and discovery, so each provider could eventually offer a different set of profiles, which do not have to be the current four. And associated mechanisms so consumers can be informed of the characteristics of the profiles.

• The ability to request a customized profile, with a fine grain of what the consumer wants. This can be interesting from the point of view of the consumer, but it must be combined with the capacities and interests of the network provided, as Eric commented.

[RandyLevensalor]

Closing this PR and will open new issues to discuss it.