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.

Slides:



Advertisements
Similar presentations
Simulation-based Comparison of Tahoe, Reno, and SACK TCP Kevin Fall & Sally Floyd Presented: Heather Heiman September 10, 2002.
Advertisements

Different TCP Flavors CSCI 780, Fall TCP Congestion Control Slow-start Congestion Avoidance Congestion Recovery Tahoe, Reno, New-Reno SACK.
TCP: Transmission Control Protocol Overview Connection set-up and termination Interactive Bulk transfer Timers Improvements.
TCP EE122 Discussion 10/31/11. TCP Flow Control Keep sender from overwhelming receiver Data not necessarily pushed to app layer ACK Adv_Win: 300 R Push.
1 TCP - Part II. 2 What is Flow/Congestion/Error Control ? Flow Control: Algorithms to prevent that the sender overruns the receiver with information.
Computer Networks: TCP Congestion Control 1 TCP Congestion Control Lecture material taken from “Computer Networks A Systems Approach”, Fourth Edition,Peterson.
School of Information Technologies TCP Congestion Control NETS3303/3603 Week 9.
Computer Networks: TCP Congestion Control 1 TCP Congestion Control Lecture material taken from “Computer Networks A Systems Approach”, Third Ed.,Peterson.
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.
1 Internet Networking Spring 2002 Tutorial 10 TCP NewReno.
CSCE 515: Computer Network Programming Chin-Tser Huang University of South Carolina.
Computer Networks : TCP Congestion Control1 TCP Congestion Control.
Transport: TCP Manpreet Singh (Slides borrowed from various sources on the web)
Congestion Avoidance and Control CSCI 780, Fall 2005.
1 Internet Networking Spring 2004 Tutorial 10 TCP NewReno.
Networks : TCP Congestion Control1 TCP Congestion Control.
Networks : TCP Congestion Control1 TCP Congestion Control Presented by Bob Kinicki.
Advanced Computer Networks: TCP Congestion Control 1 TCP Congestion Control Lecture material taken from “Computer Networks A Systems Approach”, Fourth.
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.
COMT 4291 Communications Protocols and TCP/IP COMT 429.
CS 4396 Computer Networks Lab
Copyright © Lopamudra Roychoudhuri
1 Transport Protocols (continued) Relates to Lab 5. UDP and TCP.
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
What is TCP? Connection-oriented reliable transfer Stream paradigm
CS640: Introduction to Computer Networks Aditya Akella Lecture 15 TCP – III Reliability and Implementation Issues.
Computer Networking Lecture 18 – More TCP & Congestion Control.
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
Network Protocols: Design and Analysis Polly Huang EE NTU
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.
TCP End-To-End Congestion Control Wanida Putthividhya Dept. of Computer Science Iowa State University Jan, 27 th 2002 (May, 25 th 2001)
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
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 Timeout and Retransmission
TCP Congestion Control 컴퓨터공학과 인공지능 연구실 서 영우. TCP congestion control2 Contents 1. Introduction 2. Slow-start 3. Congestion avoidance 4. Fast retransmit.
Recap Slow start introduced cwnd Slow start introduced cwnd Can transmit up to Can transmit up to min( cwnd, offered window ) Flow control by the sender.
Transport Layer3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 5 th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2009.
Transmission Control Protocol (TCP) TCP Flow Control and Congestion Control CS 60008: Internet Architecture and Protocols Department of CSE, IIT Kharagpur.
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.
TCP EE122 Discussion 10/18/13.
Chapter 5 TCP Sequence Numbers & TCP Transmission Control
Chapter 3 outline 3.1 transport-layer services
Hojun Lee TCP enhancements Hojun Lee 11/8/2018.
Precept 2: TCP Congestion Control Review
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
CS4470 Computer Networking Protocols
CS640: Introduction to Computer Networks
State Transition Diagram
EE 122: Lecture 10 (Congestion Control)
Project 3 Flow and congestion control
TCP III - Error Control TCP Error Control.
TCP: Transmission Control Protocol Part II : Protocol Mechanisms
Presentation transcript:

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 parameters like cwnd and ssthresh ns output is in “raw” form; needs processing ns output is in “raw” form; needs processing awk is often very useful for this awk is often very useful for this

