1. Un-Cooperative Congestion Control Kartikeya Chandrayana Prof. Shivkumar Kalyanaraman ECSE Dept., R.P.I. chandk@rpi.edu (http://www.rpi.edu/~chandk)

2. Outline Review Motivation Previous Work Network Optimization Proposed Framework Results

3. Present Internet Uses TCP. –TCP Variants Tahoe (First Proposal) Reno, New-Reno : Windows 95/98 Sack: Windows 2000+ Vegas –Other variants possible. Routers Deploy FIFO queues to absorb bursts.

4. Internet Dynamics Search Game: User searches for bandwidth with some help from the network

5. Feedback from Network Positive Feedback –Acks Negative Feedback –Implicit Drop Packets –Explicit Mark Packets –Set a bit in the packet. –This bit is echoed in the Acks Explicit Congestion Notification (ECN)

6. TCP Slow Start –Probe exponentially for bandwidth. Congestion Avoidance –Send w packets in a round-trip time. –If receive w acks then put w+1 packets in next RTT –If congestion put w/2 packets in next RTT.

7. TCP Variants TCP Friendliness : Any rate control scheme gets the same throughput as TCP under same operating conditions. Why ? TCP does not get beaten down by newer protocols Examples of TCP-Friendly Protocols:  SQRT: Increase: 1/sqrt(w) Decrease: sqrt(w)  IIAD : Increase: 1/wDecrease: 1 Mathematical Definition: x: Rate = w/RTTp: loss rate TCP Friendliness  x  1/sqrt(p)

8. But.. Application needs changed. –Different congestion control protocols. Real-Player, Windows Media, Quake, Half-Life etc. –Some of these are constant rate protocols. Linux, FreeBSD Boxes came along. –Make your own TCP. –If receive w acks then put w+5 packets in next RTT –If congestion put 3w/4 packets in next RTT.

9. So.. Users can choose their rate control algo  Rate Control Scheme  rate allocation.  Aggressive Rate Control  More Rate  Incentive for users to misbehave.  But majority of users are responsible. Assume (for now) the network’s standard CC scheme is TCP Any scheme which gets more rate than TCP is uncooperative

10. Consequences  Selfish flows grab most of the bandwidth.  One form of traffic volume based denial of service attack.  Congestion Collapse  Network has no control over equilibrium rate distributions.  Unfair Sharing aggravated on a network of Drop-Tail queues

11. Effect of Misbehavior Long Flow: Conformant (TCP Reno, U=-1/x), Short Flows: Mis-Behaving (U=- 1/x 0.5 ) Incr : 1 packet/RTT Decr: sqrt(w) on loss Drop Tail Queue TCP Flows shut out Present Internet is a network of Drop Tail queues Happened in NCSU !

12. AQM: Active Queue Management Drop Tail (FIFO) queues has limitations. Synchronization: –Queue is full –Packets from all flows are dropped. –All flows cut their rates by half simultaneously. –For a long period link is not fully utilized. –Pattern of simultaneous increase and decrease. AQM: Drop some packets before queue gets full. Some flows get early congestion signal and cut back. Link tends to be fully utilized. Example: Random Early Drop (RED) Selfish flows will probably have more packets in the buffer  Probably they will cut their rates more often.

13. AQM: Effect of Misbehavior Long Flow: Conformant (TCP Reno, U=-1/x), Short Flows: Mis-Behaving (U=- 1/x 0.5 ) RED RED Helps: Though unfair sharing persists

14. AQM: Deployment RED was proposed in 1993 Almost all routers have RED. But RED is not deployed ! –No one knows how to configure it. –Providers don’t like to drop packets. –RED too has limitations ! Lots of them Unfair sharing At High Loads RED is worse than Drop Tail ! Present Internet is just network of Drop Tail queues ! Possibility of Volume based Denial of Service Attack

15. Related Work Some Buffer Mgmt. Scheme Users End System Based Solution: Use same congestion control algorithm Network Routers Network Based Solution: Use AQM/Scheduler in the network Limitation Constrains the choice of congestion control algorithms AQM Placement Required at every router. Limitations May require exchange of control information between all AQMs/Schedulers in the network. Generally only provides Max-Min Fairness. Most Solutions do not work with a Drop Tail queue Network No clean method to manage non-conformant flows What is the right architectural response ?

16. Detour: Congestion Control- Optimization Frameworks Utility Functions –Economics –One function can capture a group of rate control schemes. –TCP-Friendly schemes imply U(x) = -1/x x (Rate) U(x)

17. Detour: Congestion Control-Optimization Frameworks Users choose congestion control algorithm.  Choose a Utility Function.  TCP : U(x) = -1/x CC Scheme  Utility function Every user maximizes his own utility function. Distributed optimization. Network communicates price (loss, mark, delay) to users. Users use this price to update their rate.

18. Idea: Managing Non-Conformance: Work in the Utility Function Space Key Design Objectives: Deployment Ease Retain existing link price update rules.  No changes in the core. Retain existing user’s rate updation rules.  Allows users to chose rate control protocol. Should work with either drop or marking based network. Should work on a network of Drop Tail queues. U1U1 U2U2 UsUs Conformant Non Conformant U 1,U 2 define the conformance space U x ( Rate ) Map user’s Utility Function to Conformant Space

19. User s is described by: –x s : Rate, U s : Utility function, q: end-to-end price –x s = U s ' -1 (q) –If source was using U obj then rate would be: x s = U obj ' -1 (q) Communicate to user the price q new : q new = U s ' (U obj ' -1 (q)) Now user’s update algorithm looks like x s = U s ' -1 (q new )  x s = U obj ' -1 (q)  Appears as if user is maximizing U obj ! Map user’s utility function to some (or range of) objective utility function U s  U obj, U obj  [U 1, U 2 ] How? By Penalty Function Transformation

