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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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