Implication of a time-out When a packet is lost, we stop getting new acks When a packet is lost, we stop getting new acks Left edge stops moving to the right Left edge stops moving to the right Dup acks come; suppose no fast retransmit Dup acks come; suppose no fast retransmit Transmitter keeps sending till it exhausts the usable window Transmitter keeps sending till it exhausts the usable window At this point, the transmitter stalls At this point, the transmitter stalls

Implication of a time-out What is happening to the segments already in the pipe? What is happening to the segments already in the pipe? They keep progressing to the receiver, and acks keep getting generated They keep progressing to the receiver, and acks keep getting generated But these are all dup acks But these are all dup acks As the transmitter is not putting new packets into the pipe, eventually the pipe empties out As the transmitter is not putting new packets into the pipe, eventually the pipe empties out

Eventually, pipe is empty

Implication of a time-out If RTO timer value is “appropriately” set, then by the time the timer fires, the pipe will have emptied out If RTO timer value is “appropriately” set, then by the time the timer fires, the pipe will have emptied out This is because RTO is set sufficiently large This is because RTO is set sufficiently large Same situation as when we began Same situation as when we began Hence the need for Slow Start after time-out Hence the need for Slow Start after time-out

Fast Retransmit However, if we do a Fast Retransmit, then the pipe is not empty when we retransmit However, if we do a Fast Retransmit, then the pipe is not empty when we retransmit In particular, if the duplicate ack threshold K is a small fraction of the BDP, the pipe is almost full when the fast retransmit happens In particular, if the duplicate ack threshold K is a small fraction of the BDP, the pipe is almost full when the fast retransmit happens –Hence, no need for Slow Start!

Fast Retransmit Further, K dup acks mean that K packets have left the network Further, K dup acks mean that K packets have left the network By “packet conservation”, can send K more packets! By “packet conservation”, can send K more packets!

Fast recovery Suppose that cwnd = C (packets) Suppose that cwnd = C (packets) This means that the source estimates that the pipe can hold C packets presently This means that the source estimates that the pipe can hold C packets presently Suppose that D dup acks are received Suppose that D dup acks are received This means that D packets have left the pipe This means that D packets have left the pipe –A dup ack is generated as soon as the out-of-order packet reaches the receiver So, D packets can be injected into the network So, D packets can be injected into the network

Fast recovery Observation: Observation: In order to send D packets, need to set In order to send D packets, need to set cwnd = C + D This is as if cwnd was inflated (by 1) for every dup ack received This is as if cwnd was inflated (by 1) for every dup ack received So, upon receiving the K th dup ack So, upon receiving the K th dup ack –ssthresh = (1/2)*cwnd (Usual step in CA) –Retransmit the lost packet

Fast Recovery After Fast Retransmit, set cwnd = ssthresh + K After Fast Retransmit, set cwnd = ssthresh + K Keep increasing cwnd by 1 for every duplicate ack received Keep increasing cwnd by 1 for every duplicate ack received This is the idea of Fast Recovery This is the idea of Fast Recovery Keep transmitting packets whenever allowed by the value of cwnd Keep transmitting packets whenever allowed by the value of cwnd

Fast Recovery When the (fast) retransmitted packet is acknowledged, set cwnd = ssthresh again (cwnd deflated) When the (fast) retransmitted packet is acknowledged, set cwnd = ssthresh again (cwnd deflated) Ready to begin next cycle Ready to begin next cycle Note that we are not beginning in Slow Start Note that we are not beginning in Slow Start Beginning in Congestion Avoidance instead Beginning in Congestion Avoidance instead Initial “slowness” of Slow Start avoided Initial “slowness” of Slow Start avoided Overall speed of data transfer improved Overall speed of data transfer improved

Fast Retransmit & Fast Recovery Reasons for improved performance Reasons for improved performance –Early detection of congestion (triple duplicate acks) and early retransmission –If retransmitted packet was successfully received, next cycle begins in Congestion Avoidance and not Slow Start –However, if retransmission is not successful, then next cycle begins in Slow Start again (no choice)

