Subject: Re: [tsvwg] Draft diffuser to QCI v04 posted

From: "Holland, Jake" <[email-masked]>
Date: Tue, 14 Apr 2020 17:37:49 +0000

Hi Jerome,

Thanks for the update.  To me, cataloging the classes of service for 3gpp seems like useful work for an informational doc, and thanks.

But with regard to the proposed mapping sections, I think there’s a problem:

My current belief is that a static mapping for these classes that can get wide adoption is probably not possible, and it would be a mistake for the IETF to spend substantial effort trying to define one.  And without wide adoption, the use case for things like mobile apps won’t work, except in the most limited and tightly controlled and network-specific ways, because the mobile apps won’t be portable across networks, so the networks will be forced to continue just bleaching markings from IP hosts.  (I’m willing to be convinced otherwise, but it would take some good evidence that all the parties who would need to adopt it are going to be willing to adopt such a thing.)

So I would like to suggest that dynamic negotiation might be worthwhile to define for hosts, as well as at the carrier interconnects.

One key missing piece to make that possible is a signaling system that would be capable of advertising to hosts a mapping between diffserv codepoints and classes of service offered by the network and available to that host.  I believe such a system could be defined in the IETF with a reasonable effort, and that it seems to me it would be a valuable contribution. (*see below for a proposed outline).

Although such an approach might seem technically complicated and harder to deploy compared to a static mapping, it has the advantages that it could scale to many classes of service, it could be extended with new classes of service in the future, classes of service that are not useful within a network can be ignored without cost, and it avoids consuming the scarce and already-overloaded resource represented by diffserv codepoints.

So I’ll suggest that a dynamic mapping at hosts might be an easier path to a deployable solution that actually might be able to address the given use case of being usable by mobile apps, even though it might not be easy.

By contrast with a static mapping, I’d greet a dynamic mapping proposal for hosts with open arms.  More so if the need is urgent enough that it might get some adoption.

On top of the existing needs you’ve outlined, I suspect it’s hard to overstate the future value from enabling incremental deployment for experimental classes.  (And if it drives any knock-on effects encouraging support for mapping of the most useful traffic classes at interconnects, so much the better.)

I hope that’s a helpful comment.

Best regards,
Jake

* As a starting point at a possibly-viable approach, I’ll suggest: 1. define a new service that provides a mapping within a network (with a name added to the iana service names registry), 2. use the domain-name DHCP option to provide the domain name of the local network to hosts acting as DHCP clients, and 3. use DNS-SD to discover the mapping service by combining the network’s domain name with the service name.

Then write a library for use on hosts (or the eNodeB, tho that might have other options), where the API supports requesting a service class for a socket. Make that API discover and query the new mapping service, and on successful discovery of a mapping for that service to a meaningful codepoint for the network, set the target socket to use the discovered codepoint.

From: "Jerome Henry (jerhenry)" <jerhenry=[email-masked]>
Date: Monday, April 13, 2020 at 11:01 AM
To: tsvwg <[email-masked]>
Subject: [tsvwg] Draft diffuser to QCI v04 posted

Dear tsvwg,

Following our interim meeting last week, we posted an updated version of draft-diffserv-to-qci (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=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=I0IngIMAy12l9uKMSUXtKPGuTTUZ8uFGgVoSwz2Bs3s&s=HAteQJ46NmpJurRRonWbQ1r5AJbs0gYGVFABCN77MkM&e=>).
This version integrates the feedback that was shared during the interim meeting (formatting error on one table, clarification that no IANA action was mandated).

We discussed extensively on thoughts that were shared during the interim meeting. We had also noticed that several groups had proposed DSCP values for QCI labels. ATIS was named specifically, but other organizations (e.g. NGMN) have proposed such maps. However, we found that the maps available were reflective of a specific point in time, and specific focus. As such, most mapping proposals only consider a small subset of the possible QCIs defined today, and also solely focus on a specific context (which, in the examples above, is typically Carrier to Carrier interconnect). We do not think that these actors need an IETF proposal to decide on how they should mark traffic that they exchange, and such interconnect is better defined in professional settings between Carriers.
By contrast, enterprises that implement dual path (Diffserv on one side, 3GPP on the other) for their UEs are in need of wanting to align their Diffserv markings and treatment to those they have agreed upon with their Carrier, thus creating a requirement different from the above. It seems to us that this draft can help propose such map. Dynamic negotiation (e.g. a-la-RFC 8100) and exchanges (a-la- draft-knoll-idr-qos-attribute-24) are undoubtedly very promising ways of implementing a QoS marking dialog at the interconnection point, but in a world where 3GPP has defined close to 30 traffic types, it seems that there is still a need for us (IETF) to propose a way to express these intents into Diffserv.

We are looking forward to receiving additional feedback on this version.

Best

Jerome

---

From: <[email-masked]>
Date: Mon, 20 Apr 2020 09:43:02 +0000

Hi Jake,

Thanks. I agree that IETF shouldn’t work with static QCI to DiffServ mappings. If some QCIs see a large scale deployment, i.e. several competing Mobile Network Operators deploy the same standard QCI to transport traffic of the same application, managed at least by a compatible way by these operators, then standard DSCP mappings are useful for these (and only these) QCIs.

I stopped working on the topic, as this wasn’t in sight at the time I tried to deal with the issue.

If your proposal on dynamic QCI to DSCP assignments is picked up, it might be worth thinking about private QCI to DSCP mappings too. My only concern here is ensuring a reasonable QoS transport, if that is desired. Different QCIs could be mapped to the same DSCP, unless there’s reliable information that Mobile Network Operators base their wireless QoS policies on DSCPs carried by IP packets, I think. I’m so far am not aware of the latter, but I also don’t follow QoS standardization in mobile networks.

To me, everything helping to simplify a scalable QoS policy management in the DiffServ domain is useful. I wonder whether there are network sections or requirements to differentiate say 10 different QoS classes or more on a single mobile to IP interconnection or access.

Regards,

Ruediger

Von: tsvwg <[email-masked]> Im Auftrag von Holland, Jake
Gesendet: Dienstag, 14. April 2020 19:38
An: Jerome Henry (jerhenry) <jerhenry=[email-masked]>; tsvwg <[email-masked]>
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jerome,

Best regards,
Jake

From: "Jerome Henry (jerhenry)" <jerhenry=[email-masked]<mailto:jerhenry=[email-masked]>>
Date: Monday, April 13, 2020 at 11:01 AM
To: tsvwg <[email-masked]<mailto:[email-masked]>>
Subject: [tsvwg] Draft diffuser to QCI v04 posted

Dear tsvwg,

Best

Jerome

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Mon, 20 Apr 2020 18:30:54 +0000

Hi Jake,

This is very useful feedback. In this effort, it seems that we want to arbitrate between different needs. In the scenario we envision, an enterprise has a series of assets of various types, and they leverage a dual connection (MPTCP, QUIC etc) between cellular and unlicensed (let’s call it Wi-FI, although it can be something else). As traffic reaches the other side (application server with at least a Diffserv path to the asset), the hope is that both sides would have treated the packets in an approximatively comparable fashion.

Would you mind exploring your idea a bit further? In all cases, the actor is likely an enterprise IT. They can negotiate an SLA with the carrier(s) they work with. This could result in a series of QCIs attached to the various traffic they would send. Now, their goal is to attempt to get the same intent on both legs. They may not be LTE experts.
In your proposal, how would the choreography work? Would the enterprise create their own mapping between the LCIs their carrier suggested and some DSCP, chosen from unaffected values? (Would they need any guidance on what these QCIs represent? Do we assume that they are comfortable or familiar with the various IETF QoS RFCs?) Would they then use the service.domain logic below to ask the carrier to mark the matching traffic at the interconnect? Or would the host/asset mark the DIffserv side, based on putting in a library somewhere, that the host can access, a service/socket to DSCP table?

Take care

Jerome

Hi Jerome,

Best regards,
Jake

Dear tsvwg,

Best

Jerome

---

From: <[email-masked]>
Date: Tue, 21 Apr 2020 08:03:37 +0000

Hi Jerome,

a reasonably large enterprise may run an own DiffServ scheme. Others may use a carrier DiffServ scheme, if there’s one in place for enterprise customers.

5G is designed for enterprise services and some large corporations have licences (or applied at least), that’s correct. You assume or want to offer standard LCI mappings to DiffServ, that’s reasonable.

