Subject: [netext] AD Evaluation: draft-ietf-netext-pmip-qos-wifi

From: Brian Haberman <[email-masked]>
Date: Mon, 09 Feb 2015 10:11:20 -0500

All,
     I have completed my AD Evaluation of
draft-ietf-netext-pmip-qos-wifi as a part of the publication process.  I
have a few points that I would like to discuss before moving this
document into IETF Last Call...

* The reference to RFC 2119 needs cleaning up.  The Normative References
section tags the document as [RFC 2119], but section 1.1 refers to it as
[RFC2119].

* The Introduction uses several acronyms without expansion.  Notionally,
this seems to be because the acronyms are expanded in section 1.3.  I
would suggest avoiding the use of the acronyms until after section 1.3.
 The Introduction should just use the expanded terms.

* Definitions

     - Do the definitions need to use the 2119 keywords?

     - For simplicity, I would move section 1.3 ahead of section 1.2.

* Section 2 uses "(in decreasing order)". The context derived from the
next sentence indicates that is in decreasing order of priority.  I
would state that explicitly.

* Section 3.1.1

     - Step 1 seems to require the AP/MAG to do DPI if TCLAS is not
present. Does that imply that the AP/MAG must have application layer
gateway support for each app used by the MN?  If so, that could have
scalability and usability implications.  May be worth mentioning.

     - In Step 2, what is the AP/MAG to do if the TCLAS is not present
(when WMM-AC is used)?  Does it construct one via the ALG discussed above?

* Section 3.1.2

     - This is the first mention of a policy server and there is no
description or reference of what the policy server does or how it is
expected to interact with these QoS mechanisms.  At a minimum, there
should be something in the Definitions that describes this function.

     - What is the rationale for the order of steps?  I could very
easily see the order being 1, 3, 4, 2.  Are there corner cases that
should be discussed if the original order is not followed?

* Section 3.2 seems like an attempt to cover all possible scenarios when
it may not be needed.  Can a scenario be described where the network
would originate the QoS signaling?

* Figure 5 is never referenced in the text.

Regards,
Brian

---

From: John Kaippallimalil <[email-masked]>
Date: Mon, 9 Feb 2015 21:10:47 +0000

Hi Brian,
Inline below are the proposed resolutions.

Thanks,
John

> -----Original Message-----
> From: Brian Haberman [mailto:[email-masked]]
> Sent: Monday, February 09, 2015 9:11 AM
> To: [email-masked]; netext-
> [email-masked]; [email-masked]
> Subject: AD Evaluation: draft-ietf-netext-pmip-qos-wifi
> 
> All,
>      I have completed my AD Evaluation of draft-ietf-netext-pmip-qos-
> wifi as a part of the publication process.  I have a few points that I
> would like to discuss before moving this document into IETF Last
> Call...
> 
> * The reference to RFC 2119 needs cleaning up.  The Normative
> References section tags the document as [RFC 2119], but section 1.1
> refers to it as [RFC2119].

Section 1.1: will change [RFC2119] to [RFC 2119]

> 
> * The Introduction uses several acronyms without expansion.
> Notionally, this seems to be because the acronyms are expanded in
> section 1.3.  I would suggest avoiding the use of the acronyms until
> after section 1.3.

Section 1 (Introduction): will expand each term such as MAG, LMA, etc. to Mobility Access Gateway, Local Mobility Anchor, etc.

>      - Do the definitions need to use the 2119 keywords?

Proposed revision:
- TSPECs for both uplink and downlink MAY contain Peak Data Rate
- TSPECs for both uplink and downlink SHOULD contain the Mean Data Rate.
- Minimum Data Rate is OPTIONAL and is not used in QoS provisioning described here.

>      - For simplicity, I would move section 1.3 ahead of section 1.2.

Proposed revision: move section 1.3 ahead of section 1.2.

> would state that explicitly.

Proposed revision:
"The levels of priority in EDCA are called access categories (ACs) and there are four levels (in decreasing order of priority): Voice, Video, Best-Effort, Background."

> scalability and usability implications.  May be worth mentioning.

Proposed revision for step 1 (last para):
"It should be noted that WMM-AC specifications do not contain TCLAS.  When TCLAS is not present, there is no direct way to derive flow specific attributes like Traffic Selector in PMIPv6.
In this case an Application Layer Gateway (ALG) can derive IP flow details from information in upper layer protocols (e.g. SIP). It should be noted that an ALG can increase the complexity of the AP/MAG implementation and affect its scalability. If no TCLAS is derived, the reservation applies to all flows of the MN (not desired). Parameter mapping in this case is shown in Table 2."

> (when WMM-AC is used)?  Does it construct one via the ALG discussed

