1. Spring 2006CS 3321 Congestion Control and Resource Allocation Outline: Overview Queuing Disciplines TCP Congestion Control Combined Techniques

2. Spring 2006CS 3322 Congestion Control Overview

3. Spring 2006CS 3323 Congestion vs Allocation Congestion: Packets contend at router for use of link. When too many packets contend for given link, queues overflow, and packets are dropped. Drops become common => congestion. Good allocation schemes can help avoid congestion. But allocating with precision is difficult because resources are distributed.

4. Spring 2006CS 3324 Two Sides of Same Coin Precise allocation (in both space and time) can completely avoid congestion. –As mentioned, difficult Schedule nothing (I.e. allocate nothing) and deal with congestion when it occurs –Easier approach –Disruptive: many packets discarded before congestion controlled (and retransmits only add to problem) Middle ground: make inexact allocation decisions and add some congestion recovery mechanisms

5. Spring 2006CS 3325 Who handles congestion? Network (Routers)? –Queueing disciplines decide what gets dropped –Queueing can also segregate traffic (your packets cannot affect mine, etc) End Hosts? –Control speed at which packets are placed on network

6. Spring 2006CS 3326 Issues Resources to be allocated: –Link bandwidth –Buffer space in switches and routers Fairness: share pain among users Flow control is not congestion control –Flow control: keep fast sender from overrunning slow receiver –Congestion control: keep senders from sending too much data into network Congestion control is not routing! –Some routers cannot be routed around (bottleneck)

7. Spring 2006CS 3327 Our Model Packet switched network –Excludes virtual circuit networks (though can have connection-oriented service at transport layer) Service Model: Best effort Connectionless flows –Flow: sequence of packets with same source/dest pair following same route through network –Does not imply any end-to-end semantics (such as reliable and ordered delivery)

8. Spring 2006CS 3328 Spectrum of Paradigms “Pure” connectionless: –complete independence of datagrams –no state at routers “Pure” connection-oriented: –“hard” state at routers: must be explicitly created and removed by signaling Connectionless flows: (Internet) –Datagrams not completely independent –Soft state: state maintained for each flow that helps with resource allocation decisions. Correct operation of network NOT dependent on presence of soft state –Set up is implicit or explicit (why isn’t explicit same as virtual circuit in connection-oriented network?)

9. Spring 2006CS 3329 Taxonomy of Congestion Control Mechanisms Router-Centric vs Host Centric Reservation-Based vs Feedback-Based Window-Based vs Rate-based

10. Spring 2006CS 33210 Taxonomy (cont.) Router-Centric vs Host-Centric –Router-centric: router decides when packets forwarded, which are dropped, and informs hosts of how many packets they may send –Host-centric: Hosts observe network conditions (I.e. packet success rate) and adjust behavior accordingly Reservation-Based vs Feedback-Based –Reservation-based: End host asks for capacity, router allocates resources if possible (router-centric) –Feedback-based: Explicit feedback (typically router-centric) Implicit feedback (typically host-centric)

11. Spring 2006CS 33211 Taxonomy (cont.) Windows-based vs rate-based –Windows-based: we’ve seen it –Rate-based: how many bits per second receiver or network is able to absorb Still an open area of research Logical choice for reservation-based systems supporting differentiated qualities of service (QoS) Typically two combinations used: –Host-centric, feedback-based, window-based (Internet) –Router-centric, reservation-based, rate-based (QoS service models)

12. Spring 2006CS 33212 Evaluating Effectiveness Two principle networking metrics: throughput & delay Increasing throughput can cause increased delay (one scenario: allow all packets onto network => longer router queues => increased delay) Power = Throughput/Delay Typically only crude control so better be able to handle right end of curve!

13. Spring 2006CS 33213 Problems with Power Derived from queuing theory under assumption of infinite queues. Defined relative to single flow, so not clear how it extends to multiple competing flows. It’s got problems, but right now it’s the best we have, so it’s used

14. Spring 2006CS 33214 Evaluating Fairness Murky waters –Reservation-based schemes provide explicit way to create controlled unfairness. Is fair share same as equal share? –Should path length be considered (I.e. how does one four-hop flow compare with three one-hop flows?)

15. Spring 2006CS 33215 Fairness metric Proposed by Raj Jain, assumes that fairness implies equality and all paths of equal length Given flow throughputs (in bits/sec say) Assign fairness Note: –n flows each receiving 1 bps => fairness 1 –k of n receive equal, others receive none => k/n

16. Spring 2006CS 33216 Queuing Disciplines

17. Spring 2006CS 33217 Queuing Disciplines These effectively allocate: –Bandwidth: which packets gets transmitted –Buffer space: which packets get discarded Affects latency Two components: –Scheduling discipline: order packets transmitted –Drop policy: which packets get dropped Two examples: –FIFO (also called first-come-first-served(FCFS)) –“Fair queuing”

18. Spring 2006CS 33218 FIFO Scheduling discipline: pretty obvious Drop policy: tail drop

19. Spring 2006CS 33219 FIFO (cont) Simplest of all queuing algorithms Most widely used in Internet Places all responsibility for congestion control and resource allocation at edges of network (routers don’t have any responsibility for detecting badness) A related mechanism: priority queuing –One queue for each priority level –Transmit packets of higher priority queues if nonempty –Who sets priority? What about “pushback”?

