TCP/IP flow control

TCP Flow Control and Congestion Control and flow control in tcp/ip is handled using
Dr.GriffinWood Profile Pic
Dr.GriffinWood,United Kingdom,Teacher
Published Date:23-07-2017
Your Website URL(Optional)
TCP Flow Control and Congestion Control EECS 489 Computer Networks Z. Morley Mao Monday Feb 5, 2007 1 Mao W07 Acknowledgement: Some slides taken from Kurose&Ross and Katz&Stoicaƒ ƒ TCP Flow Control flow control sender won’t overflow receive side of TCP receiver’s buffer by connection has a receive transmitting too much, buffer: too fast speed-matching service: matching the send rate to the receiving app’s drain rate app process may be slow at reading from buffer 2 Mao W07ƒƒ ƒ TCP Flow control: how it works Rcvr advertises spare room by including value of RcvWindow in segments Sender limits unACKed data to RcvWindow - guarantees receive buffer doesn’t overflow (Suppose TCP receiver discards out-of-order segments) spare room in buffer = RcvWindow = RcvBuffer-LastByteRcvd - LastByteRead 3 Mao W07ƒƒƒ TCP Connection Management Three way handshake: Recall: TCP sender, receiver establish “connection” before Step 1: client host sends TCP exchanging data segments SYN segment to server initialize TCP variables: - specifies initial seq - seq. s - no data - buffers, flow control info (e.g. RcvWindow) Step 2: server host receives SYN, replies with SYNACK segment client: connection initiator Socket clientSocket = new - server allocates buffers Socket("hostname","port - specifies server initial seq. number"); Step 3: client receives SYNACK, server: contacted by client replies with ACK segment, Socket connectionSocket = which may contain data welcomeSocket.accept(); 4 Mao W07FIN ACK TCP Connection Management (cont.) client server Closing a connection: close client closes socket: clientSocket.close(); Step 1: client end system sends TCP FIN control close segment to server Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN. closed 5 Mao W07 ACK FIN timed waitFIN ACK TCP Connection Management (cont.) client server Step 3: client receives FIN, replies with ACK. closing - Enters “timed wait” - will respond with ACK to received FINs Step 4: server, receives ACK. closing Connection closed. Note: with small modification, can handle simultaneous FINs. closed closed 6 Mao W07 ACK FIN timed waitTCP Connection Management (cont) TCP server lifecycle TCP client lifecycle 7 Mao W07ƒƒƒƒ Principles of Congestion Control Congestion: informally: “too many sources sending too much data too fast for network to handle” different from flow control manifestations: - lost packets (buffer overflow at routers) - long delays (queueing in router buffers) a top-10 problem 8 Mao W07ƒƒ ƒƒƒ Causes/costs of congestion: scenario 1 Host A λ out λ : original data in two senders, two receivers one router, infinite unlimited shared Host B output link buffers buffers no retransmission large delays when congested maximum achievable throughput 9 Mao W07ƒƒ Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of lost packet Host A λ out λ : original data in λ' : original data, plus in retransmitted data Host B finite shared output link buffers 10 Mao W07ƒƒƒ Causes/costs of congestion: scenario 2 = λ λ always: (goodput) out in “perfect” retransmission only when loss: λ λ out in retransmission of delayed (not lost) packet makes larger (than λ in perfect case) for same λ out R/2 R/2 R/2 R/3 R/4 R/2 R/2 R/2 λλλ in in in a. b. c. “costs” of congestion: more work (retrans) for given “goodput” unneeded retransmissions: link carries multiple copies of pkt 11 Mao W07 λ out λ out λ outƒƒƒ Causes/costs of congestion: scenario 3 four senders Q: what happens as λ multihop paths in and increase ? λ timeout/retransmit in Host A λ out λ : original data in λ' : original data, plus in retransmitted data finite shared output link buffers Host B 12 Mao W07Causes/costs of congestion: scenario 3 H λ o o s u t t A H o s t B Another “cost” of congestion: when packet dropped, any “upstream transmission capacity used for that packet was wasted 13 Mao W07ƒ ƒƒƒ Approaches towards congestion control Two broad approaches towards congestion control: Network-assisted congestion End-end congestion control: control: no explicit feedback from network routers provide feedback to end systems congestion inferred from end- system observed loss, delay - single bit indicating congestion (SNA, DECbit, approach taken by TCP TCP/IP ECN, ATM) - explicit rate sender should send at 14 Mao W07ƒƒƒ ƒƒƒ Case study: ATM ABR congestion control RM (resource management) ABR: available bit rate: cells: “elastic service” if sender’s path sent by sender, interspersed with “underloaded”: data cells - sender should use bits in RM cell set by switches available bandwidth (“network-assisted”) if sender’s path congested: - NI bit: no increase in rate - sender throttled to (mild congestion) minimum guaranteed - CI bit: congestion indication rate RM cells returned to sender by receiver, with bits intact 15 Mao W07ƒƒ Case study: ATM ABR congestion control two-byte ER (explicit rate) field in RM cell - congested switch may lower ER value in cell - sender’ send rate thus minimum supportable rate on path EFCI bit in data cells: set to 1 in congested switch - if data cell preceding RM cell has EFCI set, sender sets CI bit in returned RM cell 16 Mao W07ƒƒ ƒƒƒƒ TCP Congestion Control How does sender perceive end-end control (no network assistance) congestion? sender limits transmission: loss event = timeout or 3 LastByteSent-LastByteAcked duplicate acks ≤ CongWin TCP sender reduces rate Roughly, (CongWin) after loss event three mechanisms: -AIMD CongWin is dynamic, function of - slow start perceived network congestion - conservative after timeout events CongWin rate = Bytes/sec RTT 17 Mao W07TCP AIMD multiplicative decrease: additive increase: increase cut CongWin in half CongWin by 1 MSS every after loss event RTT in the absence of loss events: probing congestion window 24 Kbytes 16 Kbytes 8 Kbytes time Long-lived TCP connection 18 Mao W07ƒƒ TCP Slow Start When connection begins, When connection begins, CongWin = 1 MSS increase rate exponentially fast - Example: MSS = 500 bytes & until first loss event RTT = 200 msec - initial rate = 20 kbps available bandwidth may be MSS/RTT - desirable to quickly ramp up to respectable rate 19 Mao W07ƒƒ one segment two segments four segments TCP Slow Start (more) When connection begins, Host A Host B increase rate exponentially until first loss event: - double CongWin every RTT - done by incrementing CongWin for every ACK received Summary: initial rate is slow but ramps up exponentially fast time 20 Mao W07 RTT