Providing developers with alternate to QoS profile

[maheshc01]

Problem description
Today QoD API requires the application developer to pass in qosProfile as one of the mandatory params for creating POST /sessions. as described in the yaml this qos profile can vary from each operators which puts the burden on the developers to keep themselves updated on all the qos profiles supported by each operators across the world.
I hope we all can see the problem with this. It goes against the basic CAMARA principle of requiring the APIs to be developer friendly.

Solution
Rather than the developer having to learn all the qos profile options across the different operators and figure out which suits best for their application it should be the operator's responsibility to figure out which is the best qos profile they need to apply based on the application needs as well as additional context based on user subscription data.
Proposal is to adopt the concept of application profiles as defined in connectivity insights (which is already modeled to work closely with QoD API) via which the application developers define what they expect in terms of network performance and which calling the QoD /sessions API, they can pass on application profile id as an alternate to qos profile and the operator will take on the responsibility to identify the best qos profile and create the session based on that.

Additional context
there is an open issue in commonalities on the concept of application Id. Discussions here and connectivity insights can be used as references to be adopted in commonalities.
another advantage with this proposal is that it puts us on the path of decoupling QCI based implantation to support that API request and in further the same spec can be used to provide network slice based quality on demand.

[jlurien]

Hi @maheshc01,

The topic is interesting. Looking also into the PR, it seems like the proposal is about giving developers/applications the ability to create their own adhoc profiles, more than figuring out which of the available QoS Profiles are closer to their needs. I'm not very familiar with Connectivity Insights API, but I see that they model a policyId instead of the applicationProfileId you are proposing in the PR, are they equivalent?

To me they are 2 different requirements:

• To figure out what is the best available QoS Profile, among the available ones. For this, we could enhance the qos-profiles API with some complex filters based on the profiles characteristics. But that only would make sense if implementations had lots of profiles with detailed characteristics.

• To allow applications to create adhoc profiles which some required characteristics. For this, the complex part would be in the negotiation phase, when the implementation has to assure that the request can be fulfilled, which probably has to take into account many variables, such as device, requested characteristics, time interval, etc.. Also it is not clear how developers would know and negotiate/accept concepts like pricing for the request, SLAs, etc

Could you confirm if your proposal is more about the second point? Thanks

[hdamker]

Hi @maheshc01,

My understanding of your proposal is that your requirement is the first of the two in the previous comment: that the operator is figuring out what is the best fitting QoS profile for the actual device and the requested application profile, among the available ones, and enables that for the defined flow.

Said this, I see the value of "application-profiles" as a counterpart to "qos-profiles". The goal of CAMARA is to provide intent based APIs, therefore I'm in favour of the aim of your proposal. But there need also be predictability of the behaviour and cost for the API consumers and here I see the challenge. Definitely it makes sense to discuss the synergies between ConnectInsights and QoD.

Challenges I see if the selection of the actual QoS profile in one step directly when creating the QoS session:

• A QoS Profile is a service description which on the next level is part of a product, which comes with a price. Calling the QoD API without knowing which profile will be actually selected doesn't allow the API consumer to know the cost of this call upfront. For example there might be a profile which fulfils the defined requirements, but it comes with a high cost (due to extensive resource reservations) which is beyond what the application use case covers.
• As the application profiles can be defined freely, there is a good chance that there is no matching QoS profile which the network can provide to match the application profile or only one which is reserved for special services for which the API consumer is not subscribed. In both cases the creation of the QoD session would fail.

Therefore we have designed until now a two-step approach: providing with qos-profiles an API which allows to discover the available QoS profiles. This API can be enhanced, see for example #147. Combining it with your proposal there could be an endpoint which takes an application profile as input and returns the best matching QoS profile (if any available).

Another option could be that already the ConnectivityInsights API returns in case the requirements are beyond the standard profile one or multiple proposals of QoS Profiles which then can be directly used to create a session with the qualitiy-on-demand API.

[jlurien]

