1 / 30

Un-Cooperative Congestion Control

Un-Cooperative Congestion Control. Kartikeya Chandrayana Prof. Shivkumar Kalyanaraman ECSE Dept., R.P.I. chandk@rpi.edu ( http://www.rpi.edu/~chandk ). Outline. Review Motivation Previous Work Network Optimization Proposed Framework Results. Present Internet. Uses TCP .

rae-garza
Download Presentation

Un-Cooperative Congestion Control

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. 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/w Decrease: 1 Mathematical Definition: x: Rate = w/RTT p: 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. Drop Tail Queue TCP Flows shut out Effect of Misbehavior Long Flow: Conformant (TCP Reno, U=-1/x), Short Flows: Mis-Behaving (U=-1/x0.5) Incr : 1 packet/RTT Decr: sqrt(w) on loss Happened in NCSU ! Present Internet is a network of Drop Tail queues

  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. RED AQM: Effect of Misbehavior Long Flow: Conformant (TCP Reno, U=-1/x), Short Flows: Mis-Behaving (U=-1/x0.5) 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 Network Based Solution: Use AQM/Scheduler in the network End System Based Solution: Use same congestion control algorithm Limitation Limitations AQM Placement Required at every router. Constrains the choice of congestion control algorithms • 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 Routers Users Network Some Buffer Mgmt. Scheme 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 U(x) x (Rate)

  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. Non Conformant U Us U1 U2 Conformant U1,U2 define the conformance space x (Rate) Map user’s Utility Function to Conformant Space Idea: Managing Non-Conformance: Work in the Utility Function Space • Key Design Objectives: • DeploymentEase • 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.

  19. How? By Penalty Function Transformation • Map user’s utility function to some (or range of) objective utility function • Us Uobj , Uobj [U1 , U2 ] • User s is described by: • xs: Rate, Us: Utility function, q: end-to-end price • xs = Us'-1(q) • If source was using Uobjthenrate would be: xs = Uobj'-1(q) • Communicate to user the price qnew : qnew = Us' (Uobj'-1(q)) • Now user’s update algorithm looks like xs = Us'-1(qnew)  xs = Uobj'-1(q)  Appears as if user is maximizing Uobj !

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

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

  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/x0.5) RED Drop Tail ECN Enabled • 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.

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

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

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

More Related