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

From: <[email-masked]>
Date: Mon, 3 Jun 2019 07:13:14 +0000

Hi Subir,

thanks, I agree to your conclusion.

Regards, Ruediger

Von: tsvwg <[email-masked]> Im Auftrag von Subir Das
Gesendet: Dienstag, 28. Mai 2019 18:10
An: [email-masked]
Betreff: 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?

[snip]

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)" <[email-masked]<mailto:[email-masked]>> 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/

---

From: <[email-masked]>
Date: Mon, 3 Jun 2019 07:26:46 +0000

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 <[email-masked]> Im Auftrag von Jerome Henry (jerhenry)
Gesendet: Dienstag, 28. Mai 2019 21:25
An: Subir Das <[email-masked]>; [email-masked]
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 <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 28, 2019 at 12:08 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Jerome Henry (jerhenry)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tsvwg] updated version of QCI to Diffserv draft

Hello Jerome,

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.

Thanks,

-Subir

Dear all,

Thanks!

Jerome

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Mon, 3 Jun 2019 21:21:42 +0000

Hi Ruediger,

Thanks a lot, this to me also is indeed the fundamental question (otherwise, what’s the point? 😊). In my world, the need appears as end devices start load-balancing (or splitting) traffic between an unlicensed link (e.g. Wi-Fi) and a licensed link (today, LTE). The WiFi (and wired LAN segments after, link, I’ll call it enterprise) can honor the UP/DSCP request from the client. But if the traffic on the LTE leg receives a QCI that is distant from the differentiated service received on the enterprise link, then service consistency issues appear at the node where traffic is recombined (multipath proxy router, application in the cloud or other). This may not be problematic in a world where traffic sensitive to delay and jitter is low volume and therefore sent to only one link (e.g. voice today), but becomes dramatically visible when sensitive traffic becomes high volume (e.g. VR).
So a first location where I see this need is on the end device. If traffic goes through QCI XYZ, the device’s best interest is to mark the enterprise leg accordingly. The second location where I see this need is at the intersection point between the SP and the Diffserv domain (we all know the current practice there today). In a world where high sensitivity traffic travels through both paths, default marking (up) is likely not the best long term strategy.
I would be very happy to provide more names and details in a verbal conversation. This is not an ‘old problem no one thought of solving’, but a problem we see emerging and that will become soon hurtful.

Glad to exchange more in Montreal.

Take care

Jerome

From: "[email-masked]" <[email-masked]>
Date: Monday, June 3, 2019 at 3:27 AM
To: "Jerome Henry (jerhenry)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: AW: [tsvwg] updated version of QCI to Diffserv draft

Hi Jerome,

Regards,

Ruediger

Hello Subir,

Best

Jerome

Hello Jerome,

Thanks,

-Subir

Dear all,

Thanks!

Jerome

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 3 Jun 2019 21:36:11 +0000

Jerome

The use of QCI is engineered by the operator, as is use of DSCP (Intra network)

Regards

Martin C. Dolly
Lead Member of Technical Staff
Government & Services Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

On Jun 3, 2019, at 5:23 PM, Jerome Henry (jerhenry) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ruediger,

Take care

Jerome

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 3, 2019 at 3:27 AM
To: "Jerome Henry (jerhenry)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: AW: [tsvwg] updated version of QCI to Diffserv draft

Hi Jerome,

Regards,

Ruediger

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

Hello Subir,

Best

Jerome

Hello Jerome,

Thanks,

-Subir

"Jerome Henry (jerhenry)" <[email-masked]<mailto:[email-masked]>> Mon, 15 April 2019 17:07 UTCShow header<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_tsvwg_-3Fq-3DJerome&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=5ZjsxFJPeIovzXrXq_diXrIWlYJWF38lXB8X_p06d5I&s=GAOkX4KdHM1VyY3kfdQHUnzof_e637m1HQa9rL22b_k&e=>

Dear all,

Thanks!

Jerome

https://datatracker.ietf.org/doc/draft-henry-tsvwg-diffserv-to-qci/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhenry-2Dtsvwg-2Ddiffserv-2Dto-2Dqci_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=5ZjsxFJPeIovzXrXq_diXrIWlYJWF38lXB8X_p06d5I&s=-YERY_l-L9Mzgyptexkk87GigQ8Q-1MK_hDRouys8-s&e=>

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Mon, 3 Jun 2019 22:06:23 +0000

Martin,

Yes, this is what I see it implemented too (but the issue is not there of course).