Some points which should be discussed or at least be put in/out scope of your draft:

  *   Do you expect all standard LCIs to be supported by a single enterprise on a local and/or an end-to-end basis? The draft says no in one section and I do not expect that too.
  *   if not all standard LCIs are deployed, is there a real need for one fixed DSCP per standard LCI mapping – or might generic guidance be a reasonable alternative?
  *   If private QCIs are part of 5G, are they used by large enterprises too? I know that private QCIs saw fair deployment at the start of LTE. The draft doesn’t mention them. I suggest to put them out of scope if you don’t want to deal with them and recommend to check, whether they are still in use and whether their use is standardized and expected for 5G.
  *   The abstract of your draft reads (excerpt): “application traffic transits .. between enterprise networks, the Internet, and cellular telecommunication networks….it is crucial that quality of service be aligned between these  different environments….This document specifies a set of QCI to DSCP mappings so as to maintain a consistent QoS treatment between cellular networks and the Internet.  This mapping can be used by enterprises or implementers  expecting traffic to flow through both types of network, and wishing to align the QoS treatment applied to one network under their control with the QoS treatment applied to the other network.”
In your scenario below the sentence “enterprise has a series of assets of various types, and they leverage a dual connection (MPTCP, QUIC etc) between cellular and unlicensed (..WiFi). In addition, an application server is introduced.  In my mind
- leaving the enterprise and interconnecting to a 3rd party application server – is that a direct interconnection or is an upstream carrier involved (the Internet)? In my mind the draft should respect the state-of-the art at the relevant interconnection interfaces. From my experience, DiffServ requires an SLA between interconnected parties. Application servers operating with Diffserv belong to one of them.
The other case is communication of a single VPN across a carrier backbone. In many cases, MPLS is deployed by the backbone. It is a task of the enterprise VPN operators map his DSCP scheme to the offered carrier classes then. As mentioned above, a carrier could offer some pre-defined DSCPs / classes for enterprise VPNs too.
In any case, I’m not sure that I understand which of the above scenarios your draft addresses mainly. That should be clearly expressed by the abstract. I understand you draft aiming mainly at enterprise DSCP to QCI mapping with one end enterprise and other end any part of the Internet by now. If that isn’t correct, please reword the abstract.

Regards,

Ruediger

Von: tsvwg <[email-masked]> Im Auftrag von Jerome Henry (jerhenry)
Gesendet: Montag, 20. April 2020 20:31
An: jholland=[email-masked]
Cc: jerhenry=[email-masked]; [email-masked]
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jake,

Take care

Jerome

Von: tsvwg <[email-masked]<mailto:[email-masked]>> Im Auftrag von Holland, Jake
Gesendet: Dienstag, 14. April 2020 19:38
An: Jerome Henry (jerhenry) <jerhenry=[email-masked]<mailto:jerhenry=[email-masked]>>; tsvwg <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jerome,

Best regards,
Jake

Dear tsvwg,

Best

Jerome

---

From: "Black, David" <[email-masked]>
Date: Wed, 22 Apr 2020 15:16:06 +0000

Posting as an individual ...

> -   Do you expect all standard LCIs to be supported by a single enterprise on a local and/or an end-to-end basis? The draft says no in one section and I do not expect that too.
>  - if not all standard LCIs are deployed, is there a real need for one fixed DSCP per standard LCI mapping – or might generic guidance be a reasonable alternative

Ruediger – was QCI intended in the above bullets instead of LCI?   Assuming that QCI was intended ...

... generic guidance sounds like an interesting goal to consider.

The draft is currently intended to be comprehensive in mapping all QCIs into Diffserv in Section 5.  For an enterprise familiar with Diffserv (many are) that is looking at deploying an enterprise cellular network, the guidance in Section 4 on how to think about QCIs from a Diffserv point of view seems valuable, perhaps with somewhat less specificity, whereas the comprehensive mapping in the reverse direction may not be as valuable (e.g., there may be some QCIs that are inappropriate for non-cellular networks or otherwise difficult to support).

Thanks, --David

From: tsvwg <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, April 21, 2020 4:04 AM
To: jerhenry=[email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] Draft diffuser to QCI v04 posted

[EXTERNAL EMAIL]
Hi Jerome,

Regards,

Ruediger

Von: tsvwg <[email-masked]<mailto:[email-masked]>> Im Auftrag von Jerome Henry (jerhenry)
Gesendet: Montag, 20. April 2020 20:31
An: jholland=[email-masked]<mailto:jholland=[email-masked]>
Cc: jerhenry=[email-masked]<mailto:jerhenry=[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jake,

Take care

Jerome

Hi Jerome,

Best regards,
Jake

Dear tsvwg,

Best

Jerome

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Wed, 22 Apr 2020 18:12:04 +0000

Thank you Ruediger,

(please see inline)

Take care

Jerome

From: "[email-masked]" <[email-masked]>
Date: Tuesday, April 21, 2020 at 4:04 AM
To: "Jerome Henry (jerhenry)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: AW: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jerome,

5G is designed for enterprise services and some large corporations have licences (or applied at least), that’s correct. You assume or want to offer standard LCI mappings to DiffServ, that’s reasonable.
[jerome] thank you. 100% agree that there are different models. Quite clearly, an enterprise that is entirely DIffserv, or an enterprise that deploys their marking model fully under the guidance of a carrier, likely does not need external guidance.

  *   Do you expect all standard LCIs to be supported by a single enterprise on a local and/or an end-to-end basis? The draft says no in one section and I do not expect that too.
[Jerome] In ‘standard’ I read ‘defined in the standard’, which what I think you intent (and not a casual equivalent of ‘common’). I doubt that any enterprise would run all these traffic types (unless it becomes a large monopoly spanning multiple verticals). I expect that each enterprise, depending on its domain of operation, will have a few common traffic types, and a few specific traffic types, for which they will seek guidance on QCI/Diffserv equivalence.

  *   if not all standard LCIs are deployed, is there a real need for one fixed DSCP per standard LCI mapping – or might generic guidance be a reasonable alternative?
[Jerome] If we could know which traffic types combinations are never encountered together on any network, then we could bet on using the same DSCP for both. But I am not sure that we can make this determination, and also it may eb possible that a transport network may honor DSCP and carry traffic from multiple entities. This led me to the conclusion that it was preferable to establish a complete list (what maybe Jake calls ‘a library’), with expression of intent for each and possible label, avoiding label overlap as frequently as possible.

  *   If private QCIs are part of 5G, are they used by large enterprises too? I know that private QCIs saw fair deployment at the start of LTE. The draft doesn’t mention them. I suggest to put them out of scope if you don’t want to deal with them and recommend to check, whether they are still in use and whether their use is standardized and expected for 5G.
[Jerome] We can definitely make that mention, although it seemed to me that, as we state that we use TS 23.203 (and TS 23.501 for 5G) as a reference, the implication was there that we did not address private QCIs (as these docs specify that they define standard QCIs/5Qis to ensure interoperability and void non-translatable private QCIs), nor do we address experimental/local DSCPs or private performance characteristics (but making this mention is trivial, I’ll make it).

[Jerome] I am trying different words to express the content of the draft abstract in case it would be useful. I am not trying to change the scope 😊.  The enterprise is on one end at the UE side, which traffic goes through one 3GPP leg for which an SLA and associated QCIs are likely known, and another leg going through a Diffserv-based leg (which I call Wi-Fi for simplicity). Then the enterprise is on the other end, where traffic re-enters the AS, ie. the domain the enterprise has marking control over. At this point (which may be anywhere beyond the 3GPP boundary), the enterprise will want look at the traffic going through both legs, and make sure it gets the same treatment. The draft can help them think about QCIs, coming from Diffserv, and also, understanding the SLA and the QCIs they agreed upon with the 3GPP carrier, design a Diffserv scheme that would minimize the treatment differences between packets going through these 2 (paths. Hope this helps clarify. Please tell me if you think that the abstract does not convey this intent clearly enough. I am of course open to alternate wording.

Regards,

Ruediger

Hi Jake,

Take care

Jerome

Hi Jerome,

Best regards,
Jake

Dear tsvwg,

Best

Jerome

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 22 Apr 2020 20:09:18 -0700

Apologies for the intrusion here -

Looking for quick clarifications:

a)  Document says
" This

   document specifies a set of 3rd Generation Partnership Project (3GPP)
   Quality of Service (QoS) Class Identifiers (QCI) and 5G QoS
   Identifiers (5QI) 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."

 It says internet. I didn't quite get where this mapping is happening from
QCI to DSCP; is this in UE or at the AS boundaries  or when when packet
gets into 3GPP domain?

b)   For Ruediger : There was a comment below that private QCIs in LTE
deployments

