Re: [tsvwg] Draft diffuser to QCI v04 posted

[Uma Chunduri <[e-mail]>]

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=
[e-mail]> wrote:

> Thank you Ruediger,
>
>
>
> (please see inline)
>
>
>
> Take care
>
>
>
> Jerome
>
>
>
> *From: *"[e-mail]" <[e-mail]>
> *Date: *Tuesday, April 21, 2020 at 4:04 AM
> *To: *"Jerome Henry (jerhenry)" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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.
>
>
>
> 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.
>
> [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 <[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]> *Im Auftrag von *Holland, Jake
> *Gesendet:* Dienstag, 14. April 2020 19:38
> *An:* Jerome Henry (jerhenry) <jerhenry=[e-mail]>;
> tsvwg <[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]>
> *Date: *Monday, April 13, 2020 at 11:01 AM
> *To: *tsvwg <[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
>
>
>
>
>