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

From: GangChen <[email-masked]>
Date: Tue, 29 Apr 2014 14:06:59 +0800

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.

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

   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.

   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.

       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?

   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.

BRs

Gang