Subject: [netext] I-D Action: draft-ietf-netext-pmip6-qos-08.txt

From: [email-masked]
Date: Thu, 05 Dec 2013 14:10:06 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF.

	Title           : Quality of Service Option for Proxy Mobile IPv6
	Author(s)       : Marco Liebsch
                          Pierrick Seite
                          Hidetoshi Yokota
                          Jouni Korhonen
                          Sri Gundavelli
	Filename        : draft-ietf-netext-pmip6-qos-08.txt
	Pages           : 61
	Date            : 2013-12-05

Abstract:
   This specification defines a new mobility option, the Quality of
   Service (QoS) option, for Proxy Mobile IPv6.  This option can be used
   by the local mobility anchor and the mobile access gateway for
   negotiating Quality of Service parameters for a mobile node's IP
   flows.  The negotiated QoS parameters can be used for QoS policing
   and marking of packets to enforce QoS differentiation on the path
   between the local mobility anchor and the mobile access gateway.
   Furthermore, making QoS parameters available on the mobile access
   gateway enables mapping of these parameters to QoS rules that are
   specific to the access technology and allows those rules to be
   enforced on the access network using access technology specific
   approaches.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netext-pmip6-qos-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip6-qos-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 9 Dec 2013 22:24:14 +0000

FYI

>
>On 12/9/13 9:04 AM, "Brian Haberman" <[email-masked]> wrote:
>
>>All,
>>     Here are my comments on this draft...
>>
>>1. Somewhere in the front matter of the draft, there should be some
>>discussion as to why existing QoS signaling mechanisms are not used
>>(e.g., RSVP).
>
>
>Ok. We can add some considerations.
>
>1. In mobility deployments, access and core network can be in two
>different operator domains. Assumption  of  Int-serv based architecture
>will not work
>2. The QoS signaling and the models that we support have a tight relation
>to the subscriber policy and charging, in the context of QoS policy
>negotiation and so explicit signaling tied to mobility signaling is needed
>3. In general RSVP/Int-serv based models in SP network will not scale
>
>Agree. We need a motivation statement, summary of features supported and
>the architectural model. Will add few lines of text at the beginning.
>
>
>
>>
>>2. Section 2.2 refers to the Allocation and Retention Priority option as
>>ARP and AARP.  I assume AARP is a typo (but ARP is also an unfortunate
>>overload...).
>
>
>Agree. 
>
>Better not to confuse this with the ARP term. Will add some explanation
>around this,
>
>
>>
>>3. Is there any expectation for infrastructure devices between the MAG
>>and LMA to provide QoS services for these flows?  If so, how?  With the
>>QoS information embedded in PMIP messages, how would these intermediate
>>devices know anything about these QoS parameters and any associated
>>Per-Hop-Behaviors?  This needs some discussion in the draft to ensure a
>>consistent deployment view.
>
>
>There are some considerations here:
>
>1.) MAG and LMA apply rate-limiting and other features based on the
>negotiated QoS policies
>2.) MAG and LMA apply proper DSCP marking/re-marking on the user flows
>based on the negotiated QoS policy
>3.) Transit network honoring the QoS markings on the tunneled flows
>(tunnel peers copy the DSCP marking from inner payload to outer GRE
>header)
>
>
>>
>>4. Section 4.1 says that if M=1, D=0, but there is no discussion of what
>>to do if M=D=1 occurs.  Is the option ignored?
>
>
>It should be considered an error. May be as Carlos suggested, we will use
>a two-bit field instead of flags.
>
>
>
>
>>
>>5. I am curious as to why a 5-bit Service Request ID is sufficient.  You
>>have bits available in the Resvd field... Wouldn't an 8-bit field make
>>operations/comparisons easier?
>
>
>Typically in QoS architectures, differentiated flow treatment is
>provisioned for "N" DSCP flows. In 3GPP this is the QCI groups.  These
>have to be in single digit count, else the network cannot scale.
>
>When a MAG makes a QoS service request for a subscriber flow(s), it will
>create unique service requests, each request identifying a set of flows,
>unique DSCP marking and some QoS properties (MBR, GBR ..etc). The number
>of requests cannot be more than 64 groups (given that DSCP is a 6-bit
>field). We are tying the QoS service request to a unique DSCP value. So,
>32 QoS flow groups should be sufficient.
>
>
>
>
>>
>>6. Section 4.2 only describes bit-rate-based attributes.  Is this due to
>>use cases described in other SDOs?
>
>
>Yes. To be consistent with the 3GPP and Wi-FI QoS attributes.
>
>
>>
>>7. What is the handling if there is a conflict between a per-node QoS
>>attribute and a set of per-flow QoS attributes associated with that node?
>
>
>Its an error condition. Will add some text in the LMA processing rules.
>
>
>
>Regards
>Sri
>
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 12 Dec 2013 00:25:26 +0000

