{"id":1864,"date":"2013-10-14T20:01:49","date_gmt":"2013-10-14T19:01:49","guid":{"rendered":"http:\/\/mccltd.net\/blog\/?p=1864"},"modified":"2013-10-14T20:03:54","modified_gmt":"2013-10-14T19:03:54","slug":"long-fat-pipes-tcp-wscale-tcp-sack-and-time-stamp-options","status":"publish","type":"post","link":"http:\/\/darenmatthews.com\/blog\/?p=1864","title":{"rendered":"Long Fat Pipes: TCP WSCALE, TCP SACK and Time Stamp Options"},"content":{"rendered":"

Long Fat Pipes<\/strong>
\nHigh-capacity packet satellite channels are LFN’s\u00a0 (Delay 4 x 35\u2018800 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\u00a0 over LFNs:<\/p>\n

\u2022 Window Size Limit (2^16 or max 65k bytes) – Remedy: TCP option “Window scale”
\n\u2022 Recovery from Segment Losses – Remedy: TCP option “selective acknowledgement”
\n\u2022 Round-Trip Measurement – Remedy: TCP option “Time stamp”
\nWith 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.<\/p>\n

Calculating Throughput<\/span>:
\nYou can calculate the approximate throughput for a given TCP window size from the following formula: Throughput = TCP maximum receive windowsize \/ RTT<\/strong>
\nFor 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.<\/p>\n

WINDOW SCALING<\/strong> (mitigate window size limitation)
\nFormula to determine the scaled window:<\/span>
\nScaled Window Size = Window Bytes x 2S\u00a0 (where “S” is Scaling Factor)<\/p>\n

TCP Window Size of 65\u2018535 Bytes is too small.
\n\u2022 A multiplier Scaling Factor resolves this limitation.
\n\u2022 Scaling Factor S is negotiated at TCP setup.
\n\u2022 Each end can offer an individual Scaling Factor.
\n\u2022 The value for the Scaling Factors can vary from 0 to14.
\n\u2022 Calculation for the scaled Window Size is as follows: Scaled Window Size = Window Bytes x 2^S
\n\u2022 Example: Window Size 46 Bytes (Scaling Factor S=7) would be scaled as 2^7 = 128. So 46 Bytes x 128 = 5\u2019888 Bytes
\n\u2022 The maximum Window Size can be 1\u2019073\u2019741\u2019824 Bytes = 1 Gigabyte<\/p>\n

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

TIME STAMP<\/strong>
\nTCP 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.<\/p>\n

There are two timestamp fields:<\/p>\n