Re: [tsvwg] I-D Action: draft-henry-tsvwg-diffserv-to-qci-00.txt

["Jerome Henry (jerhenry)" <[e-mail]>]

Dear Ruediger,

Thank you for taking the time to look into this work.
Please allow me to add some context:
The scenarios described in annex A (from which you quoted scenario 1, but please note that there are 5 other scenarios in that annex) "are not intended to describe the details of the internetworking between the QoS mechanisms" (A.2). These scenarios are also described in the context of Annex A.1, which describes the network architecture considered relevant for the scope of 23.307. A.1 is simplified, but functional enough to be used as a starting point.
In scenario 1, the UE does not have an IP BS Manager. The PDP context is determined by the UE based on the application requirements (as per TS.23.228), this is of course for flows 'from' the UE. The other scenarios consider the various other combinations, where the UE performs IP BS functions or not, with various intermediate functions support. As a note, in some cases (described in 5.2. of 23.207), the UE may or may not be a Diffserv edge function. The UE may set its own DSCP values, but this case is uncommon (and does not resolve the question below).
The goal of annex 2 is to clarify which device performs which role, not to solve how the translation between UMTS QoS and DS QoS is performed (the 'internetworking between QoS mechanisms" above).

In general, there is on one side the UMTS domain (and its associated QoS functions) and on the other side the DS domain. What 23.207 (or 23.203 for that matter) does not solve is this:
When a bearer is allocated, for example, to a flow matching requirements of Discrete Automation and receives QCI 83, when the flow is sent into the DS domain, what marking should that flow carry?
Similarly, what is the significance of a packet received from the DS domain bearing, for example, CS4? TS.23.228 describes in great details service negotiation for IMS traffic, but this covers only a small subset of DS marking and intent. Similarly, GSMA IR.34 has limited its scope to only 4 types of flows.

This is what this work attempts to address: a mapping between the QoS expressions of intents in each domain, when packets are forwarded between domains. We do not intent to solve how LTE should decide of the internal QoS values on the RAN or within the LTE domain.

Hope this helps clarify.

Best

Jerome 




On 10/29/18, 7:08 AM, "[e-mail]" <[e-mail]> wrote:

    Hi Brian,
    
    thanks for the pointer to the draft. Before discussing details of the draft, I'm having some questions to the authors.
    
    Within 3GPP TS 23.207 V15.0.0 (2018-06), "3rd Generation Partnership Project;
    Technical Specification Group Services and System Aspects;
    End-to-end Quality of Service (QoS) concept and architecture
    (Release 15)"
    
    I found the following statement:
     	 
    The end-to-end QoS is provided by a local mechanism in the UE, the PDP context over the UMTS access network, DiffServ through the backbone IP network, and DiffServ in the remote access network in the scenario shown in the figure below. The GGSN provides the interworking between the PDP context and the DiffServ function.
    
    My take is, that the GGSN decides about the Diffserv markings to be set and it does so using a PDP context. DSCPs set by a UE don't matter then. From what I have read I think to understand, that DSCPs play a role within an LTE network only, if the schedulers there honor them. I've stopped being active in this area some years ago. I've not yet heard of an LTE network supporting any kind of DSCP based resource scheduling. Did this change? If it did not and DSCP settings depend on GGSN PDP context (at a wholesale or carrier internal interface, I assume), what's the point of this draft?
    
    Further, I searched TS 23.207 for "DSCP". The result is limited to a section where provider internal DSCPs are required only, but no standard ones:
    
    Annex S (normative):
    Fixed Broadband Access
    S.1	General
    This annex specifies the enhancement to PCC framework for supporting policy and charging control in the fixed broadband access network in the convergent scenario where a single operator is deploying both the fixed broadband access network and the Evolved Packet Core (EPC).....
    
    I'd like to understand which problem the draft addresses.
    
    Regards,
    
    Ruediger
    
    
    -----Ursprüngliche Nachricht-----
    Von: tsvwg <[e-mail]> Im Auftrag von Brian E Carpenter
    Gesendet: Montag, 29. Oktober 2018 02:20
    An: [e-mail]; [e-mail]
    Betreff: Re: [tsvwg] I-D Action: draft-henry-tsvwg-diffserv-to-qci-00.txt
    
    Hi,
    
    In https://tools.ietf.org/html/draft-henry-tsvwg-diffserv-to-qci-00#section-4.2.10
    we find:
    
    >    ...recommend Low-Priority Data be marked CS1 DSCP.
    > 
    >    Note: This marking recommendation may change in the future, as [LE-
    >    PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic
    >    and recommends an additional DSCP for this traffic.
    
    It seems to me that [LE-PHB] has advanced to the point where this recommendation should be the other way round: recommend the new LE codepoint, with a note that historically the CS1 codepoint has been (mis)used for this purpose.
    
    Regards
       Brian Carpenter