Jerome

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Monday, June 3, 2019 at 5:36 PM
To: "Jerome Henry (jerhenry)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [tsvwg] updated version of QCI to Diffserv draft

Jerome

Regards

Martin C. Dolly

Take care

Jerome

Hi Jerome,

Regards,

Ruediger

Hello Subir,

Best

Jerome

Hello Jerome,

Thanks,

-Subir

Dear all,

Thanks!

Jerome

---

From: <[email-masked]>
Date: Tue, 4 Jun 2019 06:23:01 +0000

Martin,

thanks, again, I fully agree.

Regards, Ruediger

Von: DOLLY, MARTIN C <[email-masked]>
Gesendet: Montag, 3. Juni 2019 23:36
An: Jerome Henry (jerhenry) <[email-masked]>
Cc: Geib, Rüdiger <[email-masked]>; [email-masked]
Betreff: Re: [tsvwg] updated version of QCI to Diffserv draft

Jerome

Regards

Martin C. Dolly

Take care

Jerome

Hi Jerome,

Regards,

Ruediger

Hello Subir,

Best

Jerome

Hello Jerome,

Thanks,

-Subir

Dear all,

Thanks!

Jerome

---

From: <[email-masked]>
Date: Tue, 4 Jun 2019 07:38:30 +0000

Hi Jerome,

the IP DSCP and QCI related policy management of the consumer mobile network, as well as the wire-line consumer access policy management reside in nodes further upstream in Deutsche Telekom’s network. DSCPs set by terminal devices are ignored in both domains (terminals are outside of the provider trust-boundary).

In your response below, you mention that your draft refers to enterprise networks. The scope of your draft doesn’t express that.

You mention that GSMA IR.34 relates to inititial DiffServ standards only. I wondered where the IR.34 Interactive class definition derived from. Either David Black or Al Morton pointed to a table of RFC5127, of which I copy in an extract below:

    -------------------------------------------
   |Treatment || MPLS ||  DSCP   |   DSCP      |
   |Aggregate || EXP  ||  name   |   value     |
    …..
   |==========++======++=========|=============|
   | Assured  || 010* ||  CS2    |   010000    |
   | Elastic  ||      ||  AF31   |   011010    |
   |          ||      ||  AF21   |   010010    |
  |          ||      ||  AF11   |   001010    |

I can’t discuss this. If GSMA took it from there, to me that’s an example of a bad interpretation of a standard written by another SDO and a good explanation, why liaising between SDOs is making sense, if something useful is to result.

That’s an important point to me: if there’s interest in linking standards of two SDOs, then these should liaise. I didn’t see any liaison between 3GPP and TSVWG on the topic yet.

Regards,

Ruediger

Von: Jerome Henry (jerhenry) <[email-masked]>
Gesendet: Montag, 3. Juni 2019 23:22
An: Geib, Rüdiger <[email-masked]>; [email-masked]
Betreff: Re: [tsvwg] updated version of QCI to Diffserv draft

Hi Ruediger,

Take care

Jerome

Hi Jerome,

Regards,

Ruediger

Hello Subir,

Best

Jerome

Hello Jerome,

Thanks,

-Subir

Dear all,

Thanks!

Jerome

---

From: Subir Das <[email-masked]>
Date: Tue, 4 Jun 2019 09:52:55 -0400

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.

