TCP protocol Options

Translated from: http://blog.chinaunix.net/uid-20249205-id-1713871.html

Kind meaning Reference
----   -------------------------------   ---------
0 End of Option List [RFC793]
1 no-operation [RFC793]
2 Maximum Segment Size [RFC793]
3 Wsopt-window scale [RFC1323]
4 SACK permitted [RFC2018]
5 SACK [RFC2018]
6 Echo (obsoleted by option 8) [RFC1072]
7 Echo Reply (obsoleted by option 8) [RFC1072]
8 Tsopt-time Stamp Option [RFC1323]
9 Partial Order Connection permitted[rfc1693]
Partial Order Service profile [RFC1693]
CC [RFC1644]
CC. NEW [RFC1644]
CC. ECHO [RFC1644]
TCP Alternate Checksum Request [RFC1146]
TCP Alternate Checksum Data [RFC1146]
Skeeter [Knowles]
Bubba [Knowles]
Trailer Checksum Option [Subbu & Monroe]
MD5 Signature Option [RFC2385]
SCPS capabilities [Scott]
Selective negative acknowledgements [Scott]
Record boundaries [Scott]
Corruption experienced [Scott]
SNAP [Sukonnik]
Unassigned (Released 12/18/00)
TCP Compression Filter [Bellovin]

TCP Options (RFC793 and updated RFC1323)
– This is filled with the possibility of various combinations
– Answer Mode "query-reply", you can put multiple options
Put it in a bag.
– Some advanced options are added to the new protocol stack implementation

TCP Options
The start of each option is a 1-byte kind field that describes the type of option.

Kind=0: End of option table (1 bytes)

Kind=1: No Action (1 bytes)

kind=2: Maximum message segment Length (4 bytes)

Kind=3: Window enlargement factor (4 bytes)

Kind=8: Timestamp (10 bytes)

3. Window Enlargement options:
The window Enlargement option increases the window definition of TCP from 16 bits to 32 bits, which is not achieved by modifying the TCP header, and the TCP header still uses 16 bits, but is accomplished by defining an option to expand the 16-bit operation.

4. Timestamp option:
The timestamp option causes the sender to place a timestamp value in each message segment. The receiver returns this value in the acknowledgment, allowing the sender to calculate the RTT for each ACK received.

rfc793

Options:variable

Options may occupy space at the end of the TCP header and is a multiple of 8 bits in length.  All options is included in the checksum.  An option could begin on any octet boundary. There is cases for the format of an option:

Case 1: A single octet of Option-kind.

Case 2:an Octet of Option-kind, an octet of Option-length, and
The actual option-data octets.

The option-length counts the octets of Option-kind and Option-length as well as the Option-data octets.

Note that the list of options is shorter than the data offset field might imply. The content of the header beyond the end-of-option Option must be header padding (i.e., zero).

A TCP must implement all options.

Currently defined options include (kind indicated in octal):

Kind Length Meaning
----     ------    -------
0-end of option list.
1-no-operation.
2 4 Maximum Segment Size.

Specific Option definitions

End of Option List

+--------+
|00000000|
+--------+
Kind=0

This option code indicates the end of the option list.  This might isn't coincide with the end of the TCP header according to the Data Offset field. This was used at the end of all options, not the end of each option, and need only be used if the end of the options would Not otherwise coincide with the end of the TCP header.

No-operation

+--------+
|00000001|
+--------+
Kind=1

This option code is used between options, for example, to align the beginning of a subsequent option on a word Boundar Y. There is no guarantee that senders would use this option, so receivers must be prepared to process options even if they Do not begin on a word boundary.

Maximum Segment Size that is, MSS option

+--------+--------+---------+--------+
|00000010|00000100| Max SEG Size |
+--------+--------+---------+--------+
kind=2 length=4
Maximum Segment Size Option data:16 bits

If This option was present, then it communicates the maximum receive segment size in the TCP which sends this segment.  This field must is sent in the initial connection request (i.e., in segments with the SYN control bit set). If This option isn't used, any segment size is allowed.

Padding:variable

The TCP header padding is used to ensure, the TCP header ends and data begins on a + bit boundary. The padding is composed of zeros.

rfc1323

1.3 Using TCP Options

