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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Oct 2018 14:19:44 +1300

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

---

From: <[email-masked]>
Date: Mon, 29 Oct 2018 10:58:38 +0000

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 <[email-masked]> Im Auftrag von Brian E Carpenter
Gesendet: Montag, 29. Oktober 2018 02:20
An: [email-masked]; [email-masked]
Betreff: Re: [tsvwg] I-D Action: draft-henry-tsvwg-diffserv-to-qci-00.txt

Hi,

>    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

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Mon, 29 Oct 2018 16:08:55 +0000

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, "[email-masked]" <[email-masked]> wrote:

    Hi Brian,

    

    
    
    Annex S (normative):
    Fixed Broadband Access
    S.1	General

    Regards,
    
    Ruediger

    -----Ursprüngliche Nachricht-----
    Von: tsvwg <[email-masked]> Im Auftrag von Brian E Carpenter
    Gesendet: Montag, 29. Oktober 2018 02:20
    An: [email-masked]; [email-masked]
    Betreff: Re: [tsvwg] I-D Action: draft-henry-tsvwg-diffserv-to-qci-00.txt
    
    Hi,

    
    
    Regards
       Brian Carpenter

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Mon, 29 Oct 2018 16:09:43 +0000

Thank you Brian,

We'll make that correction in the next iteration of the draft, great to hear the news!

Best,

Jerome 

On 10/28/18, 9:19 PM, "Brian E Carpenter" <[email-masked]> wrote:

    Hi,

    
    
    Regards
       Brian Carpenter

---

From: <[email-masked]>
Date: Tue, 30 Oct 2018 08:19:49 +0000

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 

    Hi Brian,

    

    
    
    Annex S (normative):
    Fixed Broadband Access
    S.1	General

    Regards,
    
    Ruediger

    -----Ursprüngliche Nachricht-----
    Von: tsvwg <[email-masked]> Im Auftrag von Brian E Carpenter
    Gesendet: Montag, 29. Oktober 2018 02:20
    An: [email-masked]; [email-masked]
    Betreff: Re: [tsvwg] I-D Action: draft-henry-tsvwg-diffserv-to-qci-00.txt
    
    Hi,

    
    
    Regards
       Brian Carpenter

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Tue, 30 Oct 2018 15:26:36 +0000

Hi Ruediger,

Thanks for your comments. Additional thoughts marked [jh]

Best

Jerome

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

    Hi Jerome,

    Regards, Ruediger
    
    [snip]

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

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

    [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 

    
    
        Hi Brian,

        

        
        
        Annex S (normative):
        Fixed Broadband Access
        S.1	General

        Regards,
        
        Ruediger

        -----Ursprüngliche Nachricht-----
        Von: tsvwg <[email-masked]> Im Auftrag von Brian E Carpenter
        Gesendet: Montag, 29. Oktober 2018 02:20
        An: [email-masked]; [email-masked]
        Betreff: Re: [tsvwg] I-D Action: draft-henry-tsvwg-diffserv-to-qci-00.txt
        
        Hi,

        
        
        Regards
           Brian Carpenter

---

From: <[email-masked]>
Date: Wed, 31 Oct 2018 12:42:41 +0000

Hi Jerome,

the thread below gets longer, if I continue discussion. I think, we might have a philosophical difference (which can't and doesn't have to be solved). I prefer less QoS classes and prefer to think of them by their bulk transport properties only. Bob Briscoe's work on L4s sets the minimum solution: either transport creates congestion at a bottleneck and copes with it or transport avoids congestion. 

My impression is, that 3GPP QCIs and your draft assign DSCPs much closer to applications and partially suggests fine-grained solutions. I note that also https://www.ietf.org/id/draft-ietf-tsvwg-rtcweb-qos-18.txt assigns around a dozen DSCP for browser based applications. 

I'm not able to join the meeting in Bangkok. I hope to be able to make it to Prague and maybe we could meet there.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Jerome Henry (jerhenry) <[email-masked]> 
Gesendet: Dienstag, 30. Oktober 2018 16:27
An: Geib, Rüdiger <[email-masked]>
Cc: [email-masked]; [email-masked]
Betreff: Re: [tsvwg] I-D Action: draft-henry-tsvwg-diffserv-to-qci-00.txt

Hi Ruediger,

Best

Jerome

    Hi Jerome,

    Regards, Ruediger
    
    [snip]

    

    

    Best
    
    Jerome 

    
    
        Hi Brian,

        

        
        
        Annex S (normative):
        Fixed Broadband Access
        S.1	General

        Regards,
        
        Ruediger

        -----Ursprüngliche Nachricht-----
        Von: tsvwg <[email-masked]> Im Auftrag von Brian E Carpenter
        Gesendet: Montag, 29. Oktober 2018 02:20
        An: [email-masked]; [email-masked]
        Betreff: Re: [tsvwg] I-D Action: draft-henry-tsvwg-diffserv-to-qci-00.txt
        
        Hi,

        
        
        Regards
           Brian Carpenter