1. ECE 4605 Edgar Duskin Ifiok Udowana
RFC 2018: TCP-SACK
ECE 4605
Edgar Duskin
Ifiok Udowana

2. Introduction What is TCP-SACK? Why is TCP-SACK needed?
A mechanism to overcome the poor performance TCP can experience with multiple lost packets.
Why is TCP-SACK needed?
Regular TCP forces sender to wait a full round trip time to find out about a lost packet.
With cumulative acknowledgements, multiple dropped segments degrades throughput.

3. Current TCP Example Packets 3 and 5 (of a 7 packet sequence) lost1 2 3 4 6 5 7
Packets 3 and 5 (of a 7 packet sequence) lost
After retransmitting 3, sender had to wait an entire RTT to know about the next missing packet

4. TCP-SACK Concepts
Works by including information on correctly received packets in the TCP option header.
Sender doesn’t wait full RTT to know about next lost packet.

5. Sender sends a 25 packet sequence 5, 9, and 17 are lost
TCP-SACK Example
Sender sends a 25 packet sequence
5, 9, and 17 are lost
Receiver sends back a normal ACK 5, but will include blocks of contiguous data:
(1-4)
(6-8)
(10-17)
(18-25)

6. Implementation How is TCP-SACK implemented?
16 bit SRC Port
16 bit DST Port
How is TCP-SACK implemented?
SACK uses the options field for block data
Does not remove or change the meaning of the ACK field
32 bit sequence number
32 bit ACK number HL
resvd
flags
16 bit window size
16 bit TCP checksum
16 bit urgent pointer
Options (40 bytes)
Data

7. Implementation (cont’d)
Each block definition is 8 bytes.
Length is 1 byte
Kind (TCP option type identifier) is 1 byte
n blocks will have a length of 8*n+2 bytes
With a 40 byte Options header, only 4 blocks can really be defined.
Kind=5
Length (n)
Left edge of 1st block (32 bits)
Right edge of 1st block (32 bits) …
Left edge of nth block (32 bits)
Right edge of nth block (32 bits)
TCP-SACK Option Fields

8. TCP SACK-Permitted Option Field
Interoperability
How does TCP-SACK work with other hosts?
SACK employs a TCP-SACK permitted option to determine if SACK can be used in a TCP connection.
Receiver sends with SYN packet in handshake
If the sender is SACK-capable, SACK options will be used.
2 bytes long
Kind=4
Length=2
TCP SACK-Permitted Option Field

9. Results & Performance
RFC 2018 focuses primarily on the implementation details of TCP-SACK in the TCP header.
Assuming that SACK had the entire options field, it could consolidate up to 4 ACKs.
On lossy lines, SACK would allow the sender to repacket and resend the missing packets at once.

10. TCP-SACK EXAMPLE 5000 5500 (LOST) 6000 6500 7000 7500 8000 8500 TRIG.
SEGMENT
ACK
FIRST BLOCK
SECOND BLOCK
THIRD BLOCK
LEFT
EDGE
RIGHT
LEFT EDGE
RIGHT EDGE
5000
5500
(LOST)
6000
6500
7000
7500
8000
8500

11. Problems with RFC 2018
Does not really explain what the sender should do once it receives the SACK options.
Focused more on the implementation details rather than algorithms and actual performance of TCP-SACK.

12. Questions? How many TCP options are usually implemented?
What exactly does the sender once it receives SACK options?
What is the disadvantage of making the right edge of the blocks the last segment of the contiguous data?
If there is space for only one block options, how does the performance of TCP-SACK compare to the regular TCP?
How many options out there are more important than TCP-SACK option?
Are dropped packets one of the biggest problems in today’s TCP performance?