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

[Subir Das <[e-mail]>]

Hi Ruediger,
Thanks for your suggestions and I agree.

Regards,
_Subir

On Wed, Jun 5, 2019 at 2:57 AM <[e-mail]> 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 <[e-mail]> *Im Auftrag von *Subir Das
> *Gesendet:* Dienstag, 4. Juni 2019 15:53
> *An:* Jerome Henry (jerhenry) <[e-mail]>
> *Cc:* [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]> 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]>
> *Date: *Tuesday, May 28, 2019 at 12:08 PM
> *To: *"[e-mail]" <[e-mail]>
> *Cc: *"Jerome Henry (jerhenry)" <[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]> 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/
>
>
>
>
>
>
>
>
>
>