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

[Uma Chunduri <[e-mail]>]

Hi  Ruediger,


I have a problem with this topic overall w.r.t 5G.
Various threads and in the draft we are discussing too things are mixed up
with 4G/LTE stuff and 5G.
QoS and QCI framework is thoroughly  changed in 5G and what is in the
packet doesn't directly represent the categories draft analyzes.

I asked authors of the draft (which triggered this discussion and
separate thread) 2 questions. I yet to receive response from them.

But, leaving that aside I see the spirit of your question is still valid.

in-line [Uma]:

On Mon, May 11, 2020 at 1:31 AM <[e-mail]> wrote:

> Hi Uma, hi Jerome,
>

>
after having had a brief discussion with a colleague working on mobile
> service development, I’d like to add a piece of information. He mentioned
> that deployment of QCIs comes at a cost of coding space / wireless
> spectrum. To better utilize wireless spectrum, so far deployment is often
> limited to one QCI suitable for telephony and one for Best Effort.
>
[Uma]: That is correct and I indicated that earlier (the other one is for
control plane/signaling traffic).



> He doesn’t expect that to change.
>
[Uma]: Yes for 4G/LTE.
            But given all the efforts  in 23.501 around this, one would
expect things would be different in 5G.


>

>
He mentioned that supporting more QCIs gives those in some cases guaranteed
> bandwidth, which will cause blocking of other transmissions until the QCI
> served terminal received its bandwidth (my terminology might be less than
> optimal here). The resulting effect is, that a small number of users
> experience fair Quality of Service, while a bigger number users faces a
> service degradation.
>

>
I recommend to verify that. If that holds, I’d appreciate appropriate text
> in IETF work relating DiffServ and 3GPP QCIs. To me one point to be
> discussed then is, whether IETF should set aside reserves or build
> mechanisms to support technologies of other SDOs, also if the latter are
> not deployed at significant scale.
>
[Uma]: I would still the same  as I said earlier i.e., make broader
categories and make it generic. This would enable deployments beyond 3GPP
domain. My interest on this would be is slightly different as we faced lot
of difficulty as the bits on the packet doesn't contain this information to
map it to underlying TE transport  as described here
https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-06


>
Regards,
>

>
Ruediger
>

>
>
>
>
>
>
>