Proposed revision - add new para in step (2):
"If TCLAS is not present (when WMM-AC is used), TCLAS maybe derived using an ALG and populated in Traffic Selector. If TCLAS cannot be derived, the Traffic Selector field is not included in the QoS options."  

> should be something in the Definitions that describes this function.

LMA acts as the QoS policy server as far as semantics of this draft is concerned.

Proposed revisions  a-e:
(a) Add clarifying statement in introduction - section 1:
"The LMA (Local Mobility Anchor) configures QoS policies on MN and AP/MAG. Further details on policy configuration and PCF (Policy Control Function) can be found in [RFC 7222], section 6.1."

(b) change policy server to LMA in first para:
"When the application session completes, the LMA, or the MN may signal for the release of resources."

(c) revise step (4) to remove reference to policy server.
" LMA receives the PBU and releases local resources."

(d) in section 3.2.3, first para:
" When the application session completes, the LMA, or the MN may signal for the release of resources."

(e) in section 3.2.3, remove step 1. Renumber steps 2 - 5 as 1 - 4.

> should be discussed if the original order is not followed?

Proposed revision: add following text after step 4.
"It should be noted that steps 3 and 4 can proceed independently of the DELTS Response (step 2)."

> 
> * Section 3.2 seems like an attempt to cover all possible scenarios
> when it may not be needed.  Can a scenario be described where the
> network would originate the QoS signaling?

Proposed revision - add as example - 3GPP TS23.203, section 7.4.2 (IP-CAN Session Modification, PCRF Initiated):
Replace first sentence with:
" This section describes the case when the QoS service request is initiated by the LMA. For example an application  such as voice may request the network to initiate configuration of additional QoS policy as in [TS23.203], section 7.4.2."

> * Figure 5 is never referenced in the text.

Proposed revision (in para above Figure 5):
" In this use case shown in Figure 5, the network initiates the release of QoS resources."

---

From: Brian Haberman <[email-masked]>
Date: Tue, 10 Feb 2015 12:23:28 -0500

Hi John,

On 2/9/15 4:10 PM, John Kaippallimalil wrote:
> Hi Brian, Inline below are the proposed resolutions.
> 
> Thanks, John
> 
>> -----Original Message----- From: Brian Haberman
>> [mailto:[email-masked]] Sent: Monday, February 09, 2015
>> 9:11 AM To: [email-masked];
>> netext- [email-masked]; [email-masked] Subject: AD
>> Evaluation: draft-ietf-netext-pmip-qos-wifi
>> 
>> All, I have completed my AD Evaluation of
>> draft-ietf-netext-pmip-qos- wifi as a part of the publication
>> process.  I have a few points that I would like to discuss before
>> moving this document into IETF Last Call...
>> 
>> References section tags the document as [RFC 2119], but section
>> 1.1 refers to it as [RFC2119].
> 

Ok.

>> section 1.3.  I would suggest avoiding the use of the acronyms
>> until after section 1.3. The Introduction should just use the
>> expanded terms.
> 
> Section 1 (Introduction): will expand each term such as MAG, LMA,
> etc. to Mobility Access Gateway, Local Mobility Anchor, etc.
> 

Ok.

> Proposed revision: - TSPECs for both uplink and downlink MAY contain
> Peak Data Rate - TSPECs for both uplink and downlink SHOULD contain
> the Mean Data Rate. - Minimum Data Rate is OPTIONAL and is not used
> in QoS provisioning described here.
> 

I guess I didn't ask my question as clearly as I wanted.  The
definitions currently have 2119 keywords (albeit in lower-case) and I
was curious if they needed to be there in order for them to be correct.
 I do not see a need to make them upper-case 2119 keywords, just trying
to avoid the inevitable comment during IESG review as to whether the
lower-case usage was meant to comply with 2119 definitions.

> Proposed revision: move section 1.3 ahead of section 1.2.

Ok.

>> 
>> * Section 2 uses "(in decreasing order)". The context derived from
>> the next sentence indicates that is in decreasing order of
>> priority.  I would state that explicitly.
> 
> Proposed revision: "The levels of priority in EDCA are called access
> categories (ACs) and there are four levels (in decreasing order of
> priority): Voice, Video, Best-Effort, Background."
> 

Ok.

>> present. Does that imply that the AP/MAG must have application
>> layer gateway support for each app used by the MN?  If so, that
>> could have scalability and usability implications.  May be worth
>> mentioning.
> 
> Proposed revision for step 1 (last para): "It should be noted that
> WMM-AC specifications do not contain TCLAS.  When TCLAS is not
> present, there is no direct way to derive flow specific attributes
> like Traffic Selector in PMIPv6. In this case an Application Layer
> Gateway (ALG) can derive IP flow details from information in upper
> layer protocols (e.g. SIP). It should be noted that an ALG can
> increase the complexity of the AP/MAG implementation and affect its
> scalability. If no TCLAS is derived, the reservation applies to all
> flows of the MN (not desired). Parameter mapping in this case is
> shown in Table 2."
> 

