Re: [tsvwg] updated version of QCI to Diffserv draft

[<[e-mail]>]

Hi Jerome,

I think we agree on many issues. One aspect I always feel uncomfortable with is an orientation of a single DSCPs to applications.

An assignment of PHBs to applications seems to be a useful activity. If the core idea of assigning a DSCP is transport free of congestion, then the “leased line” DSCP/PHB will do in the backbone (a tunnel or VPN may be useful, if many DSCPs/QCIs are supposed to be used at the access). If traffic is marked by 20+ DSCPs and PHBs or QCIs to enable it to compete for a frequently underdimensioned resource – that’s not typical network or service provider engineering, I think. Diffserv plays a role in the network I work upon, if rare events result in congestion. When these rare events occur, the most likely result is, that a single PHB/DSCP discards packets.

Regards,

Ruediger

Von: Jerome Henry (jerhenry) <[e-mail]>
Gesendet: Mittwoch, 5. Juni 2019 16:15
An: Geib, Rüdiger <[e-mail]>; [e-mail]
Cc: [e-mail]
Betreff: Re: [tsvwg] updated version of QCI to Diffserv draft

Thank you Rudiger, and 100% agree.
I’ll be in Montreal and will gladly exchange with Sudir and whomever else is interested in this topic. I also have a meeting planned with Gonzalo Camarillo (3GPP liaison).

In short, we are seeing this issue and want to solve it. As Rudiger rightly points out, our goal is by no mean to impose a mapping within any network operator’s network (SP or enterprise). Within an AS, the admin has all the authority to decide on what service to provide, by what mean, and to implement whatever mapping between technologies they deem appropriate. When the AS is a SP network, internal decisions drive QCI/QFI and DSCP policies, for each device and app, and we have no say or opinion on how this choice is done.

Our issue is on the other side. We implement features with handheld partners and network applications. We see issues when traffic between both ends traverses through diffserv and 3GPP domains (split paths). We could implement a proprietary mapping solution, but we also think that others start to, or will soon, face the same issues, and community wisdom is likely better than one party forcing a solution to the world.
Maybe 3GPP would be interested in providing such mapping, I am not sure, because the exchanges we have had so far with 3GPP actors indicate a lack of interest to define mapping that applies outside of the 3GPP domain. However, I’ll gladly exchange with Gonzalo on this point, in case we could obtain an official position. I note that the STA/UE is on one side of the 3GPP domain, and the application server is also on the other side of the 3GPP domain. 3GPP is simply traversed. I also note that TS 27.203 allows the UE to mark DSCP, and the network can carry, ignore or override the value. It would be helpful for the UE/STA and app server to know what to expect on the 3GPP leg, and mark the diffserv leg accordingly. Any mean to accomplish this goal is a good solution.

Looking forward to exchanging more.

Best

Jerome


From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, June 5, 2019 at 2:57 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Jerome Henry (jerhenry)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: AW: [tsvwg] updated version of QCI to Diffserv draft

Hi Subir, hi Jerome,

a good way forward may be to meet personally, and it may also be useful to involve the chairs. Unfortunately, I’m not able to attend IETF 105 (and I likely will not participate remotely).

My preferred state for the document is informational, if it proceeds. I also think that unless 3GPP and the carriers active there express a need for such a standard, the work is pointless. 5G allows for enterprises to operate own 5G networks. If this is driving the draft, the document should express that quite clearly in its scope and introduction.

Regards,

Rüdiger

Von: tsvwg <[e-mail]<mailto:[e-mail]>> Im Auftrag von Subir Das
Gesendet: Dienstag, 4. Juni 2019 15:53
An: Jerome Henry (jerhenry) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Betreff: Re: [tsvwg] updated version of QCI to Diffserv draft

Hi Jerome,
Thanks and sorry for my late response. I am afraid that this thread is getting bigger..
Subir

- What is the motivation of this draft in IETF when 3GPP is the responsible organization to create such a mapping document?

