Hojun Lee hlee@purros.poly.edu TCP enhancements Hojun Lee hlee@purros.poly.edu 11/8/2018.

Slides:



Advertisements
Similar presentations
TCP Variants.
Advertisements

TCP Variations: Tahoe, Reno, New Reno, Vegas, Sack
Simulation-based Comparison of Tahoe, Reno, and SACK TCP Kevin Fall & Sally Floyd Presented: Heather Heiman September 10, 2002.
Different TCP Flavors CSCI 780, Fall TCP Congestion Control Slow-start Congestion Avoidance Congestion Recovery Tahoe, Reno, New-Reno SACK.
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.
Computer Networks: TCP Congestion Control 1 TCP Congestion Control Lecture material taken from “Computer Networks A Systems Approach”, Fourth Edition,Peterson.
TCP Variations Naveen Manicka CISC 856 – Fall 2005 Computer & Information Sciences University of Delaware Nov 10, 2005 Most slides are borrowed from J.
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.
CSCE 515: Computer Network Programming Chin-Tser Huang University of South Carolina.
Computer Networks : TCP Congestion Control1 TCP Congestion Control.
Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 TCP (Part III: Miscl) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute
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)
COMT 4291 Communications Protocols and TCP/IP COMT 429.
Copyright © Lopamudra Roychoudhuri
Computer & Information Sciences University of Delaware
SELECTIVE ACKNOWLEDGEMENT (SACK) DUPLICATE SELECTIVE ACKNOWLEDGMENT
Malathi Veeraraghavan Originals by Jörg Liebeherr 1 Error Control Congestion Control Timers.
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
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. 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 Timeout and Retransmission
TCP Congestion Control 컴퓨터공학과 인공지능 연구실 서 영우. TCP congestion control2 Contents 1. Introduction 2. Slow-start 3. Congestion avoidance 4. Fast retransmit.
Transmission Control Protocol (TCP) TCP Flow Control and Congestion Control CS 60008: Internet Architecture and Protocols Department of CSE, IIT Kharagpur.
TCP over Wireless PROF. MICHAEL TSAI 2016/6/3. TCP Congestion Control (TCP Tahoe) Only ACK correctly received packets Congestion Window Size: Maximum.
Other Methods of Dealing with Congestion
TCP Selective Acknowledgement Options
Chapter 3 Transport Layer
TCP - Part II.
DMET 602: Networks and Media Lab
Fast Retransmit For sliding windows flow control we waited for a timer to expire before beginning retransmission of a packet TCP uses an additional mechanism.
TCP - Part II Relates to Lab 5. This is an extended module that covers TCP flow control, congestion control, and error control in TCP.
Chapter 5 TCP Sequence Numbers & TCP Transmission Control
Chapter 3 outline 3.1 transport-layer services
Introduction to Networks
COMP 431 Internet Services & Protocols
Introduction to Congestion Control
Transmission Control Protocol (TCP)
TCP.
CS 5565 Network Architecture and Protocols
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.
TCP - Part II Suman Banerjee CS 640, UW-Madison
CS 5565 Network Architecture and Protocols
CS4470 Computer Networking Protocols
Other Methods of Dealing with Congestion
Fast Retransmit Sender Receiver
Other Methods of Dealing with Congestion
If both sources send full windows, we may get congestion collapse
EE 122: Lecture 10 (Congestion Control)
The Transport Layer Reliability
Transport Layer: Congestion Control
TCP: Transmission Control Protocol Part II : Protocol Mechanisms
Presentation transcript:

Hojun Lee hlee@purros.poly.edu TCP enhancements Hojun Lee hlee@purros.poly.edu 11/8/2018

Many variants of TCP Tahoe TCP: Follows a basic go-back-n model using slow start, congestion avoidance and Fast Retransmit algorithm. With Fast Retransmit, after receiving small number of acks for the same segment, the sender infers that the packet has been lost and retransmits the packet without waiting for the retransmission timer to expire Reno TCP Modification to the Tahoe TCP Fast Retransmit algorithm to include Fast Recovery; this prevents the pipe from going empty after Fast retransmit, thereby avoiding the need to slow start after a single packet loss Recover 1 lost segment every 3 RTTs New Reno: Uses partial acknowledgement to improve loss recovery Recovers 1 lost segment every RTT SACK TCP Uses SACK option bit field to improve loss recovery Recovers up to 3 segments per RTT Other schemes exist (e.g., Vegas) 11/8/2018

Outline LFN Methods to recover from multiple packet losses in a window Needs some TCP options such as window scale, timestamp and PAWS Methods to recover from multiple packet losses in a window SACK TCP with “partial acknowledgements” Effects of increasing window size 11/8/2018

Long fat pipes problems The TCP window size is a 16-bit field in the TCP header, limiting the window to 65,535 bytes Can be solved with “window scale option” Packet loss in an LFN can reduce throughput drastically (Possible solutions for multiple packet loss within a window?) SACK (Selective acknowledgements) New Reno (use partial acknowledgements) Better RTT measurements are required for operating on an LFN Timestamp option If the network is so fast that sequence number wrap occurs in less than MSL PAWS algorithm (Protection Against Wrapped Sequence Number) 11/8/2018