" If private QCIs are part of 5G, are they used by large enterprises too? I
know that private QCIs saw fair deployment at the start of LTE. The draft
doesn’t mention them. I suggest to put them out of scope if you don’t want
to deal with them and recommend to check, whether they are still in use and
whether their use is standardized and expected for 5G."

I am not really aware of these used in LTE networks (but I could be wrong).
Not really sure what do you mean by private QCI ? Could you plz clarify:
Do you mean QCI not defined in TS 23.203 or local mapping to one of the
IANA defined DSCP values? Or non-IANA defined DSCP values?

c)  Say, if new code points are allocated as proposed, do we need to
specify  similar to 2597  (AF PHB stuff for example) ?

Thanks in advance.

--
Uma C.

On Wed, Apr 22, 2020 at 11:12 AM Jerome Henry (jerhenry) <jerhenry=
[email-masked]> wrote:

> Thank you Ruediger,
>
>
>
> (please see inline)
>
>
>
> Take care
>
>
>
> Jerome
>
>
>
> *From: *"[email-masked]" <[email-masked]>
> *Date: *Tuesday, April 21, 2020 at 4:04 AM
> *To: *"Jerome Henry (jerhenry)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *AW: [tsvwg] Draft diffuser to QCI v04 posted
>
>
>
> Hi Jerome,
>
>
>
> a reasonably large enterprise may run an own DiffServ scheme. Others may
> use a carrier DiffServ scheme, if there’s one in place for enterprise
> customers.
>
>
>
> 5G is designed for enterprise services and some large corporations have
> licences (or applied at least), that’s correct. You assume or want to offer
> standard LCI mappings to DiffServ, that’s reasonable.
>
> [jerome] thank you. 100% agree that there are different models. Quite
> clearly, an enterprise that is entirely DIffserv, or an enterprise that
> deploys their marking model fully under the guidance of a carrier, likely
> does not need external guidance.
>
>
>
>    - Do you expect all standard LCIs to be supported by a single
>    enterprise on a local and/or an end-to-end basis? The draft says no in one
>    section and I do not expect that too.
>
> [Jerome] In ‘standard’ I read ‘defined in the standard’, which what I
> think you intent (and not a casual equivalent of ‘common’). I doubt that
> any enterprise would run all these traffic types (unless it becomes a large
> monopoly spanning multiple verticals). I expect that each enterprise,
> depending on its domain of operation, will have a few common traffic types,
> and a few specific traffic types, for which they will seek guidance on
> QCI/Diffserv equivalence.
>
>    - if not all standard LCIs are deployed, is there a real need for one
>    fixed DSCP per standard LCI mapping – or might generic guidance be a
>    reasonable alternative?
>
> [Jerome] If we could know which traffic types combinations are never
> encountered together on any network, then we could bet on using the same
> DSCP for both. But I am not sure that we can make this determination, and
> also it may eb possible that a transport network may honor DSCP and carry
> traffic from multiple entities. This led me to the conclusion that it was
> preferable to establish a complete list (what maybe Jake calls ‘a
> library’), with expression of intent for each and possible label, avoiding
> label overlap as frequently as possible.
>
>    - If private QCIs are part of 5G, are they used by large enterprises
>    too? I know that private QCIs saw fair deployment at the start of LTE. The
>    draft doesn’t mention them. I suggest to put them out of scope if you don’t
>    want to deal with them and recommend to check, whether they are still in
>    use and whether their use is standardized and expected for 5G.
>
> [Jerome] We can definitely make that mention, although it seemed to me
> that, as we state that we use TS 23.203 (and TS 23.501 for 5G) as a
> reference, the implication was there that we did not address private QCIs
> (as these docs specify that they define standard QCIs/5Qis to ensure
> interoperability and void non-translatable private QCIs), nor do we address
> experimental/local DSCPs or private performance characteristics (but making
> this mention is trivial, I’ll make it).
>
>    - The abstract of your draft reads (excerpt): “application traffic
>    transits .. between enterprise networks, the Internet, and cellular
>    telecommunication networks….it is crucial that quality of service be
>    aligned between these  different environments….This document specifies a
>    set of QCI to DSCP mappings so as to maintain a consistent QoS treatment
>    between cellular networks and the Internet.  This mapping can be used by
>    enterprises or implementers  expecting traffic to flow through both types
>    of network, and wishing to align the QoS treatment applied to one network
>    under their control with the QoS treatment applied to the other network.”
>    In your scenario below the sentence “enterprise has a series of assets
>    of various types, and they leverage a dual connection (MPTCP, QUIC etc)
>    between cellular and unlicensed (..WiFi). In addition, an application
>    server is introduced.  In my mind
>    - leaving the enterprise and interconnecting to a 3rd party
>    application server – is that a direct interconnection or is an upstream
>    carrier involved (the Internet)? In my mind the draft should respect the
>    state-of-the art at the relevant interconnection interfaces. From my
>    experience, DiffServ requires an SLA between interconnected parties.
>    Application servers operating with Diffserv belong to one of them.
>    The other case is communication of a single VPN across a carrier
>    backbone. In many cases, MPLS is deployed by the backbone. It is a task of
>    the enterprise VPN operators map his DSCP scheme to the offered carrier
>    classes then. As mentioned above, a carrier could offer some pre-defined
>    DSCPs / classes for enterprise VPNs too.
>    In any case, I’m not sure that I understand which of the above
>    scenarios your draft addresses mainly. That should be clearly expressed by
>    the abstract. I understand you draft aiming mainly at enterprise DSCP to
>    QCI mapping with one end enterprise and other end any part of the Internet
>    by now. If that isn’t correct, please reword the abstract.
>
> [Jerome] I am trying different words to express the content of the draft
> abstract in case it would be useful. I am not trying to change the scope
> 😊.  The enterprise is on one end at the UE side, which traffic goes
> through one 3GPP leg for which an SLA and associated QCIs are likely known,
> and another leg going through a Diffserv-based leg (which I call Wi-Fi for
> simplicity). Then the enterprise is on the other end, where traffic
> re-enters the AS, ie. the domain the enterprise has marking control over.
> At this point (which may be anywhere beyond the 3GPP boundary), the
> enterprise will want look at the traffic going through both legs, and make
> sure it gets the same treatment. The draft can help them think about QCIs,
> coming from Diffserv, and also, understanding the SLA and the QCIs they
> agreed upon with the 3GPP carrier, design a Diffserv scheme that would
> minimize the treatment differences between packets going through these 2
> (paths. Hope this helps clarify. Please tell me if you think that the
> abstract does not convey this intent clearly enough. I am of course open to
> alternate wording.
>
>
>
> Regards,
>
>
>
> Ruediger
>
>
>
>
>
>
>
>
>
> *Von:* tsvwg <[email-masked]> *Im Auftrag von *Jerome Henry
> (jerhenry)
> *Gesendet:* Montag, 20. April 2020 20:31
> *An:* jholland=[email-masked]
> *Cc:* jerhenry=[email-masked]; [email-masked]
> *Betreff:* Re: [tsvwg] Draft diffuser to QCI v04 posted
>
>
>
> Hi Jake,
>
>
>
> This is very useful feedback. In this effort, it seems that we want to
> arbitrate between different needs. In the scenario we envision, an
> enterprise has a series of assets of various types, and they leverage a
> dual connection (MPTCP, QUIC etc) between cellular and unlicensed (let’s
> call it Wi-FI, although it can be something else). As traffic reaches the
> other side (application server with at least a Diffserv path to the asset),
> the hope is that both sides would have treated the packets in an
> approximatively comparable fashion.
>
>
>
> Would you mind exploring your idea a bit further? In all cases, the actor
> is likely an enterprise IT. They can negotiate an SLA with the carrier(s)
> they work with. This could result in a series of QCIs attached to the
> various traffic they would send. Now, their goal is to attempt to get the
> same intent on both legs. They may not be LTE experts.
>
> In your proposal, how would the choreography work? Would the enterprise
> create their own mapping between the LCIs their carrier suggested and some
> DSCP, chosen from unaffected values? (Would they need any guidance on what
> these QCIs represent? Do we assume that they are comfortable or familiar
> with the various IETF QoS RFCs?) Would they then use the service.domain
> logic below to ask the carrier to mark the matching traffic at the
> interconnect? Or would the host/asset mark the DIffserv side, based on
> putting in a library somewhere, that the host can access, a service/socket
> to DSCP table?
>
>
>
> Take care
>
>
>
> Jerome
>
>
>
>
>
>
>
> *Von:* tsvwg <[email-masked]> *Im Auftrag von *Holland, Jake
> *Gesendet:* Dienstag, 14. April 2020 19:38
> *An:* Jerome Henry (jerhenry) <jerhenry=[email-masked]>;
> tsvwg <[email-masked]>
> *Betreff:* Re: [tsvwg] Draft diffuser to QCI v04 posted
>
>
>
> Hi Jerome,
>
>
>
> Thanks for the update.  To me, cataloging the classes of service for 3gpp
> seems like useful work for an informational doc, and thanks.
>
>
>
> My current belief is that a static mapping for these classes that can get
> wide adoption is probably not possible, and it would be a mistake for the
> IETF to spend substantial effort trying to define one.  And without wide
> adoption, the use case for things like mobile apps won’t work, except in
> the most limited and tightly controlled and network-specific ways, because
> the mobile apps won’t be portable across networks, so the networks will be
> forced to continue just bleaching markings from IP hosts.  (I’m willing to
> be convinced otherwise, but it would take some good evidence that all the
> parties who would need to adopt it are going to be willing to adopt such a
> thing.)
>
>
>
> So I would like to suggest that dynamic negotiation might be worthwhile to
> define for hosts, as well as at the carrier interconnects.
>
>
>
> One key missing piece to make that possible is a signaling system that
> would be capable of advertising to hosts a mapping between diffserv
> codepoints and classes of service offered by the network and available to
> that host.  I believe such a system could be defined in the IETF with a
> reasonable effort, and that it seems to me it would be a valuable
> contribution. (*see below for a proposed outline).
>
>
>
> Although such an approach might seem technically complicated and harder to
> deploy compared to a static mapping, it has the advantages that it could
> scale to many classes of service, it could be extended with new classes of
> service in the future, classes of service that are not useful within a
> network can be ignored without cost, and it avoids consuming the scarce and
> already-overloaded resource represented by diffserv codepoints.
>
>
>
> So I’ll suggest that a dynamic mapping at hosts might be an easier path to
> a deployable solution that actually might be able to address the given use
> case of being usable by mobile apps, even though it might not be easy.
>
>
>
> By contrast with a static mapping, I’d greet a dynamic mapping proposal
> for hosts with open arms.  More so if the need is urgent enough that it
> might get some adoption.
>
>
>
> On top of the existing needs you’ve outlined, I suspect it’s hard to
> overstate the future value from enabling incremental deployment for
> experimental classes.  (And if it drives any knock-on effects encouraging
> support for mapping of the most useful traffic classes at interconnects, so
> much the better.)
>
>
>
> * As a starting point at a possibly-viable approach, I’ll suggest: 1.
> define a new service that provides a mapping within a network (with a name
> added to the iana service names registry), 2. use the domain-name DHCP
> option to provide the domain name of the local network to hosts acting as
> DHCP clients, and 3. use DNS-SD to discover the mapping service by
> combining the network’s domain name with the service name.
>
>
>
> Then write a library for use on hosts (or the eNodeB, tho that might have
> other options), where the API supports requesting a service class for a
> socket. Make that API discover and query the new mapping service, and on
> successful discovery of a mapping for that service to a meaningful
> codepoint for the network, set the target socket to use the discovered
> codepoint.
>
>
>
>
>
> *From: *"Jerome Henry (jerhenry)" <jerhenry=[email-masked]>
> *Date: *Monday, April 13, 2020 at 11:01 AM
> *To: *tsvwg <[email-masked]>
> *Subject: *[tsvwg] Draft diffuser to QCI v04 posted
>
>
>
> Dear tsvwg,
>
>
>
> Following our interim meeting last week, we posted an updated version of
> draft-diffserv-to-qci (
> 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=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=I0IngIMAy12l9uKMSUXtKPGuTTUZ8uFGgVoSwz2Bs3s&s=HAteQJ46NmpJurRRonWbQ1r5AJbs0gYGVFABCN77MkM&e=>
> ).
>
> This version integrates the feedback that was shared during the interim
> meeting (formatting error on one table, clarification that no IANA action
> was mandated).
>
>
>
> We discussed extensively on thoughts that were shared during the interim
> meeting. We had also noticed that several groups had proposed DSCP values
> for QCI labels. ATIS was named specifically, but other organizations (e.g.
> NGMN) have proposed such maps. However, we found that the maps available
> were reflective of a specific point in time, and specific focus. As such,
> most mapping proposals only consider a small subset of the possible QCIs
> defined today, and also solely focus on a specific context (which, in the
> examples above, is typically Carrier to Carrier interconnect). We do not
> think that these actors need an IETF proposal to decide on how they should
> mark traffic that they exchange, and such interconnect is better defined in
> professional settings between Carriers.
>
> By contrast, enterprises that implement dual path (Diffserv on one side,
> 3GPP on the other) for their UEs are in need of wanting to align their
> Diffserv markings and treatment to those they have agreed upon with their
> Carrier, thus creating a requirement different from the above. It seems to
> us that this draft can help propose such map. Dynamic negotiation (e.g.
> a-la-RFC 8100) and exchanges (a-la- draft-knoll-idr-qos-attribute-24) are
> undoubtedly very promising ways of implementing a QoS marking dialog at the
> interconnection point, but in a world where 3GPP has defined close to 30
> traffic types, it seems that there is still a need for us (IETF) to propose
> a way to express these intents into Diffserv.
>
>
>

---

From: <[email-masked]>
Date: Thu, 23 Apr 2020 06:51:07 +0000

Hi Uma,

Originally, there were 9 standard LTE QCIs (QCI 1 to 9). When I worked on that topic, I saw a list of deployed LTE QCIs. They were in the range 1xx and I was told, that deployment of these “private QCIs” was quite common. At that time (I don’t claim anything else).

I then started to ask for use of standard QCIs. There was neither a standard nor an agreement to deploy, say, QCI 1 for mobile telephony. Then I found out, that one mobile carrier supported mobile telephony by standard QCI 1 and another one by standard QCI 5 (my recollection may be wrong on the exact value).

My take: if the assignment of standard and/or private QCI is left to mobile carriers and that context is local only in a similar way as the deployment and interpretation of DSCP is left to local schemes of IP network operators, then I think there’s no need to assign fixed standard QCI to standard DSCP mappings.

Another approach might be to wait and see whether some QCIs see frequent deployment or whether categories of similar applications are frequently supported by differentiated QCIs (where the QCIs might differ per provider, whereas the idea of assigning differentiated treatment to the category of application is identical). Once that has become clear, a generic mapping proposal QCI to DiffServ might be useful. That could be done independently of the above approach.

Regards,

Ruediger

Von: Uma Chunduri <[email-masked]>
Gesendet: Donnerstag, 23. April 2020 05:09
An: Jerome Henry (jerhenry) <jerhenry=[email-masked]>
Cc: Geib, Rüdiger <[email-masked]>; [email-masked]
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

a)  Document says
" This

   Internet."

 It says internet. I didn't quite get where this mapping is happening from QCI to DSCP; is this in UE or at the AS boundaries  or when when packet gets into 3GPP domain?