[j] This is a critical element. I have no awareness that 3GPP’s charter includes creating QCIs/QFIs to Diffserv mapping. Would you mind pointing me to their reference mapping document, if it exists?
As far as I know, 3GPP is concerned with the 3GPP domain, which does not include Diffserv (please see section 2.1 of the draft where we expand a bit more on this point). They describe the QCIs/QFIs and their intent. When references are made to DSCP (for example in 29212-e30 4b.5.14, but a few others also can illustrate the same approach), they refer to IETF. So I do not see 3GPP building such a document, or even making a request for such document (as, again, Diffserv is outside of their domain), just like they would not define or request a QCI to 802.11UP mapping (for the same reasons). I note that others (e.g. NGMN) have attempted such mapping before (and their work can be leveraged, although it needs a lot of updates), which also seems to indicate the 3GPP does not perform such mapping definition. Now a key question is ‘who should define such mapping, if 3GPP does not?’, which leads to your second comment.

SD> Here is my understanding. If 3GPP requires such an explicit mapping document, they will create a separate work item. Since 3GPP has active liaison with IETF, one would expect that the request will come from 3GPP if they would like the IETF to do the work.

- Who will be using these recommendations if such a document exists in IETF?

[j] Such mapping provides possible recommendations between different domains, and actors concerned with such traversing traffic have interests in having a common set of understanding about the intent of each type of traffic and their relative requirements for differentiated service. For example, GSMA used an early mapping scheme. However, their scheme dates from the days where 4 main QCIs were defined, and they are left with immense gaps. Yet GSMA has no statutory expertise in Diffserv (they do have expertise in 3GPP domain), this may explain why the mapping document has not been updated.

In my view, IETF is another organization that considers such traversing traffic. We also know that, with the increase of LTE/5G of data traffic, and the apparition of load balancing schemes between radio technologies (e.g. WiFi and LTE), the scenario where coexistence of application which intent is described within 3GPP and applications which intent has been described by various RFCs will increase. Without concerted view on what these intents mean, we are guaranteed to face service quality disruption, simply because no one bother reconciling both domains vies (and simply pointing the problem back at the other side). As the IETF has a tradition of expertise in this domain, I feel that it is the best organization to understand traffic intents and compare/translate them into the models that generations of traffic experts have refined.
As such, I see any actor facing such traversal traffic in need of such a document.
SD> I am not against such a document as long as there is a use/need for it. You mentioned about ‘service quality’ disruption. Can you share any such study on the list or provide some pointers? Our experience is that if operators have multiple domains, they have policies/SLAs that varies and it is very difficult to create such a document that works across majority of the scenarios. IMO, this is possibly the reason 3GPP kept it as example mappings and left it to decide the operators as their policies.  You also referred GSMA as potential stakeholder. Is there a request from them?

- What is the intent of this document: Informational or Experimental or Standards Track?
[j] My vision is Informational, but I would like the group’s input and view on this point.
SD> Good to know. I also hope that other members of the group will chime in and express their opinion. I would be particularly interested in hearing from 3GPP-member companies and operators.

You cited 3GPP TS 23.203 QCIs mapping table as defined in TS 23.303, but I assume you understand that these QCIs to services mappings are examples only (as clearly mentioned in the service column). The correct mapping is done by the network operators based on their use cases / services and it does follow the IETF guidance on QoS treatment.  In some use cases, these mappings are not implemented simply based on QCIs, it uses other parameters such as ARP (Allocation and Retention Priority).  Therefore, it makes sense to keep them as examples as 3GPP specifies in their document since these mappings are done based on operator’s policy and should not be a recommendation.

[j] thank you for making this assumption. I am not sure that 23.303 defines QCIs, now it is my turn to assume that you meant another document, possibly 23.107. These documents define QCIs, and for each defined QCI typical characteristics of the associated traffic are provided. Then, examples of traffic that would match such requirements are provided. As such, yes, the example services are ’example’ services. In the end, each network operator is empowered to decide what structure makes sense in their network..
This logic does not seem to be vastly different from what, for example, RFC 4594 does, where categories are defined, each with a set of characteristics matching a differentiated service intent, and applications that could fit this profile are named. But in the end, just like our draft section 3 states, the mappings allow for a transcription of intents from one domain to the other, but “these mapping recommendations are not expected to fit every last deployment model, and as such MAY be overridden by network administrators, as needed.” The case of ARP is typical, and there are also countless scenarios in the Diffserv domain where an application marking gets changed for reasons that macth client type or other considerations.
SD> As you have rightly pointed out, “these mapping recommendations are not expected to fit every last deployment model, and as such MAY be overridden by network administrators, as needed.” Now the question is:  what are the 3GPP deployment models that would require such mappings?

