search

camaraproject / QualityOnDemand

Repository to describe, develop, document and test the QualityOnDemand API family
https://wiki.camaraproject.org/x/zwOeAQ
Apache License 2.0
42 stars 59 forks source link

QoD API specification version 0.8.0 #42

Closed akoshunyadi closed 1 year ago

akoshunyadi commented 2 years ago

Contribution of the QoD-API spec v0.8.0

It contains following changes based on v0.1.0:

  1. Two APIs (latency & throughput) combined to one, 0.8.0 replaces 0.1.0
  2. ueAddr (ipv4) changed to ueId (ipv4, ipv6, msisdn, externalid)
  3. asAddr (ipv4) changed to asId (ipv4, ipv6)
  4. Portspec with schema
  5. Protocol (in & out) removed
  6. QoS profiles renamed
  7. Basepath changed
  8. Some formal changes/fixes

The existing yaml-files for latency and throughput should be removed. The profile mapping file should be adjusted.

SyeddR commented 2 years ago

The new spec looks good to me. Couple of ques

  1. Are we expecting both ipv4 and ipv6 information to be provided in API? If only one type is required shall we use "anyof" in the spec? If both IPs are provided, is the expectation to create QoS for both ipv4 and ipv6 session?
  2. There is a TFT limit device (UE) can support number of flows. If we are allowing port ranges and ports that would easily reach TFT limit. Are we going to enforce restriction in the API or is it left to operator's implementation
eric-murray commented 2 years ago

Hi @SyeddR

The idea is that the API consumer provides what information they know about the UE and AS sufficient to set-up the required session. If they wanted the enhanced QoS to apply to both IPv4 and IPv6 connectivity, then they would need to provide both addresses, at least for the AS. For the UE, any one of the 4 specified identifiers can identify the UE itself, though I agree this may lead to ambiguity as to intentions.

For example, if the API consumer provides both IPv4 and IPv6 addresses for the AS, but only an IPv6 address for the UE, does that mean they want enhanced QoS for both IPv4 and IPv6 flows, and only provided the UE IPv6 address to allow the UE to be identified, or do they only want the enhanced QoS for the IPv6 flow (in which case, why provide the AS Ipv4 address)? I think a lot of details about behaviour will come down to individual operator implementations of the API, and we cannot expect consistent behaviour across different implementations for all possible parameter values.

This also applies to your second point about port ranges and, indeed, IP subnets. Some subnets allowed by the specification (setting 0.0.0.0/0 for both UE and AS for example) are clearly ridiculous and would always be rejected. But there will be a "grey area" where some operators will accept a configuration request and others will not. It will be hard to avoid such discrepancies given that operator networks are not homogeneous and each has its own limitations. This also make it hard to tie down the interface specification to only allow parameter values and ranges to be specified that can be accepted by all API implementations.