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

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

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

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

5. 01. Apr. 2004 5INF-3190: Congestion Control Congestion Control General methods of resolution Increase capacity Decrease traffic Strategies Repair 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 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

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

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

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

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

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

11. 01. Apr. 2004 11INF-3190: Congestion Control Repair by Choke Packets Principle Reduce traffic during congestion by telling source to slow down Procedure for IS Each outgoing line (OL) has one variable Utilization u Calculating u ( 0 ≤ u ≤ 1 ) (u: Utilization) 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“ Send choke packet to source (indicating destination) Tag packet (to avoid further choke packets from down stream IS) & forward it

12. 01. Apr. 2004 12INF-3190: Congestion Control Repair by Choke Packets Principle Reduce traffic during congestion by telling source to slow down Procedure for source Source receives the choke packet 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) Ignore: ES ignores further Choke packets Listen: ES listens if more Choke packets are arriving yes:further reduction by X 2 %; go to Ignore phase no:increase the data traffic

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

14. 01. Apr. 2004 14INF-3190: Congestion Control Repair by Choke Packets Hop-by-Hop Choke Packets Principle Reaction to Choke packets already at IS (not only at ES) Plain Choke packets A heavy flow is established Congestion is noticed at D A Choke packet is sent to A The flow is reduced at A The flow is reduced at D A BC D EF Hop-by-hop Choke packets 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 A BC D EF

15. 01. Apr. 2004 15INF-3190: Congestion Control Repair with Fair Queuing Background End-system adapting to traffic (e.g. by Choke-Packet algorithm) should not be disadvantaged Principle 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“ Adapt Round-Robin to packet length But weighting is not taken into account Enhancement "Weighted Fair Queuing“ Favoring (statistically) certain traffic Criteria variants In relation to VPs (virtual paths) Service specific (individual quality of service) etc.