A Game-Theoretic Approach towards Congestion Control in Communication Networks

1. A Game-Theoretic Approach towards Congestion Control in Communication Networks Rahul Garg (grahul@in.ibm.com) Abhinav Kamra (abhinav@iitd.ernet.in) Varun Khurana (varun@iitd.ernet.in)

2. Overview • Background • Congestion • Voluntary congestion control • A game-theoretic model • Diminishing weight scheduling • Properties of DWS • Simulation results • Conclusions

3. A Network • Nodes/Switches/Routers • Links • End users • Humans on terminals • Servers

4. Node Model • Output queuing gives better performance • Switching is usually fast • Small input queues, long output queues Output Buffer Input Buffers Crossbar Output link Scheduler Input links Buffer Management

5. Output link Input traffic Buffer A Link • A scheduling algorithm which decides which packet to send next • A buffer management policy which decides which packet to buffer and which to drop

6. What is Congestion? • Packet drops for long periods of time • Reasons for packet drop • Link error • Buffer overflows • Instantaneous input rate > Instantaneous output rate • Average input rate > Average output rate • Congestion • Persistent buffer overflows • Over a couple of round-trip time.

7. Congestion Collapse • Most of packets dropped because of buffer overflows • Each end user keeps on re-transmitting data • Most of retransmissions are also lost • Congestion collapse did happen in mid 1980’s.

8. Congestion Collapse • A ring of 100 Mbps • N access links of 100Mbps each • Every access link sends traffic at 100 Mbps • Input traffic at link k exits at link k + N/2. • Traffic intensity of user k at link (k + i) will be 2-i 100 Mbps = 100 Kbps for i = 10 100Mbps

9. Congestion Control in the Internet • Most of the packets are dropped due to buffer overflows during congestion • Packet loss • signal for incipient congestion • Reduce sending rate • Slowly probe network otherwise • Congestion control function added to TCP

10. Additive Increase Multiplicative Decrease Algorithms • Slowly increase sending rate to probe network status (additive increase) • Packet loss: Cut the sending rate to half Start probing again • Several Variants of TCP • Tahoe, Reno, Vegas, Sack, etc.

11. Variants of TCP • How to detect packet loss? • Timeout • Duplicate acknowledgement • How to cut down the rate? • Cut to zero, then slow start and then congestion avoidance • Just cut to half • Separate reliable transmission from congestion control • TCP SACK • Integrated congestion control

12. Enhancement to TCP Congestion Control • Router Participation • Source quench • Early congestion notification (ECN) • Random early detection (RED) • Early packet discard (EPD) • Partial packet discard (PPD)

13. Congestion Control in ATM Networks • Single bit schemes • Switches set a bit in cell indicating congestion status • End hosts adjust their rates in response • Explicit rate schemes • Switches tell hosts an explicit rate • End hosts send traffic at the dictated rate

14. What is Common in these schemes? • All of them require voluntary participation by end hosts. • End hosts could choose to not react to the congestion signal and get better (and unfair) share of network resources.

15. Voluntary Congestion Control (VCC) • The action to reduce their rates is purely voluntary • It works because end hosts cooperate • Everyone uses similar algorithms to increase and decrease • End hosts could choose to do otherwise • Very easy to remove the VCC code from TCP on a Linux machine • Applications using UDP bypass the VCC code. • FTP over UDP, HTTP over UDP may lead to another congestion collapse of the Internet

16. Why Voluntary Congestion Control will not work? • Commercialization • Growth • Competition • Definition of a good end-user behaviour • Awareness • Selfishness

17. Commercialization • Businesses depend on the Internet • They pay for the service • Expect to derive a utility • Will they follow congestion control principles? • E.g. Games on the Internet

18. Growth • How to enforce voluntary congestion control? • Billions of hosts • Thousands of ISPs

19. Competition • Competing businesses depend on the Internet • Two companies making PC to PC IP telephony software • Will they follow the principles of VCC?

20. Definition of Good Behaviour • Different versions of TCP give different performance under different conditions • Difficult to define good behaviour • Especially if one has to punish misbehaving users • End users could be reactive to congestion signal but: • Be more conservative in reducing their rate • More aggressive in increasing their rate

21. Awareness • Average programmer not aware of voluntary congestion control principles • Average user not aware of “TCP friendly software”

22. Selfishness • Individuals in large groups may become selfish

23. Who is responsible? • Who is responsible for congestion control • Network hardware vendors • Operation system software writers • Application writers • End users • ISPs • How will they carry out congestion control? • Need a way to detect misbehaving users/flows and punish them