The above is fine with me.  Is ALG the correct term to describe what is
being done here?  I could envision DPI also being a correct way of doing
this, just want to make sure a future reader clearly understands what
needs to be implemented.

> Proposed revision - add new para in step (2): "If TCLAS is not
> present (when WMM-AC is used), TCLAS maybe derived using an ALG and
> populated in Traffic Selector. If TCLAS cannot be derived, the
> Traffic Selector field is not included in the QoS options."
> 

Same point as the previous comment.  Is ALG the correct term or is it
really DPI?  I don't know the correct answer and the text is fuzzy
enough to need some work.

>> description or reference of what the policy server does or how it
>> is expected to interact with these QoS mechanisms.  At a minimum,
>> there should be something in the Definitions that describes this
>> function.
> 
> Proposed revisions  a-e: (a) Add clarifying statement in introduction
> - section 1: "The LMA (Local Mobility Anchor) configures QoS policies
> on MN and AP/MAG. Further details on policy configuration and PCF
> (Policy Control Function) can be found in [RFC 7222], section 6.1."
> 
> (b) change policy server to LMA in first para: "When the application
> session completes, the LMA, or the MN may signal for the release of
> resources."
> 
> (c) revise step (4) to remove reference to policy server. " LMA
> receives the PBU and releases local resources."
> 
> (d) in section 3.2.3, first para: " When the application session
> completes, the LMA, or the MN may signal for the release of
> resources."
> 

These all look good.

>> easily see the order being 1, 3, 4, 2.  Are there corner cases
>> that should be discussed if the original order is not followed?
> 
> Proposed revision: add following text after step 4. "It should be
> noted that steps 3 and 4 can proceed independently of the DELTS
> Response (step 2)."
> 

Ok.

>> 
>> * Section 3.2 seems like an attempt to cover all possible
>> scenarios when it may not be needed.  Can a scenario be described
>> where the network would originate the QoS signaling?
> 
> Proposed revision - add as example - 3GPP TS23.203, section 7.4.2
> (IP-CAN Session Modification, PCRF Initiated): Replace first sentence
> with: " This section describes the case when the QoS service request
> is initiated by the LMA. For example an application  such as voice
> may request the network to initiate configuration of additional QoS
> policy as in [TS23.203], section 7.4.2."
> 

Ok.

> Proposed revision (in para above Figure 5): " In this use case shown
> in Figure 5, the network initiates the release of QoS resources."

Ok.

Regards,
Brian

---

From: John Kaippallimalil <[email-masked]>
Date: Wed, 11 Feb 2015 16:06:05 +0000

Hi Brian,
Copying snippets for 3 comments that need to be resolved:

> >> .............

I think I understand better now. Don't see the need for capitalized 2119 keywords in this draft either.

Proposed resolution:
- no capitalized 2119 keywords
- Revise text for Mean data rate from "should" to "must"- since it is required to populate the PMIP QoS options:
  "TSPECs for both uplink and downlink must contain the Mean Data Rate."
- all others are good as in version 05 of the draft.

> ....
> being done here?  I could envision DPI also being a correct way of
> doing this, just want to make sure a future reader clearly understands
> what needs to be implemented.

Agree that it could be either a DPI or ALG. What we need here is some functionality to extract IP flow information from application or session layer signaling and then associate it to the subsequent QoS request. 

Proposed revision for step 1 (last para): 
"It should be noted that WMM-AC specifications do not contain TCLAS.  When TCLAS is not present, there is no direct way to derive flow specific attributes like Traffic Selector in PMIPv6. In this case functionality to derive IP flow details from information in upper layer protocols (e.g., SIP) and associate to subsequent QoS request may be used. This is not described further here, but it maybe functionality in an Application Layer Gateway (ALG) or Deep Packet Inspection (DPI). It should be noted that an ALG or DPI can increase the complexity of the AP/MAG implementation and affect its scalability. If no TCLAS is derived, the reservation applies to all flows of the MN (not desired). Parameter mapping in this case is shown in Table 2."

> ....................

Proposed revision - add new para in step (2): 
"If TCLAS is not present (when WMM-AC is used), TCLAS maybe derived from information in upper layer protocols (as described in step 1) and populated in Traffic Selector. If TCLAS cannot be derived, the Traffic Selector field is not included in the QoS options."

Best regards,
John

