Proposal to reduce QoSProfile_Mapping_Table.md back to one example

[hdamker]

There was a discussion about the changes in QoSProfile_Mapping_Table.md in our last call, which were at that point of time already merged. The discussion was mainly about second example table which maps the same 4 QoS profiles from the current API spec to very different QoS characteristics.

The two main points received also in bilateral discussions were:

• A QoS profile label should map in principle to the same connectivity characteristics across different communication service provider implementations. That does not exclude that service levels, conditions and restrictions will be still subject to an agreement between API invoker and the communication service provider. In this sense the table can only be an example and that’s expressed, I suggest.
• There were several voices who asked not to use the same profile labels for “non-guaranteed” QoS profiles and for “guaranteed” (in the text: “statistically assured”) QoS profiles.

One proposal was to use different labels for the QoS profiles described in the second table. I suggest that it is too early now to extend already the list of QoS Profile labels (we rather have implementations for the ones defined in v0.8.0).

The proposal would be therefore to leave it for now with the four QoS Profile labels defined in v0.8.0 of the API definition, as it is too early to agree already on additional QoS profile labels. That would mean also to restrict QoSProfile_Mapping_Table.md again to one (the first) example table. Additional QoS Profile labels and it’s exemplary mapping can then be added together with following versions of the API.

Please reply to the discussion on the mailing list, comment here or on the related PR.

[patrice-conil]

Fine by me.

[ToshiWakayama-KDDI]

Thank you very much, Herbert, for considering issues I raised during our 18th Nov. meeting.

The proposal to reduce the table back to one example for v0.8.0 is fine with me.

For following versions of the API, I have two comments as follows. Both are basically reiteration of my 18th Nov. comments:

1) For CAMARA's concept 'One common API', there should be some kind of basic mapping table, by which a QoS profile label is to be mapped to the same connectivity characteristics across different communication service provider implementations to a certain extent. We should keep this point open for following versions of the API.

2) Some members (including me) are interested in "guaranteed" (or "statistically assured") QoS profiles, so, we should start discussion on additional QoS Profile labels and its exemplary mapping for following versions of the API soon.

Thanks.

[jlurien]

Thank you Herbert,

We are fine with the simplification to one table as it is less confusing. However, we have some concerns about the given numbers for S, M, and L. In particular for the highest one, QOS_L, it may be too low. In our implementation, we are considering initially for this level, a non-guaranteed priorization without a higher limit.

We are still working together with marketing to identify the services and its characteristics. From there, we should be clearer about what to push, but for now this should be taken as a first approximation.