24. Possible Solutions • Making a law to punish non-compliant users • Monitory incentives for Good behaviour • Appeals to voluntarily follow Good behaviour • Incentives for Good behaviour. Punishment for bad behaviour.

25. A Game Theoretic Model • A link of capacity C • Shared by N users • A switch service discipline S • A buffer management policy B • User i sends traffic at a (input) rate ri • Traffic is received at destination at a (output) rate iSB(ri) • Vector notation:  =SB(r)

26. Utility • Every user aims to selfishly maximize its utility • A user’s utility an increasing function of its output rate only • User i’s objective: maximize i • Techniques to minimize dependence on loss rate and delay • Forward error correction for streaming media • Buffering to reduce delay-jitter • Selective retransmissions for bulk transfers • Fire-hose applications

27. Current Resource Management Policies • C = 10 Mbps • N = 5 • Input rate of one user varied • Input rate of other 4 users kept constant at 4Mbps

28. Current Resource Management Policies

29. Nash Equilibrium • The strategy profile * constitutes a Nash Equilibrium if: i i Ui(i*, -i*)  U(i, -i*) • For FCFS, RED, DT ri infinity is the only Nash Equilibrium. • For WFQ, FRED any ri > C / N is a Nash Equilibrium

30. The Diminishing Weight Scheduling • Derived from Generalized Processor Sharing (GPS) • GPS: fluid flow model • Flow conservation • Work conservation • GPS Fairness: • If Bi(t) > 0, then j: j(t) / j  i(t) / i • GPS Fairness replaced by DWS fairness

31. The Diminishing Weight Scheduling • DWS fairness: • Let bit at the head of queue of flow j at time t arrived at time j(t) • j(t) = j W(rj(j(t)) • If Bi(t) > 0, then j: j(t) / j(t) i(t) / i(t) • j DWS weights • W() is the diminishing weight function • RIS: Special case when W(r) = 1 / r

32. Packetized DWS

33. Properties of DWS • Existence of a fair rate: • There exists a unique fair rate f such that • j, j = min (W(rj) f / W(f), rj) • f  C / N • Flow j contributes to congestion iff rj > f. • Flows causing congestion get penalized according to the DWF • Well behaved flows get their rate

34. Properties of DWS • Define Nash Rate: • If r < C / N then (r) = (C – r) / (N – 1) • Otherwise (r) = x  0 s.t. x W(r) / W(x) + (N – 1) x – C = 0 • (r)  C / N • If user 1 sends at r, then (r) constitutes the unique Nash equilibrium for rest of the users.

35. Nash Rate • C = 10 Mbps • N = 5 • Variation of Nash Rate and residual Nash rate with input rate • Weight functions: • 1/r • 1/r2 • 1/log(r)

36. Properties of DWS • r = C/N constitutes the unique Nash and Stackelberg Equilibrium for a single link • Max-min-fair rate constitute a Nash and Equilibrium • There can be other Nash/Stackelberg Equilibria also • Max-min-fair rate constitute a Nash and Equilibrium that have no losses

37. Simulation Results • Unresponsive flows. • TCP Versions. • Multiple connections. • Flows with different round trip times. • Convergence to max-min fair rate in case of a network. • Impact of diminishing different weight functions.

38. Simulation Scenario NS was used to carry out all the simulations

39. Unresponsive Flows • 4 TCP flows • One unresponsive constant bit rate (CBR) flow • Different simulations with different CBR rates. • Different simulations with two versions of TCP

40. TCP Versions

41. Multiple connections

42. Different Round Trip Times

43. Network

44. Impact of Different Diminishing Weight Functions • Input rate of one user varied • Input rate of other 4 users kept constant at 4Mbps • Weight functions: • 1/r • 1/r2 • 1/r4 • 1/log(r)

45. Impact of Weight Functions • 4 TCP flows • 1 CBR flow • Rate of CBR flow varied • Weight functions: • 1/r • 1/r2 • 1/log(r)

46. Conclusions • Voluntary congestion control may not work • A class of scheduling algorithms for game-theoretic congestion control • Packetized version • Has good game theoretic properties • Fair rate is unique Nash and Stackelberg Equilibrium • Even selfish users will send traffic at fair rate

47. Conclusions • Different weight functions may be chosen for different reward penalty profiles • Rate inverse scheduling works well with TCP.

48. More Information • ACM Sigcomm Computer Communications Review: Volume 32, Number 3, July 2002, Pages 47-61 • http://www.cs.columbia.edu/~kamra/dws/

49. Thank You !!!