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

[<[e-mail]>]

Hi Jerome,

thanks; some replies marked [RG]

Regards, Ruediger

[snip]

   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?

[RG] My understanding: as long as the packet travels along one of the QCI's or bearers of the 3GPP world, the QoS is determined by the bearer (or whatever the thing is called...it's connection oriented) and the DSCP is meaningless. At the interconnection interface between mobile carrier and network provider, the DSCP depends upon the SLA and policies in place. Diffserv Intercon, RFC8100, makes sense there. Whenever DSCPs play a role inside the mobile domain, they are likely no standard ones.

[RG] I stopped being active on the subject some years ago, when I figured out that there are many more proprietary QCIs, which saw deployment and on the other hand no obligatory support for the standard QCIs (neither a mapping of service to standard QCI nor an obligation to support at least a fixed set of standard QCI). I don't claim all that still to be the case today. Unless you've checked these aspects with a mobile carrier, I understand your motivation, but I doubt that the result is helpful.

[RG] Your draft should mention the local use / proprietary QCIs, especially if their deployment is a commodity. I didn't follow actual developments, but I think it is necessary to check that.

[RG] When I was active on the topic, I've asked my mobile branch folks which QCI's are going to be supported in the case of roaming. The response was, the one we all agree upon, meaning QCI 9. And I think to recall that there even wasn't agreement between mobile carriers to support QCI 1 for telephony.
As an aside, your draft should also cover the aspect of roaming. 

     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.

[RG] As far as I'm aware of it, the DSCP's are ignored starting from the first Policy Decision Point of the mobile carrier. I don't have trouble with IR.34, apart from the Interactive traffic class with the 4 DSCPs of three different AF Ordered Aggregates. That partially motivated my work on RFC 8100.

    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.

[RG] That's the part I understood. My question is, whether there's a demand expressed by mobile carriers deploying 3GPP to provide such a standard. 


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