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

[Marco Liebsch <[e-mail]>]

Hi Ahmad,
please see inline.

>-----Original Message-----
>From: Ahmad Muhanna [mailto:[e-mail]]
>Sent: Dienstag, 25. Juni 2013 16:51
>To: Marco Liebsch; [e-mail]
>Cc: Basavaraj Patil
>Subject: RE: Review Comments on: draft-ietf-netext-pmip6-qos-02
>
>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.

There are different views on how QoS for non-cellular access is treated. The approach
as per this specification is one solution.

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

Keeping this specification more general without digging into bearer, GTP and PCC
does not conflict with deploying the spec in 3GPP later. That applies to various
previously published RFCs. 
In fact, we had some text about bearers in the first drafts and were asked to remove.
If we write about these specific background technologies, we probably need to
explain them in the draft, which is not needed IHMO.


>
>Having said the above, please see more responses below.
>
>
>Best Regards,
>Ahmad
>
>-----Original Message-----
>From: Marco Liebsch [mailto:[e-mail]]
>Sent: Monday, June 17, 2013 10:54 AM
>To: Ahmad Muhanna; [e-mail]
>Cc: Basavaraj Patil
>Subject: RE: Review Comments on: draft-ietf-netext-pmip6-qos-02
>
>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.
>
>[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.
>
>
>>
>>
>>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.
>[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.
>

Ok.


>
>>
>>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?
>[Ahmad:] Yes. If you agree to not reference 3GPP standardization, this comes
>natural. Thanks!
>

Ok.

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

The spec does not assume wildcarded policies all the time. For some, a per-MN or
per-mobility session wildcard makes sense, i.e. the aggregate of the MN or its registration.
>From that 'all-flows-of-this-MN' group, the per-flow policies can enforce specific rules
to some flows for prioritization. I do not see a problem with this.

I don't think the draft needs to go into implementation specific how to identify
flows and apply associated rules when there is a TFT and 3GPP-specific
implementation already on the MN or the LMA respectively.

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

Do you propose to describe the conceptual datastructures that hold the received
policies? Then, do you also propose to add some text about 'flow identification and
rules enforcement' ?


>
>>
>>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.
>[Ahmad:] That should be fine.


Ok

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


Ok

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

We'll try to clarify this in the revision.


>>
>>
>>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.
>[Ahmad:]
>May be the new approach (if you agree on the above comments) will address
>this too.

Also here, we'll try to clarify this in the revision.

Thanks,
marco

>
>>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
>[Ahmad:]
>Thanks 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