Subject: [tsvwg] 5G, DiffServ and new PHBs

From: <[email-masked]>
Date: Mon, 27 Apr 2020 07:18:16 +0000

Hi Uma, hi Jerome,

regarding codepoints, policies, PHBs and generic approaches, I’d like to add some thoughts…

A first question is, whether you expect DSCPs to bear a standardized end to QoS information for traffic crossing the Internet. I do not. In my experience, the only environment where DSCPs remain unchanged end-to end are tunneled networks and VPNs.

From what I can tell, in a backbone traffic is either loss and delay tolerant or it isn’t. In a backbone, a delay bound is a routing decision, not a scheduling decision, I think.

All consumer access Diffserv deployments I’m aware of come with one or more policy decision points. The one closest to the user doesn’t trust DSCP markings, no matter where they were set. That said, it means that DiffServ policy is based on other criteria than DSCP. Traffic not meeting these criteria is transported by default PHB and marked appropriately.

The only case where there’s trust in DSCPs at these policy decision points is tunneled traffic. But these aren’t consumer access types. The DSCPs accepted by the policy decision points in that case is well defined and small. The number and value of DSCPs within a tunnel can be arbitrary and I have no knowledge about it. Further, DSCPs are mapped (or transported unchanged in the case of a VPN) at interconnection interfaces with a related SLA in place.

From reading mobile specifications, I think to understand that scheduling may cover:

  *   Instant or delayed transmission
  *   A higher or a lower bit-error probability
  *   please add other aspects, like admission control/guaranteed service or guaranteed minimum bandwidth and so on.

New PHBs may be reasonable. But the architecture where these apply should be defined. I think 3GPPs standards inform their reader, that QCIs and their QoS are only valid for the RAN and there for the wireless section, but not end-to-end. That is why GSMA IR.34 aggregates 9 QCI into 4 classes.

An example is bit error rate. It is the same for all packets independent of the queue configuration in a backbone and on a fixed network access. Differentiation doesn’t add value there. Simple configuration and operation then adds values and is preferable to me.

I’m not sure if and then how a datacenter determines (preferred) processing (I mean some way of attaining more resources or faster processing). I’m not sure, whether a DSCP is relevant or the only relevant information there. From my understanding of Segment Routing, there are other options to carry that information, address or label based, I think. I add this, as 5G also intends to support machine to machine communication.

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

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

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]<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,

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 <[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,

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]<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,

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]<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,

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: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Mon, 27 Apr 2020 15:04:33 +0000

Hi Ruediger,

I do not expect DSCP to bear a standardized, consistent throughout, QoS information for a packet crossing the Internet. By its very nature, the Internet has too many paths controlled by different actors for such scheme to be either enforceable or even reliably measured.  I think that the many experiments  ran by tsvwg participants has established this point over and over.
However, I do believe (and observe) that DSCP can be used to carry QoS information within an AS, of between 2 ASes, 2 entities, agreeing on a common scheme for some traffic set. Do you agree with this statement? I am not sure if the VPN case you are raising is equivalent or different, if the VPN crosses multiple un-coordinated entities, if it runs through the backbone of a single entity or it is thought for a different scenario. Also, I am not sure if your statement about DSCP “being accepted is well-defined and small”  refers to RFC 4594, or if you are saying that most of RFC 4594 is not useful.
It seems that “DSCPs are mapped (or transported unchanged in the case of a VPN) at interconnection interfaces with a related SLA in place” is exactly the scenario I list above and in multiple iteration in the thread below.
When the 2 entities are carriers, I expect that they can decide of a joint labelling scheme without the draft we are proposing, using any scheme they agree upon, which can be the IR 34 or something else.  The draft becomes useful when one of the entities is an enterprise.
You mention that the architecture where this applies needs to be specifically defined. I am not fully aligned with this idea. RFC 4594, for example, does not go upon defining network architectures, VPNs and other interconnects where the classifications would be restricted to. The RFC is more general, proposing a scheme that can be used, if it is useful, across segments where the scheme can be applied with consistency. The same goes for our draft. It does not define architectures, does not even attempt to define what treatment should be applied to each flow. It merely aims at providing a translation mechanism between traffic labels.