Moreover, the draft has several issues. For example, it  proposes to put all dialer/conversational voice in a single category with DSCP value 44 (101100)/Voice Admit without differentiating the normal voice signaling and media with ETS (Emergency Telecommunication Service) voice signaling and media.  This conflicts with ATIS-1000063 that specifies DSCP 46 (101110)/EF for normal voice signaling and media and DSCP 44 (101100)/Voice Admit for ETS signaling and media. It also conflicts with RFC 5865, which requires differentiation between traffic associated with capacity admitted vs. non-capacity admitted IP telephony sessions.
[j] This may not be entirely accurate, and I would be very happy if you contributed to make this point clearer.  I would encourage you read again section 5.4 for example. As for QCI 1, it is admitted, so it seems to match the definition you suggest above, and therefore the mapping you suggest, 44. Glad to exchange more on this topic.

SD> Yes we can discuss this and I understand that you will be willing to address the issues but let us see if there is an agreement in the group to proceed with such a document. As I mentioned, unless the request comes from 3GPP, there will be not much use of such a document and will consume WG‘s time.

IMO, IETF community SHOULD NOT  create a document that recommends the QCI-to-DSCP mappings unless 3GPP asks for it via a liaison.

[j] I would be interested to understand better your reasoning here. First, I am not sure I can reconcile this comment with the view expressed at the beginning (that 3GPP was in charge of establishing such document… if they are, why would they ask another organization?). But also, when a mapping between two domains needs to be defined, we can either rely on one organization working above both domains to trigger the mapping exercise (but this is not the case here), or one organization can take the initiative. In this case, IETF has the expertise and a tradition of leading for such mapping. We saw this for 802.11 (RFC 8325) where IETF did not wait for IEEE 802.11 to ask via a liaison. We also saw this with RFC 7561, that also proposes a mapping between QCIs and Diffserv values (but with the goal of reaching to 802.11 mapping). So it seems to me that there is space and purpose in the IETF to start this conversation and suggest a mapping. If, as you state 3GPP is already doing it, then of course the initiative was already taken and all is well.

SD> My reasoning was simple. The abstract of the document says:
“This document specifies a set of 3rd Generation Partnership Project (3GPP) Quality of Service (QoS) Class Identifiers (QCI) to Differentiated Services Code Point (DSCP) mappings, to reconcile the marking recommendations offered by the 3GPP with the recommendations offered by the IETF, so as to maintain a consistent QoS treatment between cellular networks and the Internet.”
Therefore, if IETF does this work the request should come from 3GPP.

We can also, as a group, decide to just point the finger to some organization (insert name here, e.g. 3GPP or GSMA) and simply state that they ‘should be the one doing it’, but this is not really solving anything in my view, just pushing the problem to the future until it comes back. So I would be interested to better understand your view here: why ‘shouldn’t we’?

SD> Are you attending IETF-105 in Montreal?  I would be happy to discuss with you more on this and with others.

On Tue, May 28, 2019 at 3:25 PM Jerome Henry (jerhenry) <[e-mail]<mailto:[e-mail]>> wrote:
Hello Subir,

Thanks a lot for reaching out again and for your comment below. We might have different views on this topic, so it is important to exchange.

Going through your list one item at a time:

