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

From: Marco Liebsch <[email-masked]>
Date: Tue, 14 Oct 2014 15:03:37 +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

---

From: John Kaippallimalil <[email-masked]>
Date: Tue, 14 Oct 2014 16:45:51 +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:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, October 14, 2014 10:04 AM
To: [email-masked]
Subject: [netext] comments to draft-ietf-netext-pmip-qos-wifi

Dear authors,

>> will revise.

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

>> 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.

>> will revise.

1.2 Definitions

>> will revise.
>> updated in current revision.

>> definitely useful - appreciate the review.

Best regards,
marco

---

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Tue, 14 Oct 2014 17:13:16 +0000

Hello Marco

Thanks for the comments. Some responses inline

regards

Rajesh
________________________________
From: netext [[email-masked]] on behalf of Marco Liebsch [[email-masked]]
Sent: Tuesday, October 14, 2014 8:03 AM
To: [email-masked]
Subject: [netext] comments to draft-ietf-netext-pmip-qos-wifi

Dear authors,

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.

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.

> 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.

 >> 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.

Best regards,
marco