| 11 | 6 | CC | RFC 1644 | |
| 12 | 6 | CC.NEW | RFC 1644 | |
| 13 | 6 | CC.ECHO | RFC 1644 | |
| 14 | 3 | Alternate Checksum Request | RFC 1146 | |
| 15 | N | Alternate Checksum Data | RFC 1146 | |
| 16 | | Skeeter | | |
| 17 | | Bubba | | |
| 18 | 3 | Trailer Checksum Option | | |
| 19 | 18 | MD5 Signature Option | RFC 2385 | |
| 20 | | SCPS Capabilities | | |
| 21 | | Selective Negative Acks | | |
| 22 | | Record Boundaries | | |
| 23 | | Corruption experienced | | |
| 24 | | SNAP | | |
| 25 | | Unassigned (released 12/18/00) | | |
| 26 | | TCP Compression Filter | | |
+----+-------+------------------------------------+----------+-----+
Figure 12. Common TCP Options
The ’use’ column is marked with ’*’ to indicate options that are most
likely to be seen in TCP flows. Also note that RFC 1072 [4] has been
obsoleted by RFC 1323 [7], although the original bit usage is defined
only in RFC 1072.
4.3.2. Option Field Behavior
Generally speaking, all option fields have been classified as
changing. This section describes the behavior of each option
referenced within an RFC, listed by ’kind’ indicator.
0: End of Option List
This option code indicates the end of the option list. This
might not coincide with the end of the TCP header according to
the Data Offset field. This is used at the end of all options,
not at the end of each option, and it need only be used if the
end of the options would not otherwise coincide with the end of
the TCP header. Defined in RFC 793 [2].
There is no data associated with this option, so a compression
scheme must simply be able to encode its presence. However,
note that since this option marks the end of the list and the
TCP options are 4-octet aligned, there may be octets of padding
(defined to be ’0’ in [2]) after this option.
1: No-Operation
This option code may be used between options, for example, to
align the beginning of a subsequent option on a word boundary.
There is no guarantee that senders will use this option, so
receivers must be prepared to process options even if they do
not begin on a word boundary RFC 793 [2]. There is no data
associated with this option, so a compression scheme must
simply be able to encode its presence. This may be done by
noting that the option simply maintains a certain alignment and
that compression need only convey this alignment. In this way,
padding can just be removed.
2: Maximum Segment Size
If this option is present, then it communicates the maximum
segment size that may be used to send a packet to this end-
host. This field must only be sent in the initial connection
request (i.e., in segments with the SYN control bit set). If
this option is not used, any segment size is allowed RFC 793
[2].
This option is very common. The segment size is a 16-bit
quantity. Theoretically, this could take any value; however
there are a number of values that are common. For example,
1460 bytes is very common for TCP/IPv4 over Ethernet (though
with the increased prevalence of tunnels, for example, smaller
values such as 1400 have become more popular). 536 bytes is the
default MSS value. This may allow for common values to be
encoded more efficiently.
3: Window Scale Option (WSopt)
This option may be sent in a SYN segment by the TCP end-host
(1) to indicate that the sending TCP end-host is prepared to
perform both send and receive window scaling, and
(2) to communicate a scale factor to be applied to its receive
window.
The scale factor is encoded logarithmically as a power of 2
(presumably to be implemented by binary shifts). Note that the
window in the SYN segment itself is never scaled (RFC 1072
[4]). This option may be sent in an initial segment (i.e., in
a segment with the SYN bit on and the ACK bit off). It may
also be sent in later segments, but only if a Window Scale
option was received in the initial segment. A Window Scale
option in a segment without a SYN bit should be ignored. The
Window field in a SYN segment itself is never scaled (RFC 1323
[7]).
The use of window scaling does not affect the encoding of any
other field during the lifetime of the flow. Only the encoding
of the window scaling option itself is important. The window
scale must be between 0 and 14 (inclusive). Generally, smaller
values would be expected (a window scale of 14 allows for a
1Gbyte window, which is extremely large).
4: SACK-Permitted
This option may be sent in a SYN by a TCP that has been
extended to receive (and presumably to process) the SACK option
once the connection has opened RFC 2018 [12]. There is no data
in this option all that is required is for the presence of the
option to be encoded.
5: SACK
This option is to be used to convey extended acknowledgment
information over an established connection. Specifically, it
is to be sent by a data receiver to inform the data transmitter
of non-contiguous blocks of data that have been received and
queued. The data receiver awaits the receipt of data in later
retransmissions to fill the gaps in sequence space between
these blocks. At that time, the data receiver acknowledges the
data, normally by advancing the left window edge in the
Acknowledgment Number field of the TCP header. It is important
to understand that the SACK option will not change the meaning
of the Acknowledgment Number field, whose value will still
specify the left window edge, i.e., one byte beyond the last
sequence number of fully received data (RFC 2018 [12]).
If SACK has been negotiated (through an exchange of SACK-
Permitted options), then this option may occur when dropped
segments are noticed by the receiver. Because this identifies
ranges of blocks within the receiver’s window, it can be viewed
as a base value with a number of offsets. The base value (left
edge of the first block) can be viewed as offset from the TCP
acknowledgement number. There can be up to 4 SACK blocks in a
single option. SACK blocks may occur in a number of segments
(if there is more out-of-order data ’on the wire’), and this
will typically extend the size of or add to the existing
blocks.
Alternative proposals such as DSACK RFC 2883 [17] do not
fundamentally change the behavior of the SACK block, from the
point of view of the information contained within it.
6: Echo
This option carries information that the receiving TCP may send
back in a subsequent TCP Echo Reply option (see below). A TCP
may send the TCP Echo option in any segment, but only if a TCP
Echo option was received in a SYN segment for the connection.
When the TCP echo option is used for RTT measurement, it will
be included in data segments, and the four information bytes
will define the time at which the data segment was transmitted
in any format convenient to the sender (see RFC 1072 [4]).
The Echo option is generally not used in practice -- it is
obsoleted by the Timestamp option. However, for transparency
it is desirable that a compression scheme be able to transport
it. (However, there is no benefit in attempting any treatment
more sophisticated than viewing it as a generic ’option’).
7: Echo Reply
A TCP that receives a TCP Echo option containing four
information bytes will return these same bytes in a TCP Echo
Reply option. This TCP Echo Reply option must be returned in
the next segment (e.g., an ACK segment) that is sent. If more
than one Echo option is received before a reply segment is
sent, the TCP must choose only one of the options to echo,
ignoring the others; specifically, it must choose the newest
segment with the oldest sequence number (see RFC 1072 [4]).
The Echo Reply option is generally not used in practice -- it
is obsoleted by the Timestamp option. However, for
transparency it is desirable that a compression scheme be able
to transport it. (However, there is no benefit in attempting
any more sophisticated treatment than viewing it as a generic
’option’).
8: Timestamps
This option carries two 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 bit is set in
the TCP header; if it is valid, it echoes a timestamp value
that was sent by the remote TCP in the TSval field of a
Timestamps option. When TSecr is not valid, its value must be
zero. The TSecr value will generally be from the most recent
Timestamp option that was received; however, there are
exceptions that are explained below. A TCP may send the
Timestamps option (TSopt) in an initial segment (i.e., a
segment containing a SYN bit and no ACK bit), and it may send a
TSopt in other segments only if it received a TSopt in the
initial segment for the connection (see RFC 1323 [7]).
Timestamps are quite commonly used. If timestamp options are
exchanged in the connection set-up phase, then they are
expected to appear on all subsequent segments. If this
exchange does not happen, then they will not appear for the
remainder of the flow.
Because the value being carried is a timestamp, it is logical
to expect that the entire value need not be carried. There is
no obvious pattern of increments that might be expected,
however.
An important reason for using the timestamp option is to allow
detection of sequence space wrap-around (Protection Against
Wrapped Sequence-number, or PAWS, see RFC 1323 [7]). It is not
expected that this is a serious concern on the links on which
TCP header compression would be deployed, but it is important
that the integrity of this option be maintained. This issue is
discussed in, for example, RFC 3150 [32]. However, the
proposed Eifel algorithm [35] makes use of timestamps, so it is
currently recommended that timestamps be used for cellular-type
links [34].
With regard to compression, note that the range of resolutions
for the timestamp suggested in RFC 1323 [7] is quite wide (1ms
to 1s per ’tick’). This (along with the perhaps wide variation
in RTT) makes it hard to select a set of encodings that will be
optimal in all cases.
9: Partial Order Connection (POC) permitted
This option represents a simple indicator communicated between
the two peer transport entities to establish the operation of
the POC protocol. See RFC 1693 [9].
The Partial Order Connection option sees little (or no) use in
the current Internet, so the only requirement is that the
header compression scheme be able to encode it.
10: POC service profile
This option serves to communicate the information necessary to
carry out the job of the protocol -- the type of information
that is typically found in the header of a TCP segment. The
Partial Order Connection option sees little (or no) use in the
current Internet, so the only requirement is that the header
compression scheme be able to encode it.
11: Connection Count (CC)
This option is part of the implementation of TCP Accelerated
Open (TAO) that effectively bypasses the TCP Three-Way
Handshake (3WHS). TAO introduces a 32-bit incarnation number,
called a "connection count" (CC), that is carried in a TCP
option in each segment. A distinct CC value is assigned to
each direction of an open connection. The implementation
assigns monotonically increasing CC values to successive
connections that it opens actively or passively (see RFC 1644
[8]). This option sees little (or no) use in the current
Internet, so the only requirement is that the header
compression scheme be able to encode it.
12: CC.NEW
Correctness of the TAO mechanism requires that clients generate
monotonically increasing CC values for successive connection
initiations. Receiving a CC.NEW causes the server to
invalidate its cache entry and to do a 3WHS. See RFC 1644 [8].
This option sees little (or no) use in the current Internet, so
the only requirement is that the header compression scheme be
able to encode it.
13: CC.ECHO
When a server host sends a segment, it echoes the connection
count from the initial in a CC.ECHO option, which is used by
the client host to validate the segment (see RFC 1644 [8]).
This option sees little (or no) use in the current Internet, so
the only requirement is that the header compression scheme be
able to encode it.
14: Alternate Checksum Request
This option may be sent in a SYN segment by a TCP to indicate
that the TCP is prepared to both generate and receive checksums
based on an alternate algorithm. During communication, the
alternate checksum replaces the regular TCP checksum in the
checksum field of the TCP header. Should the alternate
checksum require more than 2 octets to transmit, either the
checksum may be moved into a TCP Alternate Checksum Data Option
and the checksum field of the TCP header be sent as zero, or
the data may be split between the header field and the option.
Alternate checksums are computed over the same data as the
regular TCP checksum; see RFC 1146 [5].
This option sees little (or no) use in the current Internet, so
the only requirement is that the header compression scheme be
able to encode it. It would only occur in connection set-up
(SYN) packets. Even if this option were used, it would not
affect the handling of the checksum, since this should be
carried transparently in any case.
15: Alternate Checksum Data
This field is used only when the alternate checksum that is
negotiated is longer than 16 bits. These checksums will not
fit in the checksum field of the TCP header and thus at least
part of them must be put in an option. Whether the checksum is
split between the checksum field in the TCP header and the
option or the entire checksum is placed in the option is
determined on a checksum-by-checksum basis. The length of this
option will depend on the choice of alternate checksum
algorithm for this connection; see RFC 1146 [5].
If an alternative checksum was negotiated in the connection
set-up, then this option may appear on all subsequent packets
(if needed to carry the checksum data). However, this option
is in practice never seen, so the only requirement is that the
header compression scheme be able to encode it.
16 - 18:
These non-RFC option types are not considered in this document.
19: MD5 Digest
Every segment sent on a TCP connection to be protected against
spoofing will contain the 16-byte MD5 digest produced by
applying the MD5 algorithm to a concatenated block of data
[13].
Upon receiving a signed segment, the receiver must validate it
by calculating its own digest from the same data (using its own
key) and comparing the two digests. A failing comparison must
result in the segment’s being dropped and must not produce any
response back to the sender. Logging the failure is probably
advisable.
Unlike other TCP extensions (e.g., the Window Scale option
[7]), the absence of the option in the SYN-ACK segment must not
cause the sender to disable its sending of signatures. This
negotiation is typically done to prevent some TCP
implementations from misbehaving upon receiving options in non-
SYN segments. This is not a problem for this option, since the
SYN-ACK sent during connection negotiation will not be signed
and will thus be ignored. The connection will never be made,
and non-SYN segments with options will never be sent. More
importantly, the sending of signatures must be under the
complete control of the application, not at the mercy of a
remote host not understanding the option. MD5 digest
information should, like any cryptographically secure data, be
incompressible. Therefore the compression scheme must simply
transparently carry this option, if it occurs.
20 - 26;
Thse non-RFC option types are not considered in this document.
This only means that their behavior is not described in detail,
as a compression scheme is not expected to be optimised for
these options. However, any unrecognised option must be
carried by a TCP compression scheme transparently, in order to
work efficiently in the presence of new or rare options.
The above list covers options known at the time of writing. Other
options are expected to be defined. It is important that any future
options can be handled by a header compression scheme. The
processing of as-yet undefined options cannot be optimised but, at
the very least, unknown options should be carried transparently.
The current model for TCP options is that an option is negotiated in
the SYN exchange and used thereafter, if the negotiation succeeds.
This leads to some assumptions about the presence of options (being
only on packets with the SYN flag set, or appearing on every packet,
for example). Where such assumptions hold true, it may be possible
to optimise compression of options slightly. However, it is seen as
undesirable to be so constrained, as there is no guarantee that
option handling and negotiation will remain the same in the future.
Also note that a compressor may not process the SYN packets of a flow
and cannot, therefore, be assumed to know which options have been
negotiated.
5. Other Observations
5.1. Implicit Acknowledgements
There may be a small number of cues for ’implicit acknowledgements’
in a TCP flow. Even if the compressor only sees the data transfer
direction, for example, seeing a packet without the SYN flag set
implies that the SYN packet has been received.
There is a clear requirement for the deployment of compression to be