- What is the motivation of this draft in IETF when 3GPP is the responsible organization to create such a mapping document?
[j] This is a critical element. I have no awareness that 3GPP’s charter includes creating QCIs/QFIs to Diffserv mapping.. Would you mind pointing me to their reference mapping document, if it exists?
As far as I know, 3GPP is concerned with the 3GPP domain, which does not include Diffserv (please see section 2.1 of the draft where we expand a bit more on this point). They describe the QCIs/QFIs and their intent. When references are made to DSCP (for example in 29212-e30 4b.5.14, but a few others also can illustrate the same approach), they refer to IETF. So I do not see 3GPP building such a document, or even making a request for such document (as, again, Diffserv is outside of their domain), just like they would not define or request a QCI to 802.11UP mapping (for the same reasons). I note that others (e.g. NGMN) have attempted such mapping before (and their work can be leveraged, although it needs a lot of updates), which also seems to indicate the 3GPP does not perform such mapping definition. Now a key question is ‘who should define such mapping, if 3GPP does not?’, which leads to your second comment.


- Who will be using these recommendations if such a document exists in IETF?
[j] Such mapping provides possible recommendations between different domains, and actors concerned with such traversing traffic have interests in having a common set of understanding about the intent of each type of traffic and their relative requirements for differentiated service. For example, GSMA used an early mapping scheme. However, their scheme dates from the days where 4 main QCIs were defined, and they are left with immense gaps. Yet GSMA has no statutory expertise in Diffserv (they do have expertise in 3GPP domain), this may explain why the mapping document has not been updated.
In my view, IETF is another organization that considers such traversing traffic. We also know that, with the increase of LTE/5G of data traffic, and the apparition of load balancing schemes between radio technologies (e.g. WiFi and LTE), the scenario where coexistence of application which intent is described within 3GPP and applications which intent has been described by various RFCs will increase. Without concerted view on what these intents mean, we are guaranteed to face service quality disruption, simply because no one bother reconciling both domains vies (and simply pointing the problem back at the other side). As the IETF has a tradition of expertise in this domain, I feel that it is the best organization to understand traffic intents and compare/translate them into the models that generations of traffic experts have refined.
As such, I see any actor facing such traversal traffic in need of such a document.


- What is the intent of this document: Informational or Experimental or Standards Track?
[j] My vision is Informational, but I would like the group’s input and view on this point.


You cited 3GPP TS 23.203 QCIs mapping table as defined in TS 23.303, but I assume you understand that these QCIs to services mappings are examples only (as clearly mentioned in the service column). The correct mapping is done by the network operators based on their use cases / services and it does follow the IETF guidance on QoS treatment.  In some use cases, these mappings are not implemented simply based on QCIs, it uses other parameters such as ARP (Allocation and Retention Priority).  Therefore, it makes sense to keep them as examples as 3GPP specifies in their document since these mappings are done based on operator’s policy and should not be a recommendation.
[j] thank you for making this assumption. I am not sure that 23.303 defines QCIs, now it is my turn to assume that you meant another document, possibly 23.107. These documents define QCIs, and for each defined QCI typical characteristics of the associated traffic are provided. Then, examples of traffic that would match such requirements are provided. As such, yes, the example services are ’example’ services. In the end, each network operator is empowered to decide what structure makes sense in their network.
This logic does not seem to be vastly different from what, for example, RFC 4594 does, where categories are defined, each with a set of characteristics matching a differentiated service intent, and applications that could fit this profile are named. But in the end, just like our draft section 3 states, the mappings allow for a transcription of intents from one domain to the other, but “these mapping recommendations are not expected to fit every last deployment model, and as such MAY be overridden by network administrators, as needed.” The case of ARP is typical, and there are also countless scenarios in the Diffserv domain where an application marking gets changed for reasons that macth client type or other considerations.


Moreover, the draft has several issues. For example, it  proposes to put all dialer/conversational voice in a single category with DSCP value 44 (101100)/Voice Admit without differentiating the normal voice signaling and media with ETS (Emergency Telecommunication Service) voice signaling and media.  This conflicts with ATIS-1000063 that specifies DSCP 46 (101110)/EF for normal voice signaling and media and DSCP 44 (101100)/Voice Admit for ETS signaling and media. It also conflicts with RFC 5865, which requires differentiation between traffic associated with capacity admitted vs. non-capacity admitted IP telephony sessions.
[j] This may not be entirely accurate, and I would be very happy if you contributed to make this point clearer.  I would encourage you read again section 5.4 for example. As for QCI 1, it is admitted, so it seems to match the definition you suggest above, and therefore the mapping you suggest, 44. Glad to exchange more on this topic.


