QoS: Where, When, and Why? Ed Knightly ECE/CS Departments Rice University (and without bankruptcy along the way)

Ed Knightly The Big Questions When do clients/customers want QoS? –Always! –No one wants unpredictable, poor performance How to deliver QoS? –Capacity planning? –Admission control (flow or aggregates)? –Adaptive algorithms and applications? –Marking/scheduling/AQM packet differentiation? Are we there yet? –NO! End-to-End service is lousy  Even the undergrads won’t use VoIP  Video is useless match-box sized –Applications can adapt, but users will not!

Ed Knightly Answers Required mechanisms depend on –QoS stringency: voice, live streaming media, … –Traffic: predictability, aggregation level, … –Economics: how can provider make $$ (or lose less) –Deployability: ten-year scale for layer 3, six-months for layer 2/7 Case studies: Core, Enterprise, Metro Edge, Internet Data Centers, Wireless access

Ed Knightly I. Why QoS in NOT Needed In Today’s Core 1. Traffic is highly predictable and not bursty in the core Operate here? Even QoS cannot save you

Ed Knightly Why QoS is NOT Needed in Today’s Core 1. Traffic is highly predictable and not bursty in the core because users are capped by –Abundance of low-rate access links  Ex. OC-3, T3, T1, DSL, modems, … –Abundance of rate limiters  Ex. Throttle dorm traffic; reduce ISP bill 2. There is no “production” real-time traffic –No VoIP, high-quality video, …

Ed Knightly With the Current Evolutionary Path Capacity planning is simple and sufficient –Traffic prediction = Time-of-day prediction (easy!) There are no research issues in the core –QoS or otherwise (why worry about ECN, AQM, multicast, …) More bankruptcies and junk bonds to come

Ed Knightly Disruptive Changes for the Future of the Core Economics? –Need to re-think;real costs to over-provisioning in line cards Integration of voice/video/new apps? –It’s happening at the edge Burstable high-speed packet access? –1 and 10 Gigabit Ethernet access  Clients will burst, the traffic will change  Contrast to today’s relatively low speed circuit access

Ed Knightly II. The Network Edge (Myth) Common, but unrealistic view –Hosts, network of switches (or routers), edge Internet router

Ed Knightly The Network Edge (Reality) Ring metro backbone –Rings are the dominant configuration for their fault tolerant properties –Size ~ 100 nodes, ~ 10 km

Ed Knightly SONET: the Dominant Metro Ring Technology Circuits between pairs of nodes. Problems: –Cannot re-use unused capacity (no statistical multiplexing) –Cannot burst to full link rate –Coarse bandwidth granularity (155 Mbps) –Up to N 2 circuits  Inefficient!

Ed Knightly Emerging Approach: Packet Rings (GigE and RPR) Advantages –Statistical multiplexing, burstable access, efficiency Example Metro Provider: Phonoscope –2 GigE rings spanning Houston with 400+ customers –400 Mbps of data –50 Mbps VoIP –800 Mbps of streaming MPEG

Ed Knightly Challenges in Packet Rings Fairness –Closest node to the gateway gets the most bandwidth –Extent of unfairness depends on protocol (TCP/UDP), topology (RTT and number of nodes) and traffic inputs –Goal: inter-node performance isolation Guaranteed QoS –Voice/Video require performance isolation (without circuits)

Ed Knightly Research Issues in Packet Rings Distributed priority scheduling and MAC –How to throttle at ingress, use simple transit path scheduling, and achieve ring-wide QoS/fairness goals? –Hot topic in ad hoc networking, equally challenging (and more relevant?) in packet rings Admission control, faster-time-scale capacity planning –Challenge in low-aggregation regime with (true) bursty traffic Potential impact is high –Aggressive and innovative edge service providers –Significant enterprise market –Fast innovation/deployment time at layer 2

Ed Knightly III. The Edge of the Network Edge: Internet Data Centers Many hosted sites at a shared physical location –Share network bandwidth –Share management facilities

Ed Knightly Problem with Today’s IDC’s Static Resource Model –Number of servers per website is fixed Performance losses –Peak allocation  poor resource utilization –Mean allocation  performance degradation –Inability to deal with flash crowds Result: inefficiency, poor QoS, bankruptcy E-news.com E-mart.com Workload Un-utilized servers

Ed Knightly QoS Research Problems in IDC’s: Infrastructure-on-Demand Migrate servers to hot spots Challenge: how to exploit efficiencies of resource sharing while providing QoS? –When to migrate –By how many –Load prediction –SLA provisioning Workload Un-utilized servers Server Migration E-news.com E-mart.com

Ed Knightly IV. QoS in the Other Edge: Wireless Yes, WiFi is in your future Applications: VoIP + multimedia + web + … Constraint: random access MAC’s are essential for low cost and simplicity

Ed Knightly QoS Challenges at the Wireless Edge Low aggregation regime with high burstiness: capacity planning won’t solve it Challenging QoS-aware MAC design problems –Unsolved under realistic channel models  exploit multi-rate physical layer  directional antennas  power aware Admission control/bandwidth allocation –Requires modeling/prediction of a complex system (random access, multi-priority MAC, wireless channel, …)

Ed Knightly Summary QoS in the core is not needed in evolutionary path –Watch out: revolutions are possible in search of profit Challenging hot spots –Metro edge, IDC, wireless edge, Enterprise Why? –Traffic less predictable, not highly aggregated, not rate limited –Can be more aggressive/innovative at layer 2/7