Congestion Management and Service Differentiation Aditya Akella Carnegie

Congestion Management and Service Differentiation Aditya Akella Carnegie Mellon University Joint work with Mukesh Agrawal, David Friedman, David Nagle and Srinivasan Seshan

Motivation n End-systems implement many functions n Reliability n In-order delivery n Demultiplexing n Message boundaries n Connection abstraction n Congestion control Of these, congestion control MUST be done for all communications 2

Congestion Control 101 n Congestion control - mechanism to track available bandwidth n Two phases Seek available bandwidth n Back-off upon over-estimation n n TCP uses AIMD n AI ( ) = Additive increase: determines aggressiveness in seeking n MD ( ) = Multiplicative Decrease: determines extent of back-off 3

Why is Congestion Control Important? n Key to using the network efficiently n Aim of tracking – Minimize losses along the way n Lost packets – Waste resources upstream 4

Outline n The Congestion Manager (CM) n CM Architecture n Evaluation of CM n Interactions with Qo. S and Multi-Path Routing n False-Sharing n Application-Customizable Traffic Management 5

Problems with Current Solution Yesterday’s Applications HTTP Telephony Internet Streaming Interactive Games n When everything used TCP, it was sufficient n Today’s traffic has moved beyond this n Not everything wants TCP n Also, multiple TCP streams are less social 6

The Big Picture HTTP Per-macroflow statistics (cwnd, rtt, etc. ) Congestion Manager Audio Video 1 TCP Video 2 UDP API IP n All congestion management tasks performed in CM n Applications learn and adapt using API n Transmissions are orchestrated by CM n All flows to the same destination – Macroflow n Granularity of sharing 7

The CM Architecture Feedback Sender App Receiver App Data API Callbacks Kernel API Congestion Controller Flow integration Scheduler = Congestion Manager Per-flow Scheduling n Congestion Controller: responsible for deciding when to send a packet n Scheduler: responsible for deciding who should send a packet n Unmodified receiver network stack 8

A Simple API n Apps use CM API to Inform CM about network state n Request and schedule transmissions n API overview n open/close new connections n request permission to send n notify of transmission n update with successes and losses n n Plus callbacks n n send a packet rate has changed 9

Transmission API n Traditional kernel buffered-send has problems n Does not allow app to “pull back” data n E. g. , transcoding App Rate change cm_send( , dst) Can’t pull out and re-encode CM IP Packets queued to dst Lesson: move buffering into the application 10

Transmission API n Request/callback-based send App cm_request( ) send( ) cmapp_send( ) CM IP Schedule requests, not packets Enables apps to adapt “at the last instant” 11

Transmission API (cont. ) n Request API: asynchronous sources wait for (some_events) { get_data( ); send( ); } n Synchronous sources do_every_t_ms { get_data( ); send( ); } n Solution: cmapp_update(rate, srtt) callback 12

Outline n The Congestion Manager (CM) n CM Architecture n Evaluation of CM n Interactions with Qo. S and Multi-Path Routing n False-Sharing n Application-Customizable Traffic Management 13

Benefits of Sharing CM-Enabled Internet Utah MIT 60 ms RTT High Bandwidth Stock Linux n Web-like n Issue a request every 500 ms regardless of completion of earlier request n Measure completion times 14

Integrating Congestion Control Helps n Throughput can benefit from sharing n Web-like workload n Internet path MIT Utah n 500 ms request spacing n 128 k file n Applications benefit locally from the CM 15

Outline n The Congestion Manager (CM) n CM Architecture n Evaluation of CM n Interaction with Qo. S and Multi-Path Routing n False-Sharing n Application-Customizable Traffic Management 16

What is False Sharing? n False sharing occurs when: n n Flows 1 and 2 treated differently by the network e. g. Diff. Serv Flows 1 and 2 take different paths e. g. , dispersity routing, NATs n Evaluate the impact, detection and response n n n Src Flow 1 Dst Flow 2 Is congestion control compromised & does the performance of individual flows suffer? When and how can false sharing be detected? How should end systems be modified to deal with false sharing? 17

