CAPWAP Issues: QoS

Mahalingam ManiIETF 67

6 Nov 2006, San Diego

QoS Issues Outline• Besides the list of issues #196, #212 & #214 (discussed subsequent slides)

which are primarily related to control, configuration (and text clarification) of QoS policies and parameters related to STA-WTP mobile traffic – we have

• The issue (not on tracker?) related to– Should QoS enforcement be extended to WTP-AC data traffic path – DTLS

encrypted or not?– The question (of applying a QoS priority to) to control path as well.

• Discussion– 2.1.1 specifies QoS division of labor as follows, in split-MAC

• Classifying @ AC• scheduling @ WTP/AC• Queuing @ WTP

– Are there any control message elements sensitive to ordering or latency• Between themselves?• Between themselves and data-frame dispatches?

– Regardless of both we have a replay-prevention problem to solve (Puneet et al)• DTLS in the control path (when management frames to AC may have to be colored)• DTLS in the data-path• Intermediaries end up reordering packets by priority

Issue #196

• Issue:– IEEE 802.11 Update Mobile QoS. Is this for data traffic to the AC? If

so, then why is this an 802.11 message element• Initial Response

– <PRC> Intended to be a way to push policies to the WTP to prioritize mobile traffic.

• further comment:– The question appears to wrongly map Update Mobile QoS command (which is

intended to QoS parameters/config. for WTP-client traffic)

• Status: Open as of -03• Proposed resolution: clarify the usage scope and close it as editorial

fix – schedule for -04?

Issue #212• Issue

– Section 11.9.9: "If the QoS field is set," - which field > (where) are you checking for the presence or absence of the QoS Field?

• Initial Response– Another good catch of a change that is missing as a result of splitting up

message elements.

• Status: Open as of -03• Followup

– This is 6.14 in the 11bindings draft now

• Proposed resolution– Clarify the reference to QoS field in 6.14– Suggested Text

• OLD: If the QoS field is set, the WTP MUST observe and provide policing of the 802.11e priority tag to ensure that it does not exceed the value provided by the AC.

• NEW: if the QoS field in the WLAN frame is set, the WTP must observe and provide policing of 802.11e priority tag to ensure it conforms to the value as specified by AC through the IEEE 802.11 Add WLAN ME (sec 6.1) (or as configured by default).

Issue #214

• Issue– Should 802.1X frames be prioritized?– Should 802.1X frames be sent with different QoS than

regular 802.11 Data Frames? What is our QoS Philosophy for such control traffic?

• Initial Response– One would think so, and we should possibly consider this.

• Status: Open as of -03• Proposed Resolution

– Discuss why we should prioritize 802.1X frames w.r.t. other traffic.

– What should the priority be, given that they are carried in the data-path?