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

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.

Current TCP Example Packets 3 and 5 (of a 7 packet sequence) lost 1 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

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.

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)

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

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

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

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.

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

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.

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?