Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 TCP (Part II) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute

Slides:



Advertisements
Similar presentations
1 TCP Congestion Control. 2 TCP Segment Structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement.
Advertisements

Congestion Control Created by M Bateman, A Ruddle & C Allison As part of the TCP View project.
1 TCP - Part II. 2 What is Flow/Congestion/Error Control ? Flow Control: Algorithms to prevent that the sender overruns the receiver with information.
School of Information Technologies TCP Congestion Control NETS3303/3603 Week 9.
Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 ECSE-4690: Experimental Networking Informal Quiz: TCP Shiv Kalyanaraman:
Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 ECSE-6600: Internet Protocols Informal Quiz #07 Shivkumar Kalyanaraman: GOOGLE: “Shiv RPI”
Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 TCP (Part II) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute
Congestion Control Tanenbaum 5.3, /12/2015Congestion Control (A Loss Based Technique: TCP)2 What? Why? Congestion occurs when –there is no reservation.
Congestion Dr. Abdulaziz Almulhem. Almulhem©20012 Congestion It occurs when network resources are becoming scarce High demand Over utilized Offered load.
Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 TCP Congestion Control: AIMD and Binomial Shivkumar Kalyanaraman Rensselaer Polytechnic Institute.
CSCE 515: Computer Network Programming Chin-Tser Huang University of South Carolina.
1 Spring Semester 2007, Dept. of Computer Science, Technion Internet Networking recitation #7 TCP New Reno Vs. Reno.
CSCE 515: Computer Network Programming Chin-Tser Huang University of South Carolina.
Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 TCP (Part III: Miscl) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute
1 Chapter 3 Transport Layer. 2 Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4.
Congestion Avoidance and Control CSCI 780, Fall 2005.
1 Internet Networking Spring 2004 Tutorial 10 TCP NewReno.
Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1-1 TCP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute
CMPE 257 Spring CMPE 257: Wireless and Mobile Networking Spring 2005 E2E Protocols (point-to-point)
Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 TCP (Part II) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute
TCP: flow and congestion control. Flow Control Flow Control is a technique for speed-matching of transmitter and receiver. Flow control ensures that a.
Transport Layer3-1 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles.
COMT 4291 Communications Protocols and TCP/IP COMT 429.
CS 4396 Computer Networks Lab
Copyright © Lopamudra Roychoudhuri
Principles of Congestion Control Congestion: informally: “too many sources sending too much data too fast for network to handle” different from flow control!
1 Transport Protocols (continued) Relates to Lab 5. UDP and TCP.
TCP: Transmission Control Protocol Overview Connection set-up and termination Interactive Bulk transfer Timers Improvements.
1 TCP III - Error Control TCP Error Control. 2 ARQ Error Control Two types of errors: –Lost packets –Damaged packets Most Error Control techniques are.
Malathi Veeraraghavan Originals by Jörg Liebeherr 1 Error Control Congestion Control Timers.
Copyright © Lopamudra Roychoudhuri
1 TCP - Part II Relates to Lab 5. This is an extended module that covers TCP data transport, and flow control, congestion control, and error control in.
Lecture 9 – More TCP & Congestion Control
Transport Layer 3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March
CS640: Introduction to Computer Networks Aditya Akella Lecture 15 TCP – III Reliability and Implementation Issues.
Computer Networking Lecture 18 – More TCP & Congestion Control.
Lab The network simulator ns The network simulator ns Allows us to watch evolution of parameters like cwnd and ssthresh Allows us to watch evolution of.
TCP: Transmission Control Protocol Part II : Protocol Mechanisms Computer Network System Sirak Kaewjamnong Semester 1st, 2004.
1 CS 4396 Computer Networks Lab TCP – Part II. 2 Flow Control Congestion Control Retransmission Timeout TCP:
1 TCP Timeout And Retransmission Chapter 21 TCP sets a timeout when it sends data and if data is not acknowledged before timeout expires it retransmits.
1 Sonia FahmyPurdue University TCP Congestion Control Sonia Fahmy Department of Computer Sciences Purdue University
1 TCP - Part II Relates to Lab 5. This is an extended module that covers TCP data transport, and flow control, congestion control, and error control in.
CS640: Introduction to Computer Networks Aditya Akella Lecture 15 TCP – III Reliability and Implementation Issues.
Transport Layer3-1 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles.
1 TCP - Part II. 2 What is Flow/Congestion/Error Control ? Flow Control: Algorithms to prevent that the sender overruns the receiver with information.
1 Computer Networks Congestion Avoidance. 2 Recall TCP Sliding Window Operation.
Internet Networking recitation #11
ECE 4110 – Internetwork Programming
TCP - Part II Relates to Lab 5. This is an extended module that covers TCP data transport, and flow control, congestion control, and error control in TCP.
TCP. TCP ACK generation [RFC 1122, RFC 2581] Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already.
TCP Congestion Control 컴퓨터공학과 인공지능 연구실 서 영우. TCP congestion control2 Contents 1. Introduction 2. Slow-start 3. Congestion avoidance 4. Fast retransmit.
Fall 2004FSU CIS 5930 Internet Protocols1 TCP – Data Exchange Reading: Section 24.4.
Peer-to-Peer Networks 13 Internet – The Underlay Network
Transmission Control Protocol (TCP) TCP Flow Control and Congestion Control CS 60008: Internet Architecture and Protocols Department of CSE, IIT Kharagpur.
Karn’s Algorithm Do not use measured RTT to update SRTT and SDEV Calculate backoff RTO when a retransmission occurs Use backoff RTO for segments until.
TCP - Part II.
TCP - Part II Relates to Lab 5. This is an extended module that covers TCP flow control, congestion control, and error control in TCP.
Internet Networking recitation #9
Chapter 3 outline 3.1 transport-layer services
Introduction to Congestion Control
Hojun Lee TCP enhancements Hojun Lee 11/8/2018.
TCP - Part II Relates to Lab 5. This is an extended module that covers TCP flow control, congestion control, and error control in TCP.
TCP - Part II Suman Banerjee CS 640, UW-Madison
CS640: Introduction to Computer Networks
Internet Networking recitation #10
TCP III - Error Control TCP Error Control.
Transport Layer: Congestion Control
TCP flow and congestion control
TCP: Transmission Control Protocol Part II : Protocol Mechanisms
Presentation transcript:

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 TCP (Part II) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute Shivkumar Kalyanaraman Rensselaer Polytechnic Institute

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 2 q TCP interactive data flow q TCP bulk data flow q TCP congestion control q TCP timers q TCP futures and performance Ref: Chap 19, 20, 21; RFC 793, 1323, 2001, papers by Jacobson, Karn/Partridge q TCP interactive data flow q TCP bulk data flow q TCP congestion control q TCP timers q TCP futures and performance Ref: Chap 19, 20, 21; RFC 793, 1323, 2001, papers by Jacobson, Karn/Partridge Overview

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 3 TCP Interactive Data Flow q Problems: q Overhead: 40 bytes header + 1 byte data q To batch or not to batch: response time important q Batching acks: q Delay-ack timer: piggyback ack on echo q 200 ms timer (fig 19.3) q Batching data: q Nagle’s algo: Don’t send packet until next ack is received. q Developed because of congestion in WANs q Problems: q Overhead: 40 bytes header + 1 byte data q To batch or not to batch: response time important q Batching acks: q Delay-ack timer: piggyback ack on echo q 200 ms timer (fig 19.3) q Batching data: q Nagle’s algo: Don’t send packet until next ack is received. q Developed because of congestion in WANs

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 4 TCP Bulk Data Flow q Sliding window: q Send multiple packets while waiting for acks (fig 20.1) upto a limit (W) q Receiver need not ack every packet q Acks are cumulative. q Ack # = Largest consecutive sequence number received + 1 q Two transfers of the data can have different dynamics (eg: fig 20.1 vs fig 20.2) q Receiver window field: q Reduced if TCP receiver short on buffers q Sliding window: q Send multiple packets while waiting for acks (fig 20.1) upto a limit (W) q Receiver need not ack every packet q Acks are cumulative. q Ack # = Largest consecutive sequence number received + 1 q Two transfers of the data can have different dynamics (eg: fig 20.1 vs fig 20.2) q Receiver window field: q Reduced if TCP receiver short on buffers

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 5 TCP Bulk Data Flow (Contd) q End-to-end flow control q Window update acks: receiver ready q Default buffer sizes: 4096 to bytes. q Ideal: window and receiver buffer = bandwidth-delay product q TCP window terminology: figs 20.4, 20.5, 20.6 q Right edge, Left edge, usable window q “closes” => left edge (snd_una) advances q “opens” => right edge advances (receiver buffer freed => receiver window increases) q “shrinks” => right edge moves to left (rare) q End-to-end flow control q Window update acks: receiver ready q Default buffer sizes: 4096 to bytes. q Ideal: window and receiver buffer = bandwidth-delay product q TCP window terminology: figs 20.4, 20.5, 20.6 q Right edge, Left edge, usable window q “closes” => left edge (snd_una) advances q “opens” => right edge advances (receiver buffer freed => receiver window increases) q “shrinks” => right edge moves to left (rare)

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 6 The Congestion Problem q Problem: demand outstrips available capacity … q Q: Will the “congestion” problem be solved when: q a) Memory becomes cheap (infinite memory)? q Problem: demand outstrips available capacity … q Q: Will the “congestion” problem be solved when: q a) Memory becomes cheap (infinite memory)? No buffer Too late All links 19.2 kb/s Replace with 1 Mb/s S S S S S S S S S S S S S S S S File Transfer Time = 7 hours File Transfer time = 5 mins q b) Links become cheap (high speed links)?

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 7 Ans: None of the above solves congestion ! q Congestion: Demand > Capacity q It is a dynamic problem => Static solutions are not sufficient q TCP provides a dynamic solution Ans: None of the above solves congestion ! q Congestion: Demand > Capacity q It is a dynamic problem => Static solutions are not sufficient q TCP provides a dynamic solution A B S C D Scenario: All links 1 Gb/s. A & B send to C. q c) Processors become cheap (fast routers switches)?

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 8 TCP Congestion Control q Window flow control: avoid receiver overrun q Dynamic window congestion control: avoid/control network overrun q Observation: Not a good idea to start with a large window and dump packets into network q Treat network like a black box and start from a window of 1 segment (“slow start”) q Increase window size exponentially (“exponential increase”) over successive RTTs => quickly grow to claim available capacity. q Window flow control: avoid receiver overrun q Dynamic window congestion control: avoid/control network overrun q Observation: Not a good idea to start with a large window and dump packets into network q Treat network like a black box and start from a window of 1 segment (“slow start”) q Increase window size exponentially (“exponential increase”) over successive RTTs => quickly grow to claim available capacity.

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 9 q Technique: Every ack: increase cwnd (new window variable) by 1 segment. q Effective window = Min(cwnd, Wrcvr) q Technique: Every ack: increase cwnd (new window variable) by 1 segment. q Effective window = Min(cwnd, Wrcvr)

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 10 Dynamics q Rate of acks = rate of packets at the bottleneck: “Self-clocking” property. 100 Mbps10 Mbps Router Q 1st RTT 2nd RTT3rd RTT4th RTT

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 11 Congestion Detection q Packet loss as an indicator of congestion. q Set slow start threshold (ssthresh) to min(cwnd, Wrcvr)/2 q Retransmit pkt, set cwnd to 1 (reenter slow start) q Packet loss as an indicator of congestion. q Set slow start threshold (ssthresh) to min(cwnd, Wrcvr)/2 q Retransmit pkt, set cwnd to 1 (reenter slow start) Time (units of RTTs) Congestion Window (cwnd) Receiver Window Idle Interval Timeout 1 ssthresh

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 12 Congestion avoidance q Increment cwnd by 1 per ack until ssthresh q Increment by 1/cwnd per ack afterwards (“Congestion avoidance” or “linear increase”) q Idea: ssthresh estimates the bandwidth-delay product for the connection. q Initialization: ssthresh = Receiver window or default bytes. Larger values thru options. q If source is idle for a long time, cwnd is reset to one. q Increment cwnd by 1 per ack until ssthresh q Increment by 1/cwnd per ack afterwards (“Congestion avoidance” or “linear increase”) q Idea: ssthresh estimates the bandwidth-delay product for the connection. q Initialization: ssthresh = Receiver window or default bytes. Larger values thru options. q If source is idle for a long time, cwnd is reset to one.

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 13 Timeout and RTT Estimation q Timeout: for robust detection of packet loss q Problem: How long should timeout be ? q Too long => underutilization; too short => wasteful retransmissions q Solution: adaptive timeout: based on RTT q RTT estimation: q Early method: exponential averaging: q R   *R + (1 -  )*M { M =measured RTT} q RTO =  *R {  = delay variance factor} q Suggested values:  = 0.9,  = 2 q Timeout: for robust detection of packet loss q Problem: How long should timeout be ? q Too long => underutilization; too short => wasteful retransmissions q Solution: adaptive timeout: based on RTT q RTT estimation: q Early method: exponential averaging: q R   *R + (1 -  )*M { M =measured RTT} q RTO =  *R {  = delay variance factor} q Suggested values:  = 0.9,  = 2

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 14 RTT Estimation q Jacobson [1988]: this method has problems w/ large RTT fluctuations q New method: Use mean & deviation of RTT q A = smoothed average RTT q D = smoothed mean deviation q Err = M - A { M = measured RTT} q A  A + g*Err {g = gain = 0.125} q D  D + h*(|Err| - D) {h = gain = 0.25} q RTO = A + 4D q Integer arithmetic used throughout. Complex initialization process... q Jacobson [1988]: this method has problems w/ large RTT fluctuations q New method: Use mean & deviation of RTT q A = smoothed average RTT q D = smoothed mean deviation q Err = M - A { M = measured RTT} q A  A + g*Err {g = gain = 0.125} q D  D + h*(|Err| - D) {h = gain = 0.25} q RTO = A + 4D q Integer arithmetic used throughout. Complex initialization process...

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 15 Timer Backoff/Karn’s Algorithm q Timer backoff: If timeout, RTO = 2*RTO {exponential backoff} q Retransmission ambiguity problem: q During retransmission, it is unclear whether an ack refers to a packet or its retransmission. Problem for RTT estimation q Karn/Partridge: don’t update RTT estimators during retransmission. q Restart RTO only after an ack received for a segment that is not retransmitted q Timer backoff: If timeout, RTO = 2*RTO {exponential backoff} q Retransmission ambiguity problem: q During retransmission, it is unclear whether an ack refers to a packet or its retransmission. Problem for RTT estimation q Karn/Partridge: don’t update RTT estimators during retransmission. q Restart RTO only after an ack received for a segment that is not retransmitted

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 16 Fast Retransmit and Recovery q Goals: q Timeout avoidance: The 500 ms timer granularity can have an adverse performance impact especially for high speed n/ws q Selective retransmission: Especially when packets are dropped due to error or light congestion q Fast Recovery: Converge quickly to a state of congestion avoidance (linear increase) with half- current window -- the assumed ideal window size. q Observation: Receivers are required to send an immediate duplicate acknowledgment when they receives out-of-order data segments. q Goals: q Timeout avoidance: The 500 ms timer granularity can have an adverse performance impact especially for high speed n/ws q Selective retransmission: Especially when packets are dropped due to error or light congestion q Fast Recovery: Converge quickly to a state of congestion avoidance (linear increase) with half- current window -- the assumed ideal window size. q Observation: Receivers are required to send an immediate duplicate acknowledgment when they receives out-of-order data segments.

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 17 Fast Retransmit and Recovery q 3 duplicate acks => assume loss q More duplicate acks => other packets have reached destination safely. q Wait for about 1/2*RTT, and resume transmitting new segments for every subsequent duplicate ack received. Stop this process once the ack for the missing segment received q 3 duplicate acks => assume loss q More duplicate acks => other packets have reached destination safely. q Wait for about 1/2*RTT, and resume transmitting new segments for every subsequent duplicate ack received. Stop this process once the ack for the missing segment received Ack 500 FRR

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 18 Fast Retransmit and Recovery q Fast Retransmit: Received third duplicate ack: q Set ssthresh to 1/2 of current cwnd q Retransmit the missing segment q Set cwnd to ssthresh+3 q Fast Recovery: For each duplicate ack hence: q Increment cwnd by 1 MSS q New packets are transmitted once cwnd grows large enough. q [If old cwnd was a pipe of length 1*RTT, the network gets a relief period of 1/2*RTT] q Fast Retransmit: Received third duplicate ack: q Set ssthresh to 1/2 of current cwnd q Retransmit the missing segment q Set cwnd to ssthresh+3 q Fast Recovery: For each duplicate ack hence: q Increment cwnd by 1 MSS q New packets are transmitted once cwnd grows large enough. q [If old cwnd was a pipe of length 1*RTT, the network gets a relief period of 1/2*RTT]

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 19 FRR (contd) q Upon receiving the next (non-duplicate) Ack: q Set cwnd to ssthresh & enter linear growth phase q Upon receiving the next (non-duplicate) Ack: q Set cwnd to ssthresh & enter linear growth phase CWND TIME CWND/2 New packets sent during this phase

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 20 FRR problems q Burst loss of 3 pkts => Timeout + window shutdown to cwnd/8 ! CWND Time 1st Fast Retransmit 2nd Fast Retransmit Timeout CWND/2 CWND/4 CWND/8 W

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 21 TCP Performance Optimization q SACK: selective acknowledgments: specifies blocks of packets received at destination. q Random early drop (RED) scheme spreads the dropping of packets more uniformly and reduces average queue length and packet loss rate. q Scheduling mechanisms protect well- behaved flows from rogue flows. q Explicit Congestion Notification (ECN): routers use a explicit bit-indication for congestion instead of loss indications. q SACK: selective acknowledgments: specifies blocks of packets received at destination. q Random early drop (RED) scheme spreads the dropping of packets more uniformly and reduces average queue length and packet loss rate. q Scheduling mechanisms protect well- behaved flows from rogue flows. q Explicit Congestion Notification (ECN): routers use a explicit bit-indication for congestion instead of loss indications.

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 22 Congestion control summary q Sliding window limited by receiver window. q Dynamic windows: slow start (exponential rise), congestion avoidance (linear rise), multiplicative decrease. q Adaptive timeout: need mean RTT & deviation q Timer back off and Karn’s algo during retransmission q Go-back-N or Selective retransmission q Cumulative and Selective acknowledgements q Timeout avoidance: FRR q Drop policies, scheduling and ECN q Sliding window limited by receiver window. q Dynamic windows: slow start (exponential rise), congestion avoidance (linear rise), multiplicative decrease. q Adaptive timeout: need mean RTT & deviation q Timer back off and Karn’s algo during retransmission q Go-back-N or Selective retransmission q Cumulative and Selective acknowledgements q Timeout avoidance: FRR q Drop policies, scheduling and ECN

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 23 Summary q Interactive and bulk TCP flow q TCP congestion control q Informal exercises: Perform some of the experiments described in chaps to see various facets of TCP in action q Interactive and bulk TCP flow q TCP congestion control q Informal exercises: Perform some of the experiments described in chaps to see various facets of TCP in action