1 / 24

QoS Controllers for the Internet

QoS Controllers for the Internet. Ibrahim Matta Azer Bestavros matta@cs.bu.edu best@cs.bu.edu www.cs.bu.edu/faculty/matta www.cs.bu.edu/faculty/best Computer Science Department

deborahowilliams
Download Presentation

QoS Controllers for the Internet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. QoS Controllers for the Internet Ibrahim Matta Azer Bestavros matta@cs.bu.edu best@cs.bu.edu www.cs.bu.edu/faculty/matta www.cs.bu.edu/faculty/best Computer Science Department Boston University Boston, MA 02215

  2. Internet QoS • Quality of Service (QoS) • Smarter bandwidth management • Eliminate cost of over-provisioning • Enhance commercial competitiveness • Traffic controllers placed in strategic places • Fast packet classification • Intelligent transmission control of packets • Keep rest of the Internet simple

  3. Placement and Functionality of QoS Controllers • Aggregate Control • Isolation Control • Proxy Control • Improved User and • Network Performance Wireless proxy Flows isolated Flows controlled as a bundle

  4. General Architecture

  5. TCP Control On every ACK if (window < threshold) // slow start phase window += 1 // double window every RTT else // congestion avoidance window += 1 / window // increment by 1 every RTT On timeout threshold = window / 2 window = 1 On duplicate acknowledgments threshold = window = window / 2 // fast recovery

  6. Aggregate TCP Control • Control congestion for collections of TCP flows that share the same bottleneck 1 MB transfers, 32 concurrent TCP flows (no cross traffic)

  7. Clients Server 1 n 25ms 25ms 32Mbps RED Why Aggregate TCP Control? • Lightly Loaded: • Bottleneck Bandwidth = 5Mbps • (delay-bandwidth product of 114 packets) • Total Transfer = 64K packets • Heavily Congested: • Delay-bandwidth product of 1 packet

  8. Lightly Loaded Conditions Bottleneck Bandwidth (n=1) Bottleneck Bandwidth (n=8) Bottleneck Bandwidth (n=16) Bottleneck Bandwidth (n=32)

  9. Heavily Congested Conditions Bottleneck Bandwidth (n=1) Bottleneck Bandwidth (n=8) Bottleneck Bandwidth (n=16) Bottleneck Bandwidth (n=32)

  10. Aggregate versus Individual TCP Control • Under individual TCP congestion control, each flow can alternate between sending packets at its minimum possible congestion window of 1 and timing out • Under heavily congested conditions, congestion window of 1 can be more than the flow’s fair share of the congested link • Bad utilization of network resources • Aggregate TCP control allows individual flows to have congestion windows of values less than 1 • Under heavy load, a flow’s fair share of the available bandwidth can actually be less than 1 • Improved stability and throughput

  11. Implementation • A common control (virtual socket) can keep track of - a count of active flows, n - an aggregate congestion window (in addition to other parameters to manage constituent flows) • The virtual socket would make sure that - the available bandwidth (in terms of aggregate congestion window packets) is divided evenly among active flows - under high congestion (timeout) conditions, if needed, the aggregate sending rate is reduced below n/RTT

  12. Size-Based Isolation Control • Routing aggregates of packet flows with divergent characteristics on (logically) separate communication paths • Length (lifetime and size) of TCP flows follows a heavy-tailed distribution - few long-lived TCP flows carry most of the bytes • Long-lived flows have a less bursty arrival/departure process • Isolate long flows from short ones

  13. Isolating Burstiness of Short Flows Load balanced assignment policy of UDP flows Short flows on Path 1, and long flows on Path 2

  14. Isolating Window Dynamics of Short Flows 200 long and 400 short TCP flows 60% of bandwidth taken by long flows 8 TCP flows (light load)

  15. More Predictability Long TCP flows with 60% of total resources Short TCP flows with 40% of total resources

  16. More Fairness • RED does not improve fairness among short TCP flows

  17. Implementation • Increase predictability by isolation and aggregate control • Only traffic controllers at the edges do per-flow management (Diffserv-like architecture) • Increase predictability for long flows by isolating burstiness and window dynamics of short flows • Short flows also benefit by not being shut off --- or unable to get their fair share before they end! • Isolation improves fairness for both short and long TCP flows • Traffic controller marks packets as belonging to long-lived flow • Direct long-lived flow to another label-switched path using MPLS • Gradually introduce re-routed TCP flow, possibly by purposely dropping packets to force it into slow-start phase

  18. QoS-Based Isolation Control • Short flows are usually interactive, delay-sensitive • Long flows are usually bulk, throughput-sensitive • Allocate more bandwidth to short flows • Response time is reduced for the majority of flows (that are short) • Fairness is also maintained for both short and long flows

  19. Proxy Control • Mask variability over shorter time scales to avoid disrupting control loops operating over longer time scales • Estimate length and characteristics of the control loops • Must not compromise the end-to-end semantics

  20. Wireless Proxy • Hiding local recovery times at • a wireless base station from TCP • Transient wireless losses do • not infiltrate into the estimation • of Round Trip Time used to • detect congestion (buffer overflow) • losses over the (wired) Internet

  21. A Control-Theoretic Approach W/difr(n-1) d <= B+C d r(n) = 1/dotherwise r : sending rate W : maximum window size d : round trip delay B : buffer space at bottleneck C : capacity of bottleneck B + C d : pipe size • Describe the behavior of the system by a discrete-time model • State changes at discrete instants of time that correspond to the arrival of feedback signals (acknowledgments, timeouts) • Evaluate stability, convergence, fairness and performance

  22. Programmable Traffic Controller • Lucent’s NEPPI (Network Element for Programmable Packet Injection) • Control programs can instruct dispatcher to forward certain packets to them • Or instruct dispatcher to create a fast path for packets

  23. Packet Processing in NEPPI • E.g. flow isolation program may instruct dispatcher to count a certain number of packets from a flow, then mark subsequent packets as long-lived • Or, may request to receive TCP packets with SYN/FIN/ACK flags to detect beginning of a TCP connection, then classify the flow based on transfer size and network state

  24. Conclusions • Traffic controllers can be placed in strategic places in the Internet to provide efficient QoS support - in front of clients/servers, or - at exchange/peering points between administrative domains • Reduce cost and enhance commercial competitiveness of Internet service providers and carriers • Basic research in the control of complex dynamical systems, that of the Internet • Experimental research in the implementation of a programmable traffic controller - programming interface to soft services, i.e. capabilities can be turned on/off and control parameters dynamically adjusted

More Related