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

["Gengxuesong (Geng Xuesong)" <[e-mail]>]

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:[e-mail]]
Sent: Wednesday, December 11, 2019 4:56 AM
To: Gengxuesong (Geng Xuesong) <[e-mail]>; Thomas Fossati <[e-mail]>
Cc: tsvwg IETF list <[e-mail]>
Subject: Re: [tsvwg] <tsvwg> Using NQB in mobile network

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)" <[e-mail]<mailto:[e-mail]>>
Date: Monday, December 9, 2019 at 7:18 PM
To: Thomas Fossati <[e-mail]<mailto:[e-mail]>>, Greg White <[e-mail]<mailto:[e-mail]>>
Cc: tsvwg IETF list <[e-mail]<mailto:[e-mail]>>
Subject: RE: [tsvwg] <tsvwg> Using NQB in mobile network


Hi Thomas,



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



Best Regards

Xuesong



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

>From: Thomas Fossati [mailto:[e-mail]]

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

>To: Gengxuesong (Geng Xuesong) <[e-mail]<mailto:[e-mail]>>;

>[e-mail]<mailto:[e-mail]>

>Cc: tsvwg IETF list <[e-mail]<mailto:[e-mail]>>; Thomas Fossati

><[e-mail]<mailto:[e-mail]>>

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

>

>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.



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



>

>>  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.)



[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?



>

>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.