Impact of False Sharing n Simulation set-up 20% of flows belong to Assured Forwarding class and 80 % are Best Effort n Bandwidth of CM flow is determined by slowest of flows n No danger of overloading links n Performance may suffer n 18

Detecting False Sharing: Motivation Unshared: Delay Correlation Plot Unshared: Loss Correlation Plot Delay in Seconds All losses on flow 2 Losses on both flows – back 2 back losses show as a “pile” All losses on flow 1 Time in Seconds n Uncorrelated delays and losses across flows is a strong indicator of false sharing n Tests compare auto-correlation with cross-correlation 19

End System Response: Motivation Flows Share a Bottleneck Flows Share no Bottlenecks Cross Correlation Auto Correlation measure Cross Correlation Time in seconds n When the 90% confidence intervals for the auto and cross correlation metrics no longer overlap, test outputs a decision of share or no share n It is harder to detect shared bottlenecks (90 secs) than to detect no shared bottlenecks (35 secs) 20

End System Response: Design Issues n Default behavior: start with congestion sharing and detect problems n Won’t overload the network n Delay and loss correlation tests detect false sharing more easily than they detect shared bottlenecks n Scheduling – detection tests work best when packets are nicely interleaved n Possible only when flows belong to the same macroflow n Upon detection – segregate flows n n Congestion Manager – associate flows with different macroflows Addition to API to support control of sharing 21

Outline n The Congestion Manager (CM) n CM Architecture n Evaluation of CM n Interactions with Qo. S and Multi-Path Routing n False-Sharing n Application-Customizable Traffic Management 22

Motivation n Storage is increasingly moving into Internet n Interaction with Internet protocols (Congestion Control) SCSI over IP (i. SCSI) n Utilization concerns n Increase sender aggressiveness n n Bandwidth allocation for storage apps n Prioritize by task (backup vs data mining) n Prioritize by user 23

Best-Effort vs Service Differentiation n TCP’s congestion control + IP’s best-effort service model n Provides fair (equal) sharing of bandwidth n What about bandwidth allocation that is not necessarily equal? n Existing methods Integrated Services & Differentiated Services n Depend on network support n Problems n n n Scalability (Int. Serv) No guaranteed service with high aggregation (Diff. Serv) 24

Simple Solution n Ask end-systems to do bandwidth allocation n Scalable n Fine-grained control on perceived performance n But, n How can the sending rate be controlled? n What about security? 25

Answers n Sending rate n Congestion control to limit sending rate n Security n Use i. NICs to detect and prevent misbehavior n In a controlled environment n Enforce social behavior 26

Congestion Control Revisited n Bandwidth Equation n Observations 27

Controlling Sending Rate n Can leverage off of congestion control n Connection aggressiveness determines bandwidth share n Aggressiveness can be tuned via congestion control parameters 28

Basic Operation n End-users with higher Qo. S requirement get higher weight n Higher weight n Assuming some mechanism to assign weights n But, End-users mostly act as sinks n Need the source system to employ appropriate per -flow parameters n 29

Solution: Token Exchange n End-systems `buy’ tokens n Tokens == Money n Send tokens over to the source == Buy Service n # tokens sent quality of service provided n How are tokens generated? Distributed? 30

Mechanism Issues n What if everyone is rich? n High loss n Nobody gains n Overall performance suffers n Options n Limit token availability n Control mapping of tokens to aggressiveness 31

Challenges n Coping with many aggressive users n API Design n Usable by apps n Achievable by network n Leveraged off of the CM n Handle network dynamics n Arrival patterns, flow lifetimes n Adaptation speed 32

Posters n “Application Customizable Traffic Management” n Mukesh Agrawal, David Friedman, David Nagle and Srinivasan Seshan n “The Impact of False Sharing on Shared Congestion Management” n Aditya Akella, Hari Balakrishnan and Srinivasan Seshan n URL n http: //nms. lcs. mit. edu/projects/CM 33