[netext] Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Tue, 16 September 2014 05:46 UTC

Return-Path: <sgundave@cisco.com>
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 489F51A02E2 for <netext@ietfa.amsl.com>; Mon, 15 Sep 2014 22:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.152
X-Spam-Level:
X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 bTJyEI2P55CS for <netext@ietfa.amsl.com>; Mon, 15 Sep 2014 22:46:53 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E9C1A02C1 for <netext@ietf.org>; Mon, 15 Sep 2014 22:46:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9287; q=dns/txt; s=iport; t=1410846413; x=1412056013; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=iWt0fqiAaZ1EA8dH3nXEWbMVMotEoChWx6zg1hQZXf8=; b=SN0i2eeQj/OYQff5NNg7kJaC4Flot7QdUWkcNpzkU5QZ2O0d8XD4bb4D M80lzGClGYPo1ssEghL3QjNgp5NVVn1WNKH+bh/bIFpuBry02v7QMgLrz 2Ee2uwjnNpNCxD34ciT+wn/c55xor4YKBCzY73EkIgddFLqDE4pDiY7Fn s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiAFAIfOF1StJV2T/2dsb2JhbABggkdGgS7SPQGBERZ4hAUEAWsTDQEaZhcOAgSISQiWK6U9ARePVIRLBY83ghaLO5U/g16CNIECAQEB
X-IronPort-AV: E=Sophos;i="5.04,533,1406592000"; d="scan'208,217";a="355528901"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 16 Sep 2014 05:46:52 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s8G5kqbB018525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <netext@ietf.org>; Tue, 16 Sep 2014 05:46:52 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Tue, 16 Sep 2014 00:46:52 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: "netext@ietf.org" <netext@ietf.org>
Thread-Topic: Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01
Thread-Index: AQHP0XGdq6lR2CqF9kq32SrRu7DxUQ==
Date: Tue, 16 Sep 2014 05:46:52 +0000
Message-ID: <D03D11DE.1645D3%sgundave@cisco.com>
In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171D9BF77E@dfweml703-chm.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.217]
Content-Type: multipart/alternative; boundary="_000_D03D11DE1645D3sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/bsSRHCFMLqeMFWmULCvdx4t5lyc
Subject: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01
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, 16 Sep 2014 05:46:55 -0000

Hi Authors:

I've reviewed the -01 version of Wi-Fi QoS document. Its is well written. Its in a good shape. Few comments below.



Major Comment:

> Section 3: "However, there are no standards defined way for the AP to initiate a QoS service request to the MN."

I'm bit disappointed to see the removal of the support for network initiated QoS set-up.  John, Rajesh and myself had several offline discussions on this few months back; Here is my comment from earlier discussions. I'm not asking the Authors to add the support for network-initiated dynamic QoS, but I thought it will be good to get some feedback from others.

"I do not understand the 802.11 guys thinking on this entire StreamId business. When I first looked at it this, I thought this is just a identifier used in Application signaling. But, when this is tied to .1Q, even the basic semantics on the StreamId length or how its used in the network is not clear to me. Their view that the tag is global and can be enforced in the entire network seems bit broken. But, that spec is not my area of expertise and so may be I missing the real intent here.

However, when I look at this from PMIP QoS point of view and with the goal of realizing end to end QoS, the QoS enforcement  in this context is on the MAG/AP. QoS enforcement on the rest of the network (MAG to LMA) is PMIP issue. If that is the baseline requirement, my point is what stops the UE or the MAG implementation to ignore the StreamId completely ? MAG and UE represent the two end points of the air interface and they both have the TFT.  So, this entire streamId business is total non-sense, specially the key protocols such as SIP have no mapping. So, even if there is public OUI allocation, I fail to understand how it fits in the overall scheme of things. So, my initial suggestion was to workaround the StreamId and make the spec work.
"



Additional Comments:

> Introduction: "STA"
Please add a reference or explanation on "STA" term - Station; In general, please add references/explanations to all Wi-Fi terminology.

> "The Mean Data Rate does not include the MAC and PHY overheads [WMM1.2.0]"
 Some explanation can help.

> However, this document does not exclude
   various deployments including those where AP and WLC are separate
   nodes, or the MAG control and data planes are separate."

Should there any guidance on how the QoS parameters are negotiated/exchanged between AP and WLC in the split mode ?

> Section 1.2: TSPEC
Add a reference to TSPEC

> GBR, AMBR Terminology
You may want to add a reference to RFC 7222 Terminology section. There is explanation for GBR, AMBR and other parameters

> PMIPV6
Should be PMIPv6

> Handovers ?
I did not see much text on what happens to the QoS states after a MN's inter-MAG handovers.

> Section 4.1
Please use "Traffic Class" in the table, instead of "DSCP"

> Error Code Mapping
RFC7222 defines couple of error codes. Its not clear how those error codes map to the Cause Codes in ADDTS Response. I saw just one Cause Code. Is that all ?

> Scope: Per-MN, Per-Session,
No discussion on the scope. Its unclear how the Per-Session, Per-MN attributes map to different Wi-Fi QoS elements

> Security Considerations
You may want to add some text on how WLAN security architecture can protect the integrity of the QoS signaling messages on the air interface. The current text may not be sufficient.


> References
Informative Reference to RFC 5213 and 5844 as the PBU/PBA messages are used in call flows
Add a reference to UPN/UPA spec (RFC7077) as its used in call flows