Re: [netext] Review of I-D: draft-ietf-netext-pmip6-qos-02

[Hidetoshi Yokota <[e-mail]>]

Hi Raj,

Sincere apology for our delayed response.

Thanks a lot for your thorough review and comments. Please see inline
for our response (we have one question about your comment #7). We will
update the I-D and submit as soon as possible.

(2013/05/14 4:19), Basavaraj Patil wrote:
>
> Below are my review comments for the
> I-D:draft-ietf-netext-pmip6-qos-02 (QoS Support for Proxy Mobile IPv6)
>
>
> Questions/Comments:
>
> 1. "Using the QoS option, the local mobility anchor and the
> mobile access gateway can exchange available QoS attributes and
> associated values."
>
> QoS for a session or subscriber or group of sessions? Not clear from
> this statement.
>

*That depends on the type of QoS attribute. As shown in Section 6 (below
Fig.7), Type=1 is Per-mobile node (could be a group of sessions),
whereas Type=3 is per-session.*

> 2. "This enables QoS policing and labeling of packets
> to enforce QoS differentiation on the path between the local mobility
> anchor and the mobile access gateway."
>
> So is the objective primarily to enable QoS on the MAG<->LMA path? Or
> is the intent to deliver QoS information to the MAG for use on the
> access link? Or both?
>

*For both the path between MAG and LMA and access link. Figs. 4 and 5
illustrate how QoS parameters are delivered and set.*

> 3. "Furthermore, making QoS
> parameters available on the MAG enables mapping these parameters to
> QoS rules being specific to the access technology which operates
> below the mobile access gateway."
>
> Would this mapping be defined elsewhere? As an example how would you
> translate the QoS parameters defined between the MAG<->LMA for use on
> an 802.11 air interface? Who would define this mapping (if it needs to
> be specified).
>

*Appendix A shows an example of how QoS parameters are mapped to
IEEE802.11e.*

> 4. "Current
> standardization effort considers strong QoS classification and
> enforcement for cellular radio access technologies."
>
> What standardization effort is being referred to here?
>

*3GPP is one of those and Section 3.5 shows detailed parameters. *

> 5. "QoS policies are
> typically controlled by a policy control function, ...."
>
> The I-D assumes a very specific network architecture (in this case
> 3GPP EPS). It would be better to indicate the applicability or
> assumptions.
>

*This sentence can go without the description of "policy control function".*

> 6. "Policy control and QoS differentiation for access to the mobile
> operator network through alternative non-cellular access technologies
> is not yet considered, even though some of these access technologies
> are able to support QoS by appropriate traffic prioritization
> techniques."
>
> Not sure how this is relevant in the scope of this I-D.
>

*This part can be removed.*

> 7. "... alternative
> radio access technologies, such as IEEE802.16 "
>
> Would be good to include EV-DO, SCDMA as other technologies as well...
>

*EV-DO could be another example standardized by 3GPP2, but could you
tell us which SDO standardized SCDMA?*

> 8. " whereas inter-working with the cellular
> architecture to establish QoS policies in alternative access networks
> has not been focussed on so far."
>
> The WG is better off defining a mechanism that is not specific to the
> current version of 3GPP standards or access technologies being
> considered.
>

*The defined mechanism is not only for 3GPP, but also for WiFi as shown
in Appendix A or for broadband fixed network as shown in Appendix B. *

> 9. "...has been identified as
> promising alternative technology to complement cellular radio
> access."
>
> It already complements cellular access.. Why is it considered
> promising?
>

*"promising" should be removed.*

> 10. " This specification
> does not depend on the approach how the cellular specific QoS
> policies have been configured on the LMA. "
>
> Is there not a need to have QoS for flows between a MAG and LMA given
> that an MN may have multiple flows between a MAG<->LMA pair?
>

*The QoS for multiple flows between MAG and LMA is also possible.
Traffic selector defined in Secion 6.8 identifies each flow for
assigning a separate QoS.*

> 11. "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. "
>
> What QoS policies are configured at the MAG/LMA for such a flow by the
> PCF? And how are these applied?
>

*In the case of video call, QCI=2 is used as per 3GPP's definition and
the PCF delivers necessary parameters to the LMA accordingly. *

> 12. "The MN is first attaching to
> the Wi-Fi network. During attachment process, the LMA, which may be
> in communication with Policy Control Function (this step of the
> process is out of the scope of this document), provides the QoS
> parameters to the MAG piggy-backing the PMIP signaling (i.e.
> PBA)."
>
> Several assumptions being made here. It could also be the case that
> when the MN attaches to a WiFI AP which has QoS support, it could
> request specific QoS already for a session. That is not considered
> here.
>

*Local QoS policy assignment does not require QoS parameters from the
LMA, but can be included as a possible use case in the document.*

> 13. Sec 3.5 describes QCI, ARP, AMBR, GBR etc. which are all 3GPP
> specific for QoS. It is not clear how these are incorporated into the
> signaling between PMIP6 nodes and how they are mapped/applied.
>
> 3GPP has specified all these QoS types. If the PMIP6 elements,
> MAG/LMA, do not support QoS signaling does it imply that 3GPP networks
> will be unable to use QoS if PMIP6 is used as the mobility protocol?
>

*In such a case, another mechanism is used in 3GPP. Instead of PMIPv6
signaling, a dedicated interface called Gxx is defined between the
policy server and MAG. Of course, this is not an ideal situation and
this I-D will fix it.*

> 14. The I-D specifies various QoS options defined in 3GPP such as
> AMBR, GBR, etc. in sections 6.x. 3GPP may continue to expand or
> deprecate these options. Why not simply follow the 3GPP defined QoS
> parameters and allocate a generic 3GPP option instead of assigning a
> type value to each one of these by IANA?
>

*3GPP-defined QoS parameters have been stable enough and referred to by
other SDOs as well. These parameters can be separately used by other
access technologies, so it would be more convenient to define each than
put into a 3GPP option, which would be invisible other than 3GPP.*

> 15. The I-D makes assumptions about interacting with a policy
> controller for obtaining the QoS parameters. What happens in the
> absence of such a PCF element? Can the LMA itself be configured to
> allocate QoS to a session?
>

*LMA-based predefined policy control is also possible. In this case,
static policy will be applied by the LMA.*

> 16. And lastly why not simply specify DSCP and the QoS for the traffic
> between the MAG and LMA instead of worrying about the mapping to
> access technology types and interaction with different elements in the
> access.
>

*We are not worried about other access technologies, but just trying to
show multiple use cases for the applicability of this specification.*

Regards,

-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:[e-mail]



> -Raj
>
>
>
>
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext