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

["Rajesh Pazhyannur (rpazhyan)" <[e-mail]>]

Hello Marco

Thanks for the comments. Some responses inline

regards

Rajesh
________________________________
From: netext [[e-mail]] on behalf of Marco Liebsch [[e-mail]]
Sent: Tuesday, October 14, 2014 8:03 AM
To: [e-mail]
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.

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?

> Yes, ADDTS response can provide success/failure status code. It does not admit flows with "downgraded" QoS values.

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.

 >> Yes, we will clarify but briefly what we are saying is the following. IEEE 802.11 has a information called TCLAS (which as the name indicates provides flow classifiers). However, TCLAS is an optional field. However, WMM-AC (from the Wi-Fi Alliance) which is a certification specification for admission control does not include TCLAS in the signaling. So WMM-AC compliant devices are unlikely to have this field.


Hope you find these comments useful.

Best regards,
marco