SELECTIVE ACKNOWLEDGEMENT (SACK) DUPLICATE SELECTIVE ACKNOWLEDGMENT

Slides:



Advertisements
Similar presentations
TCP Variants.
Advertisements

Introduction 1 Lecture 13 Transport Layer (Transmission Control Protocol) slides are modified from J. Kurose & K. Ross University of Nevada – Reno Computer.
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.
1 Transport Protocols & TCP CSE 3213 Fall April 2015.
Guide to TCP/IP, Third Edition
UDP & TCP Where would we be without them!. UDP User Datagram Protocol.
Configuring a Router with RIP Basic Configuration and Show Commands.
1 TCP - Part I Relates to Lab 5. First module on TCP which covers packet format, data transfer, and connection management.
1 CS 4396 Computer Networks Lab Transmission Control Protocol (TCP) Part I.
TCP: Transmission Control Protocol Overview Connection set-up and termination Interactive Bulk transfer Timers Improvements.
BZUPAGES.COM 1 User Datagram Protocol - UDP RFC 768, Protocol 17 Provides unreliable, connectionless on top of IP Minimal overhead, high performance –No.
Madhusudhan Shyamlal CISC 856 Computer & Information Sciences Thanks to Dr.Paul Amer Nasif Ekiz Ertugrul Yilmaz.
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 TCP CSE May TCP Services Flow control Connection establishment and termination Congestion control 2.
1 Spring Semester 2007, Dept. of Computer Science, Technion Internet Networking recitation #11 TCP Eiffel (RFC 3522)
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.
1 Internet Networking Spring 2006 Tutorial 10 The Eifel Detection Algorithm for TCP RFC 3522.
1 Internet Networking Spring 2004 Tutorial 10 TCP NewReno.
TCP. Learning objectives Reliable Transport in TCP TCP flow and Congestion Control.
WXES2106 Network Technology Semester /2005 Chapter 8 Intermediate TCP CCNA2: Module 10.
TCP: flow and congestion control. Flow Control Flow Control is a technique for speed-matching of transmitter and receiver. Flow control ensures that a.
Copyright © Lopamudra Roychoudhuri
6.1. Transport Control Protocol (TCP) It is the most widely used transport protocol in the world. Provides reliable end to end connection between two hosts.
Computer & Information Sciences University of Delaware
TCP : Transmission Control Protocol Computer Network System Sirak Kaewjamnong.
26-TCP Dr. John P. Abraham Professor UTPA. TCP  Transmission control protocol, another transport layer protocol.  Reliable delivery  Tcp must compensate.
TCP1 Transmission Control Protocol (TCP). TCP2 Outline Transmission Control Protocol.
Transmission Control Protocol
Chapter 12 Transmission Control Protocol (TCP)
CSE679: Computer Network Review r Review of the uncounted quiz r Computer network review.
Copyright © Lopamudra Roychoudhuri
ECE 8990 Advanced Computer Network SystemsMississippi State University Comparison of TCP SACK and TCP Peach Sriram Rajan Vijaykumar Rajaram.
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
1 CS 4396 Computer Networks Lab TCP – Part II. 2 Flow Control Congestion Control Retransmission Timeout TCP:
1 TCP - Part II. 2 What is Flow/Congestion/Error Control ? Flow Control: Algorithms to prevent that the sender overruns the receiver with information.
TCP OVER ADHOC NETWORK. TCP Basics TCP (Transmission Control Protocol) was designed to provide reliable end-to-end delivery of data over unreliable networks.
Internet Networking recitation #11
ECE 4110 – Internetwork Programming
Explicit Congestion Notification (ECN) RFC 3168
Guide to TCP/IP Fourth Edition
CIS679: TCP and Multimedia r Review of last lecture r TCP and Multimedia.
Transmission Control Protocol (TCP) TCP Flow Control and Congestion Control CS 60008: Internet Architecture and Protocols Department of CSE, IIT Kharagpur.
11 CS716 Advanced Computer Networks By Dr. Amir Qayyum.
Ch 3. Transport Layer Myungchul Kim
Chapter 5 Peer-to-Peer Protocols and Data Link Layer Timing Recovery.
1 Transmission Control Protocol (TCP) RFC: Introduction The TCP is intended to provide a reliable process-to-process communication service in a.
Other Methods of Dealing with Congestion
TCP Selective Acknowledgement Options
Chapter 3 Transport Layer
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.
Chapter 15 Transmission Control Protocol (TCP)
Introduction to Networks
Chapter 17 and 18: TCP is connection oriented
ECE 4605 Edgar Duskin Ifiok Udowana
TCP.
TCP.
Hojun Lee TCP enhancements Hojun Lee 11/8/2018.
Transmission Control Protocol (TCP)
TCP - Part II Relates to Lab 5. This is an extended module that covers TCP flow control, congestion control, and error control in TCP.
CS4470 Computer Networking Protocols
Other Methods of Dealing with Congestion
Fast Retransmit Sender Receiver
Other Methods of Dealing with Congestion
TCP - Part I Relates to Lab 5. First module on TCP which covers packet format, data transfer, and connection management.
Presentation transcript:

