[netext] Review Comments on: draft-ietf-netext-pmip6-qos-02

[Ahmad Muhanna <[e-mail]>]

Hi Raj and authors,

I have reviewed this draft and I have the below comments.

General Comment:
================
I have found it difficult to follow this document differentiation between IP session, IP flows, Mobility Session with respect to QoS. Since this document reference 3GPP specification for the purpose of QoS, we realize that QoS (in 3GPP) is enforced at the level of a bearer. Thus, when we talk about IP session, is that a single bearer or all types of traffic/flows is carried over this IP session. May be the question is: what is the equivalent of a bearer in PMIPv6? Then we should make sure that we use that definition when referring to QoS enforcement.

After reading on, section 4.1., mentions that the QoS is applied at three different levels, IP flow, Mobility Session, or per MN.
May be it is a good idea to have this mentioned upfront in the introduction section in order to set the stage correctly. In addition somehow, this document needs to provide the detailed logic to differentiate between the three cases. 


Editorial:
Comment No. 1:
==============
      (a) Maintenance of QoS classification during a handover between
      cellular radio access and WLAN access by means of establishing QoS
      policies in the handover target access network,

[Ahmad] 
     (a) Maintaining QoS classification ....

Comment No. 2:
==============
   This document specifies an extension to the PMIPv6 protocol, which
   enables the transport of established QoS descriptions between an LMA
   and the MAG by means of a QoS container option in case the QoS policy
   in the WLAN access is not under explicit control of a policy control
   system.

[Ahmad]
It is not clear what you are trying to say in here. I am thinking the authors intention is to say that in case there is no out of bound policy control mechanism, this document specifies an inbound mechanism using an extension to the PMIPv6 protocol. May be this can be rephrased to capture the mentioned meaning.

Comment No. 3:
==============
   The specified option allows association between IP session
   keys, such as a Differentiated Services Code Point (DSCP), and the
   expected QoS class for this IP session.

[Ahmad]
I have a problem with the word "keys", maybe we can say IP session classification parameters, 



Comment No. 4:
==============
   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.

[Ahmad]
All of a sudden introduced LTE network, maybe we can rephrase this as follows:

   The MN is first connected to the cellular network, e.g., LTE network, and having a multimedia ......

Comment No. 5:
==============
3.3.  Use Case B -- Establishment of new QoS Context in non-3G Access

[Ahmad]
I guess the intention to say non-3GPP ?


Comment No. 6:
==============
3.5.  Relevant QoS Attributes

[Ahmad]
Although, TFT is not considered a QoS parameter, but it is quite important. I did not see the UL TFT is mentioned anywhere. Is it handled outside this document? If it is, we need to mention that because it tightly coupled with the enforcement of the QoS.

After reading on, there is Traffic Selector Attribute (section 4.1, etc). However, the following text is a little misleading and gives the impression as the additional attributes are out of scope.

   For some optional QoS attributes the signaling can differentiate
   enforcement per mobility session and per IP flow.  Additional
   attributes can be appended to the QoS option, but their definition
   and specification is out of scope of this document and left to their
   actual deployment.

I think the above text can be modified to clearly reference Traffic Selector.


Technical Comments:
===================

Comment No. 1:
==============
Under section 4.2 " Local Mobility Anchor Considerations" , it says the following:

   The flow selectors and the parameters for flow treatment MUST be
   included in the option only if QoS policy is expected to apply at the
   flow level.

On the other hand, under section 5, "Quality of Service Option", it says the DSCP value to be used for the flow:

   o  DSCP: An 6-bit unsigned integer indicating the code point value,
      as defined in [RFC2475] to be used for the flow.

[Ahmad]
It is not clear to me how this will work out. If the DSCP is a fixed field in the QoS option, then how this will work to allow having different flows with different DSCP(s). Let me try to explain where I am lost! :-)

If the mobility session was established for default kind of traffic and the QoS DSCP was communicated for a QCI of 9 (DSCP1) for example. Then at a later time, the MN establishes some application session (flow) with QCI 1 and the returned QoS has a DSCP (DSCP2) in the fixed field and probably a Traffic Selector since it is a per single flow.

Now: when the MAG receives the new PBA, is DSCP2 for this flow only and the old DSCP1 for every other traffic? How that should work in relation with the above DSCP field definition?


Comment No. 2:
==============
Under section 6, the Guaranteed Downlink Bit Rate is missing.



Comment No. 3:
==============
Under section 6.8, "Traffic Selector", it says the following:

   MUST be included if QoS parameters (Options according to Section 6.5
   to Section 6.7) are expected to apply at the flow level

[Ahmad]
Why did you single out these two sections only?
For example, section 6.5, says the following:

"
6.5.  Allocation and Retention Priority

   .......
   If the attribute is expected to apply at the flow level, the
   traffic selector (Section 6.8) MUST be included in the QoS option.
"

I suggest modifying the text as follows:
   
   MUST be included when QoS is expected to be applied at the flow level.


Comment No. 4:
==============
Since the Guaranteed Downlink Bit Rate is missing, please recheck the assigned type values and their order in section 6 and the following subsections. Also, please update the IANA section accordingly.


Regards,
Ahmad


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: Basavaraj Patil [mailto:[e-mail]] 
Sent: Tuesday, May 14, 2013 4:37 PM
To: Ahmad Muhanna
Cc: [e-mail]
Subject: Request for review of I-D: draft-ietf-netext-pmip6-qos-02


Hi Ahmad,

We would appreciate it if you can review the I-D: uality of Service Option for Proxy Mobile IPv6 <draft-ietf-netext-pmip6-qos-02.txt>.

Please post your review comments directly to the list. If you can complete the review within the next 2 weeks, that would be much appreciated.

Thank you.

-Chairs

-- 
Basavaraj Patil