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

[Ahmad Muhanna <[e-mail]>]

Hi Marco,
I assume that you propose such text to be included as justification in the draft. If that the case, it sounds good to me.

Thanks again!

Regards,
Ahmad

Sent from my mobile device.

On Jul 1, 2013, at 9:17 AM, "Marco Liebsch" <[e-mail]<mailto:[e-mail]>> wrote:

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

-----Original Message-----
From: Ahmad Muhanna [mailto:[e-mail]]
Sent: Montag, 1. Juli 2013 15:15
To: Marco Liebsch; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Monday, July 01, 2013 7:59 AM
To: Ahmad Muhanna; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Dienstag, 25. Juni 2013 16:51
To: Marco Liebsch; [e-mail]<mailto:[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]<mailto:[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]> [mailto:[e-mail]] On
Behalf Of Ahmad Muhanna
Sent: Sonntag, 2. Juni 2013 21:21
To: [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netext