SELECTIVE ACKNOWLEDGEMENT (SACK) DUPLICATE SELECTIVE ACKNOWLEDGMENT CISC 856 – TCP OPTIONS SELECTIVE ACKNOWLEDGEMENT (SACK) RFC 2018 DUPLICATE SELECTIVE ACKNOWLEDGMENT (DSACK) RFC 2883 Thanks to Dr.Paul Amer and Pallavi Mahajan Rajesh Ponnurangam Computers & Information Sciences University of Delaware

TCP without SACK TCP uses cumulative ACKs Receiver identifies the last byte of data successfully received Out of rrder segments are not ACKed Receiver sends duplicate ACKs TCP without SACK forces the TCP sender Either to wait an RTT to find out a segment was lost Or, unnecessarily retransmit data that has been correctly received Can result in reduced overall throughput

TCP with Selective Ack (SACK) SACK + Selective Repeat Retransmission Policy allows receiver informs sender about all segments that are successfully received. sender fast retransmits only the missing data segments SACK is implemented using two TCP Options SACK-Permitted Option SACK Option

SACK-Permitted Option is allowed only in a SYN Segment. indicates sender handles SACKs, and receiver should send SACKs if possible. SACK option can be used once connection is established TCP Header NOP options kind=1 Source port address Destination port address Sequence Number 6 TCP header length Cumulative Ack No. 1 SYN bit Window size Checksum Urgent pointer SACK-permitted kind=4 length=2

SACK-Permitted Option and SACK SENDER RECEIVER SYN “SACK-permitted” TCP connection establishment phase SYN/ACK “SACK-permitted” ACK Cumulative Ack No. Sequence Number Source port address Destination port address SACK-permitted kind=4 length=2 Window size Urgent pointer Checksum NOP options kind=1 1 SYN bit ACK bit Cumulative Ack No. Sequence Number Source port address Destination port address SACK-permitted kind=4 length=2 Window size Urgent pointer Checksum NOP options kind=1 1 SYN bit Cumulative Ack No. Sequence Number Source port address Destination port address Window size Urgent pointer Checksum kind=1 1 ACK bit data transfer phase cum ack and optional SACKs

SACK Option Sequence Number Cumulative Ack No. HLEN Window size Source port address Destination port address Length of SACK with n blocks? = (2 + 8 * n) bytes Sequence Number Cumulative Ack No. HLEN Window size Max number bytes available for TCP Options? Checksum Urgent pointer = 40 bytes Kind=1 Kind=1 Kind=5 Length=?? Left edge of 1st block Max number of SACK blocks possible? Right edge of 1st block = 4 SACK blocks (barring no other TCP Options) Left edge of nth block Right edge of nth block

SACK Example 1 - 100 receiver’s buffer 101 - 200 ACK 201 201-300 1-100 101-200 ACK 201 201-300 sender 301-400 receiver 401 - 500 501 - 600 ACK 201 SACK 401-601 1-100 101-200 401-500 501-600

SACK Rules With SACKs, the ACK field is still a cum ACK A SACK cannot be sent unless the SACK-Permitted option has been received (in the SYN) The 1st SACK block MUST specify the contiguous block of data containing the segment which triggered this acknowledgment If SACKs are sent, SACK option should be included in all ACK’s which do not ACK the highest sequence number in the data receiver’s queue

Generating SACKs – data receiver behavior If the data receiver has not received a SACK-Permitted Option for a given connection, the receiver must not send SACK options on that connection The receiver should send an ACK for every valid segment that arrives containing new data The data receiver should include as many distinct SACK blocks as possible in the SACK option SACK option should be filled out by repeating the most recently reported SACK blocks The data receiver provides the sender with the most up-to-date info about the state of the network and the receiver’s queue

Interpreting SACKs - Data Sender behavior The sender records the SACK for future reference Maintains a retransmission queue containing unacknowledged segments One possible implementation Turns on SACK bit for the segment in retransmission queue when it receives a SACK Skips SACKed data during any later fast retransmission On fast retransmit, retransmits data not SACKed so far and less than the highest SACKed data Turns off SACK bit after retransmission time out

Another SACK Example receiver sender Receiver Buffer 100 299 100-299 300-499 500 300 699 500-699 ACK 300, SACK 500-700 700-899 699 300 500 900 1099 900-1099 ACK 300, SACK 900-1100, 500-700 1100-1299

Another SACK Example (cont’d) 699 300 500 900 1099 sender receiver 1100-1299 300-499 699 300 500 900 1099 ACK 700, SACK 900-1100 700-899 700 300 500 900 1099 ACK 1100 1100

Without SACK vs. With SACK TCP with SACK TCP without SACK sender receiver 100-199 ACK 200 200-299 300-399 400-499 500-599 ACK 200, SACK 300-400 ACK 200, SACK 300-500 fast retransmit ACK 600 ACK 200, SACK 300-600 sender receiver 100-199 ACK 200 200-299 300-399 400-499 500-599 fast retransmit 200-599 ACK 600

