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

[Brian Haberman <[e-mail]>]

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:[e-mail]] Sent: Monday, February 09, 2015
>> 9:11 AM To: [e-mail];
>> netext- [e-mail]; [e-mail] 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]

Ok.

> 
>> 
>> * 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.
> 
> Section 1 (Introduction): will expand each term such as MAG, LMA,
> etc. to Mobility Access Gateway, Local Mobility Anchor, etc.
> 

Ok.

>> 
>> * Definitions
>> 
>> - 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.
> 

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.

>> 
>> - For simplicity, I would move section 1.3 ahead of section 1.2.
> 
> 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.

>> 
>> * 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.
> 
> 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.

>> 
>> - 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?
> 
> 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.

>> 
>> * 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.
> 
> 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.
> 

These all look good.

> 
>> 
>> - 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?
> 
> 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.

>> 
>> * 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."

Ok.

Regards,
Brian