The War Between Mice and Elephants

1. The War Between Mice and Elephants By Liang Guo (Graduate Student) Ibrahim Matta (Professor) Boston University ICNP’2001 Presented By Preeti Phadnis

2. Outline • Introduction • Analyzing Short TCP Flow Performance • Architecture and Mechanism –RIO-PS • Simulations • Discussions • Conclusions and Future work

3. Mice : Short TCP flows e.g. Web Traffic 20% of internet traffic is carried by large number of mice Elephants : Long TCP flows e.g. FTP 80% of internet traffic is carried by small number of elephants Mice vs Elephants

4. Internet today • WWW : ” World Wide Wait “ term coined by R. Khare and I .Jacobs • Users spend long time downloading a plain text webpage • Reason: The mice don’t get the fair share of the network resources

5. Factors effecting the performance of mice • TCP tries to conservatively ramp up its transmission rate to the maximum available bandwidth • For short connections, since congestion window is very small, packet loss always requires timeout to detect. • For the first few packets, since no sampling data is available, TCP has to use a conservatively estimated ITO value as RTO. Short Connection performance is degraded due to large timeout period.

6. Related work • Crovella et al 2001 [16] and Bansal et al 2001 [17] comment that size aware job scheduling helps enhance the response time of short jobs without hurting the performance of long jobs. • D.D Clark and W.Fang 1998 [4] AQM scheme using RED with In and Out Policy

7. Outline • Introduction • Analyzing Short TCP Flow Performance • Architecture and Mechanism –RIO-PS • Simulations • Discussions • Conclusions and Future work

8. Sensitivity Analysis for Short and Long TCP Flows

9. Sensitivity Analysis of Transmission Time

10. Factors Effecting Variability • When Loss rate high TCP Congestion control is more likely to enter exponential back off phase, which can cause significantly high variability in transmission time of each individual packet of a flow. Short flows are effected more due to this reason. • When loss rate low, TCP either in slow start or congestion avoidance phase. This dimension of variability is more pronounced for long flows.

11. Preferential Treatment to Short TCP flows • Simulation using NS simulator • 10 long(10000-packet) TCP-NewReno flows and 10 short(100-packet) TCP-Newreno flows over 1.25Mbps link. • Queue Management Policy – Drop Tail, RED ,RIO with preference to short flows.

12. Link Utilization under Drop Tail, RED and RIO-PS

13. Network Goodput Under Different Schemes

14. Outline • Introduction • Analyzing Short TCP Flow Performance • Architecture and Mechanism –RIO-PS • Simulations • Discussions • Conclusions and Future work

15. Proposed Architecture

16. Edge Router • Determines packet coming from long or short flow • Maintains a counter Ltthat tracks how many packets have been observed so far for a flow. Ltis dynamic • Per flow state information are softly maintained to detect the termination of flow. The flow hash table is updated periodically every Tu time units. • It is configured with SLR (Short to Long ratio). • It then periodically (every Tc time units) performs AIAD control over the threshold to achieve the target SLR

17. Core Router • Gives preferential treatment to mice • RIO (Red In and Out) queuing policy is used[4] with preferential treatment to short flows- RIO-PS • RIO used twin RED algorithms for dropping packets one for ins and one for outs. • The probability of dropping “in” packets depends on the in average “in” packet queue and the probability of dropping “out” packets depend on the total average queue length. • No packet reordering will happen in the FIFO queue with RIO • RIO inherits all features of RED • RIO performs soft prioritization, thus does not lose the benefit of statistical multiplexing.

18. RIO Queue with preferential treatment to short flows

19. Outline • Introduction • Analyzing Short TCP Flow Performance • Architecture and Mechanism –RIO-PS • Simulations • Discussions • Conclusions and Future work

20. Simulation Setup

21. Simulation Configuration

22. Experiment 1 • 4000 secs simulation time,2000 secs warm up time. • Average response time relative to RED

23. Instantaneous Queue Size and Drop Rate

24. Fairness of Transmission time

25. Transmission Time of foreground traffic

26. Network goodput

27. Experiment 2:Unbalanced Requests Client set 1 requests smaller objects ,Client set 2 requests larger objects

28. Experiment 2

29. Outline • Introduction • Analyzing Short TCP Flow Performance • Architecture and Mechanism –RIO-PS • Simulations • Discussions • Conclusions and Future work

30. Discussion • Simulation Model • Dumbbell and Dancehall model used. • All TCP connections have similar end to end propagation delays, this is not common topology seen by internet users • If reverse traffic present even better performance • Queue Management Policy • RIO neither provides absolute aggregate (class based) nor relative flow based guarantees. • Other AQM policies like PI controlled RED queue better

31. Discussions • Deployment Issues • Edge devices need to perform per-flow state maintenance and per packet processing but it does not effect performance. • Not required to implement queue policies at each router, RIO-PS can be implemented at busy bottleneck links. • Flow Classification • Threshold based classification classifies the first few packets of all flows to be short but it helps enhance performance .

32. Discussions • Controller design • The actual SLR depends on values of Tc and Tu, which determines Lt. Smaller values of these increases accuracy at the expense of increased overhead • Malicious users • Can break long transmissions into short flows but overhead of fragmentation and reassembly is very high.

33. Outline • Introduction • Analyzing Short TCP Flow Performance • Architecture and Mechanism –RIO-PS • Simulations • Discussions • Conclusions and Future work

34. Conclusions and Future Work • Performance of mice is improved • Performance of few elephants is also improved • Overall goodput of the system is also improved • The proposed architecture is flexible in that the functionality that defines this scheme can be largely tuned at the edge routers

35. Future work • Integrate size aware traffic management at both network and transport layers