Window scale option Format Increase the definition of TCP window from 16 to 32 bits The 1-bytes shift count is between 0 and 14. The maximum value of 14 is a window of 1,073,725,440 bytes (65535*214) Appears in a SYN segment kind = 3 len = 4 Shift count 1 byte 1 byte 1 byte 11/8/2018

Timestamp option Format Let the sender place a timestamp value in every segment Receiver echoes this value in the ACK by allowing the sender to calculate an RTT for each received ACK Uses in SYN segment Larger window sizes require better RTT calculation Does not require any form of clock synchronization between the two hosts Kind=8 len=10 timestamp value timestamp echo reply 1 byte 1 byte 4 bytes 4 bytes 11/8/2018

PAWS Largest receiver window = 230 = 1 GB “Lost” segment may reappear before MSL, and the sequence numbers may have wrapped around. The receiver considers the timestamp as an extension of the sequence number  discard out-of- sequence segment based on both seq # and timestamp. 11/8/2018

Useful terms LW (Loss Window): size of the congestion window after a TCP sender detects loss using its retransmission timer RW (Restart Window): size of the congestion window after a TCP restarts transmission after an idle period Flight Size: The amount of data that has been sent but not yet acknowledged Three types of window sizes are used in TCP (RFC 2414) – IW, RW,LW 11/8/2018

Two methods to detect segment loss TO (Timeout ) TD (Triple Duplicate ACK) 11/8/2018

Detect a loss by TO Set cwnd = 1 Set ssthresh = max(Flight size/2, 2MSS) 11/8/2018

Detect a loss by TD (Fast Retransmit and Fast Recovery procedure) After receiving 3 duplicate ACKS, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire Good for a single loss within a window but not good for multiple losses ack 10 10 X 11 12 ack 10 13 ack 10 ack 10 TD 10 ack 14 11/8/2018

Fast retransmit and fast recovery algorithms 1. When the third duplicate ACK is received, then set ssthresh = max(Flight size/2, 2MSS) 2. Retransmit the lost segment and then set cwnd = ssthresh + 3*MSS (Inflating the window)  The reason for this is that since the three duplicate ACKS are received, it assumes that three segments got through because according to the TCP rule, if the receiver receives a new packet, it must generate an ACK. 3. For each additional duplicate ACK received, increase cwnd by 1. 4. Transmit a segment, if allowed by min(cwnd, receiver’s AW) 5. When the next ACK arrives that acknowledges new data, set cwnd = ssthresh (the value set in step 1) (deflating the window) 11/8/2018

Problem occurs if multiple packets loss happens within a window Two possible answers TCP with SACK TCP with partial acknowledgement (New Reno TCP) 10 X 11 12 ack 10 X 13 14 ack 10 ack 10 TD 10 partial ack 12 15 16 ack 12 17 ack 12 2nd TD 11/8/2018 18 ack 12

TCP with SACK (Selective Acknowledgement) Based on RFC 2018 (TCP Selective Acknowledgement Options) –standards track Good for when multiple packets are lost from one window of data Gives sender view of which segments queued at receiver and which in flight Uses two TCP options “SACK permitted” (may be sent in a SYN segment) SACK option itself (may be sent over an established connection) SACK option itself, which may be sent over an established connection one permission has been given By SACK-permitted 11/8/2018

Format of two SACK options Sack-permitted option Two bytes option Sack option itself (Kind = 5, Length=variable) Kind = 2 Length = 4 Kind = 5 Length Left edge of 1st block Right edge of 1st block Left edge of nth block Right edge of nth block 11/8/2018

SACK option examples ~ Assume the left edge is 5000 and transmitter sends a burst of 8 segments, each containing 500 data bytes Example (1) The first four segments are received but the last 4 are dropped - The data receiver will return a normal TCP ACK segment acknowledging sequence number 7000, with no SACK option 11/8/2018

SACK option examples con’t [1] Example (2) The first segment is lost but the remaining 7 segments are received. Receiver will return a TCP ACK segment that acknowledges sequence number 5000 and contains SACK option specifying one block of queued data LE = Left Edge RE = Right Edge 11/8/2018

SACK option examples con’t [2] Example (3)The 2nd, 4th, 6th and 8th (last) segments are dropped. First block Second block Third block Left Edge Right Edge Left Edge Right Edge Left Edge Right Edge (a) SACK not used (b) 6000 6500 (c) 7000 7500 6000 6500 (d) 8000 8500 7000 7500 6000 6500 11/8/2018

SACK option examples con’t [3] Suppose at this point (continue from pervious example), the 4th packet is received out of order. Receiver replies with the following SACK: Suppose that the 2nd segment is received. ACK First block Second block Third block Left edge Right edge Left edge Right edge Left edge Right edge 5500 6000 7500 8000 8500 First block 7500 8000 8500 11/8/2018

