Some history

1. Distributed QoS model for IEEE 802.11IEEE 802.11 Task Group E September 2000 meetingJan Kruys - WCND Harold Teunissen - Bell Labs Twente Jan Kruys, Harold Teunissen, Lucent Technologies

2. 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… Jan Kruys, Harold Teunissen, Lucent Technologies

3. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

4. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

5. 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) Jan Kruys, Harold Teunissen, Lucent Technologies

6. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

7. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

8. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

9. Robustness Principle Be liberal in what you accept, and conservative in what you send* - Jon Postel *) RFC-1122, Requirements for Internet Hosts - Communication Layers Jan Kruys, Harold Teunissen, Lucent Technologies

10. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

11. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

12. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

13. Example Implementation System & Networkt Mgnt System Interactive Stream Best Effort Multimedia Traffic Source Medium Access Control Drop Rate Control Service Rate Control Jan Kruys, Harold Teunissen, Lucent Technologies

14. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

15. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

16. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

17. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

18. 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 Jan Kruys, Harold Teunissen, Lucent Technologies

19. 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)? Jan Kruys, Harold Teunissen, Lucent Technologies

20. 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 Jan Kruys, Harold Teunissen, Lucent Technologies