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

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%