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

From: Ahmad Muhanna <[email-masked]>
Date: Sun, 2 Jun 2013 19:21:21 +0000

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:[email-masked]] 
Sent: Tuesday, May 14, 2013 4:37 PM
To: Ahmad Muhanna
Cc: [email-masked]
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

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 17 Jun 2013 15:54:01 +0000

Hi Ahmad,

thanks a lot for your detailed comments and proposals.
Please see inline for feedback.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Ahmad Muhanna
>Sent: Sonntag, 2. Juni 2013 21:21
>To: [email-masked]
>Cc: Basavaraj Patil
>Subject: [netext] Review Comments on: draft-ietf-netext-pmip6-qos-02
>
>Hi Raj and authors,
>
>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.

I would not try to map the bearer concept, which applies to cellular networks,
to IP tunneling as used by PMIP. A PMIP tunnel is shared even by multiple users,
whereas the bearer is established per MN and per QoS. I'd rather add more text about
how QoS differentiation should be enabled on a PMIP tunnel. In current cellular systems,
mapping of flows to a per MN and per-QoS bearer is performed on the downlink
after the termination of the PMIP tunnel, i.e. at the MAG. So, no bearer assumed on
PMIP even in cellular networks. Scope of the spec is to enable QoS differentiation by means
of DSCPs on the PMIP tunnel and opt for mapping of QoS rules to non-cellular access
technology specific QoS.

>
>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.

Fully agree to that point and we addressed past comments on this mainly in the
message format description. The general parts, such as the Intro, lack in
clear text, which we'll add in the updated version. Thanks again for the hint.

>Comment No. 1:

Ok.

>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.

Agreed. How about that (omitting the pointer to the policy control system):
This document specifies an extension to the PMIPv6 protocol to establish QoS policies
for an MN's data traffic on the LMA and the MAG. QoS policies are conveyed in-band with
PMIPv6 signaling using the specified QoS option and are enforced on the LMA for downlink
traffic and on the MAG for uplink traffic.

>Comment No. 3:

I think your proposal is good. We'll adopt it.

>Comment No. 4:

Good point.

>Comment No. 5:

Yes. Even better: '..non-cellular Access'. Ok with you?

>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.

The TFT is a cellular-specific concept, better a collection of filter and mapping rules,
that holds flow information and allow mapping of each flow to a bearer in the cellular
network. The downlink TFT applies to the MAG in the cellular network which use PMIP,
the uplink TFT (do you refer only to this one?) applies to the MN. I consider functions of
the TFT on both sides out of scope of this document's focus, as it's related to bearer mapping.
Also I do not think the spec needs to classify it explicitly as out of scope.
Implementations may re-use the TFT data structures to hold and maintain QoS
information for non-cellular access, but I'd hesitate entering that level and the
need to introduce a TFT term, which also needs to be described then.
Other opinions?

>
>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.
>

Not sure I got your point correctly. The specification of additional QoS attributes and
the associated options' format is out of scope of this specification, but may be relevant for
a particular deployment. Means, the specified mechanisms can be
used to convey more options, e.g. ones that are defined by other SDOs.
About the Traffic Selector, what else than a reference to RFC6088 would you
like to see in the draft?

>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?

Per-flow policies overrule default policies. I hope this is only a clarification issue
in the draft, or do you see an inconsistency and technical issue here?

>Comment No. 2:

Only in the listed attributes, not in the specification (Sec. 6.6 and 6.7).
Thanks for the catch! 

>Comment No. 3:

Because the use of per-flow rules made sense here, whereas
the per-Mobility Session attributes should represent an aggregated view
taking all flows of the mobility session into account.

>   MUST be included when QoS is expected to be applied at the flow level.

Ok.

>
>
>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.

Ok.

Thanks again for your detailed comments and suggestions.

marco

>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
>_______________________________________________
>netext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netext

---

From: Ahmad Muhanna <[email-masked]>
Date: Tue, 25 Jun 2013 14:50:59 +0000

Hi Marco,
Sorry I was out last week.
I would like to address your comments as follows. The below is in general and comments to your specific replies.

In general, I agree 3GPP standard does not specify a PMIPv6 tunnel that is comparable to a GTP bearer. That's given. However, that is the reason 3GPP specify a different PCC architecture when PMIP is used. In other words, the MAG goes directly to the PCRF over Gxa, for example.

I believe that allowing a different architecture for PCC to be used over PMIP6 must have one of two options.
1. Define the needed extras for PMIP6 to be able to be comparable to GTP bearer and then use PCC as it is being used for GTP and as you are trying to use in your draft, this means you need to describe the scenarios to the level of bearers and NOT MN or Mobility session. However, I must say that this option SHOULD NOT be addressed in IETF and should be handled in 3GPP standardization, for example SA2. I remember in the past there was lots of discussion related to PCC architecture and for PMIP the option was to use out-of-bound mechanism.