[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) <[email-masked]>
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.
>
>
>
> - 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.
>
>
>
> [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.
>
> 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 <[email-masked]>
> *Date: *Tuesday, May 28, 2019 at 12:08 PM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"Jerome Henry (jerhenry)" <[email-masked]>
> *Subject: *Re: [tsvwg] updated version of QCI to Diffserv draft
>
>
>
> Hello Jerome,
>
> - What is the motivation of this draft in IETF when 3GPP is the
> responsible organization to create such a mapping document?
>
> 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
>
>
>
>
> "Jerome Henry (jerhenry)" <[email-masked]> Mon, 15 April 2019 17:07
> UTCShow header <https://mailarchive.ietf.org/arch/browse/tsvwg/?q=Jerome>
>
> Dear all,
>
>
>

---

From: <[email-masked]>
Date: Wed, 5 Jun 2019 06:56:46 +0000

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 <[email-masked]> Im Auftrag von Subir Das
Gesendet: Dienstag, 4. Juni 2019 15:53
An: Jerome Henry (jerhenry) <[email-masked]>
Cc: [email-masked]
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

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.

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.

[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?

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.

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.

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hello 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.

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

Hello Jerome,

Thanks,

-Subir

Dear all,

Thanks!

Jerome

---

From: Subir Das <[email-masked]>
Date: Wed, 5 Jun 2019 09:58:56 -0400

Hi Ruediger,
Thanks for your suggestions and I agree.

Regards,
_Subir

On Wed, Jun 5, 2019 at 2:57 AM <[email-masked]> wrote:

> 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 <[email-masked]> *Im Auftrag von *Subir Das
> *Gesendet:* Dienstag, 4. Juni 2019 15:53
> *An:* Jerome Henry (jerhenry) <[email-masked]>
> *Cc:* [email-masked]
> *Betreff:* Re: [tsvwg] updated version of QCI to Diffserv draft
>
>
>
> Hi Jerome,
>
> getting bigger..
> 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
> 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
> network..
> 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?
>
>
>
> “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.”
>
> On Tue, May 28, 2019 at 3:25 PM Jerome Henry (jerhenry) <
> [email-masked]> wrote:
>
> Hello Subir,
>
>
>
> includes creating QCIs/QFIs to Diffserv mapping.. Would you mind pointing
> me to their reference mapping document, if it exists?
>
> of reaching to 802.11 mapping).. So it seems to me that there is space and

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 5 Jun 2019 14:04:34 +0000

Me as well

Martin C. Dolly

On Jun 5, 2019, at 9:59 AM, Subir Das <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ruediger,

Regards,
_Subir

On Wed, Jun 5, 2019 at 2:57 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Subir, hi Jerome,

Regards,

Rüdiger

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

Hi Jerome,

[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..

Best

Jerome

Hello Jerome,

Thanks,

-Subir

"Jerome Henry (jerhenry)" <[email-masked]<mailto:[email-masked]>> Mon, 15 April 2019 17:07 UTCShow header<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf..org_arch_browse_tsvwg_-3Fq-3DJerome&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=EgZpeYsqheUhwWfnT1eG9RGlU8JupFIvHR5uQGd584M&s=HgsC2Amec5CwqFTsCWu0vgDS0rIlBxcGiTKfxxzu_2U&e=>

Dear all,

Thanks!

Jerome

https://datatracker.ietf.org/doc/draft-henry-tsvwg-diffserv-to-qci/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhenry-2Dtsvwg-2Ddiffserv-2Dto-2Dqci_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=EgZpeYsqheUhwWfnT1eG9RGlU8JupFIvHR5uQGd584M&s=E-smm8GQQrW-SLbXR2hIFitvbWD2Wi8jkL6AyVXxNWQ&e=>

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Wed, 5 Jun 2019 14:15:03 +0000

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: "[email-masked]" <[email-masked]>
Date: Wednesday, June 5, 2019 at 2:57 AM
To: "[email-masked]" <[email-masked]>, "Jerome Henry (jerhenry)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: AW: [tsvwg] updated version of QCI to Diffserv draft

Hi Subir, hi Jerome,

Regards,

Rüdiger

Hi Jerome,

Best

Jerome

Hello Jerome,

Thanks,

-Subir

Dear all,

Thanks!

Jerome

---

From: [email-masked]
Date: Wed, 5 Jun 2019 15:33:29 +0000

Good discussion.
I agree too.

Thanks!

[Verizon]<http://www.verizon.com/>

Julian Richards
Engineer
Priority Services Support Center

From: tsvwg [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
Sent: Wednesday, June 05, 2019 10:05 AM
To: Subir Das <[email-masked]>
Cc: [email-masked]
Subject: [E] Re: [tsvwg] updated version of QCI to Diffserv draft

Me as well
Martin C. Dolly
Lead Member of Technical Staff
Government & Services Standards
AT&T
Cell: +1.609.903..3360<tel:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

Regards,
_Subir

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).

Regards,

Rüdiger

Hi Jerome,

[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..

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?

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.

[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'?

- 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.

- 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.

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

Hello Jerome,

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.

Thanks,

-Subir

Dear all,

Thanks!

Jerome

---

From: <[email-masked]>
Date: Thu, 6 Jun 2019 10:42:58 +0000

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) <[email-masked]>
Gesendet: Mittwoch, 5. Juni 2019 16:15
An: Geib, Rüdiger <[email-masked]>; [email-masked]
Cc: [email-masked]
Betreff: Re: [tsvwg] updated version of QCI to Diffserv draft

Best

Jerome

To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Jerome Henry (jerhenry)" <[email-masked]<mailto:[email-masked]>>

Hi Subir, hi Jerome,

Regards,

Rüdiger

Hi Jerome,

Best

Jerome

Hello Jerome,

Thanks,

-Subir

Dear all,

Thanks!

Jerome