[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
- [pcp] review on draft-penno-pcp-mobile-qos GangChen
- Re: [pcp] review on draft-penno-pcp-mobile-qos Tirumaleswar Reddy (tireddy)