I also think that it is clear (in 3GPP various TS specifications and in the draft we propose) that the QCI is  a label. The label represents a traffic type, and (j 3GPP) the expected requirements for that traffic. One consequence of such specification has bearing on the resources allocated in the RAN. This is very fitting, because WiFi6, (for example, and ‘as it is called now’) defines scheduling allocation using OFDMA, which outcome is not without resemblance to what can be done on the RAN. Thus the same treatment could be achieved in both radio links, if some traffic can be labelled in a comparable manner (and thus its associated expected treatment qualified) on both links. Then, of course, the treatment in the core, in the slice etc. uses scheduling/ queuing etc. This is clear in 3GPP, and is also clear in the Diffserv world (see for example RFC 4594 1.4). The label itself is merely a representation of the traffic type, it does not guaranty any treatment (scheduling etc.). However, treatment cannot happen for traffic that is neither described nor understood. Our contribution aims at providing a map to allow this characterization, this label.

Hope this helps

Best

Jerome

From: "[email-masked]" <[email-masked]>
Date: Monday, April 27, 2020 at 3:18 AM
To: "[email-masked]" <[email-masked]>, "Jerome Henry (jerhenry)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: 5G, DiffServ and new PHBs

Hi Uma, hi Jerome,

 Hi Ruediger ,

Thank you!

Best,
--
Uma C.

Regards,

Ruediger

a)  Document says
" This

   Internet."

Thanks in advance.

--
Uma C.

(please see inline)

Take care

Jerome

Hi Jerome,

Regards,

Ruediger

Hi Jake,

Take care

Jerome

Hi Jerome,

Best regards,
Jake

Dear tsvwg,

Best

Jerome

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 27 Apr 2020 15:24:36 -0700

quick comments in-line..

(stuff in agreement is removed).

--
Uma C.

regarding codepoints, policies, PHBs and generic approaches, I’d like to
> add some thoughts…
Thx!

A first question is, whether you expect DSCPs to bear a standardized end to
> QoS information for traffic crossing the Internet. I do not. In my
> experience, the only environment where DSCPs remain unchanged end-to end
> are tunneled networks and VPNs.
>

>
>From what I can tell, in a backbone traffic is either loss and delay
> tolerant or it isn’t. In a backbone, a delay bound is a routing decision,
> not a scheduling decision, I think.
>

All consumer access Diffserv deployments I’m aware of come with one or more
> policy decision points.
Right; see below further on this.

...

> New PHBs may be reasonable. But the architecture where these apply should
> be defined. I think 3GPPs standards inform their reader, that QCIs and
> their QoS are only valid for the RAN and there for the wireless section,
> but not end-to-end.
>

Right and the assumption of only RAN and wireless section (aka their core
network) will be simply insufficient  as the transport network in between,
simply can't provide anything they are seeking (let alone preserve if any
processing benefits that traffic might have got there). Here assigning new
PHBs and consistent definition *may*  help for the end-to-end SLA
objectives (this is the one of the points  - end-to-end in not internet).

That is why GSMA IR.34 aggregates 9 QCI into 4 classes.
So, we can leave all 23.501/5QIs classification to leave it somebody or
make it generic (one aspect of the draft under discussion is doing
classification too and support that effort). But may not be necessary to
carve out the all new code points. I leave that to authors of the proposal
and you as being discussed in the other thread.

I’m not sure if and then how a datacenter determines (preferred) processing
> (I mean some way of attaining more resources or faster processing). I’m not
> sure, whether a DSCP is relevant or the only relevant information there.
>

Can be relevant in some places as policy input, see below.

>From my understanding of Segment Routing, there are other options to carry
> that information, address or label based, I think. I add this, as 5G also
> intends to support machine to machine communication.
>

