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

Brian Haberman <brian@innovationslab.net> Tue, 10 February 2015 17:23 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5842A1A1AE5 for <netext@ietfa.amsl.com>; Tue, 10 Feb 2015 09:23:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJEvpKAbWAk7 for <netext@ietfa.amsl.com>; Tue, 10 Feb 2015 09:23:35 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE351A1AE0 for <netext@ietf.org>; Tue, 10 Feb 2015 09:23:35 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 3D46F880ED; Tue, 10 Feb 2015 09:23:35 -0800 (PST)
Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A3C4371B0001; Tue, 10 Feb 2015 09:23:34 -0800 (PST)
Message-ID: <54DA3E90.1070107@innovationslab.net>
Date: Tue, 10 Feb 2015 12:23:28 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, "draft-ietf-netext-pmip-qos-wifi@tools.ietf.org" <draft-ietf-netext-pmip-qos-wifi@tools.ietf.org>, "netext-chairs@tools.ietf.org" <netext-chairs@tools.ietf.org>, "netext@ietf.org" <netext@ietf.org>
References: <54D8CE18.1030101@innovationslab.net> <6561EABF52675C45BCDACA1B4D7AA1171DA68E1B@dfweml703-chm>
In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171DA68E1B@dfweml703-chm>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Wata8tEi7kCHgfO6XKSU0gvKajJ8NqrSo"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netext/zomKdBG-Wo3vmz0l65HcoqtLt0o>
Subject: Re: [netext] AD Evaluation: draft-ietf-netext-pmip-qos-wifi
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext/>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2015 17:23:38 -0000

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:brian@innovationslab.net] Sent: Monday, February 09, 2015
>> 9:11 AM To: draft-ietf-netext-pmip-qos-wifi@tools.ietf.org;
>> netext- chairs@tools.ietf.org; netext@ietf.org 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