Response to Brian's review Š

On 12/11/13 3:13 AM, "Marco Liebsch" <[email-masked]> wrote:

>Brian, thanks a lot for your review and valuable comments.
>
>All, please see inline for some considerations to address the comments,
>adding to Sri's feedback.
>
>
>>-----Original Message-----
>>From: Brian Haberman [mailto:[email-masked]]
>>Sent: Montag, 9. Dezember 2013 18:04
>>To: Sri Gundavelli (sgundave)
>>Cc: Hidetoshi Yokota; jouni korhonen; Marco Liebsch;
>>[email-masked]
>>Subject: Re: FW: [netext] I-D Action: draft-ietf-netext-pmip6-qos-08.txt
>>
>>All,
>>discussion
>>as to why existing QoS signaling mechanisms are not used (e.g., RSVP).
>>
>>ARP and
>>AARP.  I assume AARP is a typo (but ARP is also an unfortunate
>>overload...).
>
>Good point. I don't see an issue with deviating from the 3GPP term and
>gain
>advantage of the typo :-) to avoid confusion. What about naming the
>attribute
>AARP instead of ARP to abbreviate Allocation And Retention Priority?
>
>>
>>and LMA
>>to provide QoS services for these flows?  If so, how?  With the QoS
>>information
>>embedded in PMIP messages, how would these intermediate devices know
>>anything about these QoS parameters and any associated Per-Hop-Behaviors?
>>This needs some discussion in the draft to ensure a consistent
>>deployment view.
>
>The expectation is to prioritize traffic according to the DSCP, which is
>the
>only carried per-packet classifier being understood by transport network
>routers. Sect. 6 provides some clarification, but I agree that's a bit
>late.
>We could clarify in the introduction already what's the expectation from
>LMA, MAG and transport network infrastructure to enable QoS
>differentiation
>by using the specified option and attributes. Will add this.
>
>
>>
>The spec mandates D to be cleared when M=1. We can treat M=D=1 as
>violation
>of the spec and reject QoS enforcement using the
>CANNOT_MEET_QOS_SERVICE_REQUEST
>status. Description of how to set the status to this value is solely
>about failure in
>supporting the requested QoS. If we adopt the above mechanism, the
>protocol
>operations section 6 must add description to set this status code in case
>of
>unambiguous flag settings.
>
>
>>
>>have bits
>>available in the Resvd field... Wouldn't an 8-bit field make
>That would leave no space for additional flags in case such extension is
>needed.
>So far the format has a good packing style. If we want to align fields to
>8 bit, e.g. to
>enable easier decoding, we can consider 8 bit for flags (two are used), 8
>bit
>for a Traffic Class field (6 used for the DS code point) and add the
>service request
>ID to another line of 32 bit, which gives us more space for the ID, but
>implies
>much reserved fields.
>Sri, all, what do you think? According to your description 5 bit are
>sufficient.
>Preferences to keep the packing style?
>
>>
>>attribute
>>and a set of per-flow QoS attributes associated with that node?
>
>We'll add clarifying text according to Sri's feedback,
>
>Thanks,
>
>marco

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 12 Dec 2013 00:27:22 +0000