Slightly off topic though (yes, loosely relevant). You have very little
possibility in SR-MPLS (no space) and for SRv6 you one can do lot of things
i.e., in the address itself (if used as SID), SRH bits or TLVs??. But only
if this is used/deployed as a preferred option as the TE mechanism in the
transport.  On the other hand, mapping this in the DSCP field in the
original IP header (v4/v6) or outer header if traffic is tunneled helps
policy  inputs as you alluded above but also can potentially achieve more
in the E2E model (beyond RAN and cellular core).

---

From: "Black, David" <[email-masked]>
Date: Mon, 27 Apr 2020 23:06:36 +0000

Hi Jerome,

> Also, I am not sure if your statement about DSCP “being accepted is well-defined and small”  refers to RFC 4594, or if you are saying that most of RFC 4594 is not useful.

I’m not Ruediger ... but as his co-author of RFC 8100, I’d suggest reading that RFC to provide some insight into the network environment from which his comments arise.  This particular comment refers to the customer-facing side of a network, in contrast to RFC 8100 being about interconnection of networks, but that RFC will nonetheless provide some insight into how backbone networks differ from enterprise networks in which RFC 4594 can be more aggressively applied.

In general, I’d suggest continuing to assemble use cases where this draft is useful (and write them up in the draft).  I like the dual-path use case that is at the bottom of this thread:

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

Thanks, --David (as an individual)

From: tsvwg <[email-masked]> On Behalf Of Jerome Henry (jerhenry)
Sent: Monday, April 27, 2020 11:05 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] 5G, DiffServ and new PHBs

[EXTERNAL EMAIL]
Hi Ruediger,

Hope this helps

Best

Jerome

To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Jerome Henry (jerhenry)" <[email-masked]<mailto:[email-masked]>>

Hi Uma, hi Jerome,

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

 Hi Ruediger ,

Thank you!

Best,
--
Uma C.

Regards,

Ruediger

a)  Document says
" This

   Internet."

Thanks in advance.

--
Uma C.

(please see inline)

Take care

Jerome

Hi Jerome,

Regards,

Ruediger

Hi Jake,

Take care

Jerome

Hi Jerome,

Best regards,
Jake

Dear tsvwg,

Best

Jerome

---

From: <[email-masked]>
Date: Tue, 28 Apr 2020 09:13:46 +0000

Hi Jerome,

Thanks. My replies marked [RG] in your text, marked (jerhenry) by me.

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

Hi Ruediger,

(jerhenry)   I do not expect DSCP to bear a standardized, consistent throughout, QoS information for a packet crossing the Internet. By its very nature, the Internet has too many paths controlled by different actors for such scheme to be either enforceable or even reliably measured.  I think that the many experiments  ran by tsvwg participants has established this point over and over.
(jerhenry)  However, I do believe (and observe) that DSCP can be used to carry QoS information within an AS, of between 2 ASes, 2 entities, agreeing on a common scheme for some traffic set. Do you agree with this statement?
[RG] Two interconnecting parties can agree Diffserv and a codepoint scheme for the interconnection, so far I agree. My operational practice relating interconnection DSCP schemes to operator internal ones is documented by RFC8100. If your draft only refers to two interconnected networks or VPNs, it should inform the reader.

(jerhenry) I am not sure if the VPN case you are raising is equivalent or different, if the VPN crosses multiple un-coordinated entities, if it runs through the backbone of a single entity or it is thought for a different scenario.
[RG] A VPN to me is means an inner tunnel under the control of one party. I don’t make assumptions how many transport and transmission sections of how many other parties are crossed.

(jerhenry) Also, I am not sure if your statement about DSCP “being accepted is well-defined and small”  refers to RFC 4594, or if you are saying that most of RFC 4594 is not useful.
[RG] RFC4594 and 5127 give guidance on practice learned by the authors, configuration of queues and informs, that while many DSCPs are standardized, often only a subset is deployed. That is the useful part. Then it starts to suggest assigning applications per DSCP and there the motivation seems to be “there’s a standard DSCP and we must figure out an application (application class) to consume it”. That it is hard to engineer, complex in operation not easy to debug – and, at least concerning the environment I’m working with – not supportable by hardware along a longer chain of network elements by different vendors and hardware generations.

