Computer Networking Introduction Halgurd S. Maghdid Software Engineering Department Koya University-Koya, Kurdistan-Iraq Lecture No.11
Chapter 3 outline 3.1 transport-layer services 3.2 multiplexing and demultiplexing 3.3 connectionless transport: UDP 3.4 principles of reliable data transfer (Pipelined) 3.5 connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 principles of congestion control 3.7 TCP congestion control 2 of 32
congestion: informally: too many sources sending too much data too fast for network to handle Packet retransmission thus treats a symptom of network congestion different from flow control! manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers) a top-10 problem! 3 of 32 Principles of congestion
Congestion Collapse We really go to this situation, in which many retransmissions are clogged into network, the goodput or useful information will fell down. Thus the network no longer perform well. 4 of 32
Causes/costs of congestion: scenario 1 two senders, two receivers one router, infinite buffers output link capacity: R no retransmission For a sending rate between 0 and R/2, the throughput at the receiver equals the sender s sending rate everything sent by the sender is received at the receiver with a finite delay. R/2 Host B original data: l in Host A unlimited shared output link buffers throughput: l out l out delay 5 of 32 l in R/2 l in R/2 maximum per-connection (for host A) throughput: R/2 large delays as arrival rate, l in, approaches capacity
Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of timed-out packet application-layer input = application-layer output: l in = l out transport-layer input includes retransmissions : l in l' in Host A l in : original data l' in : original data, plus retransmitted data l out 6 of 32 Host B finite shared output link buffers
Causes/costs of congestion: scenario 2 idealization: perfect knowledge sender sends only when router buffers available First, consider the unrealistic case that Host A is able to somehow (magically!) determine whether or not a buffer is free in the router and thus sends a packet only when a buffer is free. No loss would occur and l in= l' in R/2 l out l in R/2 copy A l in : original data l' in : original data, plus retransmitted data free buffer space! l out 7 of 32 Host B finite shared output link buffers
Causes/costs of congestion: scenario 2 Idealization: known loss packets can be lost, dropped at router due to full buffers sender only resends if packet known to be lost copy A l in : original data l' in : original data, plus retransmitted data no buffer space! l out 8 of 32 Host B
Causes/costs of congestion: scenario 2 R/2 Idealization: known loss packets can be lost, dropped at router due to full buffers sender only resends if packet known to be lost R/3 l out l in R/2 A l in : original data l' in : original data, plus retransmitted data free buffer space! l out 9 of 32 Host B
Causes/costs of congestion: scenario 2 Realistic: duplicates packets can be lost, dropped at router due to full buffers sender times out prematurely, sending two copies, both of which are delivered R/2 R/4 l out l in R/2 copy timeout l in l' in l out A free buffer space! 10 of 32 Host B
Causes/costs of congestion: scenario 2 Realistic: duplicates packets can be lost, dropped at router due to full buffers sender times out prematurely, sending two copies, both of which are delivered R/2 R/4 l out l in R/2 costs of congestion: more work (retrans) for given goodput unneeded retransmissions: link carries multiple copies of pkt decreasing goodput 11 of 32
Causes/costs of congestion: scenario 3 four senders multihop paths timeout/retransmit Host A Q: what happens as l in and l in increase? A: as red l in increases, all arriving blue pkts at upper queue are dropped, blue throughput g 0 l in : original data l' in : original data, plus retransmitted data finite shared output link buffers l out Host B Host D Host C 12 of 32
Causes/costs of congestion: scenario 3 R/2 l out l in R/2 another cost of congestion: when packet dropped, any upstream transmission capacity used for that packet was wasted! 13 of 32
Approaches towards congestion control Two broad approaches towards congestion control: end-end congestion control: no explicit feedback from network congestion inferred from end-system observed loss, delay approach taken by TCP network-assisted congestion control: routers provide feedback to end systems single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) explicit rate for sender to send at Two ways: choke packet would be send by router to the sender. Or the router updates a field of a packet that sent to the reviewer then the receiver informs the sender. 14 of 32
Approaches towards congestion control 15 of 32 Network-assisted congestion control
Chapter 3 outline 3.1 transport-layer services 3.2 multiplexing and demultiplexing 3.3 connectionless transport: UDP 3.4 principles of reliable data transfer 3.5 connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 principles of congestion control 3.7 TCP congestion control 16 of 32
cwnd: TCP sender congestion window size TCP congestion control: additive increase multiplicative decrease Flow control: is between source and destination while congestion control is avoiding the overflow of router buffers. The window is measured in byte. approach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs. additive increase: increase cwnd by 1 MSS every RTT until loss detected multiplicative decrease: cut cwnd in half after loss additively increase window size. until loss occurs (then cut window in half) AIMD saw tooth behavior: probing for bandwidth 17 of 32 time
TCP congestion control: additive increase multiplicative decrease The TCP congestion-control mechanism operating at the sender keeps track of an additional variable, the congestion window. The congetion window (cwnd) is measured in segment size. The congestion window, denoted cwnd, imposes a constraint on the rate at which a TCP sender can send traffic. Thus, the sender s send rate is roughly cwnd/rtt bytes/sec. By adjusting the value of cwnd, the sender can therefore adjust the rate at which itsends data into its connection. How a TCP sender perceives that there is congestion on the path between itself and the destination? When overflow occurs in the buffers of a router, causing TCP datagram to be dropped and this imposes transmitted packet timeout. TCP uses clock to trigger the increase of congestion window 18 of 32
TCP Congestion Control: details sender sequence number space cwnd last byte ACKed sent, notyet ACKed ( in-flight ) last byte sent sender limits transmission: LastByteSent- LastByteAcked < cwnd cwnd is dynamic, function of perceived network congestion TCP sending rate: roughly: send cwnd bytes, wait RTT for ACKS, then send more bytes rate ~ cwnd RTT bytes/sec 19 of 32
How TCP Sender determines the transmission rate? How TCP sender determines its transmission rate such that they do not congest the network but the same time make use of available bandwidth. A lost segment implies congestion, and hence, the TCP sender s rate should be decreased when a segment is lost An acknowledged segment indicates that the network is delivering the sender s segments to the receiver, and hence, the sender s rate can be increased when an ACK arrives for a previously unacknowledged segment. Given ACKs indicating a congestion-free source-to-destination path and loss events indicating a congested path, TCP s strategy for adjusting its transmission rate is to increase its rate in response to arriving ACKs until a loss event occurs, at which point, the transmission rate is decreased. 20 of 32
TCP congestion-control algorithm Given this overview of TCP congestion control, we re now in a position to consider the details of the celebrated TCP congestion-control algorithm The first algorithm was described in [Jacobson 1988] and is standardized in [RFC 5681]. The algorithm has three major components: (1) slow start, (2) congestion avoidance, and (3) fast recovery. 21 of 32
TCP Slow Start TCP slow start is a condition that the sender does not trust the network to send all data segments. Two devices advertises its receive window by using packet header. TCP slow start occur at initial connection setup and when TCP retransmit timer expires. If the sender does not receive an ACK at certain amount of time, it will bound the transmitted segment. 22 of 32
TCP Slow Start Scenario If the receiver window size is 64 kbyte, the receiver can buffer 44 packets (with packet size of 1460 byte). It means that the sender can send 44 packets sequentially without any ACK. Slow start says not sending 44 packets, but only send 2 packets and when ACK received then start increase the window. This process will continue until the time this will equal the TCP receive window in the client side (as shown in the next slide). Unless the packet loss occurs, in which it will switch to Congestion Avoidance and cut half the amount of packets sent. 23 of 32
24 of 32 TCP Slow Start Scenario
RTT TCP Slow Start Scenario when connection begins, increase rate exponentially until first loss event: initially cwnd = 1 MSS double cwnd every RTT done by incrementing cwnd for every ACK received. summary: initial rate is slow but ramps up exponentially fast Host A Host B time 25 of 32
TCP: detecting, reacting to loss loss indicated by timeout: cwnd set to 1 MSS; window then grows exponentially (as in slow start) to threshold (ssthresh, which is usually equal to the cwnd/2), then grows linearly loss indicated by 3 duplicate ACKs: TCP RENO dup ACKs indicate network capable of delivering some segments cwnd is cut in half window then grows linearly TCP Tahoe always sets cwnd to 1 (timeout or 3 duplicate acks) 26 of 32
27 of 32 TCP Congestion Avoidance TCP congestion control is implemented at the sender. The sender has two parameters: Congestion window (cwnd) Slow start threshold value (ssthresh): the initial value of ssthresh is the window size. Congestion control is working in three modes: Slow start (cwnd<ssthresh) Congestion avoidance (cwnd>=ssthresh) Fast Recovery
28 of 32 Slow start : TCP Slow Start Initial value: cwnd=1 Each time the receiver sends an ACK, the sender increases the cwnd by 1: cwnd+1. The slow start increases exponentially. Cwnd Linearly increasing with acknowledged packets while doubled with time (RTT). TCP sender slows down the increase of cwnd, when cwnd>ssthresh
TCP: switching from slow start to CA The congestion avoidance is started when cwnd reaches the value of ssthresh The window is increased by 1 segment for each RTT. 29 of 32
TCP: switching from slow start to Q: when should the exponential increase switch to linear? A: when cwnd gets to 1/2 of its value before timeout. CA Congestion occur and the sender drops the window size Implementation: variable ssthresh on loss event, ssthresh is set to 1/2 of cwnd just before loss event 30 of 32
31 of 32 Fast Recovery
cwnd: TCP sender congestion window size Additive Increase Multiplicative Decrease (AIMD) Principle approach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs. additive increase: increase cwnd by 1 MSS every RTT until loss detected multiplicative decrease: cut cwnd in half after loss additively increase window size. until loss occurs (then cut window in half) AIMD saw tooth behavior: probing for bandwidth 32 of 32 time Transport Layer