> Sent: Tuesday, February 10, 2015 11:23 AM
> To: John Kaippallimalil; draft-ietf-netext-pmip-qos-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: AD Evaluation: draft-ietf-netext-pmip-qos-wifi
> 
> Hi John,
> 
> >> after section 1.3. The Introduction should just use the expanded
> >> terms.
> >
> etc.
> > to Mobility Access Gateway, Local Mobility Anchor, etc.
> >
> 
> Ok.
> 
> >>
> >> * Definitions
> >>
> >> the next sentence indicates that is in decreasing order of priority.
> >> I would state that explicitly.
> >
> shown
> > in Table 2."
> being done here?  I could envision DPI also being a correct way of
> doing this, just want to make sure a future reader clearly understands
> what needs to be implemented.
> 
> >>
> present
> > (when WMM-AC is used), TCLAS maybe derived using an ALG and populated
> > in Traffic Selector. If TCLAS cannot be derived, the Traffic Selector
> > field is not included in the QoS options."
> >
> 
> > LMA acts as the QoS policy server as far as semantics of this draft
> is
> > concerned.
> >
> >> - What is the rationale for the order of steps?  I could very easily
> >> see the order being 1, 3, 4, 2.  Are there corner cases that should
> >> be discussed if the original order is not followed?
> >
> may
> > request the network to initiate configuration of additional QoS
> policy

---

From: Brian Haberman <[email-masked]>
Date: Wed, 11 Feb 2015 11:25:16 -0500

Hi John,
     Your proposed changes below look fine.  Go ahead and make them and
post the updated version.

Regards,
Brian

---

From: John Kaippallimalil <[email-masked]>
Date: Thu, 12 Feb 2015 05:20:51 +0000

Hi Brian,
I have posted version 6 of the draft with all the changes made.

BR,
John

> Sent: Wednesday, February 11, 2015 10:25 AM
> >>  I do not see a need to make them upper-case 2119 keywords, just
> >> trying to avoid the inevitable comment during IESG review as to
> >> whether the lower-case usage was meant to comply with 2119
> definitions.
> >
> > - Revise text for Mean data rate from "should" to "must"- since it is
> required to populate the PMIP QoS options:
> >> The above is fine with me.  Is ALG the correct term to describe what
> >> is being done here?  I could envision DPI also being a correct way
> of
> >> doing this, just want to make sure a future reader clearly
> >> understands what needs to be implemented.
> >
> > Agree that it could be either a DPI or ALG. What we need here is some
> functionality to extract IP flow information from application or
> session layer signaling and then associate it to the subsequent QoS
> request.
> >
> > "It should be noted that WMM-AC specifications do not contain TCLAS.
> When TCLAS is not present, there is no direct way to derive flow
> specific attributes like Traffic Selector in PMIPv6. In this case
> functionality to derive IP flow details from information in upper layer
> protocols (e.g., SIP) and associate to subsequent QoS request may be
> used. This is not described further here, but it maybe functionality in
> an Application Layer Gateway (ALG) or Deep Packet Inspection (DPI). It
> should be noted that an ALG or DPI can increase the complexity of the
> AP/MAG implementation and affect its scalability. If no TCLAS is
> derived, the reservation applies to all flows of the MN (not desired).
> Parameter mapping in this case is shown in Table 2."
> >
> >
> >
> >>>> (when WMM-AC is used)?  Does it construct one via the ALG
> discussed
> >>>> above?
> >> ....................
> >>
> > "If TCLAS is not present (when WMM-AC is used), TCLAS maybe derived
> from information in upper layer protocols (as described in step 1) and
> populated in Traffic Selector. If TCLAS cannot be derived, the Traffic
> Selector field is not included in the QoS options."
> >
> >
> > Best regards,
> > John
> >
> >
> >
> >
> >>  I do not see a need to make them upper-case 2119 keywords, just
> >> trying to avoid the inevitable comment during IESG review as to
> >> whether the lower-case usage was meant to comply with 2119
> definitions.
> >>
> >>>>
> >> The above is fine with me.  Is ALG the correct term to describe what
> >> is being done here?  I could envision DPI also being a correct way
> of
> >> doing this, just want to make sure a future reader clearly
> >> understands what needs to be implemented.
> >>
> >>>>
> >>>> (when WMM-AC is used)?  Does it construct one via the ALG
> discussed
> >>>> above?
> >>>
> >>> (when WMM-AC is used), TCLAS maybe derived using an ALG and
> >>> - section 1: "The LMA (Local Mobility Anchor) configures QoS
> >>> policies on MN and AP/MAG. Further details on policy configuration
> >>> and PCF (Policy Control Function) can be found in [RFC 7222],
> section 6.1."
> >>>
> that
> scenarios

Subject: [netext] New Version Notification - draft-ietf-netext-pmip-qos-wifi-06.txt
From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 12 Feb 2015 05:15:39 +0000

A new version (-06) has been submitted for draft-ietf-netext-pmip-qos-wifi:
http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-qos-wifi-06.txt

Sub state has been changed to AD Followup from Revised ID Needed

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-qos-wifi/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-qos-wifi-06

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.

IETF Secretariat.

_______________________________________________
netext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netext