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

[<[e-mail]>]

Hi Jerome,

to me, Subir hits an important point. Picking up his question, who will be using these [QCI to DiffServ mapping] recommendations, then my question is, who needs these mappings? Which existing network operation problem do these mappings solve?

Regards,

Ruediger


Von: tsvwg <[e-mail]> Im Auftrag von Jerome Henry (jerhenry)
Gesendet: Dienstag, 28. Mai 2019 21:25
An: Subir Das <[e-mail]>; [e-mail]
Betreff: Re: [tsvwg] updated version of QCI to Diffserv draft

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/