The application server schema supports subnets, so you can already specify 0.0.0.0/0 or ::/0 if you want the profile to apply to any flow to/from the device.

DSCP values can be implicitly associated with a given QoS profile, in the same way that 3GPP QCI/5QI values can be implicitly associated with a given QoS profile. The API consumer should not have to select more than the profile name from the available options to specify the QoS they would like. CAMARA APIs are intended to be used by developers who do not have the first clue about telco networking, but do understand their throughput, latency and jitter requirements.

If you think it is important that the typical QoD API consumer knows exactly what DSCP they will get for the fixed network part of the route, and that cannot be captured in either the profile name or description, then it could be considered to add this as an additional optional property of a QoS profile.

But I am strongly against giving API consumers the ability to "pick and mix" QoS profile parameters so as to build their own custom profile.

The application server schema supports subnets, so you can already specify 0.0.0.0/0 or ::/0 if you want the profile to apply to any flow to/from the device.

Excellent. That works.

CAMARA APIs are intended to be used by developers who do not have the first clue about telco networking, but do understand their throughput, latency and jitter requirements.

DSCP and L4S are not limited to the telecommunications space. To date, all of the application developers that I've spoken with are very familiar with marking using DSCP since it also helps with Wi-Fi networks. The Wi-Fi improvements are arguably more impactful than the access networks ones for wireline networks.

I've spoken with gaming, streaming application and other related developers on this subject.

The primary downside that we've encountered with DSCP values is that they are frequently bleached at different points in the network.

QoD API consumer knows exactly what DSCP they will get for the fixed network part of the route, and that cannot be captured in either the profile name or description, then it could be considered to add this as an additional optional property of a QoS profile.

This approach would work. It overloads functionality the QoS profile more than I like, but it would solve this in a way to enable server providers flexibility.

Does anyone else have thoughts on this?

I agree with @eric-murray's comment. DSCP is implicitly a part of QoS profile that captures the application intent. Additionally, operators have their own DSCP schema implementation which could be quite different than the standards. Also, it would be confusing to the developers who may not have deep knowledge of the protocol.

I appreciate that not all networks will have support for DSCP header markings for traffic classification. However, I don't think that is a reason to not include it in the session creation, since this includes all of the information necessarily for identifying the traffic which will be managed by the QoD flow.

Some of the device attributes in the create session schema are not supported by wireline networks. There is a president for including attributes in the create session schema which are not supported by all underly networks.

• phoneNumber
• networkAccessIdentifier

While collecting feedback on this topic, I've found that explaining why the DSCP would be in the QoS Profile to be quite confusing. Since the DSCP is a packet marking and not an actual QoS attribute.

I would like to modify the proposal to add a new optional property diffServe to the createSession schema.

If the diffServe classification is requested, but is not supported, then the server can return 400 with an appropriate error message.

The alternate approach is to add a diffServe or preserveDiffServe property to the QoSProfile. This has the advantage of allowing the operator to specify if they support this. Unlike the other attribute in the QoS Profile schema, this is a packet marking and not an attribute of the actual quality of service. This could be used to preserve the diffServe packet markings, since they are frequently bleach by default. Since this isn't a part of the session, it would be confusing to use a specific attribute in the QoS Profile identifying the traffic. But other elements and mechanisms in the network would have access to these fields.

Hi @RandyLevensalor

I think including dscp in the QoS profile is no more confusing than including priority. Neither are QoS metrics in themselves, but rather are technical means to achieving specified QoS metrics, particularly latency. If end users only cared about the QoS of their traffic, they would not care what priority their traffic is given. Indeed, they should not care.

But we recognise that there are end users who understand such details and would like to know or even specify how their traffic is managed. As network operators, this works to our advantage because setting priority is one thing that we can control with absolute certainty. If that doesn't give the end user the QoS that they expected (because other traffic has an even higher priority), well, we still gave them what they asked for, so can charge them anyway.

Can you clarify the following points about your proposal:

• Why can the existing priority field of the QoS profile not be used for this? It's an integer, so can easily be interpreted as a DSCP value. How will fixed networks otherwise use the priority field?
• If the API consumer directly specifies a diffServe value when creating a QoS session, what are the allowed values? Is it boolean (diffServe will / will not be preserved), or are they actually specifying a required DSCP value, or something more?
• If diffServe is a DSCP value, what does the network accepting this actually mean? Does it mean that any traffic accepted by the network that has the DSCP field set to that value is guaranteed to leave the network with that value preserved? Or does it mean more than that? What exactly is the API consumer expecting if the network accepts their diffServe requirement?

Why can the existing priority field of the QoS profile not be used for this? It's an integer, so can easily be interpreted as a DSCP value. How will fixed networks otherwise use the priority field?

Priority is a QoS setting at the MAC layer based on a policy in the access network. DSCP and DiffServe is an L3 / IP header that can be set by the application. It's possible to create a policy to set any priority for a given DSCP value across all access network types.

There are conventions to map different DSCP values to specific priorities. However, there is no guarantee that the a specific DSCP value be mapped to a given priority. Allowing developers to map traffic with a DSCP value to specific priority is one of the primary goals of this enhancement.

Priority is a QoS setting at the MAC layer based on a policy in the access network.

I think that should be documented if that is the case for fixed networks, as my expectation would otherwise be that QoS profile parameters apply to the defined flow, which is a layer 3 flow between the two specified IP addresses.

Priority is a QoS setting at the MAC layer based on a policy in the access network.

I think that should be documented if that is the case for fixed networks, as my expectation would otherwise be that QoS profile parameters apply to the defined flow, which is a layer 3 flow between the two specified IP addresses.

I think that I wasn't clear. That flow is an L3 flow. However, none of the QoS attributes are defined in the L3 header. There is L3 priority field.

From QoD Call Feb 9th: Related to #243, also move to backlog until use cases are described.

Slides presented on November 15th.
qos-profile-l4s.pptx