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

[Brian Haberman <[e-mail]>]

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

Regards,
Brian


On 2/11/15 11:06 AM, John Kaippallimalil wrote:
> Hi Brian,
> Copying snippets for 3 comments that need to be resolved:
> 
>>>> * Definitions
>>>>
>>>> .............
>>>> - Do the definitions need to use the 2119 keywords?
>> 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.
> 
> 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.
> 
> 
>>>> * Section 3.1.1
>>>>
>> ....
>> 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. 
> 
> 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."
> 
> 
> 
>>>> - 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?
>> ....................
>>
>> 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.
> 
> 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
> 
> 
> 
> 
>> -----Original Message-----
>> From: Brian Haberman [mailto:[e-mail]]
>> Sent: Tuesday, February 10, 2015 11:23 AM
>> To: John Kaippallimalil; draft-ietf-netext-pmip-qos-
>> [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: AD Evaluation: draft-ietf-netext-pmip-qos-wifi
>>
>> 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
>>
>