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

GangChen <phdgang@gmail.com> Tue, 29 April 2014 06:07 UTC

Return-Path: <phdgang@gmail.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1971A884F for <pcp@ietfa.amsl.com>; Mon, 28 Apr 2014 23:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhB7xkCvI9IF for <pcp@ietfa.amsl.com>; Mon, 28 Apr 2014 23:07:00 -0700 (PDT)
Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7751A8840 for <pcp@ietf.org>; Mon, 28 Apr 2014 23:07:00 -0700 (PDT)
Received: by mail-qa0-f43.google.com with SMTP id ih12so5570349qab.30 for <pcp@ietf.org>; Mon, 28 Apr 2014 23:06:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MYzNEsgtewUxHvVsShtXdgyc1FRdkVI68+5ul/RslNA=; b=tlKNe9kkiauSoa8Xb26kbpJ0kWDVcNkrfeyjSgmiV75tYZBnqabQ5H8ZAzPy93x84q P3cqifm0+pVKUfYfPimMqvLwqyiXuPkIcP85YLSlYSj57jBfLsEOUsT32A0meWWSdRjA LY4NiYo4eKjVlhDQGhbbSJ6DO1247R9mqcBB/0fNrX0xNQkZBWZcmt7rm2SL0d2DTs4E jx8TAmXGBD+MVeBguX6j3EVDxhzZ91W1Xh6EP7aKKP89YMephw7e578Ox5HP6cOQ+urd EPEAF08F/d9C2nukjBnF2SVkR20Gk0q1Ft7GsFEq8vYEH44sgib0UJSBoAagqWdTF53I msxQ==
MIME-Version: 1.0
X-Received: by 10.224.61.200 with SMTP id u8mr39804420qah.18.1398751619403; Mon, 28 Apr 2014 23:06:59 -0700 (PDT)
Received: by 10.224.51.137 with HTTP; Mon, 28 Apr 2014 23:06:59 -0700 (PDT)
Date: Tue, 29 Apr 2014 14:06:59 +0800
Message-ID: <CAM+vMERs_30vaTwyrPD_Y_U-Anwv61m-Ftt+WqC6FPc_YJPXsQ@mail.gmail.com>
From: GangChen <phdgang@gmail.com>
To: "pcp@ietf.org" <pcp@ietf.org>, draft-penno-pcp-mobile-qos@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/RfTM7eqQYVsacqMCWJTCWooCAb8
Subject: [pcp] review on draft-penno-pcp-mobile-qos
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Apr 2014 06:07:02 -0000

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