Post on 13-Dec-2015
Spring 2006 CS 332 1
Congestion Control and Resource Allocation
Outline:OverviewQueuing DisciplinesTCP Congestion ControlCombined Techniques
Spring 2006 CS 332 2
Congestion Control Overview
Spring 2006 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.
Spring 2006 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
Spring 2006 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
Spring 2006 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)
Spring 2006 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)
Spring 2006 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?)
Spring 2006 CS 332 9
Taxonomy of Congestion Control Mechanisms
• Router-Centric vs Host Centric• Reservation-Based vs Feedback-Based• Window-Based vs Rate-based
Spring 2006 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)
Spring 2006 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)
Spring 2006 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/DelayTypically only crude control
so better be able to handle right
end of curve!
Spring 2006 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
Spring 2006 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?)
Spring 2006 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
( )nxxx ,,, 21 K
( )∑∑
=
== n
i i
n
i in
xn
xxxxf
1
2
2
121 ),,,( K
Spring 2006 CS 332 16
Queuing Disciplines
Spring 2006 CS 332 17
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”
Spring 2006 CS 332 18
FIFO• Scheduling discipline: pretty obvious• Drop policy: tail drop
Spring 2006 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”?
Spring 2006 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
Spring 2006 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)
Spring 2006 CS 332 22
Fair Queuing
Spring 2006 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
Spring 2006 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)
Spring 2006 CS 332 25
Shorter packets sent first
Sending of longer packet, alreadyin progress, is completed first.
Spring 2006 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)
Spring 2006 CS 332 27
TCP Congestion Control
Thanks to thinkgeek.com. Check it out…
Spring 2006 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)?!
Spring 2006 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
Spring 2006 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)
Spring 2006 CS 332 31
Spring 2006 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
Spring 2006 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)
Spring 2006 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
Spring 2006 CS 332 35
Slow Start
• When used after initialization, uses CongestionThreshold (which is half of last value of CongestionWindow)
Spring 2006 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
Spring 2006 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%