[tsvwg] Re: 5QI to DiffServ DSCP Mapping for Slicing (was TR: [Teas] IETF 120 - TEAS WG - Session Logistics

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi Gorry, David, Med, all,

During IETF 119 there was a question from Lou (as TEAS chair) on the chat of TEAS WG meeting about to explain the differences between draft-cbs-teas-5qi-to-dscp-mapping and draft-henry-tsvwg-diffserv-to-qci, which is referenced in the former draft, and that was presented to TSVWG.

There are a number of similarities but also differences. Both drafts try to relate the quality indicators in the Radio Access Network (RAN) part, as defined by 3GPP, with DSCP values interpretable by the network (transport network in 3GPP terminology). The departing point from draft-henry-tsvwg-diffserv-to-qci was to define such relationship based on the type of communication service being delivered, so following an application-centric approach.

In draft-cbs-teas-5qi-to-dscp-mapping we follow a different strategy. Here we refer to the characteristics / properties associated to such quality indicators (i.e., 5QI / QCI) in terms of expected latency, packet-loss as well as the nature of the flows (i.e., guaranteed bit rate vs non-guaranteed bit rate). After such characterization there is a proposal of grouping indicators according to similar expected behavior, with the aim of providing afterwards a common DSCP marking to such groups. The reason for it is that the number of queues in the network elements is limited, so similar services / applications can be allocated to the same queue in terms of QoS expectation. So we can call this approach as behavior-centric.

Apart from this different approach, draft-cbs-teas-5qi-to-dscp-mapping covers both 4G and 5G quality indicators (i.e., QCI and 5QI), and also extends the initial approach to the consideration of fronthaul traffic as proposed by radio functional splits as proposed in O-RAN.

The motivation of bringing this work initially to TEAS is because this association of characteristics / properties derived from the indicators (including the idea of grouping) is closely related to the concept of network slicing, in our understanding.

Please, note that the intention of the draft is NOT to do any kind of modification or proposal for changing anything about QCI/5QI, which is a subject of standardization of 3GPP in TS-23.501. Furthermore, we are NOT intending to standardize any particular association, grouping or mapping. We are just proposing a way (i.e., procedure) of considering 5QIs when requiring DSCP marking in the network.

Hope this clarifies better the purpose behind the draft. For sure, as very next steps, we can consider to present the draft at TSVWG as soon as it is possible (IETF 121?) for receiving the proper feedback from the working group.

Thanks,

Best regards

Luis, Krzysztof and Ivan


De: Gorry Fairhurst <[e-mail]>
Enviado el: viernes, 19 de julio de 2024 16:53
Para: Black, David <David.Black=[e-mail]>; [e-mail]; [e-mail]
CC: [e-mail]; [e-mail]; Black, David <[e-mail]>
Asunto: Re: [tsvwg] Re: 5QI to DiffServ DSCP Mapping for Slicing (was TR: [Teas] IETF 120 - TEAS WG - Session Logistics

AVISO/WARNING: Este correo electrónico se originó desde fuera de la organización. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro / This email has been originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On 19/07/2024 15:05, Black, David wrote:
Hi Med,
[+teas list]

Thanks for the pointer – IMHO, the specific DSCP mappings also ought to be discussed in tsvwg.  Beyond the mappings, the draft contains a lot of 5G and MPLS material for which teas is likely to be a better forum.

The draft's reference to draft-henry-tsvwg-diffserv-to-qci brings up some important context.  Back when draft-henry-tsvwg-diffserv-to-qci was considered in tsvwg, 3GPP was strongly opposed to any IETF standardization (even via an Informational RFC) of QCI/5CI – Diffserv (including DSCP) mappings, especially for public (carrier) networks.  Has that 3GPP position changed since then?

Thanks, --David (a former tsvwg chair)

+1 on what David said.... Let's try to make sure that anything DSCP-related is presented to tsvwg if this draft proceeds, and reviewed there.

I's suggest also that the MPLS-related topics belongs in a WG that has that scope.

Best wishes,

Gorry (as TSVWG Co-Chair)

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição