Re: [tsvwg] Draft diffuser to QCI v04 posted

["Jerome Henry (jerhenry)" <[e-mail]>]

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

From: "[e-mail]" <[e-mail]>
Date: Monday, April 27, 2020 at 2:27 AM
To: "Jerome Henry (jerhenry)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: AW: [tsvwg] Draft diffuser to QCI v04 posted

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) <[e-mail]>
Gesendet: Montag, 27. April 2020 01:20
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

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

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, April 23, 2020 at 11:07 AM
To: "Jerome Henry (jerhenry)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: AW: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jerome,

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

Regards, Ruediger

From: Jerome Henry (jerhenry) <[e-mail]<mailto:[e-mail]>>



From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>



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

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


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




Von: tsvwg <[e-mail]<mailto:[e-mail]>> Im Auftrag von Jerome Henry (jerhenry)
Gesendet: Montag, 20. April 2020 20:31
An: jholland=[e-mail]<mailto:jholland=[e-mail]>
Cc: jerhenry=[e-mail]<mailto:jerhenry=[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> Im Auftrag von Holland, Jake
Gesendet: Dienstag, 14. April 2020 19:38
An: Jerome Henry (jerhenry) <jerhenry=[e-mail]<mailto:jerhenry=[e-mail]>>; tsvwg <[e-mail]<mailto:[e-mail]>>
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.

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=[e-mail]<mailto:jerhenry=[e-mail]>>
Date: Monday, April 13, 2020 at 11:01 AM
To: tsvwg <[e-mail]<mailto:[e-mail]>>
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