Another option could be that already the ConnectivityInsights API returns in case the requirements are beyond the standard profile one or multiple proposals of QoS Profiles which then can be directly used to create a session with the qualitiy-on-demand API.

This approach would fit quite well with the current API. If Connectivity Insights API, after evaluating the requirements, determines that certain available QoS profile fulfills those requirements, it may return it as suggestions. Developers can then examine those QoS profiles and decide to use QoD APIs. The part about pricing, SLA, etc is out of the scope of CAMARA, so probably another APIs are needed for that.

[maheshc01]

@jlurien In connectivity insights what started out as policy id which defined application needs from a network performance perspective went through its fair share of updates post multiple discussions to be renamed as application-profile to make it more developer friendly.

Application Profile takes inputs from app developers on what is the minimum values for each network performance KPI which the application is tolerant to.it doesn't take input for upper bound values.
For example a web conferencing app can say that it requires a minimum of 2 mbps uplink and minimum of 5 mbps downlink. If the network is not able to meet these requirements from any of the available QoS profiles then the API should respond saying the required quality cannot be provided so that the application can plan for contingencies on their side. As the application profile is intended to take the minimum values i think we should be good to allow it and use them for decision making.
Another example of application profile is in edge discovery service(EDS) , where via the application profile the app developer can share the minimum latency required by the app to ensure their end users have a good experience. and based on the network performance data, if there is one or more edge clouds that is able to provide the latency then EDS would return the list but in case none of the edge clouds are able to meet the latency requirement then we need to be transparent and tell that the latency requirement cannot be met so that the app developer can plan accordingly.
With the examples above i am highlighting the need for application profile in multiple sub projects and not limited to just connectivity insights and quality on demand.

Regarding the concept of using application profile to present the best set of QoS profiles to the developer. my opinion is not all subscriber will have entitlement to all qos profiles. it would be frustrating to developers to again receive failed responses based on subscriber entitlement.
Also going back to the point i have made in the additional context while creating this issue. App developers shouldn't have to care about what qos profile(telco terminology) to use or how the network operators are providing the quality on demand. Its for the operators to figure out the how part (specific QCI mapping or via NW slice mapping) and confirm if they can meet the app requirements or not.

Pricing is more complex topic but also have different approaches which the business groups can figure out.

[RandyLevensalor]

Also going back to the point i have made in the additional context while creating this issue. App developers shouldn't have to care about what qos profile(telco terminology) to use or how the network operators are providing the quality on demand. Its for the operators to figure out the how part (specific QCI mapping or via NW slice mapping) and confirm if they can meet the app requirements or not.

@maheshc01 We tried out best to make these more generically networking centric and not just telco focused. We may not have entirely hit the mark, but an attempt was made. QoS Profiles actually helped us add support for fixed line networks, in addition to mobile network. These could also apply to non-terrestrial networks (aka satellite based internet) as well, but I don't think that anyone has tested that.

Not every network will have the capabilities and capacity to support every application profile, and others will be able to support capabilities beyond and individual application. QoD can apply to all traffic to/from a device, where this device could be a gateway on a cable or fiber network. We don't want to limit the capabilities.

As @hdamker mentioned above, we do have issue #147 opened. This issue has been open since QoS profiles were introduced, since the idea behind profiles was to provide a mechanism find profiles which meet the requirements for a given application or use case.

My suggestion is that we start by extending the QoS Profile to add a query mechanism to identify profiles that can meet the application requirements. Either through profile querying based on a set of attributes or if there is a sufficient standard around the application ids. While we are getting late into the 0.11 release, if we get consensus quickly it could make this release.

Longer term, we could look to extend the session create to allow for the QoS profile query or minimum criteria to be included instead of the QoS profile ID. I suspect that this will be a much more involved discussion since it has far reaching implication when the developer doesn't know which profile they will use when they make the query.

The current process isn't that different from identifying the type of compute resources when spinning up cloud compute. Even between regions within a single cloud provider, there are different classes of machines available.