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

Marco Liebsch <Marco.Liebsch@neclab.eu> Mon, 01 July 2013 14:17 UTC

Return-Path: <Marco.Liebsch@neclab.eu>
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 959A911E81E8 for <netext@ietfa.amsl.com>; Mon, 1 Jul 2013 07:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 CDdx7Wj-jZ+u for <netext@ietfa.amsl.com>; Mon, 1 Jul 2013 07:17:11 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DFA2911E8170 for <netext@ietf.org>; Mon, 1 Jul 2013 07:17:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AF458104883; Mon, 1 Jul 2013 16:16:42 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNlTOl8EOIe1; Mon, 1 Jul 2013 16:16:42 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 9028F104887; Mon, 1 Jul 2013 16:16:27 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.234]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 1 Jul 2013 16:15:36 +0200
From: Marco Liebsch <Marco.Liebsch@neclab.eu>
To: Ahmad Muhanna <amuhanna@awardsolutions.com>, "netext@ietf.org" <netext@ietf.org>
Thread-Topic: Review Comments on: draft-ietf-netext-pmip6-qos-02
Thread-Index: AQHOX8Ztyr3m4jYzDECTM8RQi1fIwJk6FdKQgAxv6YCACWoaUP//6SkAgAAvgbA=
Date: Mon, 1 Jul 2013 14:15:36 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26D552DCC1D@DAPHNIS.office.hd>
References: <CAA5F1T3bLg9D+4zohzKPRsu_yQyD4fQsNa00_d1m2On4mLtg4w@mail.gmail.com> <3359F724933DFD458579D24EAC7690988B231081@Redwood.usa.awardsolutions.com> <69756203DDDDE64E987BC4F70B71A26D552CD2D7@DAPHNIS.office.hd> <3359F724933DFD458579D24EAC769098A217AB7F@Redwood.usa.awardsolutions.com> <69756203DDDDE64E987BC4F70B71A26D552DCBD9@DAPHNIS.office.hd> <3359F724933DFD458579D24EAC769098A217D9A5@Redwood.usa.awardsolutions.com>
In-Reply-To: <3359F724933DFD458579D24EAC769098A217D9A5@Redwood.usa.awardsolutions.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.6.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Basavaraj Patil <bpatil1@gmail.com>
Subject: Re: [netext] Review Comments on: 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, 01 Jul 2013 14:17:15 -0000

Ahmad,
on the spotted point about the TFT, one more opinion inline.

>-----Original Message-----
>From: Ahmad Muhanna [mailto:amuhanna@awardsolutions.com]
>Sent: Montag, 1. Juli 2013 15:15
>To: Marco Liebsch; netext@ietf.org
>Cc: Basavaraj Patil
>Subject: RE: Review Comments on: draft-ietf-netext-pmip6-qos-02
>
>Hi Marco,
>
>Seems we are converging.
>Just one follow up:
>
>>[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.
>[Ahmad]
>Good.
>
>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.
>
>[Ahmad]
>All what I think is needed is for the proposed mechanism to also include the
>communication of TFT as needed. If you think communicating UL TFT to the UE,
>for example, is not needed for Non-cellular network, then please explain why.

Since we don't have bearers here, we can assume the MAG on the uplink to be the
first entity that applies the associated rules for QoS on the path between the MAG and the LMA.
If QoS policies are communicated further towards the access, e.g.  to a WLAN controller,
the controller can enforce rules on the downlink and validate packets' QoS and priority as
sent be thy MN on the uplink. It depends on the radio technology if the MN already classifies
packets to a QoS class. In that case, the MN would need flow and QoS rules locally.
Since the spec should neither propose nor go into mechanisms to bring these
rules down to the mobile, I think the limitation to the MAG the and LMA makes sense.
Of course it opts for extending the scope up to the radio access and the mobile, which
is described in the draft. But details are not part of the core specification. Can you agree?

marco


>
>Thanks again!
>
>
>Best Regards,
>Ahmad
>
>-----Original Message-----
>From: Marco Liebsch [mailto:Marco.Liebsch@neclab.eu]
>Sent: Monday, July 01, 2013 7:59 AM
>To: Ahmad Muhanna; netext@ietf.org
>Cc: Basavaraj Patil
>Subject: RE: Review Comments on: draft-ietf-netext-pmip6-qos-02
>
>Hi Ahmad,
>please see inline.
>
>>-----Original Message-----
>>From: Ahmad Muhanna [mailto:amuhanna@awardsolutions.com]
>>Sent: Dienstag, 25. Juni 2013 16:51
>>To: Marco Liebsch; netext@ietf.org
>>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:Marco.Liebsch@neclab.eu]
>>Sent: Monday, June 17, 2013 10:54 AM
>>To: Ahmad Muhanna; netext@ietf.org
>>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: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On
>>>Behalf Of Ahmad Muhanna
>>>Sent: Sonntag, 2. Juni 2013 21:21
>>>To: netext@ietf.org
>>>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:bpatil1@gmail.com]
>>>Sent: Tuesday, May 14, 2013 4:37 PM
>>>To: Ahmad Muhanna
>>>Cc: netext@ietf.org
>>>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
>>>netext@ietf.org
>>>https://www.ietf.org/mailman/listinfo/netext