[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