1 / 32

Controlling High Bandwidth Aggregates in the Network

Controlling High Bandwidth Aggregates in the Network. Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker ACM SIGCOMM Computer Communication Review

byronl
Download Presentation

Controlling High Bandwidth Aggregates in the Network

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. Controlling High Bandwidth Aggregates in the Network Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker ACM SIGCOMM Computer Communication Review 􀀀 July 2002 Presented by J.H. Su OPlab, IM, NTU

  2. Outline • Introduction • Local ACC • Pushback mechanism • Simulation • Conclusions OPlab, IM, NTU

  3. Introduction(1/3) • Persistent overloads can arise for several reasons. • A single flow not using end-to-end congestion control. • A general excess of traffic. • denial of service (DoS) • flash crowds • Slashdot effect OPlab, IM, NTU

  4. Introduction(2/3) • The persistent congestion is due to a particular aggregate of packets causing the overload, and these offending packets are usually spread across many flows. • Congestion caused by aggregates cannot be controlled by conventional flow-based protection mechanisms. OPlab, IM, NTU

  5. Introduction(3/3) • Aggregate-based congestion control(ACC) • Local ACC • Identification algorithm • Control algorithm • Pushback • Allows a router to request adjacent upstream routers to rate-limit the specified aggregates. OPlab, IM, NTU

  6. Local ACC • Local ACC can be broken down into detection and control • ACC Agent • responsible for identifying aggregates and computing a rate limit for them(by drop rate). • Rate-Limiter • responsible for classifying packets, rate-limiting those belonging to a rate-limited aggregate. OPlab, IM, NTU

  7. Local ACC-rate limiting architecture Rate-Limiter Packet surviving the rate-limiter Y High-BW Agg? Drop? In N FIFO output queue out N Y Information on Identified aggregates ACC Agent OPlab, IM, NTU

  8. Detecting Congestion • The identification process in the ACC Agent is triggered when the output queue experiences sustained high congestion. • Define sustained congestion as a drop rate of more than Phigh over a period of K seconds. OPlab, IM, NTU

  9. Identification of High Bandwidth Aggregates • identify high-bandwidth aggregates based on the destination address. • 1.Identify high-bandwidth aggregates based on the destination address(32-bits). • 2.Cluster these addresses into 24-bit prefixes. • 3.For each of these clusters try obtaining a longer prefix that still contains most of the drops. • 4.All these clusters are then sorted in decreasing order based on the number of drops associated with them. OPlab, IM, NTU

  10. Determining the Rate Limit for Aggregates(1/2) • The ACC Agent has a sorted list of aggregates, starting with the aggregate with the most drops from the drop history. • The ACC Agent estimate the arrival rate from each aggregate over the most recent seconds. • The ACC Agent next calculates Rexcess , the excess arrival rate at the output queue used Ptarget. OPlab, IM, NTU

  11. Determining the Rate Limit for Aggregates(2/2) • Determines the minimum number of aggregates that could be rate-limited. • total number of rate-limited aggregates must be at most MaxSessions. • If the ACC Agent has determined that it can rate-limit the i top aggregates, it next computes the rate-limit L to be applied to each aggregate such that OPlab, IM, NTU

  12. Rate-limiter • The rate-limiter is a pre-filter before the output queue that merely decides whether or not to drop each arriving packet in the aggregate. • drop packets from the aggregate when the aggregate’s arrival rate to the rate-limiter is above the specified limit. • Else forwarded packet to the real output queue. OPlab, IM, NTU

  13. Notation(1/2) OPlab, IM, NTU

  14. Notation(2/2) OPlab, IM, NTU

  15. Algorithms(1/2) OPlab, IM, NTU

  16. Algorithms(2/2) OPlab, IM, NTU

  17. Simulation without Local ACC All OPlab, IM, NTU

  18. Simulation with Local ACC OPlab, IM, NTU

  19. Pushback Highly congested OPlab, IM, NTU

  20. Deciding when to Invoke Pushback • After detecting aggregate-based congestion, the ACC Agent must decide whether to invoke pushback by calling the Pushback Agent at the router. • Two situations warrant the invocation of pushback • when the drop rate for an aggregate in the rate limiter remains high for several seconds. • when the Pushback Agent has other information that a DoS attack is in progress. OPlab, IM, NTU

  21. Sending the Pushback Requests Upstream • Pushback Agent does not send a pushback request to non-contributing links. • Pushback Agent determine how much traffic in the aggregate each link contributes. • Pushback Agent determines the limit-rate and sends a pushback request message to those routers. OPlab, IM, NTU

  22. Feedback to Downstream Routers • The upstream send pushback status messages to the downstream router, reporting the total arrival rate for that aggregate from upstream. • Downstream router determine how to divide the new bandwidth limit among the upstream routers. OPlab, IM, NTU

  23. Feedback to Downstream Routers Estimate the total arrival rate for the aggregate as 23.5 Mbps OPlab, IM, NTU

  24. Simulation • The bad sources send attack traffic to the victim destination D • The poor sources are innocent sources that happen to send traffic to the destination when it is under attack. • The good sources send traffic to destinations other than D . OPlab, IM, NTU

  25. Simulation without ACC OPlab, IM, NTU

  26. Simulation with only local ACC OPlab, IM, NTU

  27. Simulation with local ACC and pushback OPlab, IM, NTU

  28. Simulation with DDoS Attacks OPlab, IM, NTU

  29. Simulation with DDoS Attacks OPlab, IM, NTU

  30. Simulationwith Flash Crowds • Flash crowds with the “flash” traffic from 32 sources sending Web traffic to the same destination. • The good traffic comes from ten other sources sending Web traffic to various other destinations. OPlab, IM, NTU

  31. Simulationwith Flash Crowds More than 80% good transfer complete within 6’s with pushback less than 40% Good transfer Complete within 6’s Without pushback OPlab, IM, NTU

  32. Conclusions • Proposed both local and cooperative mechanisms for aggregate-based congestion control. • These mechanisms are promising directions to control both DoS attacks and flash crowds. • Need to understand the pitfalls and limitations of ACC itself. • Expect the ACC mechanisms to be heavily in fluenced by policy. OPlab, IM, NTU

More Related