1 / 54

Novel Function Placement of Congestion Control Building Blocks in the Internet

Novel Function Placement of Congestion Control Building Blocks in the Internet. Kartikeya Chandrayana. Outline. Review Randomized TCP Uncooperative Congestion Control virtual AQM Conclusions. Congestion Control. Internet Meltdown Need for congestion control.

tilly
Download Presentation

Novel Function Placement of Congestion Control Building Blocks in the Internet

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. Novel Function Placement of Congestion Control Building Blocks in the Internet Kartikeya Chandrayana

  2. Outline • Review • Randomized TCP • Uncooperative Congestion Control • virtual AQM • Conclusions

  3. Congestion Control • Internet Meltdown • Need for congestion control. • Congestion Avoidance and Control • End system based techniques. • TCP • Network based solutions • Active Queue Management (AQM) e.g. RED

  4. TCP • Transmission Control Protocol • Protocol used to transport data • Source: Send a packet, Receiver: Acknowledge the packet • Almost all applications (90%) use TCP • What rate to send ? • No way of knowing what is the available bandwidth • Probe for bandwidth • In some time “T” send w packets • If Acks for all w packets are rcvd then • Send w+1 packets next time • Else • Send w/2 packets

  5. End-System Based Solution • TCP + Drop-Tail Queuing. • TCP’s performance suffers on Drop-Tail queues. • Synchronization • Congestion window of different flows increase and decrease simultaneously • Burst losses • Bias against flows with large RTT • Full Queues • Phase Effects • Only a section of flows get dropped all the time • Lockout Effect • Few flows monopolize the buffer space

  6. Active Queue Management • Proactively Manage Queues • Drop packet before queue overflows • Small queues • Probabilistic Dropping • Introduces randomization in network • Early Congestion Indication • ProtectTCP Flows • CBR flows, selfish flows • e.g. RED (and variants), REM, AVQ, CHOKe

  7. Drop/Mark Accept Probabilistically Accept Random Early Drop (RED) Head Maxth Minth avg: average queue length (EWMA) • if avg < Minth then queue packet • if avg > Maxth then drop packet • else, probabilistically drop/accept packet.

  8. AQM Continued • Have parameters which require configuration • e.g. Threshold to probabilistically drop packets • Configuration Parameters are generally a function of link capacity, number of flows etc. • Small operating region • RED can perform worse than Drop-Tail queues • AQMs are not deployed on the Internet Problems with Drop-Tail Queues Persist Internet Works with Drop-Tail Queues

  9. Review: Possible Solutions 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. How do we verify the trust ? 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 Routers Users Network Some Buffer Mgmt. Scheme What are the alternate architectural responses ?

  10. Big, Fast Routers, Millions of Flows, Giga Bytes of Data Minimal Changes/upgrades in the network Any queue mgmt algorithm  Drop Tail/RED etc. First place where network can verify trust Medium Sized Routers, Manageable number of flow/data Uncooperative Congestion Control Virtual AQM Protect TCP Flows, Manage Queues Emulate Many Beneficial Properties of RED Proposed Solution Edge Routers Core Routers Network Users Randomized TCP De-couple congestion control tasks from their placement

  11. Outline • Review • Randomized TCP • Uncooperative Congestion Control • virtual AQM • Conclusions

  12. TCP Randomized TCP Randomized TCP • Randomize the packet sending times •  = (1+x) RTT/W • X : Uniform(-1, 1) • Always observe packet conservation

  13. Benefits of Randomized TCP • End-System solution for introducing randomization in the network • Emulates many beneficial properties of RED • Breaks synchronization • Spreads losses over time • Independent losses • Removes Phase Effects • Removes Bias against large RTT flows • Reduces burst losses • Competes fairly with TCP Reno

  14. 60 ms 8 Mbps 2 Mbps 80 ms Randomized TCP: Bias against large RTT flows Single Bottleneck, Ideal Share: Long (43%), Short(57%)

  15. Randomized TCP: Phase Effects 8 Mbps 5 ms 8 Mbps 5 ms 0.8 Mbps 100 ms Randomized TCP removes phase effects

  16. Randomized TCP: More Results • Randomized TCP competes fairly with TCP Reno • Removal of Phase Effects, Bias against large RTT flows, synchronization • Other Single bottleneck setups • Multi-bottleneck setups • Even one Randomized TCP flow improves performance • Randomized TCP reduces burst losses • Randomized TCP improves performance of other window based rate control schemes • Binomial Congestion Control We can decouple management of synchronization, phase effect, bias against large RTT flows, burst losses from AQM design Randomized TCP can emulate many beneficial properties of RED

  17. Outline • Review • Randomized TCP • Uncooperative Congestion Control • virtual AQM • Conclusions

  18. New Congestion Control Schemes • Application needs have changed • TCP not suitable • Different congestion control protocols • Real-Player, Windows Media, Quake, Half-Life etc. • Linux, FreeBSD Boxes came along • Make your own TCP. • If receive w acks then put w+5 packets in next RTT • TCP send w+1 packets in next RTT • If congestion put 3w/4 packets in next RTT • TCP send w/2 packets in next RTT

  19. Classification • Responsive • React to congestion indication by cutting down its rate • e.g. TCP (and its variants) • Selfish/Mis-Behaving • Maybe • Un-responsive • Do not react to congestion indications • e.g. UDP, CBR • Selfish/Mis-Behaving • Always

  20. 1 Mbps Bandwidth left For TCP UDP Source Sending at 600Kbps Consistently looks at increasing it’s share Responsive Selfish Source 1 Mbps Responsive vs Un-responsive

  21. TCP Flows shut out Selfish Responsive Flows: Impact 8 Mbps 5 ms 20 ms 20 ms Drop Tail Queue 0.8 Mbps 0.8 Mbps Traffic Volume Based Denial-of-Service Attack

  22. Possible Solutions • Everyone uses TCP • TCP Friendliness • Any rate control scheme gets the same throughput as TCP under same operating conditions. • x  1/sqrt(p) (x: rate, p : packet loss probability) • Network Based Solutions • Use Active Queue Management (AQM) • e.g. Random Early Drop (RED) • Minth, Maxth, p, Qavg • FRED, CHOKe etc. • Require Deployment at ALL routers

  23. RED AQM: Effect of Misbehavior 8 Mbps 5 ms 20 ms 20 ms RED Queue 0.8 Mbps 0.8 Mbps RED Helps: Though unfair sharing persists

  24. Other TCP Like Schemes • TCP - Every RTT • W(t+1) = W(t) +  ( = 1) if no loss • W(t+1) = (1-)W(t) ( = 0.5) otherwise • Time-Invariant Schemes • Control parameters do not change with time • Utility function does not change with time • Increase : /f(W) f(W) > 0 • Decrease: (1-)*g(W) 0 < g(W) < 1 • TCP Friendly Schemes • f(W)g(W) = W • Binomial Congestion Control Schemes • Increase: /Wk(t) , Decrease: (1-)Wl(t) • TCP Friendly Schemes given by k+l = 1

  25. Other TCP Like Schemes • Time Invariant Schemes • Aggressive Selfish schemes: •  > 1 •  > 0.5 • f(W)g(W) < W • e.g Increase: , Decrease: W0.5(t) • Time Variant Schemes • Control Parameters change with time • (t) > 0 • (t) > 0 • Increase: 1/Wk(t) , Decrease: Wl(t) • k(t) + l(t) = 0

  26. Consequences.. Users can choose their rate control scheme • Rate Control Scheme  rate allocation. • Aggressive Rate Control  More Rate • Incentive for users to misbehave. • But majority of users are responsible. • Traffic-Volume based denial-of-service attack • Assume (for now) the network’s standard CC • scheme is TCP • Any scheme which gets more rate than TCP is • uncooperative

  27. 1M + 10 10 20 1M 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)

  28. 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 imposes capacity constraints • Total input rate cannot exceed capacity • Communicates to users the price of using link • Price : loss rate, mark (ECN), delay • Users use this price to update their rate

  29. Optimization Framework: TCP Max -1/xs s.t. (xs – Cl)  0, for all l • TCP tries to minimize delay • Equilibrium allocation (fairness) • Minimum Potential Delay Fairness • Max-Min Fairness • U(x) = –1/xN (N ) • Proportional Fairness (TCP Vegas) • U(x) = log(x)

  30. Non Conformant Non Conformant U Selfish Us U Map Us U1 U1 = U2 = -1/x U2 Conformant TCP Friendliness U1,U2 define the conformance space x (Rate) x (Rate) Map user’s Utility Function to Conformant Space 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. Map user’s Utility Function to Conformant Space

  31. 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 !

  32. 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). Idea: Remap @Edge, Not in every Router Edge Routers Core Routers Core Network (No Changes) Users Decouple Management of Selfish Flows from AQM Design

  33. What do we need to make it work ? • Estimate utility function • Currently using Least Squares, Recursive LS • Needs only estimates of sending and loss rates • Estimate loss/mark rate • Currently using EWMA, WALI methods of TFRC • Need to identify misbehaving flows. • Smart Sampling in Netflow, Sample & Hold etc

  34. Utility Function Estimation • Increase: /xk(t) , Decrease xl(t) • Utility function (n = k+l) • U = -  /(Rn (xR)n) • U  -1/xn • U’(x) = p • log(p) = log(nK) – (n+1)log(x) • Use linear least squares to estimate n

  35. Results: Single Bottleneck TCP Reno, U=-1/x 4x Mbps 5 ms x Mbps 20 ms Mis-Behaving (U=-1/x0.5) RED/ ECN Enabled Drop Tail

  36. Results: Multi-Bottleneck (Drop Tail) 8 Mbps TCP Reno, U=-1/x 5 ms 20 ms 20 ms Drop-Tail Queue 0.8 Mbps 0.8 Mbps Selfish (U=-1/x0.5) Selfish (U=-1/x0.5) Without Re-Mapping With Re-Mapping TCP Flows shut out Framework prevents volume based denial of service attack.

  37. Results: Multi-Bottleneck (RED) 8 Mbps TCP Reno, U=-1/x 5 ms 20 ms 20 ms RED Queue 0.8 Mbps 0.8 Mbps Selfish (U=-1/x0.5) Selfish (U=-1/x0.5) Without Re-Mapping With Re-Mapping Framework improves fair sharing of network

  38. Results: Multi-Bottleneck in an ECN Enabled Network 8 Mbps TCP Reno, U=-1/x 5 ms 20 ms 20 ms RED Queue 0.8 Mbps 0.8 Mbps Selfish (U=-1/x0.5) Selfish (U=-1/x0.5) With Re-Mapping Ideal Case No Re-Mapping Congestion Response Conformance

  39. Utility Function Estimation Results TCP Reno, U=-1/x 4x Mbps 5 ms x Mbps 20 ms Mis-Behaving (U=-1/x0.5) N = 0.6, (Ideal: N=0.5) N = 0.8, (Ideal: N=1.0) Can estimate the exponent with a very small sample set

  40. 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

  41. Outline • Review • Randomized TCP • Uncooperative Congestion Control • virtual AQM • Conclusions

  42. Stream H Stream F Stream G virtual AQM: Definitions R2 R3 R1 E1 I1 R4 I1- R1 -R2 -R3 -E1 : Path

  43. S Bytes  C = 8*S/ a + c a Ceff = 8*S/c D = C - Ceff Cross-Traffic virtual AQM: Definitions • Path Capacity : Minimum Link Capacity on a Path • Send a pair of back-to-back packets through Priority Queues • Path Demand : Demand on a Path • Send a packet train through data queue

  44. virtual AQM: Algorithm • : network utilization ( < 1) • Calculate virtual path capacity as • Cv =  * path Capacity • Idea : Match Demand to Virtualpath capacityat the network edge • For every path • For every packet • Drain virtual buffer as (tn-tn-1)* Cv • Increase count of virtual buffer • If virtual buffer overflows Drop(Mark) packets  < 1 => At Steady State total input rate is less than the network capacity => smaller steady state queue

  45. virtual AQM: Results Demand Estimation vAVQ We can decouple management of bottleneck queue from AQM design

  46. Demand Estimation vAVQ vAVQ virtual AQM: Results 8 Mbps 5 ms 20 ms 20 ms Drop Tail Queue 0.8 Mbps 0.8 Mbps

  47. Conclusions • Network based congestion avoidance and control solutions are not deployed • De-couple congestion control task from it’s placement • Deployable architectures • Can get many beneficial properties of network based solutions • Randomized TCP • End-System based solution • Can reduce synchronization, phase effects, bias against large RTT flows, burst losses • Emulate many beneficial properties of RED (AQM).

  48. Conclusions • Un-Cooperative Congestion Control • Edge Based Solution • De-couple management of selfish flows from AQM design • Edge-based transformation of price can handle misbehaving flows • No changes in the core • Works with packet drop or packet marking (ECN) • Independent of buffer management algorithm • virtual AQM • Edge-based proposal for managing bottleneck queues • For any path using packet probes find capacity and demand • Mark (drop) packets to match demand to path capacity • Results depend on estimation, length of virtual buffer • Initial Conceptual Prototype Presented

  49. References • Kartikeya Chandrayana, Sthanunathan Ramakrishnan, Biplab Sikdar and Shivkumar Kalyanaraman, “On Randomizing the Sending Times in TCP and other Window Based Algorithms”, Conditional Accept for Journal of Computer Networks • Kartikeya Chandrayana and Shivkumar Kalyanaraman, “Uncooperative Congestion Control”, ACM SIGMETRICS 2004, Also under submission to IEEE Transactions on Networking. • Kartikeya Chandrayana and Shivkumar Kalyanaraman, “On Impact of Non-Conformant Flows on a Network of DropTail Gateways”, IEEE GLOBECOM 2003 • K. Chandrayana, Y. Xia, B. Sikdar and S. Kalyanaraman, “A Unified Approach to Network Design and Control with Non-Cooperative Users”, RPI Networks Lab Tech Reoprt, ECSE-NET-2002-1, March 2002

  50. Randomized TCP: Synchronization 4x Mbps 5 ms x Mbps 20 ms Randomized TCP reduces/removes synchronization

More Related