Distributed QoS model for IEEE 802.11 doc.: IEEE 802.11-00/267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 1 Distributed QoS model

September 2000

Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 1Distributed QoS model for IEEE 802.11

doc.: IEEE 802.11-00/267

Distributed QoS model for IEEE 802.11

IEEE 802.11 Task Group E September 2000 meeting

Jan Kruys - WCND Harold Teunissen - Bell Labs Twente

September 2000


doc.: IEEE 802.11-00/267

Some history• 802.11 started out as wireless Ethernet

• listen before talk is essential for robustness• little concern for QoS at the time

• HIPERLAN/1– distributed QoS with active signaling

• QoS not a burning issue at the time• active signaling was not trusted

• HIPERLAN/2 • born when wireless ATM was riding high• with a lot of telecom drive behind it• today the paradigm is IP and the Internet…

September 2000


doc.: IEEE 802.11-00/267

Challenges• No clear definition of requirements

• different applications spaces: home, business,• different applications, change with time• no quantitative yardstick to judge designs

• Changing environments• QoS on the Internet evolves• new frequencies and technologies• variable performance of wireless links

• Installation and management• should be easy / automatic

September 2000


doc.: IEEE 802.11-00/267

QoS Requirements Analysis • Support for interactive services

• voice, videoconferencing, games• limited delay and jitter margins

• Support for streaming services• large volumes, video on demand• tolerates delay and jitter

• Support for data• variable and any time scale• user likes a short response time

• Users or SPs define QoS Policy, not vendors

September 2000


doc.: IEEE 802.11-00/267

Operational Constraints• Variable QoS policies

• w.r.t. priorities of traffic types or connections

• w.r.t. starvation (allowed or not)

• w.r.t. to downgrading services when the medium capacity degrades

• etc.

• Variable medium capacity• short term, due to changing propagation conditions

• long term, due to changes in the population of users and subnets (shared medium)

September 2000


doc.: IEEE 802.11-00/267

Some observations• To bring QoS under control requires

• a policy for, e.g. admission control and flow control

• Centralized admission control is feasible• Centralized demand/assignment is unfeasible

• too complex• many terminals; changing instantaneous demands• changing propagation and interference conditions

cause rate adaptation• only approximate QoS optimization is possible

• Centralized flow control is not “RF robust” • even at 5 GHz not enough RF channels

September 2000


doc.: IEEE 802.11-00/267

Network Considerations• IP is the dominant network technology

• at least on the link to the user

• IP (IETF) has a variety of QoS mechanisms at TCP and IP layers

• Flow control at TCP layer• Integrated and Differentiated Services • any wireless MAC solution has to tie in with these

• a lot of research is being done on Network QoS mechanisms

• that should be leveraged

September 2000


doc.: IEEE 802.11-00/267

Design Requirements• Robustness

• maintain the robustness of 802.11 DCF• PCF suffers from hidden nodes and communication’s

errors

• Low overhead• to maintain efficient medium use (DCF is pretty good)

• Simplicity• easy to implement and install

• “Backward compatible” with current 802.11 MAC

September 2000


doc.: IEEE 802.11-00/267

Robustness Principle

Be liberal in what you accept, and conservative in what you send*

- Jon Postel

*) RFC-1122, Requirements for Internet Hosts - Communication Layers

September 2000


doc.: IEEE 802.11-00/267

Systems Approach• Address QoS at system level

• involve the application in connection set-up• define QoS Classes of Service as generic classification

that can be mapped to specific solutions and mechanisms (e.g. windowing, priorities, leaky buckets, etc)

• provide feedback to higher layers to adjust feed rate to the available wireless capacity

• Tie in with IETF work on QoS• Tie in with “OS” functions - admission control

September 2000


doc.: IEEE 802.11-00/267

Basic model for D-QOS

• Distributed QoS Flow Control• progressive reduction of service rate for lower

classes of service as the medium load goes up

• use medium load feedback to drive local service rate decisions - per Service Class

• Distributed Admission Control• use drop rate feedback to tell the application if a

new “connection” is possible.

• Based on Proportional Diff. Services model

September 2000


doc.: IEEE 802.11-00/267

QoS Policy Elements• Service Class Specification

• specifies delay and jitter targets• implies relative priority

• Service Policy specifies– basic policy

• absolute or proportional service rate• drop rate control and starvation constraints

– impact of medium load on service classes • increase or decrease the relative service rate of each class

– admission conditions

September 2000


doc.: IEEE 802.11-00/267

Example Implementation

Medium Access Control

Multimedia Traffic Source

System

Interactive

Stream

Best Effort

Drop Rate Control

Service Rate Control

System & Networkt Mgnt

September 2000


doc.: IEEE 802.11-00/267

Example Policy• Service classes are e.g.: A, B, C, D, …• Q size for Class A = n, etc.• Service rate = proportional, default distance is .5

– means A will get 2 times as much service as B, etc

• If medium access delay = x then increase class distance to .25

• if medium access delay = y than increase class distance to .1

• if Q is full then drop 2 random packets• if drop rate is > m packets/sec then refuse new

interactive and stream connections

September 2000


doc.: IEEE 802.11-00/267

Resulting Behaviour• At low medium load, all classes get “full”

service• As load increases, bias shift towards higher

classes• smooth adjustment• no starvation of lower classes

• As delay increases beyond medium capacity, applications see packet drop and adjust flow rate

• as drop rate reverses, applications increase flow

September 2000


doc.: IEEE 802.11-00/267

Further considerations• Scales to any size network• Distributes capacity evenly over multiple

cells • no need for cell overlap management

• Can be implemented at any level• but requires packet stream separation - e.g. by labels or

priority levels; this is needed any way for IntServ

• Centralised admission control and/or service rate control can be added

• e.g. driven by SBM

September 2000


doc.: IEEE 802.11-00/267

How to specify this?• Define MAC SAPs or extend current SAP

definitions with additional primitives per Service Class

• Define Service Class operations and parameters as part of 802.11 MIB

• to allow for remote control of policy and class parameters

• Define API for Service Access and drop rate feedback

September 2000


doc.: IEEE 802.11-00/267

Summary• D-QoS works with proven 802.11 DCF• D-QoS is robust and self-adjusts to medium

changes• D-QoS is simple, effective and open-ended

• fits with the Internet thinking• supports different policies

• D-QoS easy to implement - avoids the complexities of centralised scheduling and cell overlap management

September 2000


doc.: IEEE 802.11-00/267

Issues• What is needed for the feedback channels

(what information needs to be passed up/down)?

• What to do if only lower classes are used, how to use the transmit opportunities?

• What to do with backoff and possible retries?

• Overlap with neighbor cell is still resolved by retransmissions, etc. but what are the effects for QoS (delay, jitter)?

September 2000


doc.: IEEE 802.11-00/267

Next Steps• Refinement and Simulations

• before decision to adopt

• Further work on • interaction with higher layers

• interface into OS

• Propose this, besides PCF, to 802.11TGe and the Joint 802.11-HIPERLAN/2 group as basis of a QoS MAC specification

Documents

Distributed QoS model for IEEE 802.11 doc.: IEEE 802.11-00/267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 1 Distributed QoS model