[netext] Review of I-D: draft-ietf-netext-pmip6-qos-02
Basavaraj Patil <bpatil1@gmail.com> Mon, 13 May 2013 19:19 UTC
Return-Path: <bpatil1@gmail.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id 412E521F896B for <netext@ietfa.amsl.com>;
Mon, 13 May 2013 12:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_33=1, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dHJXsaxkeFu for
<netext@ietfa.amsl.com>; Mon, 13 May 2013 12:19:35 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com
[IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id
4672321F8956 for <netext@ietf.org>; Mon, 13 May 2013 12:19:35 -0700 (PDT)
Received: by mail-ob0-f169.google.com with SMTP id vb8so1119278obc.28 for
<netext@ietf.org>; Mon, 13 May 2013 12:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:x-received:date:message-id:subject:from:to
:content-type; bh=nxFrMKpKv5VvOFrDPSeMAUsrZqmb3UgxbR6UAiiy/nQ=;
b=SNNje6FTfilNeIpiR2W3zVxsFFb9p3Vl0h6GWcm8b9FpHSRukMOZ1839DXQjU5KPl5
AuE9HljO23qVtXklt2ZOEC4rhPjsEGvjU/q3+H0h2HEVGMrmRT7VQxTL8KMmi5vWIkUs
cKt0naAw++k9jbCSyjgGXi3y8tVtHRARVBRWTBkxamV86eXKCC3fLBVFH+B2QBOjncLh
VcrRiHjrlDUX65W3Dc+/kR2m7kCPUaVfqqw41gUYP9YnacFZNtnbKOtqTYu1hN3dQcUC
OUM+/jqYbTuMZCRn6YwAd/3fa+jn94aHYKcnEj2eGhOEMi5XOk7gGg1ASJz8/rT7WNon lTMw==
MIME-Version: 1.0
X-Received: by 10.60.96.35 with SMTP id dp3mr14357672oeb.21.1368472774803;
Mon, 13 May 2013 12:19:34 -0700 (PDT)
Received: by 10.76.180.165 with HTTP; Mon, 13 May 2013 12:19:34 -0700 (PDT)
Date: Mon, 13 May 2013 14:19:34 -0500
Message-ID: <CAA5F1T2jaFYQpUw4eostxToWe_RiW3aZHsFRvNCqPdrYvgLwag@mail.gmail.com>
From: Basavaraj Patil <bpatil1@gmail.com>
To: "netext@ietf.org" <netext@ietf.org>
Content-Type: multipart/alternative; boundary=089e011775a7a0884704dc9e652a
Subject: [netext] Review of I-D: draft-ietf-netext-pmip6-qos-02
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility
protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>,
<mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>,
<mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2013 19:19:36 -0000
Below are my review comments for the I-D:draft-ietf-netext-pmip6-qos-02 (QoS Support for Proxy Mobile IPv6) Questions/Comments: 1. "Using the QoS option, the local mobility anchor and the mobile access gateway can exchange available QoS attributes and associated values." QoS for a session or subscriber or group of sessions? Not clear from this statement. 2. "This enables QoS policing and labeling of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway." So is the objective primarily to enable QoS on the MAG<->LMA path? Or is the intent to deliver QoS information to the MAG for use on the access link? Or both? 3. "Furthermore, making QoS parameters available on the MAG enables mapping these parameters to QoS rules being specific to the access technology which operates below the mobile access gateway." Would this mapping be defined elsewhere? As an example how would you translate the QoS parameters defined between the MAG<->LMA for use on an 802.11 air interface? Who would define this mapping (if it needs to be specified). 4. "Current standardization effort considers strong QoS classification and enforcement for cellular radio access technologies." What standardization effort is being referred to here? 5. "QoS policies are typically controlled by a policy control function, ...." The I-D assumes a very specific network architecture (in this case 3GPP EPS). It would be better to indicate the applicability or assumptions. 6. "Policy control and QoS differentiation for access to the mobile operator network through alternative non-cellular access technologies is not yet considered, even though some of these access technologies are able to support QoS by appropriate traffic prioritization techniques." Not sure how this is relevant in the scope of this I-D. 7. "... alternative radio access technologies, such as IEEE802.16 " Would be good to include EV-DO, SCDMA as other technologies as well... 8. " whereas inter-working with the cellular architecture to establish QoS policies in alternative access networks has not been focussed on so far." The WG is better off defining a mechanism that is not specific to the current version of 3GPP standards or access technologies being considered. 9. "...has been identified as promising alternative technology to complement cellular radio access." It already complements cellular access.. Why is it considered promising? 10. " This specification does not depend on the approach how the cellular specific QoS policies have been configured on the LMA. " Is there not a need to have QoS for flows between a MAG and LMA given that an MN may have multiple flows between a MAG<->LMA pair? 11. "The MN is first connected to the LTE network and having a multimedia session such as a video call with appropriate QoS parameters set by the policy control function. " What QoS policies are configured at the MAG/LMA for such a flow by the PCF? And how are these applied? 12. "The MN is first attaching to the Wi-Fi network. During attachment process, the LMA, which may be in communication with Policy Control Function (this step of the process is out of the scope of this document), provides the QoS parameters to the MAG piggy-backing the PMIP signaling (i.e. PBA)." Several assumptions being made here. It could also be the case that when the MN attaches to a WiFI AP which has QoS support, it could request specific QoS already for a session. That is not considered here. 13. Sec 3.5 describes QCI, ARP, AMBR, GBR etc. which are all 3GPP specific for QoS. It is not clear how these are incorporated into the signaling between PMIP6 nodes and how they are mapped/applied. 3GPP has specified all these QoS types. If the PMIP6 elements, MAG/LMA, do not support QoS signaling does it imply that 3GPP networks will be unable to use QoS if PMIP6 is used as the mobility protocol? 14. The I-D specifies various QoS options defined in 3GPP such as AMBR, GBR, etc. in sections 6.x. 3GPP may continue to expand or deprecate these options. Why not simply follow the 3GPP defined QoS parameters and allocate a generic 3GPP option instead of assigning a type value to each one of these by IANA? 15. The I-D makes assumptions about interacting with a policy controller for obtaining the QoS parameters. What happens in the absence of such a PCF element? Can the LMA itself be configured to allocate QoS to a session? 16. And lastly why not simply specify DSCP and the QoS for the traffic between the MAG and LMA instead of worrying about the mapping to access technology types and interaction with different elements in the access. -Raj
- [netext] Review of I-D: draft-ietf-netext-pmip6-q… Basavaraj Patil
- Re: [netext] Review of I-D: draft-ietf-netext-pmi… Hidetoshi Yokota