(jerhenry) It seems that “DSCPs are mapped (or transported unchanged in the case of a VPN) at interconnection interfaces with a related SLA in place” is exactly the scenario I list above and in multiple iteration in the thread below. When the 2 entities are carriers, I expect that they can decide of a joint labelling scheme without the draft we are proposing, using any scheme they agree upon, which can be the IR 34 or something else.  The draft becomes useful when one of the entities is an enterprise.
[RG] You seem to describe an interconnection of an enterprise with a carrier at a peering or upstream interface, which is not a VPN or tunnel. I admit not to have any recollection of such a case in my professional career. I’ve dealt or am aware of provider internal/external  business/consumer/carrier/VPN access/service production QoS. If your draft doesn’t address the latter or only partially addresses these, it should be clear to the reader which part offers guidance useful for a broader section of a market and which offers guidance for a particular environment.

(jerhenry) You mention that the architecture where this applies needs to be specifically defined. I am not fully aligned with this idea. RFC 4594, for example, does not go upon defining network architectures, VPNs and other interconnects where the classifications would be restricted to. The RFC is more general, proposing a scheme that can be used, if it is useful, across segments where the scheme can be applied with consistency. The same goes for our draft. It does not define architectures, does not even attempt to define what treatment should be applied to each flow. It merely aims at providing a translation mechanism between traffic labels.
[RG] To me that is where RFC4594 fails. The statement “only subset will be deployed” doesn’t match with “define assignment of applications to each DSCP” and “leave it to the reader to figure out end-to-end engineering, operation, interconnection and mapping”. That part is missing or covered insufficiently.

(jerhenry) I also think that it is clear (in 3GPP various TS specifications and in the draft we propose) that the QCI is  a label. The label represents a traffic type, and (j 3GPP) the expected requirements for that traffic. One consequence of such specification has bearing on the resources allocated in the RAN. This is very fitting, because WiFi6, (for example, and ‘as it is called now’) defines scheduling allocation using OFDMA, which outcome is not without resemblance to what can be done on the RAN.
[RG] I agree.

(jerhenry) Thus the same treatment could be achieved in both radio links, if some traffic can be labelled in a comparable manner (and thus its associated expected treatment qualified) on both links.
[RG] That is one option only, the “label bears a standardized end-to-end specification of identifying a qualified treatment”). The other option is, to specify the qualified treatment and ask the/each operator for the label assigned, without fixing a standardized end-to-end relation between label and treatment.

(jerhenry) Then, of course, the treatment in the core, in the slice etc. uses scheduling/ queuing etc. This is clear in 3GPP, and is also clear in the Diffserv world (see for example RFC 4594 1.4). The label itself is merely a representation of the traffic type, it does not guaranty any treatment (scheduling etc.). However, treatment cannot happen for traffic that is neither described nor understood. Our contribution aims at providing a map to allow this characterization, this label.
[RG] It is useful to specify which application benefits from which treatment, so far I agree. A set of defined treatments is useful too. These at best correspond to what can be expected by a broad section of vendor equipment, as soon a multi-operator and larger production chains apply. Operators likely prefer simplicity in engineering, operation, planning and evolution. If not all treatments are expected to see deployment, are there some which are useful and simple to deploy? Which treatments could replace others and what are the merits (simplicity) and tradeoffs? A review after years of operational experience would be good ?
The same holds for codepoints: If you don’t deploy the complete set of labels, which subset of codepoints is recommended? Please keep an eye on simple end-to-end operation and engineering (ignoring this aspect increases the likelihood of failing in a long QoS production chain).

Regards,

Ruediger

Hi Uma, hi Jerome,

 Hi Ruediger ,

Thank you!

Best,
--
Uma C.

Regards,

Ruediger

a)  Document says
" This

   Internet."

Thanks in advance.

--
Uma C.

(please see inline)

Take care

Jerome

Hi Jerome,

Regards,

Ruediger

Hi Jake,

Take care

Jerome

Hi Jerome,

Best regards,
Jake

Dear tsvwg,

Best

Jerome