Additional response to Brian's feedback.

From: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 11, 2013 4:22 PM
To: Marco Liebsch <[email-masked]<mailto:[email-masked]>>, Brian Haberman <[email-masked]<mailto:[email-masked]>>
Cc: Hidetoshi Yokota <[email-masked]<mailto:[email-masked]>>, jouni korhonen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netext] I-D Action: draft-ietf-netext-pmip6-qos-08.txt

Marco/Brian

Inline …

On 12/11/13 3:13 AM, "Marco Liebsch" <[email-masked]<mailto:[email-masked]>> wrote:

2. Section 2.2 refers to the Allocation and Retention Priority option as ARP and
AARP.  I assume AARP is a typo (but ARP is also an unfortunate overload...).

Good point. I don't see an issue with deviating from the 3GPP term and gain
advantage of the typo :-) to avoid confusion. What about naming the attribute
AARP instead of ARP to abbreviate Allocation And Retention Priority?

We had the typo in the Terminology section as well, keeping it consistent across, but Yokota-san fixed it :)

4. Section 4.1 says that if M=1, D=0, but there is no discussion of what to do if
M=D=1 occurs.  Is the option ignored?

The spec mandates D to be cleared when M=1. We can treat M=D=1 as violation
of the spec and reject QoS enforcement using the CANNOT_MEET_QOS_SERVICE_REQUEST
status. Description of how to set the status to this value is solely about failure in
supporting the requested QoS. If we adopt the above mechanism, the protocol
operations section 6 must add description to set this status code in case of
unambiguous flag settings.

Its a pain to define error codes for this flag combination and document them.
May be as Carlos suggested, we combine the D and M flags into a 2 bit number.

1 - Create
2 - Delete
3 - Modify
0 - Reserved - Receiver will ignore; Or allow the sender to set to 0 when re-negotiating a QoS proposal with a counter proposal

5. I am curious as to why a 5-bit Service Request ID is sufficient.  You have bits
available in the Resvd field... Wouldn't an 8-bit field make
operations/comparisons easier?

That would leave no space for additional flags in case such extension is needed.
So far the format has a good packing style. If we want to align fields to 8 bit, e.g. to
enable easier decoding, we can consider 8 bit for flags (two are used), 8 bit
for a Traffic Class field (6 used for the DS code point) and add the service request
ID to another line of 32 bit, which gives us more space for the ID, but implies
much reserved fields.
Sri, all, what do you think? According to your description 5 bit are sufficient.
Preferences to keep the packing style?

I think this is a good suggestion. Works for me This should address Brian's concern.

Yokota-san/Jouni/Pierrick/ ?

OLD:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Length      |D|M|Resvd|    ID   |   DSCP    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   QoS Attribute(s)                            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NEW:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Length      |       ID      |       TC      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|M|                         Resvd                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   QoS Attribute(s)                            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6. Section 4.2 only describes bit-rate-based attributes.  Is this due to use cases
described in other SDOs?

7. What is the handling if there is a conflict between a per-node QoS attribute
and a set of per-flow QoS attributes associated with that node?

We can define a new QoS error code and handle this.

Brian - We are going to this last update and hopefully we got a head-start here with respect to your reviews. We hope to see this doc in IESG by Jan.

Regards
Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 19 Dec 2013 23:14:22 +0000

Hi Brian,

We have posted the 09 version of the document. Based on your review feedback and discussion, we have updated the draft.  Please let us know if you have any further comments.

  http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip6-qos-09.txt

Regards
Sri

[Authors] We have added some text on the overall  QoS architecture, base line assumptions and the scope of the work.

[Authors] We now use the term AARP consistently

[Authors] Captured in the intro section on the end-to-end DiffServ architectural assumption

[Authors] We got rid of the flags and used a opcode int field.

[Authors] We also re-worked the QoS option per your recommendations/comments

[Authors] No change.

[Authors] The peer can renegotiate the QoS proposal, by sending a downgraded profile.