Congestion Control Foreleser Carsten Griwodz Email griffifi uio

Congestion Control Foreleser: Carsten Griwodz Email: griff@ifi. uio. no 01. Apr. 2004 1 INF-3190: Congestion Control

Congestion Opposite objectives n End-system n n n Opposite objectives n Network Optimize its own throughput Possibly at the expense of other end-systems n Transmission rate adjustment Two different problems n n Receiver capacity Network capacity Cannot be distinguished easily at all places Should be differentiated Optimize overall throughput Internal congestion Network Small receiver capacity Large receiver capacity Packet loss 01. Apr. 2004 2 INF-3190: Congestion Control

Congestion n General problem Congestion Higher delays retransmissions n => more delays at end-systems => retransmissions (because of timeouts) => additional load increases 2 problem areas n n n Receiver capacity Network capacity Avoid both bottlenecks n 01. Apr. 2004 (“actual window”) (“congestion window”) valid send window = min(actual window, congestion window) 3 INF-3190: Congestion Control

Congestion When too much traffic is offered n n n Congestion sets in Performance degrades sharply Reasons for congestion, among others n n n packets delivered n maximum transmission capacity of the subnet IS too slow for routing algorithms Incoming traffic overloads outgoing lines perfect desirable congested packets sent Congestions tend to amplify themselves n n IS drops packet due to congestion Packet has to be retransmitted n n Additional bandwidth used Sender cannot release the buffer n 01. Apr. 2004 Thereby additionally tying up resources 4 INF-3190: Congestion Control

Congestion Control n General methods of resolution n Increase capacity Decrease traffic Strategies n Repair n n n When congestion is noticed “Closed loop” Explicit feedback (packets are sent from the point of congestion) Implicit feedback (source assumes that congestion occurred due to other effects) Drop packets, choke packets, hop-by-hop choke packets, fair queuing, . . . Avoid n n n 01. Apr. 2004 Before congestion happens “Open loop” Initiate countermeasures at the sender Initiate countermeasures at the receiver Traffic shaping, leaky bucket, token bucket, reservation (multicast), isarithmic congestion control 5 INF-3190: Congestion Control

Repair n Principle n n No resource reservation Necessary steps n n 01. Apr. 2004 Congestion detected Introduce appropriate procedures for reduction 6 INF-3190: Congestion Control

Repair by Packet dropping n Principle n n n At each intermediate system Queue length are tested Incoming packet is dropped if it cannot be buffered n n We may not wait until the queue is entirely full Preconditions for n Connectionless service n n No preparations necessary Connection-oriented service n 01. Apr. 2004 Packet will be buffered until receipt has been acknowledged 7 INF-3190: Congestion Control

Repair by Packet dropping Output lines Input lines n Avail buffers Assigning buffers to queues at output lines 1. Maximum number of buffers per output line n Packet may be dropped although there are free lines 2. Minimal number of buffers per output line n 01. Apr. 2004 Line cannot be starved 8 INF-3190: Congestion Control

Repair by Packet dropping 3. Content-related dropping: relevance n n Relevance of data connection as a whole (or all single data packets from one end system to another end system) Relevance of single packets n 01. Apr. 2004 Examples n WWW document images vs. text and structural information n File transfer old packets more important than new ones (algorithm to initiate correction process should start as late as possible) 9 INF-3190: Congestion Control

Repair by Packet dropping n Properties n n Very simple But n n Retransmitted packets waste bandwidth Packet has to be sent 1 / (1 - p) times before it is accepted n n (p. . . probability that packet will be dropped) Optimization necessary to reduce the waste of bandwidth n Dropping packets that have not gotten that far yet 01. Apr. 2004 10 INF-3190: Congestion Control

Repair by Choke Packets n Principle n n Reduce traffic during congestion by telling source to slow down Procedure for IS n Each outgoing line (OL) has one variable n n Calculating u ( 0 ≤ u ≤ 1 ) (u: Utilization) n n Utilization u IS checks the line usage f periodically (f is 0 or 1) u=a*u+(1 -a)*f 0 ≤ a ≤ 1 determines to what extent "history" is taken into account u > threshold: OL changes to condition "warning“ n n 01. Apr. 2004 Send choke packet to source (indicating destination) Tag packet (to avoid further choke packets from down stream IS) & forward it 11 INF-3190: Congestion Control

Repair by Choke Packets n Principle n n Reduce traffic during congestion by telling source to slow down Procedure for source n Source receives the choke packet n n Reduces the data traffic to the destination in question by x 1% Source recognizes 2 phases (gate time so that the algorithm can take effect) n n 01. Apr. 2004 Ignore: ES ignores further Choke packets Listen: ES listens if more Choke packets are arriving n yes: n no: further reduction by X 2%; go to Ignore phase increase the data traffic 12 INF-3190: Congestion Control

Repair by Choke Packets n Enhancements n Varying choke packets depending on state of congestion n For u instead of utilization n Warning Acute warning Queue length. . Properties n n Effective procedure But n Possibly many choke packets in the network n n n End systems can (but do not have to) adjust the traffic Choke packets take time to reach source n 01. Apr. 2004 Even if Choke bits may be included in the data at the senders to minimize reflux Transient (short-term) congestion may have passed when the source reacts 13 INF-3190: Congestion Control

Repair by Choke Packets Hop-by-Hop Choke Packets Principle n n n Reaction to Choke packets already at IS (not only at ES) Plain Choke packets B C A n n B D E n Hop-by-hop Choke packets A F D E A heavy flow is established Congestion is noticed at D A Choke packet is sent to A The flow is reduced at D 01. Apr. 2004 C n n n 14 F A heavy flow is established Congestion is noticed at D A Choke packet is sent to A The flow is reduced at F The flow is reduced at D INF-3190: Congestion Control

Repair with Fair Queuing n Background n n Principle n n n On each outgoing line each end-system receives its own queue Packet sending based on Round-Robin (always one packet of each queue (sender)) Enhancement "Fair Queuing with Byte-by-Byte Round Robin“ n n n End-system adapting to traffic (e. g. by Choke-Packet algorithm) should not be disadvantaged Adapt Round-Robin to packet length But weighting is not taken into account Enhancement "Weighted Fair Queuing“ n n Favoring (statistically) certain traffic Criteria variants n n n 01. Apr. 2004 In relation to VPs (virtual paths) Service specific (individual quality of service) etc. 15 INF-3190: Congestion Control