20. Spring 2006CS 33220 FIFO problems Doesn’t separate packets according to flow to which they belong –Can any congestion-control implemented entirely at source work? (Remember, no help from routers!) –No means to police how well sources adhere to policies (what if they’re not using TCP as transport protocol?) Ill-behaved app can grab arbitrarily large fraction of network capacity Some apps do this now: Internet telephony

21. Spring 2006CS 33221 Fair Queuing (FQ) Maintain separate queue for each flow, service these queues in round-robin manner Prevents any single flow from grabbing too much capacity, since it only floods its own queue Routers need not tell hosts anything about router state or limit the amount they send (I.e. designed to be used in conjunction with end-to-end mechanism, but limits damage from ill-behaved sources)

22. Spring 2006CS 33222 Fair Queuing

23. Spring 2006CS 33223 FQ Details Packets being processed at router not same length –So can’t just use simple round robin servicing of packets –Want bit-by-bit round robin. FQ handles this by determining when packet would finish being transmitted if done in bit-by-bit fashion, then sequences packets using finishing time. Assume clock ticks once per bit sent. S i =start transmit time of packet i F i =finish time of packet i P i =length of packet i A i =time packet i arrives at router F i =max(F i-1,A i ) + P i

24. Spring 2006CS 33224 More FQ Details Handle multiple flows –Clock must tick one tick when n bits transmitted if n active flows –Calculate, for each flow, F i using above formulae and transmit packet with lowest timestamp –No preemption (so not quite totally fair)

25. Spring 2006CS 33225 Shorter packets sent first Sending of longer packet, already in progress, is completed first.

26. Spring 2006CS 33226 Still More FQ FQ is work conserving: link never left idle as long as there is a packet queued –So sharing link with flows that are not sending data means that I can get larger share of bandwidth n flows means I get 1/n of bandwidth. If I try to use more than that, packets get larger TS, sit in queue longer (which ones dropped is not concern of FQ since it’s only a scheduling policy) Weighted Fair Queuing (WFC): assign different weights to flows (see QoS stuff)

27. Spring 2006CS 33227 TCP Congestion Control Thanks to thinkgeek.com. Check it out…

28. Spring 2006CS 33228 TCP Congestion Control End-to-end congestion control Assumes FIFO queuing, but works with FQ also Broadly: –Each source determines how much capacity in network –When source has placed this many packets in network, ACKS signal that packets have left network, so safe to transmit (TCP is self-clocking) How do we determine network capacity (which changes over time)?!

29. Spring 2006CS 33229 TCP Congestion Control Additive increase/multiplicative decrease State variables: CongestionWindow (measured in bytes, but think in terms of packets) MaxWindow=MIN(CongestionWindow, AdvertisedWindow) EffectiveWindow=MaxWindow–(LastByteSent–LastByteAcked) Who sets CongestionWindow ? –TCP sets it based on level of congestion it perceives –Decrease if congestion increases and vice-versa

30. Spring 2006CS 33230 Setting CongestionWindow Observation: when packets not delivered, cause is congestion (except in rare instances) With any timeout, CongestionWindow is cut in half (multiplicative decrease) –In practice, not allowed to fall below maximum segment size (MSS) Each time source successfully sends CongestionWindow worth of packets (each packet in last RTT is ACKed) it adds equivalent of 1 packet to CongestionWindow (additive increase)

31. Spring 2006CS 33231

32. Spring 2006CS 33232 Practical Detail TCP doesn’t wait for entire RTT worth of packets to increase CongestionWindow instead increments it a little for each arriving ACK Increment = MSS × (MSS/CongestionWindow) CongestionWindow += Increment

33. Spring 2006CS 33233 TCP Congestion Control Note: source reduces congestion window much faster than it increases it –A (proven) necessary condition for stability Consequences of too large window much worse than too small window—packets dropped, adding to congestion, so important to leave this state quickly Note need for accurate timeout mechanism (because timeouts trigger congestion control)

34. Spring 2006CS 33234 “Slow Start” Additive increase too slow during initial ramp up Slow start (which is actually fast) increases window size exponentially fast Algorithm: –Set CongestionWindow to 1 packet –When this is ACKed, increase by 1 packet –When these ACKed, increase by 2 packets –Continue until there is a loss, causing decrease Why the name? Compared to original TCP which sent whole window size Also used after timeout due to having sent as much data as window allows

35. Spring 2006CS 33235 Slow Start When used after initialization, uses CongestionThreshold (which is half of last value of CongestionWindow )

36. Spring 2006CS 33236 “Packet-pair” Slow start has potential to cause lots of dropped packets (what if window is 16K?) Packet-pair: Send groups of packets and see how many make it through –Specifically, send pair of packets with no spacing between them and measure difference in return time of Acks –Promising, but too new to know how effective it may be

37. Spring 2006CS 33237 Fast Retransmit Coarse grained implementation of TCP timers led to lots of wasted bandwidth Fast retransmit: enhances normal timeouts by sometimes triggering faster retransmit –Third duplicate ACK (ACK with same sequence number) causes retransmit Eliminates half of course-grained Timeouts, improves throughput by 20%