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

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

Hi Ruediger,

Thanks for your comments. Additional thoughts marked [jh]

Best

Jerome

On 10/30/18, 1:20 AM, "[e-mail]" <[e-mail]> wrote:

    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. 
[jh] Agree, and this is not the domain that this draft addresses.

 [RG] 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.
[jh] this is where we play (at the interconnection interface). RFC 8100 is an option to simplify network operations, the draft we suggest is another option. Our goal is by no mean to diminish the value of RFC 8100, suggest that it is not sufficient or anything along those lines. Our goal is to suggest a set of intent translation mechanisms that  more closely look at each individual value (QCI for one direction, DSCP for the other).

    
    [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.
[jh] Duly noted, thank you for the candid feedback. As a side note, it happens that our work is not merely theoretical and coming out of thin air, but the result of countless exchanges with service providers (please see further below).
    
    [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.
[jh] We had a lot of exchanges on this topic. As you know, part of the work in 3GPP, that saw the explosion of QCI counts over the last few years, came from a need to normalize proprietary QCIs that were commonly used. Although we know that there are still proprietary QCIs (just like there are locally-significant DSCP configurations and values), we are not sure that we can suggest a standardized translation mechanism for proprietary values (beyond the provision we make about proprietary values in 2.4 and 3.).
    
    [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. 
[jh] I am not sure I am following your logic here. If roaming occurs so that packets would transit through a DS domain, then the draft makes sense. Otherwise, IR.34 or intra-domain logic would imply. I am not sure why roaming should be a special case.
    
         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.
[jh] I guess then that the logic ("ignore DSCP" or "consider DSCP") depends on the service provider. This conversation would be a bit long for an email exchange, but we do not get the sense that an aggregate would be sufficient anymore in the upcoming years for all cases.
    
        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. 
[jh] There is indeed a demand from the market (this is the reason why we came to work on the topic). Glad to provide more names verbally if you are in Bangkok.    

    
    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