Congestion Control and Resource Allocation

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

2. Congestion Control Overview CS 332

3. 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. CS 332

4. 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 CS 332

5. 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 CS 332

6. 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) CS 332

7. 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) CS 332

8. 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?) CS 332

9. Taxonomy of Congestion Control Mechanisms • Router-Centric vs Host Centric • Reservation-Based vs Feedback-Based • Window-Based vs Rate-based CS 332

10. 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) CS 332

11. 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) CS 332

12. 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! CS 332

13. 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 CS 332

14. 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?) CS 332

15. 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 CS 332

16. Queuing Disciplines CS 332

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

18. FIFO • Scheduling discipline: pretty obvious • Drop policy: tail drop CS 332

19. 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”? CS 332

20. 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 CS 332

21. 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) CS 332

22. Fair Queuing CS 332

23. 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. Si=start transmit time of packet i Fi=finish time of packet i Pi=length of packet i Ai=time packet i arrives at router Fi=max(Fi-1,Ai) + Pi CS 332

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

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

26. 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) CS 332

27. Thanks to thinkgeek.com. Check it out… TCP Congestion Control CS 332

28. 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)?! CS 332

29. 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 CS 332

30. 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) CS 332

31. CS 332

32. 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 CS 332

33. 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) CS 332

34. “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 CS 332

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

36. “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 CS 332

37. 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% CS 332