Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 1 Distributed QoS model for IEEE IEEE Task Group E September 2000 meeting Jan Kruys - WCND Harold Teunissen - Bell Labs Twente

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 2 Some history 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…

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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)

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 8 Design Requirements Robustness maintain the robustness of 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 MAC

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 13 Example Implementation Medium Access Control Multimedia Traffic Source System Interactive Stream Best Effort Drop Rate Control Service Rate Control System & Networkt Mgnt

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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 MIB to allow for remote control of policy and class parameters Define API for Service Access and drop rate feedback

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 18 Summary D-QoS works with proven 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

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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)?

Distributed QoS model for IEEE doc.: IEEE /267 September 2000 Jan Kruys, Harold Teunissen, Lucent TechnologiesSlide 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 TGe and the Joint HIPERLAN/2 group as basis of a QoS MAC specification