Re: [tsvwg] Draft diffuser to QCI v04 posted

["Black, David" <[e-mail]>]

Hi Xuesong,

> I notice that in the previous email, the scenario of ”carrier to carrier interconnect”
> seems to be excluded from the scope of the document. If I understand this right,
> the “carrier to carrier interconnect” here means that the RAN or CN belongs to
> one carrier and the TN belongs to another carrier. I think this is the most general
> use case for “QCI/5QI and DSCP mapping” . Considering that this draft is supposed
> to be “informational”, I think there is no harm to include this scenario in the draft at this stage ☺

Among the relevant considerations is that RFC 4594 (Diffserv Service Classes) is Informational, but has had sufficient adoption to be viewed as a de facto standard by some.  The TSVWG chairs have had a number of discussions with 3GPP participants/representatives, and would want to ensure that covering this use case (even in an Informational document) is acceptable to 3GPP before including that use case in a draft that the WG adopts.  In those discussions, we have heard strong 3GPP objections to the IETF advising large mobile carriers on interconnections among themselves, or as Jerome writes:

>> We do not think that these actors [large Carriers] 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.

Thanks, --David (TSVWG co-chair)

From: tsvwg <[e-mail]> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Monday, April 13, 2020 11:44 PM
To: Jerome Henry (jerhenry); tsvwg
Subject: Re: [tsvwg] Draft diffuser to QCI v04 posted


[EXTERNAL EMAIL]
Hi Jerome,

Thank you for your work. I think it is especially  useful for 5G deployment.
I notice that in the previous email, the scenario of ”carrier to carrier interconnect” seems to be excluded from the scope of the document. If I understand this right, the “carrier to carrier interconnect” here means that the RAN or CN belongs to one carrier and the TN belongs to another carrier. I think this is the most general use case for “QCI/5QI and DSCP mapping” . Considering that this draft is supposed to be “informational”, I think there is no harm to include this scenario in the draft at this stage ☺

Best Regards
Xuesong

From: tsvwg [mailto:[e-mail]] On Behalf Of Jerome Henry (jerhenry)
Sent: Tuesday, April 14, 2020 2: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/).
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