2. Forget about 3GPP PCC and define your own mechanism for exchanging some QoS parameters without ANY reference to 3GPP. That is possible but I am not sure about the value.

Having said the above, please see more responses below.

Best Regards,
Ahmad

-----Original Message-----
From: Marco Liebsch [mailto:[email-masked]] 
Sent: Monday, June 17, 2013 10:54 AM
To: Ahmad Muhanna; [email-masked]
Cc: Basavaraj Patil
Subject: RE: Review Comments on: draft-ietf-netext-pmip6-qos-02

Hi Ahmad,

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Ahmad Muhanna
>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.

I would not try to map the bearer concept, which applies to cellular networks, to IP tunneling as used by PMIP. A PMIP tunnel is shared even by multiple users, whereas the bearer is established per MN and per QoS. I'd rather add more text about how QoS differentiation should be enabled on a PMIP tunnel. In current cellular systems, mapping of flows to a per MN and per-QoS bearer is performed on the downlink after the termination of the PMIP tunnel, i.e. at the MAG. So, no bearer assumed on PMIP even in cellular networks. Scope of the spec is to enable QoS differentiation by means of DSCPs on the PMIP tunnel and opt for mapping of QoS rules to non-cellular access technology specific QoS.

[Ahmad:] 
[Ahmad:] Please see my comments above.

>
>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.

Fully agree to that point and we addressed past comments on this mainly in the message format description. The general parts, such as the Intro, lack in clear text, which we'll add in the updated version. Thanks again for the hint.
[Ahmad:] Thank you.

Ok.

>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.

Agreed. How about that (omitting the pointer to the policy control system):
This document specifies an extension to the PMIPv6 protocol to establish QoS policies for an MN's data traffic on the LMA and the MAG. QoS policies are conveyed in-band with
PMIPv6 signaling using the specified QoS option and are enforced on the LMA for downlink traffic and on the MAG for uplink traffic.
[Ahmad:] 
I think that may be an option as I listed above. However, you need to present this document as a mechanism for exchanging some QoS parameters that you need to define in this document or reference other IETF documents because you no longer is able to reference any 3GPP documents. In that case, please make sure that the document is consistent across the board and I believe the new/updated document needs further fresh reviews.

Good point.

Yes. Even better: '..non-cellular Access'. Ok with you?
[Ahmad:] Yes. If you agree to not reference 3GPP standardization, this comes natural. Thanks!

>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.

The TFT is a cellular-specific concept, better a collection of filter and mapping rules, that holds flow information and allow mapping of each flow to a bearer in the cellular network. The downlink TFT applies to the MAG in the cellular network which use PMIP, the uplink TFT (do you refer only to this one?) applies to the MN. I consider functions of the TFT on both sides out of scope of this document's focus, as it's related to bearer mapping.
 
[Ahmad:] May be I am missing something here. At the end regardless of the mapping to a single bearer or a tunnel for multiple UEs, you need to enforce the PCC rules at the level of flows. That could be a wild card but if you have a solution that assumes wild card all the time, then you may have a problem. In other words, I believe the TFT is needed to be communicated to the UE and the MAG. If in non-cellular the UE does not need to have the uplink TFT, then please explain this in the draft. In other words, whatever option you want to choose, please mention the justification. Thanks.

Also I do not think the spec needs to classify it explicitly as out of scope.
Implementations may re-use the TFT data structures to hold and maintain QoS information for non-cellular access, but I'd hesitate entering that level and the need to introduce a TFT term, which also needs to be described then.
Other opinions?
[Ahmad:] Well, then we disagree. That communication of QoS parameters is useless if you do not know how to enforce it. Whenever, people talks about PCC, they automatically thinks of the enforcement and you need to address it. Either referencing other IETF documents or give justification for why it is not needed.

>
>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.
>

Not sure I got your point correctly. The specification of additional QoS attributes and the associated options' format is out of scope of this specification, but may be relevant for a particular deployment. Means, the specified mechanisms can be used to convey more options, e.g. ones that are defined by other SDOs.
[Ahmad:] That should be fine.

About the Traffic Selector, what else than a reference to RFC6088 would you like to see in the draft?
[Ahmad:] That should suffice to eliminate the possible misunderstanding of the text above.

>On the other hand, under section 5, "Quality of Service Option", it 
>says the DSCP value to be used for the flow:
>
>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?

Per-flow policies overrule default policies. I hope this is only a clarification issue in the draft, or do you see an inconsistency and technical issue here?
[Ahmad:] 
As I said earlier, please remember you are defining a new mechanism for using 3GPP PCC architecture that is NOT defined by 3GPP. May be if you agree on the previous comments above, then this point will automatically be addressed.

>Comment No. 3:

Because the use of per-flow rules made sense here, whereas the per-Mobility Session attributes should represent an aggregated view taking all flows of the mobility session into account.
[Ahmad:] 
May be the new approach (if you agree on the above comments) will address this too.

Ok.

>
>
>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.

Ok.

Marco
[Ahmad:] 
Thanks Marco!

>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