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

From: <[email-masked]>
Date: Mon, 11 May 2020 08:31:12 +0000

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. He doesn’t expect that to change.

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.

Regards,

Ruediger

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 11 May 2020 14:18:41 -0700

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

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

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Mon, 11 May 2020 23:07:01 +0000

Thank you Ruediger.

I am not sure to fully understand why using a QCI would remove spectrum (it would be congruent to say that DSCPs remove bandwidth on the Internet). I have been thinking about it for a good part of the day, and think that your colleague may be referring to the idea of your second paragraph, that if we allocate more QBRs, then we mechanically reduce access to other traffic, in order to ensure a guaranteed bearer. And if we guarantee bandwidth, we need to make sure that the BW is provided, which also mechanically constraints the access of other traffic over the same radio.

This definitely sounds consistent with what I hear as well. I must say that I have also heard a couple of times the statement “we implement Voice and BE, and don’t care about the rest” from some implementers. But I have also heard very different positions from many others. It seems that the disconnect may come from the notion of small number of users vs bigger number. In essence, it seems to me that a large cell deployed to connect a gazillion of UEs across a very large area will attempt to maximize the overall aggregated throughout. In this environment, I expect BE to be the norm, and Voice QCI to be a necessary luxury. As the cell size decreases, as deployment density (from one or more implementers in the same physical area), the conversation tends to shift to SLA as part of the value proposition. In these environments, I hear the “2 QCI” argument much less often. Obviously, I will not provide specifics, but I will say that implementations do exist, and they are not uncommon in my universe (thus the need for the mapping, it is not an academic exercise).

I remember, after hearing this point (“really only 2 QCIs in the field”) and asking my colleagues working in 3GPP how general this statement was (“it depends” and “it is far from being a universal truth” was their answer), I went to ask more generally (non-Cisco) 3GPP folks if 3GPP had been working, since release 8, year after year, release after release, to add new QCIs consistently, redesigning their scheme deeply with 5G, to put together a growing list of QCIs no one in fact really used or cared about. I think I still have planted in my back a butter knife that was thrown at me as I was running away. I am half joking, but you see my point. If there was 0 adoption, the effort to define more QCIs and deeply rethink the structure for 5QI would likely not have happened. So when I hear that adoption is there, but depends on the location and the implementer, I hear something that is consistent with what I hear about DSCP.

My 2 cents

Jerome

From: "[email-masked]" <[email-masked]>
Date: Monday, May 11, 2020 at 4:31 AM
To: "Jerome Henry (jerhenry)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: AW: 5G, DiffServ and new PHBs

Hi Uma, hi Jerome,

Regards,

Ruediger

---

From: <[email-masked]>
Date: Tue, 12 May 2020 06:35:10 +0000

Hi Jerome,

Thanks….you wrote “..If there was 0 adoption, the effort to define more QCIs and deeply rethink the structure for 5QI would likely not have happened. So when I hear that adoption is there, but depends on the location and the implementer, I hear something that is consistent with what I hear about DSCP.”

I think that holds. Would it be wrong to say, there’s little consistency (meaning two operators, same number of DSCP, same DSCP to PHB mapping)? That’s the picture I get every time I see a new DSCP to PHB mapping scheme (I don’t know about the 3GPP deployments).

Regards,

Ruediger

Von: Jerome Henry (jerhenry) <[email-masked]>
Gesendet: Dienstag, 12. Mai 2020 01:07
An: Geib, Rüdiger <[email-masked]>; [email-masked]
Cc: [email-masked]
Betreff: Re: 5G, DiffServ and new PHBs

Thank you Ruediger.

My 2 cents

Jerome

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 11, 2020 at 4:31 AM
To: "Jerome Henry (jerhenry)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: AW: 5G, DiffServ and new PHBs

Hi Uma, hi Jerome,

Regards,

Ruediger

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 12 May 2020 13:06:30 +0000

QCI’s with lower latency will be emitted first by the eNB

From: tsvwg <[email-masked]> On Behalf Of Jerome Henry (jerhenry)
Sent: Monday, May 11, 2020 7:07 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] 5G, DiffServ and new PHBs

Thank you Ruediger.

My 2 cents

Jerome

Hi Uma, hi Jerome,

Regards,

Ruediger

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Thu, 14 May 2020 15:30:07 +0000

Thank you Martin, makes sense.

Take care

Jerome

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tuesday, May 12, 2020 at 9:06 AM
To: "Jerome Henry (jerhenry)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: 5G, DiffServ and new PHBs

Thank you Ruediger.

My 2 cents

Jerome

Hi Uma, hi Jerome,

Regards,

Ruediger

---

From: Dave Taht <[email-masked]>
Date: Thu, 14 May 2020 08:37:13 -0700

> QCI’s with lower latency will be emitted first by the eNB

One of the things that seem to be underdefined (and left to the
operator) are the number of retries allowed for reliable transport at
this layer. I think for the voice queue it's in the range 8-100ms? For
the BE queue?

Are there any "typical" parameters for this?

Are there measured results for the typical retry distributions in
various circumstances?

-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

[email-masked] <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Thu, 14 May 2020 15:37:21 +0000

Hi Ruediger,

And thank you for your reply and for caring about this topic. I see indeed little consistency, meaning that 2 entities may implement a different QCI subset. Then, there seems to be the usual race to be king, where their enterprise customers (or the SP) fight around the usual “my traffic is of utmost importance, no doubt it should get DSCP 65 (joke intended)”… and we usually have to come in and wipe the floor from all the broken glass, spilled beer before sitting down to reconcile the views (gently explaining that ‘important’ does not necessarily mean sensitive to loss/jitter etc. in short rebuild RFC4594 around the QCis they chose to use).

Take care

Jerome

From: "[email-masked]" <[email-masked]>
Date: Tuesday, May 12, 2020 at 2:35 AM
To: "Jerome Henry (jerhenry)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: AW: 5G, DiffServ and new PHBs

Hi Jerome,

Regards,

Ruediger

Thank you Ruediger.

My 2 cents

Jerome

Hi Uma, hi Jerome,

Regards,

Ruediger

---

From: <[email-masked]>
Date: Mon, 18 May 2020 09:37:54 +0000

Hi Uma,

Thanks for the link, I read a little into your draft. It is closer to what I’d expect by having a policy point between 3GPP and IP network, which I think you refer to in section “2.2.  Front Haul Transport Network”. For the time being to me, the best way to signal the demand for a specific policy to an IP network is combining VPN/addressing/IP-Network-Operator-DiffServ and leave the rest to the preferred engineering of the operator. This still requires a fair amount of standards on policy options and their support, and also some common understanding between remote policy decision points. But it allows for separated deployment of functionality subsets in 3GPP and backbone/fixed network domains. To me, the latter should be as simple as possible, as both technologies so far evolve separately, one seemingly connection oriented (3GPP) and the other connectionless (IP network services).

Regards, Ruediger

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