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

[John Kaippallimalil <[e-mail]>]

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]

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

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

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

Proposed revision: 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.

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

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

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

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


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

> 
> * 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."
> 
> Regards,
> Brian