Fast Retransmit & Fast Recovery SS Loss detection (triple duplicate ack) Fast retransmit cwnd=ssthresh + 3 cwnd inflated for every duplicate ack; keep transmitting if possible Fast recovery Hopefully, retransmission succeeded cwnd= ssthresh Beginning the next cycle in congestion avoidance cwnd=1 Retransmission failed & timeout SS Triple duplicate ack ssthresh=(1/2)*cwnd

Retransmissions Measurements for obtaining RTT RTO calculations (parameters)

RTT measurements Not all transmitted segments are timed Not all transmitted segments are timed One connection is associated with one timer One connection is associated with one timer –If the timer is already in use when a segment S is transmitted, the segment S is not timed cwnd = 1 ack cwnd = 2 ack Segment not timed

RTT measurements RTT: time between sending a byte with a particular sequence number and getting an ack covering that sequence number RTT: time between sending a byte with a particular sequence number and getting an ack covering that sequence number Timing: counting ticks that occur every 500 ms Timing: counting ticks that occur every 500 ms Only segments containing data are timed Only segments containing data are timed –A segment with only an Ack will not be timed

RTT measurements If 1 tick between transmission of data and reception of ack, then RTT is taken to be 500 ms If 1 tick between transmission of data and reception of ack, then RTT is taken to be 500 ms –If 2 ticks, then RTT taken to be 1000 ms What should we do if a packet is retransmitted? What should we do if a packet is retransmitted?

RTT Measurements A packet is transmitted, a timeout occurs, the packet is retransmitted A packet is transmitted, a timeout occurs, the packet is retransmitted Now an ack is received Now an ack is received Ack corresponding to the 1st transmission or the 2nd? Ack corresponding to the 1st transmission or the 2nd? –Retransmission ambiguity problem

RTT Measurements Difficulty: Not sure if the 1 st transmission was lost Difficulty: Not sure if the 1 st transmission was lost Perhaps the RTO was too small and the retransmission happened too soon Perhaps the RTO was too small and the retransmission happened too soon

Karn’s algorithm Upon loss detected by time-out, back off the RTO timer Upon loss detected by time-out, back off the RTO timer –Exponential backoff: double the RTO interval upon a time-out –Continues till an upper limit is reached –Allowing time for congestion to clear out

Karn’s algorithm Ack for a retransmitted packet arrives Ack for a retransmitted packet arrives –No updates of the RTT estimates –No change in RTO values being used currently –Update estimates when ack received for a segment that was not retransmitted

RTT estimates and RTO How long should the time-out interval (RTO) be? How long should the time-out interval (RTO) be? Adaptive Adaptive –Should depend on the round-trip time (RTT) experienced on a connection Therefore, need to keep measuring RTTs Therefore, need to keep measuring RTTs

RTT estimates and RTO Denote the measured RTT value by M Denote the measured RTT value by M [RFC 793] R: “running” estimate of avg RTT [RFC 793] R: “running” estimate of avg RTT –R <---  R + (1-  )M –Smoothed estimator –  = 0.9 (recommended) Round-trip timeout Round-trip timeout –RTO =  R –  recommended  Experience showed that this setting of RTO did not work well (Jacobson) Experience showed that this setting of RTO did not work well (Jacobson)

RTT estimates and RTO Variability in RTT is not adequately captured Variability in RTT is not adequately captured –Leads to unnecessary retransmissions Keep track of the variability in RTT Keep track of the variability in RTT –Calculate RTO based on both mean and mean deviation of RTT A: running estimate of avg RTT A: running estimate of avg RTT –Err = (M - A) –“Error” between measured value and estimate

RTT estimates and RTO Algorithm Algorithm –Update A: A <-- (1 - g) A + g M –g = D: running estimate of deviation D: running estimate of deviation –Update D: D <-- (1 - h) D + h | Err | –h = 0.25 RTO = A + 4D RTO = A + 4D