New Reno algorithm Based on RFC 2582 (The NewReno modification to TCP’s Fast Recovery Algorithm) - experimental Little information available to the TCP sender in making retransmission decision during Fast recovery Use “partial acknowledgements” (ACKs which cover new data, but not all the data outstanding when loss was detected) Recover 1 lost segment every RTT NewReno modification to TCP’s Fast Recovery 11/8/2018

New Reno algorithm con’t [1] Refer to slide 12 Variable “recover” – used to record the highest sequence number transmitted Add variable “recover” in step 1. Step 5: when an ACK arrives that acknowledges new data, this ACK could be the acknowledgement elicited by the retransmission from step 2, or elicited by a later transmission 11/8/2018

New Reno algorithm con’t [2] Two possibilities If this ACK, acknowledges all of the data up to and including “recover”, then the ACK acknowledges all the intermediate segments sent between the original retransmission of the lost segment and the receipt of the third duplicate ACK Set either cwnd = min (ssthresh, FlightSize + mss) or cwnd = ssthresh (set in step 1) (Flight size (in this case)  amount of data outstanding when the Fast Recovery is exited) 2. If this ACK does not acknowledge all of the data up to and including “recover”, then this is a partial ACK Set cwnd = “deflate the previous cwnd by the amount of new data acknowledged” + mss 11/8/2018

New Reno algorithm con’t [3] Possible variants to the simple response to partial acknowledgements How many packets to retransmit after each partial ACK? When to reset the retransmit timer after a partial ACK? Reset the retransmit timer only after the first partial ACK ( Impatient variant of NewReno) Reset the retransmit timer after each partial ACK ( Slow-but-steady variant of NewReno) How to avoid multiple Fast Retransmits caused by the retransmission of packets already received by the receiver? 11/8/2018

New Reno algorithm con’t [4] Avoiding multiple fast retransmit Reason: TCP data sender is unable to distinguish between a duplicate ACK that results from a lost or delay data packet, and a duplicate ACK that results from the sender’s retransmission of a data packet that had already been received at the receiver Needs a new variable called “send_high” = highest sequence number transmitted so far after each retransmit timeout 11/8/2018

New Reno algorithm con’t [5] Example (a): Assumption: When the third duplicate ACK is received and the sender in not already in the Fast Recovery procedure, then check whether those duplicate ACKs cover more than “send_high” or not. 13 X 10 14 11 ack 13 ack 13 15 12 ack 13 16 ack 13 ack 13 Send_high = 12 ack 13 Sender is not in the fast recovery procedure at this point 1st Scenario 2nd Scenario Wait for RTO Set ssthresh = max(flight size/2, 2MSS) Set the highest sequence number transmitted in the variable called “recover” Go to step 2 11/8/2018

New Reno algorithm con’t [6] Example (b): when the duplicate ACKs don’t cover “send_high”, then do nothing. Do not enter fast retransmit and fast recovery procedure Do not change the ssthresh value Do not go to step 2 to retransmit lost segment Do not execute step 3 upon receiving subsequent duplicate ACKs After a retransmit timeout, record the highest sequence number in “send_high” and exit the Fast Recovery procedure if applicable 13 14 ack 11 15 ack 11 ack 11 Send_high = 12 11/8/2018

Increase IW (Initial Window) size Limited to 2 segments (RFC 2581) Standard track RFC (not experimental) Upper bound for IW is given more precisely: IW = min (4*MSS, max(2*MSS,4380 bytes)) 4 segments (RFC 2416) - informational A simple experiment with only 3 buffers leading into a 9600 baud modem at the receiver No significant degradation of performance even when the IW size 4 11/8/2018

Advantages/disadvantages of larger IW When an IW of at least two segments, the receiver will generate an ACK after the second data segment arrives (eliminates the wait on the timeout (~200 msec) For small file sizes, delay can be improved from 3RTTs down to 1 (Email, webpage transfers less than 4 Kbytes  yields 1RTT) Disadvantages A burst of 4 segments (small burst) may not be “handable” in a rotuer Slightly increase packet drop rate 11/8/2018

Re-starting after idle connections A known problem with TCP congestion control algorithm: Potentially in appropriate burst of traffic to be transmitted after TCP has been idle for a relatively long period of time (line rate burst occurs – source is idle but also due to ACK losses) Idle time; more than one retransmission timeout (RTO) When TCP does not receive during the idle time, then set RW(Restart Window) = IW After an idle period, TCP can not use the ACK clock to strobe new segments into the network, as all the ACKs are from out of the network. Thus, TCP can send a cwnd-size lie-rate burst into the network after an idle. 11/8/2018

Summary Studied TCP options for LFN,many variants of TCP such as SACK TCP and New Reno, and the effect of increasing IW ECN (Explicit Congestion Notification) with RED (other TCP enhancement) 11/8/2018