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

[Vishnu Pavan Beeram <[e-mail]>]

Agree that this draft needs to also be introduced and discussed in TSVWG.
As noted earlier, the 00 version of the draft was presented in the IETF 119
TEAS session. Please refer to the corresponding meeting notes [1] for the
brief discussion that ensued (and the questions posed by the chairs). We
(TEAS WG chairs) expect the questions related to the target home for this
draft and the relationship with the referenced tsvwg draft to be discussed
in this Thursday's TEAS WG session.

With respect to interaction with 3GPP, we (TEAS WG) have been sending
regular liaisons to 3GPP on WG adopted network slicing related work. If
this draft were to eventually get adopted in TEAS (note that it is still
early days for the draft -- we haven't yet determined the right home for
this), the same practice would be followed and feedback would be sought
from 3GPP.

Regards,
- Pavan, Lou and Oscar

[1]
https://notes.ietf.org/notes-ietf-119-teas?view#09-1420--10-min--Title-5QI-to-DiffServ-DSCP-Mapping-Example-for-Enforcement-of-5G-End-to-End-Network-Slice-QoS

On Tue, Jul 23, 2024 at 2:46 AM Black, David <David.Black=
[e-mail]> wrote:

> Hi Luis and everyone,
>
>
>
> The explanation of the differences in approach is helpful, and I apologize
> for the intrusion of procedural concerns into technical discussion.  With
> the passage of time (4-5 years), 3GPP's views may have changed, plus the
> scope of this draft is considerably less aggressive than the prior scope of
> draft-henry was ... but ... there's still a potential for problems:
>
>
>
> > 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.
>
> Unfortunately, draft-henry had the same intention at the time (4-5 years
> ago).
>
>
>
> > 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.
>
> That "procedure" would be a standard for use of 5QIs, which would likely
> have fallen within the scope of 3GPP's prior strenuous objections.
>
>
>
> On a more positive note, there was some process-oriented discussion of
> this draft in an IETF-3GPP coordination meeting earlier today.  IMHO, that
> discussion suggests that if there's WG interest in adopting this draft,
> then prior to actual adoption, it would be good to ascertain whether 3GPP's
> views in this area have changed via a liaison statement from the WG to 3GPP
> (and a response).  If 3GPP's views have changed to accommodate IETF work in
> this area, then that liaison process should not pose any problems.
>
>
>
> I will plan to attend the discussion of this draft in the TEAS meeting
> later this week.
>
>
>
> Thanks, --David
>
>
>
> *From:* LUIS MIGUEL CONTRERAS MURILLO <
> [e-mail]>
> *Sent:* Saturday, July 20, 2024 9:12 PM
> *To:* Gorry Fairhurst <[e-mail]>; Black, David <David.Black=
> [e-mail]>; [e-mail]; [e-mail]
> *Cc:* [e-mail]; [e-mail]; Black,
> David <[e-mail]>; Ivan Bykov <[e-mail]>; Krzysztof
> Szarkowicz <[e-mail]>
> *Subject:* RE: [tsvwg] Re: 5QI to DiffServ DSCP Mapping for Slicing (was
> TR: [Teas] IETF 120 - TEAS WG - Session Logistics
>
>
>
> [EXTERNAL EMAIL]
>
> 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
> _______________________________________________
> Teas mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>