The extensions defined in this memo all use the new TCP options. We
Must address possible issues concerning the use of TCP
Options: (1) compatibility and (2) overhead.

We must pay careful attention to compatibility, i.e., to
interoperation with existing implementations. The only TCP option
Defined previously, MSS, may appear only on a SYN segment. Every
Implementation should (and we expect that most would) ignore
Unknown options on SYN segments. However, some buggy TCP
Implementation might is crashed by the first appearance of a
option on a Non-syn segment. Therefore, for each of the
Extensions defined below, TCP options'll be sent on Non-syn
Segments only if the exchange of options on the SYN segments have
indicated that both sides understand the extension. Furthermore,
An extension option would be sent in a segment only if
The corresponding option is received in the initial
Segment.

A question May is raised about the bandwidth and processing
Overhead for TCP options. Those options that occur on SYN
Segments is not likely to cause a performance concern. Opening A
TCP connection requires execution of significant special-case
Code, and the processing of options are unlikely to increase that
Cost significantly.

On the other hand, a timestamps option could appear in any data or
ACK segment, adding bytes to the 20-byte TCP header. We believe the bandwidth saved by reducing unnecessary
Retransmissions'll and than pay for the extra header bandwidth.

There is also a issue about the processing overhead for parsing
The variable byte-aligned format of options, particularly with a
Risc-architecture CPU. To meet this concern, appendix A contains
A recommended layout of the options in TCP headers to achieve
Reasonable data field alignment. In the spirit of Header
Prediction, a TCP can quickly test for this layout and if it is
Verified then use a fast path. Hosts that use this canonical
Layout would effectively use the options as a set of Fixed-format
Fields appended to the TCP header. However, to retain the
Philosophical and protocol framework of TCP options, a TCP must be
Prepared to parse a arbitrary options field, albeit with less
Efficiency.

Finally, we observe the most of the mechanisms defined in this
Memo is important for LFN ' s and/or very high-speed networks. For
Low-speed networks, it might be a performance optimization to not
Use these mechanisms. A TCP vendor concerned about optimal
Performance over low-speed paths might consider turning these
Extensions off for low-speed paths, or allow a user or
Installation Manager to disable them.

2. TCP WINDOW Scale OPTION

TCP Window scale Option (wsopt):

Kind:3 Length:3 bytes

                +---------+ ---------+---------+
                 | kind=3  | Length=3 |shift.cnt|
                +--------- +---------+---------+

         this option is an offer, not a promise; both sides must send
         window scale options on their SYN segments to enable Window
         scaling in either direction.  if window scaling is enabled,
         then the TCP that sent this option would Right-shift its true
         receive-window values by ' shift.cnt ' Bits for transmission in
         seg. Wnd.  the value ' shift.cnt ' May is zero (offering to scale,
          while applying a scale factor of 1 to the Receive window).

This option is sent in an initial segment (i.e., a
Segment with the SYN bit on and the ACK bit off). It may also
Be sent in a segment, but only if a Window scale op-
tion is received in the initial segment. A Window Scale
option in a segment without a SYN bit should is ignored.

The Window field in a SYN (i.e., a or) segment
itself is never scaled.

3.2 TCP Timestamps Option
TCP timestamps Option (tsopt):

Kind:8

Length:10 bytes

+-------+-------+---------------------+---------------------+
|  kind=8 |   10 | TS Value (TSval) | TS Echo Reply (TSECR) |
+-------+-------+---------------------+---------------------+
1 1 4 4

         the Timestamps option carries-four-byte timestamp fields .
         the Timestamp Value field (TSval) contains the current value of
         the timestamp clock of the TCP sending the option.

         the Timestamp Echo Reply field (TSECR) is only valid if the ack< Br>         bit is a set in the TCP header; If it is valid, it echos a times-
         tamp value of is sent by the Remote TCP in the TSval field
         of a timestamps option. & nbsp When tsecr are not valid, their value
         must be zero.   The TSECR value would generally is from the most
         recent Timestamp option that is received; However, there is
         exceptions that is explained below.

A TCP could send the timestamps option (TSopt) in an initial
Segment (i.e., segment containing a SYN bit and no ACK
bit), and may send a tsopt on other segments only if it re-
Ceived a TSopt in the initial segment for the connection.

TCP protocol Options