IMO, IETF community SHOULD NOT  create a document that recommends the QCI-to-DSCP mappings unless 3GPP asks for it via a liaison.
[j] I would be interested to understand better your reasoning here. First, I am not sure I can reconcile this comment with the view expressed at the beginning (that 3GPP was in charge of establishing such document… if they are, why would they ask another organization?). But also, when a mapping between two domains needs to be defined, we can either rely on one organization working above both domains to trigger the mapping exercise (but this is not the case here), or one organization can take the initiative. In this case, IETF has the expertise and a tradition of leading for such mapping. We saw this for 802.11 (RFC 8325) where IETF did not wait for IEEE 802.11 to ask via a liaison. We also saw this with RFC 7561, that also proposes a mapping between QCIs and Diffserv values (but with the goal of reaching to 802.11 mapping).. So it seems to me that there is space and purpose in the IETF to start this conversation and suggest a mapping. If, as you state 3GPP is already doing it, then of course the initiative was already taken and all is well.
We can also, as a group, decide to just point the finger to some organization (insert name here, e.g. 3GPP or GSMA) and simply state that they ‘should be the one doing it’, but this is not really solving anything in my view, just pushing the problem to the future until it comes back. So I would be interested to better understand your view here: why ‘shouldn’t we’?

Best

Jerome




From: Subir Das <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, May 28, 2019 at 12:08 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "Jerome Henry (jerhenry)" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [tsvwg] updated version of QCI to Diffserv draft


Hello Jerome,

 I read your ver-01 draft and have the following questions and comments.

- What is the motivation of this draft in IETF when 3GPP is the responsible organization to create such a mapping document?

- Who will be using these recommendations if such a document exists in IETF?

- What is the intent of this document: Informational or Experimental or Standards Track?



You cited 3GPP TS 23.203 QCIs mapping table as defined in TS 23.303, but I assume you understand that these QCIs to services mappings are examples only (as clearly mentioned in the service column). The correct mapping is done by the network operators based on their use cases / services and it does follow the IETF guidance on QoS treatment.  In some use cases, these mappings are not implemented simply based on QCIs, it uses other parameters such as ARP (Allocation and Retention Priority).  Therefore, it makes sense to keep them as examples as 3GPP specifies in their document since these mappings are done based on operator’s policy and should not be a recommendation.



Moreover, the draft has several issues. For example, it  proposes to put all dialer/conversational voice in a single category with DSCP value 44 (101100)/Voice Admit without differentiating the normal voice signaling and media with ETS (Emergency Telecommunication Service) voice signaling and media.  This conflicts with ATIS-1000063 that specifies DSCP 46 (101110)/EF for normal voice signaling and media and DSCP 44 (101100)/Voice Admit for ETS signaling and media. It also conflicts with RFC 5865, which requires differentiation between traffic associated with capacity admitted vs. non-capacity admitted IP telephony sessions.



IMO, IETF community SHOULD NOT  create a document that recommends the QCI-to-DSCP mappings unless 3GPP asks for it via a liaison.



Thanks,

-Subir


Re: [tsvwg] updated version of QCI to Diffserv draft

"Jerome Henry (jerhenry)" <[e-mail]<mailto:[e-mail]>> Mon, 15 April 2019 17:07 UTCShow header<https://mailarchive.ietf.org/arch/browse/tsvwg/?q=Jerome>

Dear all,



We submitted an update to the Diffserv to QCI mapping document. As part of the 5G finalization, then 3GPP added a few  QCIs, and we updated the draft accordingly.



We are looking forward to input and feedback, through the mailer and in Montreal. Our ambition is to (eventually) get this draft to a consensus state where we can share it with GSMA, who documents how QCI markings can be translated to other values when exchanged through other domains (e.g. Diffserv) between carriers.



Thanks!



Jerome





https://datatracker.ietf.org/doc/draft-henry-tsvwg-diffserv-to-qci/