b)   For Ruediger : There was a comment below that private QCIs in LTE deployments

" If private QCIs are part of 5G, are they used by large enterprises too? I know that private QCIs saw fair deployment at the start of LTE. The draft doesn’t mention them. I suggest to put them out of scope if you don’t want to deal with them and recommend to check, whether they are still in use and whether their use is standardized and expected for 5G."

I am not really aware of these used in LTE networks (but I could be wrong). Not really sure what do you mean by private QCI ? Could you plz clarify:
Do you mean QCI not defined in TS 23.203 or local mapping to one of the IANA defined DSCP values? Or non-IANA defined DSCP values?

c)  Say, if new code points are allocated as proposed, do we need to specify  similar to 2597  (AF PHB stuff for example) ?

Thanks in advance.

--
Uma C.

On Wed, Apr 22, 2020 at 11:12 AM Jerome Henry (jerhenry) <jerhenry=[email-masked]<mailto:[email-masked]>> wrote:
Thank you Ruediger,

(please see inline)

Take care

Jerome

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 21, 2020 at 4:04 AM
To: "Jerome Henry (jerhenry)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: AW: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jerome,

Regards,

Ruediger

Von: tsvwg <[email-masked]<mailto:[email-masked]>> Im Auftrag von Jerome Henry (jerhenry)
Gesendet: Montag, 20. April 2020 20:31
An: jholland=[email-masked]<mailto:[email-masked]>
Cc: jerhenry=[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jake,

Take care

Jerome

Hi Jerome,

Best regards,
Jake

Dear tsvwg,

Best

Jerome

---

From: <[email-masked]>
Date: Thu, 23 Apr 2020 15:07:30 +0000

Hi Jerome,

My replies in-line [RG], deleted uncommented and “in agreement” text.

Regards, Ruediger

From: Jerome Henry (jerhenry) <[email-masked]>

  *   if not all standard LCIs are deployed, is there a real need for one fixed DSCP per standard LCI mapping – or might generic guidance be a reasonable alternative?
[Jerome] If we could know which traffic types combinations are never encountered together on any network, then we could bet on using the same DSCP for both. But I am not sure that we can make this determination, and also it may be possible that a transport network may honor DSCP and carry traffic from multiple entities. This led me to the conclusion that it was preferable to establish a complete list (what maybe Jake calls ‘a library’), with expression of intent for each and possible label, avoiding label overlap as frequently as possible.
[RG] We follow different philosophies here, I think. I prefer to aggregate traffic and consume as little codepoint and mapping space to keep configuration and operation simple. Neither are DSCPs binding, nor is QCI deployment or assignment to applications binding. For me, these are too many “may” to base activity upon.

  *   If private QCIs are part of 5G, are they used by large enterprises too? I know that private QCIs saw fair deployment at the start of LTE. The draft doesn’t mention them. I suggest to put them out of scope if you don’t want to deal with them and recommend to check, whether they are still in use and whether their use is standardized and expected for 5G.
[Jerome] We can definitely make that mention, although it seemed to me that, as we state that we use TS 23.203 (and TS 23.501 for 5G) as a reference, the implication was there that we did not address private QCIs (as these docs specify that they define standard QCIs/5Qis to ensure interoperability and void non-translatable private QCIs), nor do we address experimental/local DSCPs or private performance characteristics (but making this mention is trivial, I’ll make it).
[RG] It took me some time until I learned about the existence and the deployment of the private QCIs. We should try to avoid that frustration for others, that’s my intent.

  *   The abstract of your draft reads (excerpt): “application traffic transits .. between enterprise networks, the Internet, and cellular telecommunication networks….it is crucial that quality of service be aligned between these  different environments….This document specifies a set of QCI to DSCP mappings so as to maintain a consistent QoS treatment between cellular networks and the Internet.  This mapping can be used by enterprises or implementers  expecting traffic to flow through both types of network, and wishing to align the QoS treatment applied to one network under their control with the QoS treatment applied to the other network.”
In your scenario below the sentence “enterprise has a series of assets of various types, and they leverage a dual connection (MPTCP, QUIC etc) between cellular and unlicensed (..WiFi). In addition, an application server is introduced.  In my mind
- leaving the enterprise and interconnecting to a 3rd party application server – is that a direct interconnection or is an upstream carrier involved (the Internet)? In my mind the draft should respect the state-of-the art at the relevant interconnection interfaces. From my experience, DiffServ requires an SLA between interconnected parties. Application servers operating with Diffserv belong to one of them.
The other case is communication of a single VPN across a carrier backbone. In many cases, MPLS is deployed by the backbone. It is a task of the enterprise VPN operators map his DSCP scheme to the offered carrier classes then. As mentioned above, a carrier could offer some pre-defined DSCPs / classes for enterprise VPNs too.
In any case, I’m not sure that I understand which of the above scenarios your draft addresses mainly. That should be clearly expressed by the abstract. I understand you draft aiming mainly at enterprise DSCP to QCI mapping with one end enterprise and other end any part of the Internet by now. If that isn’t correct, please reword the abstract.
[Jerome] I am trying different words to express the content of the draft abstract in case it would be useful. I am not trying to change the scope 😊.  The enterprise is on one end at the UE side, which traffic goes through one 3GPP leg for which an SLA and associated QCIs are likely known, and another leg going through a Diffserv-based leg (which I call Wi-Fi for simplicity). Then the enterprise is on the other end, where traffic re-enters the AS, ie. the domain the enterprise has marking control over. At this point (which may be anywhere beyond the 3GPP boundary), the enterprise will want look at the traffic going through both legs, and make sure it gets the same treatment. The draft can help them think about QCIs, coming from Diffserv, and also, understanding the SLA and the QCIs they agreed upon with the 3GPP carrier, design a Diffserv scheme that would minimize the treatment differences between packets going through these 2 (paths. Hope this helps clarify. Please tell me if you think that the abstract does not convey this intent clearly enough. I am of course open to alternate wording.
[RG] The only way to reliably conserve DSCPs between sites of an enterprise interconnected by a single (or more) other domains is to use a VPN or a tunnel. A domain supporting Diffserv will not honour or preserve any codepoint scheme apart from its own, I think. It is standard conformant to rewrite many incoming DSCP to a single one, as I far as I recall discussion around RFC8100. The abstract should clarify, whether it is especially tunnel or VPN of deployment, which is addressed. This would also allow to assign a simple backbone mapping at carrier interfaces (there’s default, there may be up to a dozen more bulk transport QoS classes, maybe).
If you expect a third party carrier to offer a public WiFi service upon which an enterprise domain follows to honour your draft standard and carry the DSCPs unchanged, it’s beyond my imagination. I didn’t check whether your draft is compatible with draft-ietf-tsvwg-rtcweb-qos-18<https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/>, RFC 4594<https://datatracker.ietf.org/doc/rfc4594/> (you mentioned that in your draft, I think), and RFC 5127<https://datatracker.ietf.org/doc/rfc5127/>, which likely all may be expected to be honoured by the domain operating that WiFi access.

Regards,

Ruediger

Hi Jake,

Take care

Jerome

Hi Jerome,

Best regards,
Jake

Dear tsvwg,

Best

Jerome

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 23 Apr 2020 20:31:29 +0000

Hi Jerome,

I’m glad it’s possibly helpful.  I’ll try to answer your questions and expand a bit on the vision I had in mind, responses are inline with <JH></JH>

From: "Jerome Henry (jerhenry)" <jerhenry=[email-masked]>
Date: Monday, April 20, 2020 at 11:31 AM
To: "Holland, Jake" <[email-masked]>
Cc: "jerhenry=[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jake,

<JH>
The “(s)” in “carrier(s)” is the trickiest part here, I think, and a major driver for proposing a dynamic approach.

I assume here that the different carriers might have different markings for similar PHBs that might be hard for them to change. (For instance, the choices might be from hardware-driven constraints from their vendors, or perhaps due to things like legacy internal use cases within the carrier that drove an assignment some time ago, which now can’t be easily changed.)

The proposal is intended as a way that the carrier has the ability, with a relatively simple deployment of a simple service, to advertise the right markings that should be used for that network, and that these can be different from network-to-network, yet still usable by hosts, with apps that have a use for specific, named PHBs for their traffic.
</JH>

In your proposal, how would the choreography work? Would the enterprise create their own mapping between the LCIs their carrier suggested and some DSCP, chosen from unaffected values?
(Would they need any guidance on what these QCIs represent? Do we assume that they are comfortable or familiar with the various IETF QoS RFCs?) Would they then use the service.domain logic below to ask the carrier to mark the matching traffic at the interconnect? Or would the host/asset mark the DIffserv side, based on putting in a library somewhere, that the host can access, a service/socket to DSCP table?

<JH>
I think the answer to these depends on exactly how the mobile devices are connected, and how the enterprise network is structured, and whether the enterprise itself has any constraints on the DSCP values.

I imagine the most typical (or at least simplest) case being a transparent pass-through, where the lookup service is operated by the carrier, and it provides carrier-chosen values, and all the enterprise does is propagate the search domain from the carrier and the appropriate DNS entries for service discovery, and then passes through the DSCP markings.

I imagine that for enterprises with more complex networks, it could get more complex.  One can certainly imagine enterprises with expertise who would choose to run their own mapping and their own classes of service, especially for internal connections.  These may or may not come with enterprise constraints on the markings that may or may not match the carrier’s constraints, so there would perhaps be a marking translation config at the interconnect (where inside markings are translated back and forth to outside markings for the same class of service), and this would either be manually configured based on reviewing the SLAs, or might be automatable using the same sort of discovery logic (or the bgp interconnect, if preferred).  In this kind of scenario, the enterprise would operate its own search domain and provide its own mapping service for the mobile devices to use, and it would take more expertise, but it would only be required if the enterprise has its own uses for the codepoints.  (I imagine in practice there’d be vendors providing some kind of integration here, but some shops employing experts and doing it themselves.)

Whether the host connects to an enterprise-owned service (by discovering the service in an enterprise-owned search domain), or the carrier-owned service (by the enterprise passing through the carrier’s search domain to the end hosts), if the service messaging for the traffic_class_name->codepoint lookup is defined with the same messaging between host and service (for instance, it could perhaps be done as a RESTCONF server using a YANG model defined in the spec, or if there’s some reason could instead define a specific set of messages and version detection, etc.).

But the point of the service would be that the host would be able to look up the codepoint to use in order to get a named PHB for the packets it’s sending.  If the traffic class names come from a registry that map them to PHBs (probably a “specification required” registry, I would think), then collisions can be avoided in the traffic class names, and the hosts will know what name to use to attempt to get a certain kind of PHB from the network, and whether they can in fact meaningfully use that class of service within the network they’re connected to (The ability to provide a null result will be important in this service.)

So with this approach, the host would always mark the DSCP according to what it learned from the service.

The simple deployment would just pass it through transparently (both the markings and the mapping service discovery), whereas a complex deployment could if necessary provide a translation layer (by providing their own mapping service, and configuring an interconnect that remaps codepoints where necessary).  So the place the host learns the mapping from would be the control point, and setting up the right search domain so that the host discovers the right service would need to be configured in the host’s dhcp server to match the intended operation for that network.

I hope that makes some sense and helps clarify the suggestion.  It’s of course not a fully specified proposal, so of course there are many unspecified details.

For instance, just like with the bgp carrier interconnect proposal, maybe there could be different available classes of service based on the intended destination, and maybe these need to be handled as part of the mapping service (so maybe the lookup needs to use a destination, as well, and maybe maintaining the service is not trivial in all cases).  As another complicating factor, maybe there’s different permissions on different hosts’ access to the classes of service for different individuals, which might need to be handled in some enterprises with some sort of 802.x-based enforcement on the allowed markings from that host, and/or with client identity via client certs for the mapping service connection.

Describing these details and how to make them satisfy the needed use cases are left as an exercise for the prospective authors of this proposal, but to my mind (without having tried to write it all out) there seem like reasonable and tractable approaches that can be defined in the same way as for other services, or listed as out-of-scope details that may or may not be required for implementations to support.

All that said, I should give a disclaimer and clarify that it’s possible some of these underspecified details might make the whole approach non-viable for some reason I haven’t thought of yet.  This is really just a brainstorming idea at this stage, not a fully realized proposal, so caveat emptor.  I don’t vouch for it entirely, I only claim that it sounds easier to me and more likely to succeed than making a static mapping actually work.

Best,
Jake
</JH>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 24 Apr 2020 16:55:18 -0700

Hi Ruediger ,

Thank you!

You are right about the 9 QCIs, way back (REL 8??). I see now, your comment
to private the QCI deployments and the local usage of DSCPs. Let's leave
this for a moment now. Though there were bunch of QCI's defined for LTE,
only very few QCIs are in use widely (default bearer and voice bearers). We
can see the number of defined QCIs increased over a period of time.

Coming to 5G stuff, lot of things changed especially on how this whole
things is handled in 3GPP domain i.e., the equivalent 5QI and dynamic QFIs
(one example).   But it's expected given the expanded types of UEs and
types of traffic more types of 5QIs would be in use (again who knows how
this turns out). I also see some gaps (hence some of my questions below),
which leads me to question even with all the effort of carving out new code
points as this document proposed, if the mapping can be achievable.

Yes, one approach as you said below, could be to wait for emerging QCIs and
then start acting.  However, my take on this would be progressing the
analysis the way this document attempting but not fully tied to QCIs (if
possible of course, as what I suggested changes the whole scope).
Appreciate all the efforts from authors. It can also focus on aggregates
first as opposed to individual flow level mappings.  The best approach
would be to make this in a generic way, where one usage of this could be in
cellular domain (LTE/5G). So we don't have to depend fully on any
particular generation and can also be used for beyond 3GPP traffic.

There is a need in shared transport scenarios to have not only  for
standardized mapping but also for new PHB definition for vendor agnostic
deployment in the transport network.

Best,
--
Uma C.

On Wed, Apr 22, 2020 at 11:51 PM <[email-masked]> wrote:

> Hi Uma,
>
>
>
> Originally, there were 9 standard LTE QCIs (QCI 1 to 9). When I worked on
> that topic, I saw a list of deployed LTE QCIs. They were in the range 1xx
> and I was told, that deployment of these “private QCIs” was quite common.
> At that time (I don’t claim anything else).
>
>
>
> I then started to ask for use of standard QCIs. There was neither a
> standard nor an agreement to deploy, say, QCI 1 for mobile telephony. Then
> I found out, that one mobile carrier supported mobile telephony by standard
> QCI 1 and another one by standard QCI 5 (my recollection may be wrong on
> the exact value).
>
>
>
> My take: if the assignment of standard and/or private QCI is left to
> mobile carriers and that context is local only in a similar way as the
> deployment and interpretation of DSCP is left to local schemes of IP
> network operators, then I think there’s no need to assign fixed standard
> QCI to standard DSCP mappings.
>
>
>
> Another approach might be to wait and see whether some QCIs see frequent
> deployment or whether categories of similar applications are frequently
> supported by differentiated QCIs (where the QCIs might differ per provider,
> whereas the idea of assigning differentiated treatment to the category of
> application is identical). Once that has become clear, a generic mapping
> proposal QCI to DiffServ might be useful. That could be done independently
> of the above approach.
>
>
>
> Regards,
>
>
>
> Ruediger
>
>
>
> *Von:* Uma Chunduri <[email-masked]>
> *Gesendet:* Donnerstag, 23. April 2020 05:09
> *An:* Jerome Henry (jerhenry) <jerhenry=[email-masked]>
> *Cc:* Geib, Rüdiger <[email-masked]>; [email-masked]
> " If private QCIs are part of 5G, are they used by large enterprises too?
> I know that private QCIs saw fair deployment at the start of LTE. The draft
> I am not really aware of these used in LTE networks (but I could be
> wrong). Not really sure what do you mean by private QCI ? Could you plz
> clarify:
>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 24 Apr 2020 17:07:49 -0700

Hi Jake,

Quick comments below

I’m glad it’s possibly helpful.  I’ll try to answer your questions and
> expand a bit on the vision I had in mind, responses are inline with
> <JH></JH>
>

> *Date: *Monday, April 20, 2020 at 11:31 AM
> *To: *"Holland, Jake" <[email-masked]>
> *Cc: *"jerhenry=[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [tsvwg] Draft diffuser to QCI v04 posted
>
*Date: *Monday, April 20, 2020 at 11:31 AM
*To: *"Holland, Jake" <[email-masked]>
*Cc: *"jerhenry=[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
>
*Subject: *Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jake,

<JH>
The “(s)” in “carrier(s)” is the trickiest part here, I think, and a major
> driver for proposing a dynamic approach.
>

right; but I would note, even in single carrier scenario this could
potentially give vendor agnostic behavior.

I assume here that the different carriers might have different markings for
> similar PHBs that might be hard for them to change. (For instance, the
> choices might be from hardware-driven constraints from their vendors, or
> perhaps due to things like legacy internal use cases within the carrier
> that drove an assignment some time ago, which now can’t be easily changed.)
>

this should/need not be the case, say, if new code points are proposed
(depending on the type of traffic we are talking, of course).

The proposal is intended as a way that the carrier has the ability, with a
> relatively simple deployment of a simple service, to advertise the right
> markings that should be used for that network, and that these can be
> different from network-to-network, yet still usable by hosts, with apps
> that have a use for specific, named PHBs for their traffic.
>
</JH>

very good start!

Best,

--
Uma C.

---

From: "Luis M. Contreras" <[email-masked]>
Date: Sat, 25 Apr 2020 12:48:28 +0200

Hi all,

sorry for jumping late.

I think we are missing part of the motivations for having  guidance on the
mapping of QCI/QFI to DSCP. I think we all agree on the fact that this
should be informational and that each operator can perfectly ignore or
apply this partially or totally. However it is yet a valuable exercise,
precisely to guide some (or all) mappings. These are some other arguments
on favor of it, just to name a few:

.- some operators are not "single-network" operators. A guidance on how to
map  QCI/QFI to DSCP across the footprint of affiliates can help in
different ways, as e.g. to have a common ground for detecting problems in
the design of a particular network, functioning of some equipments, etc;
.- in some cases different vendors have different implementations with
respect to specific features. This happens, for instance, in the mobile
arena where some vendors have the possibility of separating e.g. S1
interface from X2, or even S1-U and S1-C. This sometimes deal to different
mappings when carried on the backhaul.
.- traffic carried is much more than external applications. Traffic tyoes
such as synchronism, core network control, routing, traffic from fixed
services, etc will be there. Even this is not in the scope of the draft, it
helps to have a comprehensive overview will help also to understand how the
rest of the traffic outside QCI/QFIs can me accomodated in a multi-service
network .
.- This kind of exercise can also help for benchmarking and network
migration/merging processes

The point is that we (operators) are in a point where 5G networks start to
be deployed, so it is a good moment for reconsidering mappings since the
networks have to be adapted to the new situation.

Best regards

Luis

El sáb., 25 abr. 2020 a las 2:07, Uma Chunduri (<[email-masked]>)
escribió:

> [email-masked] <40akamai.com@dmarc..ietf.org>> wrote:
>
>> Hi Jerome,
>>
>
>>
> I assume here that the different carriers might have different markings
>> for similar PHBs that might be hard for them to change. (For instance, the

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Sun, 26 Apr 2020 23:20:10 +0000

Hi Ruediger,

Thank you for this exchange. It is not without reminding me a similar exchange we have about  a year ago on very similar lines.
A few more thoughts inline (greyed out the rest to limit noise).

Take care

Jerome

Date: Thursday, April 23, 2020 at 11:07 AM

Hi Jerome,

Regards, Ruediger

  *   if not all standard LCIs are deployed, is there a real need for one fixed DSCP per standard LCI mapping – or might generic guidance be a reasonable alternative?
[Jerome] If we could know which traffic types combinations are never encountered together on any network, then we could bet on using the same DSCP for both. But I am not sure that we can make this determination, and also it may be possible that a transport network may honor DSCP and carry traffic from multiple entities. This led me to the conclusion that it was preferable to establish a complete list (what maybe Jake calls ‘a library’), with expression of intent for each and possible label, avoiding label overlap as frequently as possible.
[RG] We follow different philosophies here, I think. I prefer to aggregate traffic and consume as little codepoint and mapping space to keep configuration and operation simple. Neither are DSCPs binding, nor is QCI deployment or assignment to applications binding. For me, these are too many “may” to base activity upon.
[Jerome] It seems that 3GPP also follows the ‘race to more’ route, defining more QCIs over the years.  I am not supporting the idea that each application should have its own label, this seems overkill to me. But I do recognize that 3GPP now has defined applications that do not fit in our model (RFC4594 or another). One first step in my view is to defining a working map we can rely on when addressing these traffic categories.

[Jerome] I am not sure if we are using different words for the same thing or if there is something deeper. Our goal is not to address the domains boundaries, how traffic enters domains etc. It is obvious than any third party B between entity A (maybe a carrier) and an entity C (maybe an enterprise) would have an effect on the traffic carried between A and C through B, in particular QoS. Quite obviously as well, entity B may have a contractual link with either A or C (or both) to determine a particular treatment for traffic going to C. In backbones where Layer 2 or Layer 2.5 technologies, like MPLS, are deployed, a VPN can carry traffic with treatment consistency. But our goal is not define the architecture of an enterprise whose traffic goes through both links, where they interconnect, which third party is there, what kind of tunnel they use etc. Our goal is to create a map, whereby if a device sends traffic that matches QCI 85, we have a way to express what that could be in the Diffserv domain. Similarly, we need a way, for example, for a utility company sending high voltage automation messages, and deciding to use both paths, to know that such traffic is described as QCI 85, and find an equivalent in DIffserv.
As for the above RFCs, we do not address WebRTC specifically, so I am not sure that the draft above applies. However, the draft is compatible with RFC5127, although we do not address this network location. As for RFC4594, we qupote it 46 times, and it is foundational for our work.

Regards,

Ruediger

Hi Jake,

Take care

Jerome

Hi Jerome,

Best regards,
Jake

Dear tsvwg,

Best

Jerome

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 27 Apr 2020 00:26:37 +0000

Hi Jerome,

I wanted to clarify one thing that I perhaps didn’t explain well in my proposal.

from multiple entities. This led me to the conclusion that it was preferable to establish a complete list (what maybe Jake calls ‘a library’), with expression of intent for each and possible label, avoiding label overlap as frequently as possible.

<JH>
My intent with the term “library” was something more like a dynamically linked shared executable object that runs on a host operating system—something along the lines of libxml, zlib, or libresolv, which could be linked into programs running on the host OS to provide functionality through API calls that host applications could use.

The functionality I was proposing to provide in this library was to do a service discovery and lookup into a network-provided web API, to find the network provide mapping from name to codepoint through that web API.

The complete list you describe with well-known names mapped to feature descriptions would be a new registry, similar to the service names registry but hopefully smaller (e.g. https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)

This registry and the names in it would be known to the app, the library, and the web service providing the codepoint mapping for the network.

I just wanted to clarify the terminology I intended, since from your comment I wasn’t sure whether I had made it clear enough, since it seemed like you were describing what I’d call a “registry”, but saying I’d call it a “library”, and I realized I might have been too loose with the terminology.  I guess this is part of why a proper proposal is supposed to be written up as an internet draft instead of a hasty email ;)

HTH.

Best regards,
Jake
</JH>

---

From: <[email-masked]>
Date: Mon, 27 Apr 2020 06:27:09 +0000

Hi Jerome,

Thanks and you are right, we discuss this time and again.

I’d definitely appreciate mentioning private QCIs (and later types of private QoS identifiers) and put them out of scope.

With regard to our different approaches of course, if we knew the future, our actual decisions were made appropriate.

Regards,

Ruediger

Von: Jerome Henry (jerhenry) <[email-masked]>
Gesendet: Montag, 27. April 2020 01:20
An: Geib, Rüdiger <[email-masked]>
Cc: [email-masked]
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Ruediger,

Take care

Jerome

Hi Jerome,

Regards, Ruediger

From: Jerome Henry (jerhenry) <[email-masked]<mailto:[email-masked]>>

Regards,

Ruediger

Hi Jake,

Take care

Jerome

Hi Jerome,

Best regards,
Jake

Dear tsvwg,

Best

Jerome

---

From: <[email-masked]>
Date: Mon, 27 Apr 2020 09:35:33 +0000

Hi Luis,

thanks for your mail. My take is that nobody objects to work on mapping QCI/QFI to DiffServ. There are different approaches.

My experience with network provider DiffServ support is, that a different choice of DSCP should be expected (or not come as a surprise). Commonalities may be found with the Per-Hop Behaviours or the differentiation of performance. I also think to have understood, that wireless schedulers are offering more technical features to differentiate traffic, than for example backbone routers do. The question to me is, whether and how to ensure best, that the expected treatment results from the standards being agreed. To me, codepoint assignment is secondary to that. Generic standardizing treatment of codepoints in the case of mappings is desirable, fixing too many details isn’t my preferred approach (fixing to many details from start doesn’t match with the production environment I’m in – but as with the codepoints, I don’t expect any other network to be operated and engineered the way like the one I’m working with).
You’ve mentioned some constraints, like problem detection, mix of many applications demanding differentiated transport. Mine are ability to engineer, configure and operate, across an end-to-end chain of hardware of different purpose and vendors. QoS isn’t a local feature. Solutions, which work on one section of an end-to-end path may fail at another.

Regards,

Ruediger

Von: tsvwg <[email-masked]> Im Auftrag von Luis M. Contreras
Gesendet: Samstag, 25. April 2020 12:48
An: [email-masked]
Cc: Jerome Henry (jerhenry) <jerhenry=[email-masked]>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Holland, Jake <jholland=[email-masked]>
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi all,

sorry for jumping late.

I think we are missing part of the motivations for having  guidance on the mapping of QCI/QFI to DSCP. I think we all agree on the fact that this should be informational and that each operator can perfectly ignore or apply this partially or totally. However it is yet a valuable exercise, precisely to guide some (or all) mappings. These are some other arguments on favor of it, just to name a few:

.- some operators are not "single-network" operators. A guidance on how to map  QCI/QFI to DSCP across the footprint of affiliates can help in different ways, as e.g. to have a common ground for detecting problems in the design of a particular network, functioning of some equipments, etc;
.- in some cases different vendors have different implementations with respect to specific features. This happens, for instance, in the mobile arena where some vendors have the possibility of separating e.g. S1 interface from X2, or even S1-U and S1-C. This sometimes deal to different mappings when carried on the backhaul.
.- traffic carried is much more than external applications. Traffic tyoes such as synchronism, core network control, routing, traffic from fixed services, etc will be there. Even this is not in the scope of the draft, it helps to have a comprehensive overview will help also to understand how the rest of the traffic outside QCI/QFIs can me accomodated in a multi-service network .
.- This kind of exercise can also help for benchmarking and network migration/merging processes

The point is that we (operators) are in a point where 5G networks start to be deployed, so it is a good moment for reconsidering mappings since the networks have to be adapted to the new situation.

Best regards

Luis

El sáb., 25 abr. 2020 a las 2:07, Uma Chunduri (<[email-masked]<mailto:umac.ietf@gmail..com>>) escribió:
Hi Jake,

Quick comments below

On Thu, Apr 23, 2020 at 1:31 PM Holland, Jake <jholland=[email-masked]<mailto:40akamai.com@dmarc..ietf.org>> wrote:
Hi Jerome,

From: "Jerome Henry (jerhenry)" <jerhenry=[email-masked]<mailto:[email-masked]>>
Date: Monday, April 20, 2020 at 11:31 AM
To: "Holland, Jake" <[email-masked]<mailto:[email-masked]>>
Cc: "jerhenry=[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tsvwg] Draft diffuser to QCI v04 posted
Date: Monday, April 20, 2020 at 11:31 AM
To: "Holland, Jake" <[email-masked]<mailto:[email-masked]>>
Cc: "jerhenry=[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jake,

<JH>

right; but I would note, even in single carrier scenario this could potentially give vendor agnostic behavior.

I assume here that the different carriers might have different markings for similar PHBs that might be hard for them to change.. (For instance, the choices might be from hardware-driven constraints from their vendors, or perhaps due to things like legacy internal use cases within the carrier that drove an assignment some time ago, which now can’t be easily changed.)

this should/need not be the case, say, if new code points are proposed (depending on the type of traffic we are talking, of course).
The proposal is intended as a way that the carrier has the ability, with a relatively simple deployment of a simple service, to advertise the right markings that should be used for that network, and that these can be different from network-to-network, yet still usable by hosts, with apps that have a use for specific, named PHBs for their traffic.
</JH>

very good start!

Best,

--
Uma C.

--
___________________________________________
Luis M. Contreras
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
Global CTIO unit / Telefonica

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Mon, 27 Apr 2020 17:54:57 +0000

Thank you Ruediger,

And apologies, you did mention private QCIs last year in your feedback of 04/20, I did not appreciate their importance back then, I’ll definitely mention them in the next version.

Take care

Jerome

Date: Monday, April 27, 2020 at 2:27 AM

Hi Jerome,

Regards,

Ruediger

Hi Ruediger,

Take care

Jerome

Hi Jerome,

Regards, Ruediger

Regards,

Ruediger

Hi Jake,

Take care

Jerome

Hi Jerome,

Best regards,
Jake

Dear tsvwg,

Best

Jerome

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Mon, 27 Apr 2020 18:53:20 +0000

Thank you Jake,

I think that I understand the logic better now , thank you for taking the time to explain. I think that the proposal has a lot of merit, and I wonder if it is a replacement, or an addition/customization of our current proposal.
There may be some difficulties of course, like with any scheme. One particular that comes to mind (causing the previous sentence) is a use case as follows (trying to be cautious so as not to expose customer-specific information):
Suppose a location where maintenance of large objects is performed. A/R is used to display the internal expected map and state of particular pieces of equipment (tablet with AR). Because the objects are large, multiple contractors are on the floor working on their respective parts. Several of them use dual path, through the local Wi-Fi and through LTE, each through the carrier(s) the individual contractor company  contracted with.
Wouldn’t we face the risk to see on the local network AR marked differently based on which carrier the contractor is using?
(this could be limited if there were a common marking reference the enterprise could turn to).

Also, on a personal note, I am of the impression that such service would be very useful, but is not something I hear carriers asking for (but my visibility is limited). I am not sure how enthusiastic the carrier community would be to have to implement a service in order to share a marking scheme (vs 101 negotiation with enterprises, or applying standard schemes, e.g. IR 34 or others). Would you have views on this point?

Take care

Jerome

From: "Holland, Jake" <[email-masked]>
Date: Thursday, April 23, 2020 at 4:31 PM
To: "Jerome Henry (jerhenry)" <jerhenry=[email-masked]>
Cc: "Jerome Henry (jerhenry)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jerome,

Hi Jake,

<JH>

<JH>

Best,
Jake
</JH>

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 27 Apr 2020 20:03:54 +0000

Hi Jerome,

I guess it depends what clamor you’re hearing.

I thought I understood you’re hearing clamoring for a need to coordinate the use of classes of service across different networks.

In response to that clamoring, I thought you came with a suggestion to solve it by doing some static codepoint assignments (or suggested values, at least) to achieve the coordination of classes of service.

Because we’ve seen before how poorly it goes when we try to suggest static codepoint assignments in the limited DSCP space, I thought I’d suggest addressing the need by letting networks continue to use local codepoint assignments without suggesting specific static values, and instead provide a standardized way to communicate the meaning of the localized assignments, so that service classes could still be coordinated between networks.

I guess if you don’t hear clamoring for the need to coordinate classes of service across networks, I’m not sure I understood your presentation.

The main premise of my responses in this thread is that I think the idea of static codepoint mappings seem doomed from the start and not worth working on here.

Of course dynamic mapping also is doomed if nobody is interested enough to invest in solving the underlying problem, but to me it seems less doomed because it wouldn’t mess up anyone’s existing assignments, and it would only need voluntary adoption where it’s useful, so incremental deployment would be possible wherever anybody chooses to roll it out, and vendors could develop solutions that would work for multiple different interconnects.  I assume only networks that have the need you described (to coordinate the use of service classes across networks) would be interested.

Anyway, I don’t mean to belabor the point, or to spend undue time and list space on fleshing out a brainstorming idea that doesn’t sound useful to you, I just wanted to offer the suggestion as a possible path forward, rather than suggesting that you abandon hope of finding a way to coordinate the classes of service across networks.

But best of luck with the problem, however you choose to approach it.

Best,
Jake

PS: In case it’s useful, in answer to your technical question:

I would imagine that to support different markings on different interfaces for a multi-homed mobile device, you would need a per-interface mapping that applies markings for the desired class differently to connections that use different outbound interfaces (or even sub-connections if there are multipath connections).  Or if there’s an overlay layer that hides the multi-homing from the app, the mapping would have to be handled there instead.

There are certainly technical complexities here that would need fleshing out in prototypes and testing in the networks that have a need to coordinate service classes, and the only reason I would consider suggesting it is because it’s less complex than convincing all the carriers to agree to a specific static mapping of codepoints.

I think enterprises with specific apps that need to work and specific carriers they’re integrating with can achieve this without operating a lookup service by statically building their apps to use hardcoded codepoints that work for their carriers, and negotiating with their carriers to get the interconnections and codepoints worked out in whatever way works for them.

But if this were easy for enterprises to arrange, I wouldn’t think you’d be reporting the need to solve the coordination problem I thought you were describing.

But like I said, I don’t want to push this idea if it doesn’t sound useful, so I’ll bow out now, hoping I’ve made myself adequately understood, with best wishes and a thank-you for the intriguing conversation.

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Monday, April 27, 2020 at 11:53 AM
To: "Holland, Jake" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [tsvwg] Draft diffuser to QCI v04 posted

Thank you Jake,

Take care

Jerome

Hi Jerome,

Hi Jake,

<JH>

<JH>

Best,
Jake
</JH>