Home > Network Design > Long Fat Pipes: TCP WSCALE, TCP SACK and Time Stamp Options

Long Fat Pipes: TCP WSCALE, TCP SACK and Time Stamp Options

October 14th, 2013

Long Fat Pipes
High-capacity packet satellite channels are LFN’s  (Delay 4 x 35‘800 km = 470ms RTT) and modern terrestrial long-haul fibre-optic paths will also fall into the LFN class. There are three fundamental performance problems with the current TCP  over LFNs:

• Window Size Limit (2^16 or max 65k bytes) – Remedy: TCP option “Window scale”
• Recovery from Segment Losses – Remedy: TCP option “selective acknowledgement”
• Round-Trip Measurement – Remedy: TCP option “Time stamp”
With today’s high-BDP transmission paths, the originally designed TCP window size, even at its maximum value, becomes a throughput bottleneck. The size of the Window field in the TCP header is 16 bits, allowing a TCP peer to advertise a maximum receive window size of 65,536 bytes.

Calculating Throughput:
You can calculate the approximate throughput for a given TCP window size from the following formula: Throughput = TCP maximum receive windowsize / RTT
For example, with a 65,536 byte receive window you can only achieve an approximate throughput of 5.24 megabits per second (Mbps) on a path with a 100ms RTT, regardless of the transmission path’s actual bandwidth.

WINDOW SCALING (mitigate window size limitation)
Formula to determine the scaled window:
Scaled Window Size = Window Bytes x 2S  (where “S” is Scaling Factor)

TCP Window Size of 65‘535 Bytes is too small.
• A multiplier Scaling Factor resolves this limitation.
• Scaling Factor S is negotiated at TCP setup.
• Each end can offer an individual Scaling Factor.
• The value for the Scaling Factors can vary from 0 to14.
• Calculation for the scaled Window Size is as follows: Scaled Window Size = Window Bytes x 2^S
• Example: Window Size 46 Bytes (Scaling Factor S=7) would be scaled as 2^7 = 128. So 46 Bytes x 128 = 5’888 Bytes
• The maximum Window Size can be 1’073’741’824 Bytes = 1 Gigabyte

SECLECTIVE ACKNOWLEDGEMENTS (improve recovery from segment losses)
The usage of the TCP SACK option is negotiated during the 3-way handshake.
• The SACK option can be activated from one or both sides.
• Without SACK option, only the last received segment of a contiguous series can be acknowledged.
• The SACK Option allows to acknowledge non-contiguous segments of a series and can request for specific segments.
• The SACK Option can improve the throughput of LFN’s significantly

TCP timestamps help TCP to determine in which order packets were sent. TCP timestamps are not normally aligned to the system clock and start at some random value. Many operating systems will increment the timestamp for every elapsed millisecond; however the RFC only states that the ticks should be proportional.

There are two timestamp fields:

  • a 4-byte sender timestamp value (my timestamp)
  • a 4-byte echo reply timestamp value (the most recent timestamp received from you).

TCP timestamps are used in an algorithm known as Protection Against Wrapped Sequence numbers, or PAWS (see RFC 1323 for details). PAWS is used when the TCP window size exceeds the possible numbers of sequence numbers (232). In the case where a packet was potentially retransmitted it answers the question: “Is this sequence number in the first 4 GB or the second?” And the timestamp is used to break the tie.

Comments are closed.