1 / 58

Fair Bandwidth Allocation in the Internet Using a Capture-Recapture Model

Fair Bandwidth Allocation in the Internet Using a Capture-Recapture Model. Hong Kong University of Science and Technology Lawrence, Chan Ming Kit Mounir Hamdi. Presentation Outline. Motivation Previous Works Introduction To The Capture-recapture Model Proposed Solution

walda
Download Presentation

Fair Bandwidth Allocation in the Internet Using a Capture-Recapture Model

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. Fair Bandwidth Allocation in the Internet Using a Capture-Recapture Model Hong Kong University of Science and Technology Lawrence, Chan Ming Kit Mounir Hamdi

  2. Presentation Outline • Motivation • Previous Works • Introduction To The Capture-recapture Model • Proposed Solution • Implementation on the software router • Performance Evaluation • Conclusion

  3. Queuing Disciplines • Each router must implement some queuing discipline • The queuing discipline allocates both bandwidth and buffer space: • Bandwidth: which packet to serve (transmit) next - This is scheduling • Buffer space: which packet to drop next (when required) – this buffer management

  4. Scheduling & Queue Management • What routers want to do? • Isolate unresponsive flows (e.g., UDP) • Provide Quality of Service to all users • Two ways to do it • Scheduling algorithms: e.g., WFQ, WRR • Queue management algorithms: e.g., RED, FRED, SRED

  5. WFQ vs. RED • Isolation from non-adaptive flows • Hard / Expensive to implement • No isolation from non-adaptive flows • Easy to implement

  6. Random Early Detection(RED)

  7. RED Dropping Curve

  8. Active Queue ManagementGoals • Provide isolation from unresponsive flows • Be as simple as RED

  9. What QoS does RED Provide? • Lower buffer delay: good interactive service • qavg is controlled to be small • Given responsive flows: packet dropping is reduced • Early congestion indication allows traffic to throttle back before congestion • RED provide small delay, small packet loss, and high throughput (when it has responsive flows).

  10. Problems with RED – unresponsive flows

  11. Motivation • RED does NOT provide protection from unresponsive flows – it is unfair. • To provide fair bandwidth sharing, different buffer management schemes are developed to protect the well-behaved flows from the misbehaving flows. • However, most of the existing buffer management schemes cannot provide accurate fair bandwidth share.

  12. S(1) S(1) 100Mbps 100Mbps TCP sources TCP sources S(m) R1 R2 S(m) 10Mbps S(m+1) S(m+1) UDP sources UDP sources S(m+n) S(m+n) Motivation • Try to look at the following example: • Assume there is a network which is set up as:

  13. Motivation Where the configuration are: • Setup the RED (Random Early Detection) for the link between two routers • bottleneck bandwidth = 10Mbps • other links = 100Mbps • link latency for all links = 2.0msec • 20 (mixed) TCP flows • 1 1Mbps UDP flows • Fair share = 10/21 = 0.48Mbps/flow

  14. Motivation

  15. Previous works (SRED) • Stabilized RED (SRED) is a buffer management mechanism intended to estimate the number of active flows (connections). • Its main idea is simple: • compare each arriving packet with a randomly chosen packet that preceded it into the buffer. • If both packets are of the same flow, declare a "hit". • The level of hit estimates the number of active flows. • Drop probabilities are then adjusted according to number of active flows.

  16. Previous works (SRED) • Although SRED provides a mechanism to estimate number of active flows, and controls buffer occupancy by adjusting drop probabilities using estimated number of active flows, only TCP flows are assumed for the SRED algorithm. • The experimental results show that SRED cannot estimate the number of flows and provide the fair bandwidth sharing accurately in the present of the UDP traffic.

  17. Previous works (RED-PD) • RED with Preferential Drop (RED-PD) • a small number of flows occupy most of the bandwidth • RED-PD identifies a number of high bandwidth flows by means of a monitoring process. • An estimation of rate is achieved by counting the occupancy of packets in a drop history buffer. • Dropping probability of each flow in monitored lists is adjusted and stored so that the sending rate of all monitored flows can be bounded by a fair share.

  18. Previous works (RED-PD) • Weaknesses: • The threshold or the fair share in the drop history buffer is calculated by a predefined constant. • The algorithm cannot adapt to different network setups because the number of monitored flows relies on the predefined constant.

  19. Previous works (SFB) • Stochastic Fair Blue (SFB) is a technique for protecting TCP flows against non-responsive flows • SFB maintains N times L bins. • The bins are organized in L levels with N bins in each level. • Hash functions are used to map a flow into one of the N accounting bins. • Each bin in SFB keeps a dropping probability Pm.

  20. Previous works (SFB) • If the number of packets mapped to a bin goes above a certain threshold, Pm for the bin is increased. • However, simulation results show that SFB cannot provide a high degree of fairness.

  21. capture-recapture model • The CR model was originally developed for estimating the size of animal populations. • It is based on several key ideas: animals are captured randomly, marked, released and then recaptured randomly from the population.

  22. capture-recapture model • Suppose the population is of size N, so that N is the number we wish to estimate. • Suppose, • n1 animals were captured, • n2 animals were recaptured, and • m2 of these appeared to be marked. • Under capture recapture model: m2/n2 = n1/N

  23. N N N n2 n2 n1 n1 capture-recapture model • M0 model : m2/n2 = n1/N N m2

  24. capture-recapture model • M0 implies that capture probability for all animals are the same. • ‘0’ refers to constant capture probability • Capture probability refers to the chance that individual animal get caught. • In Mh model, capture probabilities vary by animal, sometimes for reasons like differences in species, sex, or age. • ‘h’ refers to heterogeneity.

  25. capture-recapture model • We use multiple captures for the Mh Model. t represents the number of capture occasions.

  26. capture-recapture model • Estimation of N under Model Mh is based on the capture frequency data f1, f2…, and ft • f1 is the number of animals were caught only once, • f2 is the number of animals were caught only twice, … etc.

  27. capture-recapture model • The jackknife estimator of N is computed as a linear combination of these capture frequencies, s.t.: N = a1f1 + a2f2 + … + atft • where ai are the coefficients which are in terms of t.

  28. A New AQM using CR model • We propose a technique, called CAP (CAPture-recapture fair sharing), for: • estimating the source data rates, and • the fair share using the capture-recapture (CR) model.

  29. A New AQM using CR model • Consider a buffer, which stores the recent arrived packets. • Number of flows = 4 • Buffer size = 8 • “fair share” = Buffer size/ Number of flows = 2

  30. A New AQM using CR model • Dropping probabilities should be adjusted, such that all users receive the same amount of bandwidth: • If a flow has occupied more than the fair share (that means it sends packets in a high rate), packets of this flow should be dropped to leave space for the other flows.

  31. Estimation of the number of flows • In general, thebuffer space occupied by different flows are different, thus, capture probabilities vary by flow. Hence, we choose Mh model to estimate the number of flows in the buffer.

  32. Estimation of the number of flows • Thus, the estimation of the total number of flows under Model Mh is based on the capture frequency data f1, f2…, and ft • f1 is the number of flows were caught only once, • f2 is the number of flows were caught only twice, … etc. • ft is the number of flows were caught only t times, … etc.

  33. Estimation of the number of flows • The jackknife estimator of N is computed as a linear combination of these capture frequencies, s.t.: N = a1f1 + a2f2 + … + atft • where ai are the coefficients which are in terms of t.

  34. Estimation of the number of flows • Instead of scanning the whole buffer to find the exact number of flows in the buffer, the Mh CR model provides an accurate estimation by simply random capturing among the incoming packets.

  35. Estimation of the data rate • Let us consider the estimation of the source data rates. • The sending rate of a certain flow can be represented by the packet counts of that flows in the buffer. • Ratered = 5, and Rategreen = 1

  36. Estimation of the data rate • Recap (M0 CR Model) • n1 animals were captured, • n2 animals were recaptured, and • m2 of these appeared to be marked. • N is the total population m2/n2 = n1/N

  37. Estimation of the data rate • Assume that all the packets with flow ID x are captured and marked when they arrived, so that n1 (the number of captures) is also the number of packets in the buffer with flow ID x.

  38. Estimation of the data rate • Flow ID x =>

  39. Estimation of the data rate • N is the size of the buffer. • Therefore, n1 can be estimated by using the equation which solves the M0 model, such that: m2/n2 = n1/N or n1 = N * m2/n2 • where n2 is the number of the recaptured packets, and m2 is the number of the marked packets among the recaptured packets.

  40. N N N n2 n2 n1 n1 Estimation of the data rate • Recap: M0 model: m2/n2 = n1/N N m2

  41. Estimation of the data rate • m2/n2 = n1/N • N=12*6, m2=3, n2=7*3

  42. Implementation on the Software Router • An Overview of a Linux software router Front end program Incoming traffic Linux Kernel (packets scheduling and shaping) Linux Kernel (Classifying)

  43. Routing & Control • Admission control • Congestion control • Reservation Policing Switching Output Scheduling Implementation on the Software Router • When comparing with traditional router, a Linux router does provides the same functions as traditional router does. Incoming traffic Linux Kernel (packets scheduling and shaping) Linux Kernel (Classifying)

  44. Implementation on the Software Router • Under real network traffic

  45. Performance evaluation • Default network setup • bottleneck bandwidth = 10Mbps • other links = 100Mbps • link latency for all links = 2.0msec • 10% TCP flows are in 10.0 msec latency • 10% are standard TCP • 10% TCP are Binomial (1.0, 0.5, 0, 1) • 10% TCP are Binomial (1.5, 1.0, 2, 0) • 20% TCP are AIMD (2, 0.5) • 20% TCP are AIMD (0.75, 0.31) • 20% TCP are AIMD (1, 0.9) • inject a CBR flow with 10-30% of bottleneck link

  46. Performance evaluation • Estimation of number of flows

  47. Performance evaluation (RED) • Throughput Comparison between CAP and RED

  48. Performance evaluation (SFB) • Throughput Comparison between CAP and SFB

  49. Performance evaluation (SRED) • Throughput Comparison between CAP and SRED

  50. Performance evaluation (RED-PD) • Throughput Comparison between CAP and RED-PD

More Related