TCP Selective Acknowledgement Options ECE 4605 - Fall 2005 Shyam Seshadri Zaheer Ahmed

Need for selective acknowledgements TCP uses cumulative acknowledgements scheme Delay exists before sender learns of a lost packet Multiple packet losses from same window cause poor TCP performance and low throughput 4 3 2 1 Not ack’d

Selective Acknowledgements Selective Acknowledgements solve the problem at hand! SACK informs the sender about all received packets Sender can then resend only the ones which were not received

How is it implemented? SACK-Permitted Option Representation: This two-byte option may be sent in a SYN by a TCP that has been extended to receive (and presumably process) the SACK option once the connection has opened. Representation: TCP Options – Kind : 4 Kind=4 Length=2

IMPLEMENTATION - SACK Option The SACK option is sent by a data receiver to inform the data transmitter of non-contiguous blocks of data that have been received and queued . When missing segments are received, the data receiver acknowledges the data normally by advancing the left window edge in the ACK Field of the TCP header. Each contiguous block of data queued at the data receiver is defined by two 32-bit unsigned integers. A SACK option that specifies n blocks will have a length of 8* n +2 bytes. WHY?

SACK options format Each block represents contiguous and isolated bytes of received data Bytes below the block and above the block have not been received Triggering Segment ACK Left edge Right edge 6000 5000 5500 6500 Packet(s) before 5500 have not been received Packets 6500 and beyond have not been received

SACK Options format Kind = 5 Variable Left Edge of First Block Length – Kind = 5 Variable Left Edge of First Block Right Edge of First Block …………. Left Edge of nth Block Right Edge of nth Block

Where do SACK options go? 16 bit SRC Port 16 bit DST Port 32 bit sequence number 32 bit ACK number HL resvd flags 16 bit window size In the SYN flag TCP options 16 bit TCP checksum 16 bit urgent pointer Options (if any) Data

Data receiver behavior Data receiver can send SACK options only if it has received a SACK-permitted SACK options should be included in all ACKs which do not ACK the highest sequence number First SACK block must specify triggering segment All recently reported SACK blocks must be repeated

Data sender behavior Sender must maintain queue of un-ACK’d packets A new flag called “SACKed” is added to each segment When an ACK arrives, the SACKed bit is changed to 1 All segments which have a 0 as the SACKed bit are to be retransmitted If timeout occurs, segment on left edge of the window must be retransmitted

Examples Assume the left window edge is 5000 Sender sends 8 segments, each has 500 bytes of data Example 1: First 4 segments are received, last 4 are dropped Receiver sends a normal ACK acknowledging sequence number 7000 No SACK option is required since no intermediate segment is missing

Examples Triggering Segment ACK Left Edge Right Edge 5000 (lost) 5500 6000 6500 7000 7500 8000 8500 9000 Example 2: First segment is dropped, following 7 are received Data receiver sends the following SACKs

Examples Example 3: 2nd, 4th, 6th, 8th segments are lost 1st packet is ACKed normally 3rd, 5th and 7th packets trigger SACK options Segments are constantly shifted to the right as more SACK options are triggered

Examples – Example 3 5000 5500 (lost) 6000 6500 7000 7500 8000 8500 Triggering Segment ACK 1st Block Left Edge 1st Block Right Edge 2nd Block Left Edge 2nd Block Right Edge 3rd Block Left Edge 3rd Block Right Edge 5000 5500 (lost) 6000 6500 7000 7500 8000 8500

Congestion Control Issues To preserve robustness, recovery is not triggered by a single ACK reporting out-of- order packets at the receiver During recovery, the data sender limits the number of segments sent in response to each ACK Since the data receiver is allowed to discard SACKed data when a retransmit timeout occurs, the data sender MUST ignore prior SACK information in determining which data to retransmit

Efficiency Issues In a lossless medium, one block per SACK option packet would always be sufficient In a lossy medium, The redundant blocks in the SACK option packet increase the robustness of SACK delivery in the presence of lost ACKs However, if all of the ACK packets reporting a particular SACK block are dropped, then the sender might unnecessarily retransmit those segments

Improved Retransmission Very inefficient for the sender to wait for a timeout before the segment is declared lost and retransmitted. One SACK packet provides enough information to declare a packet lost and allow for recovery faster. Very beneficial in cases where small window sizes and large roundtrip time with respect to packet losses come into play.

Implementation Issues High Buffer size required Possible increase in transmission time due to redundant SACK data blocks being transferred Limited TCP option bits available per TCP header

Questions/Comments