Re: [netext] comments to draft-ietf-netext-pmip-qos-wifi

John Kaippallimalil <John.Kaippallimalil@huawei.com> Tue, 14 October 2014 16:46 UTC

Return-Path: <John.Kaippallimalil@huawei.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 657291A8A94 for <netext@ietfa.amsl.com>; Tue, 14 Oct 2014 09:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level:
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 hkLlmGl2GT0I for <netext@ietfa.amsl.com>; Tue, 14 Oct 2014 09:46:53 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51DB51A895D for <netext@ietf.org>; Tue, 14 Oct 2014 09:46:52 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNQ38382; Tue, 14 Oct 2014 16:46:50 +0000 (GMT)
Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Oct 2014 17:45:57 +0100
Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Tue, 14 Oct 2014 09:45:51 -0700
From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
To: Marco Liebsch <Marco.Liebsch@neclab.eu>, "netext@ietf.org" <netext@ietf.org>
Thread-Topic: comments to draft-ietf-netext-pmip-qos-wifi
Thread-Index: Ac/nuHxofJ1lKyptQieRHXagCdp7jQAEOXCg
Date: Tue, 14 Oct 2014 16:45:51 +0000
Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DA24914@dfweml703-chm>
References: <69756203DDDDE64E987BC4F70B71A26D91A96295@PALLENE.office.hd>
In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D91A96295@PALLENE.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.238]
Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DA24914dfweml703chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/6AmayovWCujiO9ElkjiX-FUR6Fg
Subject: Re: [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 16:46:56 -0000

Hi Marco,
Thank you for the detailed review. The comments and suggestions are very useful to clarify operation and improve readability - especially since this draft contains guidelines.
Will revise with input from these comments in the next few days.

Some notes on planned revision inline below.

Best Regards,
John


From: netext [mailto:netext-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, October 14, 2014 10:04 AM
To: netext@ietf.org
Subject: [netext] comments to draft-ietf-netext-pmip-qos-wifi

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.

>> will revise.

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?

>> correct. Revision 02 has some updates to clarify this, but will look over again.

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?

>> This would be a failed request per WiFi.
Can add text to clarify this. Recommendations beyond that would perhaps be beyond the scope of this draft.

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.

>> will revise.


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.

>> will revise.
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.
>> updated in current revision.


Hope you find these comments useful.

>> definitely useful - appreciate the review.

Best regards,
marco