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

[Marco Liebsch <[e-mail]>]

Hi Ahmad,

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

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

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.


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

Ok.


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

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:
>==============
>   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,
>

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


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

Good point.

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

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

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

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

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?

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

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:
>==============
>Under section 6, the Guaranteed Downlink Bit Rate is missing.

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

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

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.

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

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

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