Congestion Control Reasons: - too many packets in the network and not enough buffer space S = rate at which packets are generated R = rate at which receivers take packets S – R == access packet rate

Some nodes are slow - links used by too many sources - example: two high speed links feeding into a low speed link

Flow control vs congestion control Flow control may be required even if congestion is not present and vice versa

Classification Router-centric and host-centric Router-centric - controlled by the routers (inside the network) - each router decides which packets to forward and which to drop to ensure the service model

Host centric: - control is done at the end points - source adjusts the rate and the receiver provides feedback

Reservation-based vs feedback based * each source requests resources (bandwidth, buffers) when flow is established. * flow is rejected if not enough resources are available

Feedback based: - no resources are reserved - discard packets if buffers are full -explicit or implicit feedback to adjust the sending rate

Window-based vs Rate based Both mechanism control the speed of the sender;

Although any combination of the above strategies are possible, only two are popular best effort model: feedback, host-centric and window based QoS model: reservation based, router centric and rate based

Evaluation of congestion control Throughput Delay must also be taken into account: - all links are totally packed; high-throughput but long delays Throughput/delay * fairness

Queuing Disciplines Each router must maintain queues for packets to be transmitted Packet forwarding rule Packet dropping rule

FIFO disciplines One queue at each router The first packet to arrive is the first to be transmitted If the queue is full, discard the packet Most IP routers are FIFO

Priority queues One queue for each priority level Transmit from highest priority queue first Packet dropping policy: drop low priority packets

Fair queuing FIFO does not distinguish packets of different flows Problem: all responsibility is pushed to sources (no network control) Some sources could flood the network

Fair queuing Separate queue for each flow Router serves the queues in round-robin fashion When a queue is full, its packets are discarded according to some discipline In this scheme, a source cannot hog the network Enforces fairness but no priority

Simple fair queuing is not entirely fair as packets may be of different lengths Solution: bit-by-bit round robin

Fair queuing Use clocks for each flow Assume clock ticks for each bit transmitted Pi = length of packet numbered i Si = time at which packet i transmission is started Fi = finish time for packet i Ai = arrival time for packet i Fi = Si + Pi Si = max(Fi-1, Ai), Fi = max(Fi-1, Ai) + Pi

All flows: treat Fi as timestamps Transmit the packet with the lowest timestamp

Variation: weighted fair queuing Weight is assigned to each flow Weight specifies how many bits to transmit each time the router services that queue Source must communicate the weight information: QoS

Feedback based control If congestion is detected then send a control packet to source Problem: too many control packets Congestion bit in message: - this bit is sent to 1 if congestion is detected and a choke packet is sent - subsequent routers do not send choke packet if congestion bit is already set.

Implicit feedback Randomly drop packets Increased timeout

TCP congestion control Each source determines how much capacity is available for a given flow in the networks. Acks are used to reach an operating point: self-clocking

Additive increase/multiplicative decrease Window = min(Congestion Window, advertised window) Linear increase Multiplicative decrease

Slow start Linear additive increase takes too long

Fast retransmit Timeouts may not be accurate; results in slow response Duplicate acks Fast recovery: reduce congestion window