Data Receiver Reneging Reneging – fail to fulfill a promise or obligation Data receiver is permitted to discard data in its queue that has not been acknowledged to the data sender, even if the data has already been SACKed Such discarding of SACKed segments is discouraged, but may occur if the receiver must give buffer space back to the OS If reneging occurs first SACK should reflect the newest segment even if its going to be discarded Except for the newest segment, all SACK blocks MUST NOT report any old data which is no longer actually held by the receiver

reneg occurs; window decreases Reneging Example sender 100-199 receiver 100 199 200-299 ACK 200 200 399 300 300-399 400-499 ACK 200; SACK 300-400 reneg occurs; window decreases 200 200 window increases 500-599 599 500 200 ACK 200; SACK 500-600

Consequences of Reneging Sender must maintain normal TCP timeouts Data cannot be considered “communicated” until a cum ACK is sent Sender must retransmit the data at the left window edge after a retransmit timeout, even if that data has been SACKed by the receiver Sender MUST NOT discard data before being acked by the Cum Ack

SACK Observations SACK TCP follows standard TCP congestion control; Adding SACK to TCP does not change the basic underlying congestion control algorithms SACK TCP has major advantages when compared TCP Tahoe, Reno, Vegas and New Reno, as PDUs have been provided with additional information due to the SACK Difference in behavior when multiple packets are dropped from one window of data SACK information allows the sender to better decide what to retransmit and what not to

Duplicate SACK (D-SACK) Extension to SACK – RFC 2883 How is SACK option used when duplicate segments are received? D-SACK does not require separate negotiation between a TCP sender and receiver that have already negotiated SACK When D-SACK is used, the first block of the SACK option should be a D-SACK block specifying a duplicate segment A D-SACK block is only used to report a duplicate contiguous sequence of data received by the receiver in the most recent segment Each duplicate contiguous sequence of data received is reported in at most one D-SACK block

Segment replicated by the network D-SACK Example Segment replicated by the network Receiver Buffer sender receiver 200 399 200-399 ACK 400 400-599 600 400 799 600-799 ACK 400, SACK 600-800 800 400 600 999 800-999 ACK 400, SACK 600-1000 800 400 600 999 ACK 400, SACK 800-1000, 600-1000

DSACK – Another example Receiver Buffer sender receiver 500 599 500-599 600-699 700-799 800-899 900-999 1000-1099 600 1100 1199 1100-1199 700-899 1100 600 699 1199 ACK 600, SACK 1100-1200 1100 600 699 1199 800 899 ACK 700, SACK 1100-1200 ACK 700, SACK 800-900,1100-1200 700 800 899 1100 1199 ACK 900, SACK 800-900,1100-1200

Interpreting D-SACK - Data Sender Behavior The loss of a single ACK can prevent this information from reaching the sender. How does sender knows the first SACK block is a D-SACK? Compares the sequence space in the 1st SACK block to the cum ACK if seq_space < cum_ACK, then duplicate data has been received if seq_space > cum_ACK, then sender compares seq_space with the seq_space in 2nd SACK block (if there is one) if the 1st SACK block is reporting duplicate data that lies above the cumulative ACK, then the 1st SACK block will be a subset of the 2nd SACK block.

DSACK Example TCP with SACK & without D-SACK TCP with SACK and D-SACK sender receiver 100-199 ACK 200 300-399 400-499 500-599 ACK 200, SACK 300-400 ACK 200, SACK 300-500 fast retransmit 200-299 ACK 600 ACK 200, SACK 300-600 cwnd =10 cwnd =5 sender receiver 100-199 ACK 200 300-399 400-499 500-599 ACK 200, SACK 300-400 ACK 200, SACK 300-500 fast retransmit 200-299 ACK 600 ACK 200, SACK 300-600 ACK 600, SACK 200-300 cwnd =10 cwnd =5

D-SACK and Retransmissions D-SACK allows TCP sender to determine when a retransmission was “spurious” (ie, unnecessary) and then undo congestion control measures D-SACK allows TCP sender to determine if the network is duplicating TCP-PDUs D-SACK does not allow a sender to determine if both the original and retransmitted data are received, or the original is lost and the retransmitted data is duplicated by the network.

SACK and D-SACK Interaction There is no difference between SACK and D-SACK, except that the first SACK block is used to report a duplicate segment in D-SACK. D-SACK does not require separate negotiation between a TCP sender and receiver that have already negotiated SACK capability. D-SACK is compatible with current implementations of SACK option in TCP.

Current Implementations of SACK Windows 2000/XP Controlled by a registry parameter – SackOpts in “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters” - SackOpts="1" Windows Vista Windows Server 2008 and Windows Vista support TCP SACK Free BSD and NetBSD have optional modules Solaris 7 and later

References RFC 2018 – TCP Selective Acknowledgement Options. RFC 2883 – An Extension to SACK option for TCP. Kevin Fall and Sally Floyd, “Simulation-based Comparisons of Tahoe, Reno, and SACK TCP”, Lawrence Berkley National Laboratory.