Re: [tsvwg] Draft diffuser to QCI v04 posted

[[e-mail]]

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 <[e-mail]> Im Auftrag von Jerome Henry (jerhenry)
Gesendet: Montag, 20. April 2020 20:31
An: jholland=[e-mail]
Cc: jerhenry=[e-mail]; [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