20. Core Network (No Changes) Any queue mgmt algorithm  Drop Tail/RED etc. Core Routers Edge Routers Edge Based Re-Marking Agent Maps utility function Manages Selfish Flows. ( Decouple it from AQM design ) Provides Service differentiation ( Map users to different utility functions ). Users Free to choose their congestion control algorithm Either marking or dropping Idea: Remap @ the Edge, Not in AQM Decouple Management of Non-Conformant Flows from AQM Design

21. Users Network Routers Placement Destination Mark Packets Mark Acks Mark Acks Drop Packets

22. What do we need to make it work ? Need to identify misbehaving flows. –Smart Sampling in Netflow, Sample & Hold etc Estimate loss/mark rate –Currently using EWMA, WALI methods of TFRC Estimate utility function –Currently using Least Squares, Recursive LS –Needs only estimates of sending and loss rates Scalability –Keep state about only mis-behaving flows CBR/UDP flows –Need to drop (Marking does not work)

23. Re-Marker Design Implemented it in Network Simulator Estimation of loss rate Estimation of throughput Get utility function estimate Compute the Re-Marking function Appropriately Mark/Drop packets. –Can also Mark Acks Different Algorithm for CBR flows.

24. Results: Single Bottleneck Conformance: TCP-Friendliness 2 Flows: Conformant (TCP Reno, U=-1/x), Mis-Behaving (U=-1/x 0.5 ) Packet Drop Based Network. Drop packets from mis-behaving flows at the edge of the network. Marking Based Network. Re-mark packets from mis-behaving flows at the edge of the network. Drop Tail RED ECN Enabled

25. Results: Multi-Bottleneck (Drop Tail) Conformance: TCP-Friendliness Long Flow: Conformant (TCP Reno, U=-1/x), Short Flows: Mis-Behaving (U=- 1/x 0.5 ) TCP Flows shut out Framework prevents volume based denial of service attack. Without Re-Mapping With Re-Mapping

26. Results: Multi-Bottleneck (RED) Conformance: TCP-Friendliness Long Flow: Conformant (TCP Reno, U=-1/x), Short Flows: Mis-Behaving (U=- 1/x 0.5 ) Framework improves fair sharing of network Without Re-Mapping With Re-Mapping

27. Results: Multi-Bottleneck in an ECN Enabled Network Ideal Case No Re-Mapping With Re-Mapping Conformance: TCP-Friendliness Long Flow: Conformant (TCP Reno, U=-1/x), Short Flows: Mis-Behaving (U=- 1/x 0.5 )

28. More Results Background Traffic –Web (http) Traffic –Single/Multi Bottleneck scenarios Cross Traffic –Reverse path congestion –Especially important with RED –Multi-Bottleneck scenarios Comparison with other AQM schemes Differentiated Services

29. Conclusions On a network of Drop Tail queues Mis-Behaving flows can force Traffic Volume based denial of service attack. –RED can prevent it though not unfair sharing. Edge-based transformation of price can handle misbehaving flows –No changes in the core No need to add penalty box functions in the context of AQM schemes (eg: CHoKe …) –Decouple mgmt of non-conformant flows from AQM Design. Works with packet drop or packet marking (ECN) Independent of buffer management algorithm. Limitation : Path Asymmetry –Different Exit and Entry routers

30. Thanks For more details see  http://networks.ecse.rpi.edu/~kartikc/nccc.ps  Or email chandk@rpi.edu