Subject: Re: [tsvwg] <tsvwg> Using NQB in mobile network

From: Thomas Fossati <[email-masked]>
Date: Thu, 5 Dec 2019 23:13:08 +0000

Hi Xuesong,

On 05/12/2019, 07:13, Geng Xuesong wrote:
> I notice that in section 7.2, you mentioned that "To support the NQB
> PHB, the mobile network MUST be configured to give UEs a dedicated,
> low-latency, non-GBR, EPS bearer ... or Data Radio Bearer..."

First, whatever we say in 7.2 should be at the RECOMMEND level.  Any
MUST in that section is wrong in principle -- my bad.  This will be
fixed in -01.

>  I'm a little confused about why NQB is limited to provide service for
>  non-GBR service. I think considering the low latency and congestion
>  avoidance feature of NQB, it is more suitable for delay-critical GBR
>  defined in 3GPP TR23.501, or do you have any other considerations in
>  this point?

Now to your main point, per the PHB definition (Section 5, third para):

   NQB traffic SHOULD NOT be rate limited or rate policed separately
   from queue-building traffic of equivalent importance.

Which looks incompatible with an implementation of the PHB that routes
NQB through a GBR bearer and QB via non-GBR.  (And this looks to me like
the only option here since we don't want QB on GBR.)

It is still possible to get what you have in mind, but that needs a
second dedicated low-latency GBR bearer.  So you could do the first
split between QB and NQB based on the DSCP marking and then have a
further bisection inside the NQB class and say that, e.g., UDP:12345
warrants delay-critical treatment and therefore gets mapped to the
GBR bearer whereas the rest receives the "normal" NQB handling.

cheers, thanks
t

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 10 Dec 2019 02:18:31 +0000

Hi Thomas,

Thank you for your response. Please find the comments in line.

Best Regards

Xuesong

>-----Original Message-----

>From: Thomas Fossati [mailto:[email-masked]]

>Sent: Friday, December 06, 2019 7:13 AM

>To: Gengxuesong (Geng Xuesong) <[email-masked]>;

>[email-masked]

>Cc: tsvwg IETF list <[email-masked]>; Thomas Fossati

><[email-masked]>

>Subject: Re: [tsvwg] <tsvwg> Using NQB in mobile network

>First, whatever we say in 7.2 should be at the RECOMMEND level.  Any MUST

>in that section is wrong in principle -- my bad.  This will be fixed in -01.

[XS] Thank you for the modification, and this will make it easy to understand.

>Which looks incompatible with an implementation of the PHB that routes NQB

>through a GBR bearer and QB via non-GBR.  (And this looks to me like the only

>option here since we don't want QB on GBR.)

[XS] If we follow the original logic of NQB, I agree with you, because there is no guarantee of latency or data rate for NQB, so it is not suitable for GBR or delay-critical GBR. However, if we check the possible applications of NQB(e.g., online game, real-time IoT analytics data, mentioned in section 3 of the draft), we could find that it belongs to GBR or delay-critical GBR, for example:
Resource Type :GBR
Default Priority Level :30

Example Services : Real Time Gaming, V2X messages Electricity distribution – medium voltage, Process automation - monitoring

Which is defined in Table 5.7.4-1 of TS 23.501

>It is still possible to get what you have in mind, but that needs a second

>dedicated low-latency GBR bearer.  So you could do the first split between QB

>and NQB based on the DSCP marking and then have a further bisection inside

>the NQB class and say that, e.g., UDP:12345 warrants delay-critical treatment

>and therefore gets mapped to the GBR bearer whereas the rest receives the

>"normal" NQB handling.

[XS] I think you are right, it works if we split the NQB again. But I'm afraid it will make the problem really complex.

If we could have bisection inside the NQB class, why NQB could be mapped to delay-critical GBR from the first place?

>IMPORTANT NOTICE: The contents of this email and any attachments are

>confidential and may also be privileged. If you are not the intended recipient,

>please notify the sender immediately and do not disclose the contents to any

>other person, use it for any purpose, or store or copy the information in any

>medium. Thank you.

---

From: Greg White <[email-masked]>
Date: Tue, 10 Dec 2019 20:55:31 +0000

Hi Xuesong,

In my view, an operator can always set up specialized handling of certain traffic, regardless of which DSCP happens to be in the packet headers.  If there is a specialized service for which the operator wishes to establish GBR or delay-critical GBR bearers, they would need to set up classifiers (TFT) to match the desired application traffic.  If this traffic happened to carry the NQB DSCP, that is fine, but this specialized treatment is different from the NQB PHB (i.e not compliant with the PHB definition).

Does that help?
-Greg

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Monday, December 9, 2019 at 7:18 PM
To: Thomas Fossati <[email-masked]>, Greg White <[email-masked]>
Cc: tsvwg IETF list <[email-masked]>
Subject: RE: [tsvwg] <tsvwg> Using NQB in mobile network

Hi Thomas,

Best Regards

Xuesong

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 11 Dec 2019 03:20:30 +0000

Hi Greg,

Thank you for your explanation.
I agree with you, it is flexible for mobile network QoS system to set up new rule about flow classification. However, I am just considering whether this exposes some mismatch between 5G QoS system and transport  QoS system. New 5QI is defined for delay-critical applications in 5G, but there is no corresponding DSCP in fixed network. I think NQB is a good start to discuss how to deal with these kind of flows, because it is able to provide relative high-quality service for latency sensitive applications. So maybe it could be considered to relax the restriction in the draft about that UE has to be given a non-GBR Data Radio Bearer.
By the way, perhaps I have missed some previous discussions, and I am not sure whether there exists core confliction between NQB and bit rate guarantee. In my understanding, NQB itself doesn’t provide bit rate guarantee, but considering it is suitable for  “traffic at relatively low data rates and/or in a fairly smooth and consistent manner”, it could be used for service that requires bandwidth reservation, although bandwidth reservation should be provided by other mechanisms. If this is acceptable, maybe it will be easier to allow UE to be given a GBR or delay-critical GBR when using NQB PHB.

Best Regards
Xuesong

From: Greg White [mailto:[email-masked]]
Sent: Wednesday, December 11, 2019 4:56 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; Thomas Fossati <[email-masked]>
Cc: tsvwg IETF list <[email-masked]>
Subject: Re: [tsvwg] <tsvwg> Using NQB in mobile network

Hi Xuesong,

Does that help?
-Greg

From: "Gengxuesong (Geng Xuesong)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 9, 2019 at 7:18 PM
To: Thomas Fossati <[email-masked]<mailto:[email-masked]>>, Greg White <[email-masked]<mailto:[email-masked]>>
Cc: tsvwg IETF list <[email-masked]<mailto:[email-masked]>>
Subject: RE: [tsvwg] <tsvwg> Using NQB in mobile network

Hi Thomas,

Best Regards

Xuesong

>To: Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>;

>[email-masked]<mailto:[email-masked]>

>Cc: tsvwg IETF list <[email-masked]<mailto:[email-masked]>>; Thomas Fossati

><[email-masked]<mailto:[email-masked]>>

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 11 Dec 2019 04:45:16 +0000

Hi Xuesong,

On 10/12/2019, 20:55, "Greg White" <[email-masked]> wrote:
> In my view, an operator can always set up specialized handling of
> certain traffic, regardless of which DSCP happens to be in the packet
> headers.  If there is a specialized service for which the operator
> wishes to establish GBR or delay-critical GBR bearers, they would need
> to set up classifiers (TFT) to match the desired application traffic.
> If this traffic happened to carry the NQB DSCP, that is fine, but this
> specialized treatment is different from the NQB PHB (i.e not compliant
> with the PHB definition).

What Greg said, and a couple of additional notes:

The intent here is to provide a more adequate treatment (and supposedly
better QoS) to the sparse, application-limited flows that are currently
pushed through the same queues as capacity seeking flows in the mobile
core and radio.

It doesn't aim to be perfect, we are just trying to grab an optimisation
opportunity that has been lingering for a while.

To keep the game in balance we need to have the right set of incentives
(you tell the truth, you win; you lie, you lose) and checks (trust but
verify, via queue protection) that minimise the opportunity for
cheating.  ISTM that giving NQB markers a guaranteed bit-rate over QB
would modify those premises quite substantially.

The main target is Internet-bound flows.  Customer specific low-latency
services can still exist on top or parallel to NQB.

Cheers, thanks!

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 11 Dec 2019 09:09:37 +0000

Hi Thomas,

Thank you for making clarification.

I think there is no basic disagreement between us. You are trying to explain NQB from the view of technology. In that point, I think NQB is well defined and the whole logic behind it is very reasonable(the flows that won't contribute to the congestion are separated and buffered in an independent queue ). What I am trying to do is just to think it from the other side: applications, especially 5G applications. Which applications are the real potential use cases for NQB? The resource type of these applications in 5G system should be non-GBR, GBR or delay-critical GBR is just a small point coming from this. (Maybe if the question of editor’s note :“How can an application determine whether it is queue building or not” in section 3 is answered, all these application relevant questions will be more clear)

Best Regards

Xuesong

>Sent: Wednesday, December 11, 2019 12:45 PM

>To: Greg White <[email-masked]>; Gengxuesong (Geng Xuesong)

><[email-masked]>

>On 10/12/2019, 20:55, "Greg White" <[email-masked]<mailto:[email-masked]>> wrote:

>The intent here is to provide a more adequate treatment (and supposedly better

>QoS) to the sparse, application-limited flows that are currently pushed through

>the same queues as capacity seeking flows in the mobile core and radio.

>To keep the game in balance we need to have the right set of incentives (you tell

>the truth, you win; you lie, you lose) and checks (trust but verify, via queue

>protection) that minimise the opportunity for cheating.  ISTM that giving NQB

>markers a guaranteed bit-rate over QB would modify those premises quite

>substantially.