[netext] comments to draft-ietf-netext-pmip-qos-wifi
Marco Liebsch <Marco.Liebsch@neclab.eu> Tue, 14 October 2014 15:03 UTC
Return-Path: <Marco.Liebsch@neclab.eu>
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 7AC441A8791 for <netext@ietfa.amsl.com>; Tue, 14 Oct 2014 08:03:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.387
X-Spam-Level:
X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 kg5Jomm5dq2n for <netext@ietfa.amsl.com>; Tue, 14 Oct 2014 08:03:41 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4AC1A88CC for <netext@ietf.org>; Tue, 14 Oct 2014 08:03:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B32C31083AB for <netext@ietf.org>; Tue, 14 Oct 2014 17:03:39 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jFSArFHOyj5 for <netext@ietf.org>; Tue, 14 Oct 2014 17:03:39 +0200 (CEST)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 9383610839F for <netext@ietf.org>; Tue, 14 Oct 2014 17:03:37 +0200 (CEST)
Received: from PALLENE.office.hd ([169.254.1.93]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Tue, 14 Oct 2014 17:03:37 +0200
From: Marco Liebsch <Marco.Liebsch@neclab.eu>
To: "netext@ietf.org" <netext@ietf.org>
Thread-Topic: comments to draft-ietf-netext-pmip-qos-wifi
Thread-Index: Ac/nuHxofJ1lKyptQieRHXagCdp7jQ==
Date: Tue, 14 Oct 2014 15:03:37 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26D91A96295@PALLENE.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.6.1]
Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D91A96295PALLENEofficehd_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/EHbRqiQm5sLL4rx3fXGlAIgBjlI
Subject: [netext] comments to 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, 14 Oct 2014 15:03:49 -0000
Dear authors, please find some observations during review summarized below. Sorry for posting my comments late, they are still based on revision 01 and may be obsolete with the recent update. The draft is written well and provides guidelines about operation when combining WiFi QoS with a PMIP QoS backend. I try to provide a few hints how the 'guideline'-aspects could be emphasized. It's up to the authors whether or not to adopt them. Some limitations, often constrained by WiFi/WMM, are analyzed, but few recommendations or guidelines are provided how to tackle certain situations. Clarification is not mandatory, but may help implementations. In general I see some implementation impact to the AP, so it's not simply a configuration issue or even plug and play :) The fact to have two policy decision points with strong dependencies now breaks the WiFi QoS state machine. It may be useful to state this in the draft. Impact of the described WiFi admission control may be clarified, so I do not assume that a failed QoS request results in broken connectivity. But a hint about how to treat that case can be useful. I suppose no QoS state will be set up but traffic is treated BE, correct? Taking the operation in sec 3.1.1, the LMA may revise the requested QoS and let the MAG/AP know in the PBA. Is there support in WiFi/WMM to notify the MN about a successful QoS request but with adjusted (downgraded) QoS values? Or is this treated as failed QoS request as per the WiFi specification? Sec. 3.2.1 describes the case when the LMA initiates a QoS setup and correctly points to the lack of support for network initiated QoS setup in WLAN. The current description is clear, but some recommendations how to tackle this may be given to meet a reader's expectations on guidelines. E.g. how could a MAG accept or re-negotiate an LMA-initiated QoS setup? It should not accept the LMA's request when the AP has not sufficient resources. So, the MAG may have knowledge about a resources budget from the AP (aggregated or per MN). Providing such information is of course optional and up to authors' decision. 1.2 Definitions >From sec. 3.1.1 I understand that terms peak and mean data rate are per-flow, correct? This may be stated in sec. 1.2 if it's the general assumption for the referred WMM procedure. I am not so clear about the statement that WMM-AC specs do not consider a TCLAS (sec 3.1.1). Missing this attribute does not allow the description of a flow using the Traffic Selector in PMIP. Sec. 3.1.1 indicates that in such case only a single reservation per AC is possible. Are there default configurations then to identify best effort, video, voice, etc. traffic? Or is that case even limited to a single reservation per MN/MAC address, hence all traffic of that MN is assigned to the AC? How is that limitation reflected on the PMIP QoS; should per MN, per mobility session aggregates be used? This could be clarified. Hope you find these comments useful. Best regards, marco
- [netext] comments to draft-ietf-netext-pmip-qos-w… Marco Liebsch
- Re: [netext] comments to draft-ietf-netext-pmip-q… John Kaippallimalil
- Re: [netext] comments to draft-ietf-netext-pmip-q… Rajesh Pazhyannur (rpazhyan)