Connections and Translators
NAT
TCP Options
Every option begins with a 1-byte kind that specifies the type of option.
Options that are not understood are simply ignored, according to [RFC1122].
The options with a kind value of 0 and 1 occupy a single byte. The other options have a len byte that follows the kind byte.
The length is the total length, including the kind and len bytes.
The reason for the NOP option is to allow the sender to pad fields to a multiple of 4 bytes, if it needs to.
Remember that the TCP header’s length is always required to be a multiple of 32 bits because the TCP Header Length field uses that unit.
The EOL option indicates the end of the list and that no further processing of the options list is to be performed.
Maximum Segment Size (MSS) Option
The maximum segment size (MSS) is the largest segment that a TCP is willing to receive from its peer and, consequently, the largest size its peer should ever use when sending.
The MSS value counts only TCP data bytes and does not include the sizes of any associated TCP or IP header
When a connection is established, each end usually announces its MSS in an MSS option carried with its SYN segment.
The option allows for 16(8*(4-2)) bits to be used to specify the MSS value. If no MSS option is provided, a default value of 536 bytes is used.
Note that the MSS option is not a negotiation between one TCP and its peer; it is a limit.
When one TCP gives its MSS option to the other, it is indicating its unwillingness to accept any segments larger than that size for the duration of the connection.
Selective Acknowledgment (SACK) Options
Because it uses cumulative ACKs, TCP is never able to acknowledge data it has received correctly but that is not contiguous, in terms of sequence numbers, with data it has received previously.
In such cases, the TCP receiver is said to have holes in its received data queue.
A receiving TCP prevents applications from consuming data beyond a hole because of the byte stream abstraction it provides.
If a TCP sender were able to learn of the existence of holes (and out-of- sequence data blocks beyond holes in the sequence space) at the receiver,
it could better select which particular TCP segments to retransmit when segments are lost or otherwise missing at the receiver.
The TCP selective acknowledgment (SACK) options [RFC2018][RFC2883] provide this capability.
The scheme works effec- tively, however, only if the TCP sender logic is able to make effective use of the SACK information it receives from a SACK-capable receiver.
A TCP learns that its peer is capable of advertising SACK information by receiving the SACK-Permitted option in a SYN (or SYN + ACK) segment.
SACK information contained in a SACK option consists of a range of sequence numbers representing data blocks the receiver has successfully received.
Each range is called a SACK block and is represented by a pair of 32-bit sequence numbers.
Thus, a SACK option containing n SACK blocks is (8n + 2) bytes long. Two bytes are used to hold the kind and length of the SACK option.
Because of the limited amount of space available in the option space of a TCP header, the maximum number of SACK blocks available to be sent in a single seg- ment is three
Window Scale (WSCALE or WSOPT) Option
The Window Scale option (denoted WSCALE or WSOPT) [RFC1323] effectively increases the capacity of the TCP Window Advertisement field from 16 to about 30 bits.
Instead of changing the field size, however, the header still holds a 16-bit value, and an option is defined that applies a scaling factor to the 16-bit value.
This factor effectively left-shifts the window field value by the scale factor.
The 1-byte shift count is between 0 and 14 (inclusive).
The maximum scale value of 14 provides for a maximum window of 1,073,725,440 bytes (65,535 × 214), close to 1,073,741,823 (230 −1), effectively 1GB.
TCP then maintains the “real” window size internally as a 32-bit value.
This option can appear only in a SYN segment, so the scale factor is fixed in each direction when the connection is established.
To enable window scaling, both ends must send the option in their SYN segments.
The end doing the active open sends the option in its SYN, but the end doing the passive open can send the option only if the received SYN specifies the option.
The scale factor can be differ- ent in each direction.
If the end doing the active open sends a nonzero scale factor but does not receive a Window Scale option from the other end, it sets its send and receive scale values to 0.
This lets systems that do not understand the option interoperate with systems that do.
The shift count is automatically chosen by TCP, based on the size of the receive buffer.
The size of this buffer is set by the system, but the capability is normally provided for the application to change it.
The Window Scale option is most relevant when TCP is used to provide bulk data transfer over networks with large-bandwidth-delay products (i.e., those with a product of round-trip time and bandwidth being relatively large).
Timestamps Option and Protection against Wrapped Sequence Numbers (PAWS)
The Timestamps option (sometimes called the Timestamp option and written as TSOPT or TSopt) lets the sender place two 4-byte timestamp values in every seg- ment.
The receiver reflects these values in the acknowledgment, allowing the sender to calculate an estimate of the connection’s RTT for each ACK received.
When using the Timestamps option, the sender places a 32-bit value in the Timestamp Value field (called TSV or TSval) in the first part of the TSOPT,
and the receiver echoes this back unchanged in the second Timestamp Echo Retry field (called TSER or TSecr). 【relative meaning】
The main reason for wishing to calculate a good estimate of the connection’s RTT is to set the retransmission timeout, which tells TCP when it should try resending a segment that is likely lost.
Prior to the creation of the Timestamps option, most TCPs would perform just one RTT sample per window of data.
With the Timestamps option, more samples can be taken, leading to the potential of a better RTT estimate
...
We say “for that purpose” because although the Timestamps option allows for more frequent RTT samples,
it also provides a way for the receiver to avoid receiving old segments and considering them as valid.
This is called Protection Against Wrapped Sequence Numbers (PAWS)
The 32-bit Sequence Number field wraps between times D and E.
We assume that one segment gets lost at time B and is retransmitted. We also assume that this lost segment reappears at time F.
This assumes that the time difference between the segment getting lost and reappearing is less than the maximum time a seg- ment can live in the network (called the MSL; see Section 13.5.2);
otherwise the segment would have been discarded by some router when its TTL expired.
As we mentioned earlier, it is only with relatively high-speed connections that this prob- lem appears, where old segments can reappear and contain sequence numbers currently being transmitted.
We can also see from Table 13-2 that using the Timestamps option prevents this problem.
The receiver considers the timestamp as a 32-bit extension of the sequence number.
Because the lost segment that reappears at time F has a time- stamp of 2, which is less than the most recent valid timestamp (5 or 6), it is dis- carded by the PAWS algorithm.
The PAWS algorithm does not require any form of time synchronization between the sender and the receiver.
All the receiver needs is for the timestamp values to be monotonically increasing, and to increase by at least 1 per window of data.
User Timeout (UTO) Option
The UTO value (also called USER_TIMEOUT) specifies the amount of time a TCP sender is willing to wait for an ACK of outstanding data before con- cluding that the remote end has failed.
USER_TIMEOUT has traditionally been a local configuration parameter for TCP [RFC0793].
The UTO option allows one TCP to signal its USER_TIMEOUT value to its connection peer.
This allows the receiv- ing TCP to adjust its behavior (e.g., to tolerate a longer period of disrupted con- nectivity prior to aborting a connection).
UTO option values are advisory; just because one end of a connection might wish to use a large or small UTO value does not mean that the other end needs to comply.
UTO options are included on SYN segments when a connection is estab- lished,
on the first non-SYN segments, and whenever the USER_TIMEOUT value is changed.
As a relatively new option, it is not yet widely deployed.
Authentication Option (TCP-AO)
There is an option used to enhance the security of TCP connections.
Path MTU Discovery with TCP
MTU concept(TODO)
TCP State Transitions
TCP State Transition Diagram
States are indicated by ovals and transitions between states by arrows