Re: [pcp] review on draft-penno-pcp-mobile-qos

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Gang,

Thanks for the review. Please see inline

> -----Original Message-----
> From: GangChen [mailto:[e-mail]]
> Sent: Tuesday, April 29, 2014 11:37 AM
> To: [e-mail]; [e-mail]
> Subject: [pcp] review on draft-penno-pcp-mobile-qos
> 
> Hello Authors,
> 
> I have reviewed the draft. The below is the comments.
> 
>    However, the Mobile Network may not
>    trust the host (UE) to signal the correct flow characteristics
>    permitted by the WebRTC server.
> 
> => If you take look at TR23.701, 3GPP prefers WebRTC signalling function serving
> a AF to customize the policy. WebRTC signalling function entity is aware of the
> flow characteristics, afterwards the entity could direct correct network actions.
> So, I guess the sentence of "However" we could remove.

In TR23.701, WebRTC service (AF) is co-located in the Mobile Network, this scenario is also discussed in http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-03#section-4.3. This draft is solving a different problem of prioritizing the media streams for Over-the-top (OTT) services. For example let's say WebRTC service is provided by a social networking site that has tie-up with the Mobile network. In this case, Mobile Network needs a mechanism to identify the media streams trigged because of using the social networking site to provide differentiated service. 

> 
> 
>        For third party applications differentiated QoS
>        services can be installed even if the UE is behind NAT provided
>        by the Mobile Network.  In contrast, other mechanisms struggle to
>        install differentiated QOS if the UE is behind NAT.
> 
> => Te scenario you indicated may worth to be clarified. You may indicate the
> case where there the bearer in PGW is identified by private 5 tuple and PCRF asks
> PGW to binding a Service Data Flow with public address. Looking at the
> architecture of TR23.701, it's may not happened at this time, because there is no
> NAT between PGW and WebRTC signalling function entity(AF).

Yes, as I have previously explained it's not a problem when the AF is co-located in the Mobile Network. It's a problem when the AF is a third party provider not co-located in the Mobile Network but has tie-up with the Mobile operator.
 
> 
> 
>    b.  Mobile Network can authorize the differentiated service request
>        from third party application because the proposed mechanism is
>        compliant with the 3GPP's network-triggered QoS policy
>        enforcement model.
> 
> => AF(from third party) assigns particular policies to PCRF, which translate
> application specific language to 3GPP compliant. I guess there is no need to ask
> 3rd party app informs PCRF 3GPP specific language.

No, the 3rd party application is not using PCRF 3GPP specific language. At high-level the mechanism suggested in the draft is as follows:
PCP client obtains a cryptographic token obtained from the third party WebRTC signaling function entity (AF) and includes the token in the PCP request with the flow characteristics signaled in PCP FLOWDATA. PCP server in the Mobile network validates the token and grants the request. It's based on http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-03. 

> 
> 
>    1.  It is out of scope of this document to discuss the trade-offs
>        between the proposed approach vs. deploying local WebRTC-IMS
>        Gateways within the Mobile Network.
> 
> => It's an important information. May I suggest elaborate this information in the
> main body. It also would be good to say what the relation of local WebRTC-IMS
> solution to the proposed solution.

The proposed solution in the draft is not targeting WebRTC-IMS solution.

> 
> 
>        PCP success response would be sent without waiting
>        for network-initiated bearer activation or modification to be
>        complete: i.e., PCP success response would be sent based on the
>        resource availability to setup or modify bearers.
> 
> why not waiting for the completion of EPC bearer allocation ?

The idea is to quickly respond to the PCP request, otherwise the client have to wait for the response.  The success response is sent only if there are sufficient resources available to setup bearers.

> 
>    3.  The PDN-GW will communicate with the PCRF to trigger the
>        appropriate Policy charging and control (PCC) decision based on
>        which PDN-GW will initiate bearer activation or modification
>        procedure.
> 
> I can't understand the intention of PCRF selecting different PGWs. The process
> the draft described is more like ADC procedure. The PGW monitor the particular
> event (i.e. PCP request in this draft) and inform PCRF, after then PCRF only needs
> to permit the resource usage on the initiated PGW.

PCRF is not selecting different PGWs. It's just following the procedure given in 3GPP TS 23.401 section "PDN GW initiated bearer modification with bearer QoS update".

Cheers,
-Tiru

> 
> 
> BRs
> 
> Gang