One document matched: draft-ietf-tcpm-1323bis-21.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC1191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1191.xml">
<!-- update to latest TCP congestion control RFC -->
<!ENTITY RFC4821 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4821.xml">
<!ENTITY RFC1981 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1981.xml">
<!ENTITY RFC2581 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2581.xml">
<!ENTITY RFC5681 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5681.xml">
<!ENTITY RFC2675 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2675.xml">
<!ENTITY RFC1122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC2883 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2883.xml">
<!ENTITY RFC4015 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4015.xml">
<!ENTITY RFC4963 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4963.xml">
<!ENTITY RFC1072 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1072.xml">
<!ENTITY RFC1185 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1185.xml">
<!ENTITY RFC1323 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1323.xml">
<!ENTITY RFC2018 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2018.xml">
<!ENTITY RFC1110 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1110.xml">
<!ENTITY RFC0896 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0896.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3522 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3522.xml">
<!ENTITY RFC6191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6191.xml">
<!ENTITY RFC6298 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6298.xml">
<!ENTITY RFC5961 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5961.xml">
<!ENTITY RFC6528 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6528.xml">
<!ENTITY RFC6675 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6675.xml">
<!ENTITY RFC6691 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6691.xml">
<!ENTITY RFC6817 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6817.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std"
obsoletes="1323"
docName="draft-ietf-tcpm-1323bis-21"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title>TCP Extensions for High Performance</title>
<!-- <title>TCP options for Window Scaling and Timestamps</title> -->
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="David Borman"
initials="D."
surname="Borman">
<organization>Quantum Corporation</organization>
<address>
<postal>
<street></street>
<city>Mendota Heights</city>
<code>MN 55120</code>
<country>USA</country>
</postal>
<email>david.borman@quantum.com</email>
</address>
</author>
<author fullname="Bob Braden"
initials="B."
surname="Braden">
<organization>University of Southern California</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<code>CA 90292</code>
<country>USA</country>
</postal>
<email>braden@isi.edu</email>
</address>
</author>
<author fullname="Van Jacobson"
initials="V."
surname="Jacobson">
<organization>Google, Inc.</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<code>CA 94043</code>
<country>USA</country>
</postal>
<email>vanj@google.com</email>
</address>
</author>
<author fullname="Richard Scheffenegger"
initials="R."
surname="Scheffenegger"
role="editor">
<organization>NetApp, Inc.</organization>
<address>
<postal>
<street>Am Euro Platz 2</street>
<code>1120</code>
<city>Vienna</city>
<region></region>
<country>Austria</country>
</postal>
<email>rs@netapp.com</email>
</address>
</author>
<date year="2014" />
<area>Transport</area>
<workgroup>TCP Maintenance (TCPM)</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>I-D</keyword>
<abstract>
<t>This document specifies a set of TCP extensions to improve
performance over paths with a large bandwidth * delay product and to
provide reliable operation over very high-speed paths. It defines
the TCP Window Scale (WS) option and the TCP Timestamps (TS) option
and their semantics. The Window Scale option is used to support
larger receive windows, while the Timestamps option can be used for
at least two distinct mechanisms, PAWS (Protection Against Wrapped
Sequences) and RTTM (Round Trip Time Measurement), that are also
described herein. </t>
<t>This document obsoletes RFC1323 and describes changes from it.
</t>
</abstract>
</front>
<middle>
<section anchor="sec1" title="Introduction">
<t>The TCP protocol <xref target="RFC0793"/> was designed to operate
reliably over almost any transmission medium regardless of transmission
rate, delay, corruption, duplication, or reordering of segments. Over the
years, advances in networking technology have resulted in ever-higher
transmission speeds, and the fastest paths are well beyond the domain for
which TCP was originally engineered.
</t>
<t>This document defines a set of modest extensions to TCP to extend the
domain of its application to match the increasing network capability. It
is an update to and obsoletes <xref target="RFC1323"/>, which in turn is
based upon and obsoletes <xref target="RFC1072"/> and <xref
target="RFC1185"/>.
</t>
<t>Changes between <xref target="RFC1323"/> and this document are detailed
in <xref target="AppC"/>. These changes are partly due to errata in
<xref target="RFC1323"/>, and partly due to the improved understanding
of how the involved components interact.</t>
<t>For brevity, the full discussions of the merits and history behind the
TCP options defined within this document have been omitted. <xref
target="RFC1323"/> should be consulted for reference. It is recommended
that a modern TCP stack implements and make use of the extensions
described in this document.
</t>
<section anchor="sec11" title="TCP Performance">
<t>TCP performance problems arise when the bandwidth * delay product is
large. A network having such paths is referred to as "long, fat network"
(LFN).
</t>
<t>There are two fundamental performance problems with basic TCP over LFN
paths:
<list style="format (%d)">
<t>Window Size Limit
<vspace blankLines="1"/>
The TCP header uses a 16 bit field to report the receive window size
to the sender. Therefore, the largest window that can be used is
2^16 = 64 KiB. For LFN paths where the bandwidth * delay product
exceeds 64 KiB, the receive window limits the maximum throughput of
the TCP connection over the path, i.e., the amount of unacknowledged
data that TCP can send in order to keep the pipeline full.
<vspace blankLines="1"/>
To circumvent this problem, <xref target="sec2"/> of this memo defines a TCP
option, "Window Scale", to allow windows larger than 2^16. This
option defines an implicit scale factor, which is used to multiply
the window size value found in a TCP header to obtain the true
window size.
<vspace blankLines="1"/>
It must be noted, that the use of large receive windows increases
the chance of too quickly wrapping sequence numbers, as described
below in <xref target="sec12"/>, (1).
</t>
<t>Recovery from Losses
<vspace blankLines="1"/>
Packet losses in an LFN can have a catastrophic effect on
throughput.
<vspace blankLines="1"/>
To generalize the Fast Retransmit / Fast Recovery mechanism to handle
multiple packets dropped per window, Selective Acknowledgments are
required. Unlike the normal cumulative acknowledgments of TCP,
Selective Acknowledgments give the sender a complete picture of
which segments are queued at the receiver and which have not yet
arrived.
<vspace blankLines="1"/>
Selective acknowledgments and their use are specified in separate
documents, "TCP Selective Acknowledgment options" <xref
target="RFC2018"/>, "An Extension to the Selective Acknowledgement
(SACK) option for TCP" <xref target="RFC2883"/>, and "A Conservative
Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for
TCP" <xref target="RFC6675"/>, and not further discussed in this
document.
</t>
</list>
</t>
</section>
<section anchor="sec12" title="TCP Reliability">
<t>An especially serious kind of error may result from an accidental reuse
of TCP sequence numbers in data segments. TCP reliability depends upon
the existence of a bound on the lifetime of a segment: the "Maximum
Segment Lifetime" or MSL.
</t>
<t>Duplication of sequence numbers might happen in either of two ways:
<list style="format (%d)">
<t>Sequence number wrap-around on the current connection
<vspace blankLines="1"/>
A TCP sequence number contains 32 bits. At a high enough transfer
rate of large volumes of data (at least 4 GiB in the same session),
the 32-bit sequence space may be "wrapped" (cycled) within the
time that a segment is delayed in queues.
</t>
<t>Earlier incarnation of the connection
<vspace blankLines="1"/>
Suppose that a connection terminates, either by a proper close
sequence or due to a host crash, and the same connection (i.e.,
using the same pair of port numbers) is immediately reopened. A
delayed segment from the terminated connection could fall within the
current window for the new incarnation and be accepted as valid.
</t>
</list>
</t>
<t>Duplicates from earlier incarnations, case (2), are avoided by
enforcing the current fixed MSL of the TCP specification, as explained
in <xref target="sec43"/> and <xref target="AppB"/>. In addition, the
randomizing of ephemeral ports can also help to probabilistically reduce
the chances of duplicates from earlier connections. However, case
(1), avoiding the reuse of sequence numbers within the same connection,
requires an upper bound on MSL that depends upon the transfer rate, and
at high enough rates, a dedicated mechanism is required.
</t>
<t>A possible fix for the problem of cycling the sequence space would be
to increase the size of the TCP sequence number field. For example, the
sequence number field (and also the acknowledgment field) could be
expanded to 64 bits. This could be done either by changing the TCP
header or by means of an additional option.
</t>
<t><xref target="sec4"/> presents a different mechanism, which we call
PAWS (Protection Against Wrapped Sequence numbers), to extend TCP
reliability to transfer rates well beyond the foreseeable upper limit of
network bandwidths. PAWS uses the TCP Timestamps option defined in
<xref target="sec32"/> to protect against old duplicates from the same
connection.
</t>
</section>
<section anchor="sec13" title="Using TCP options">
<t>The extensions defined in this document all use TCP options.
</t>
<t>When <xref target="RFC1323"/> was published, there was concern that
some buggy TCP implementation might crash on the first appearance
of an option on a non-<SYN> segment. However, bugs like that can
lead to DOS attacks against a TCP. Research has shown that most TCP
implementations will properly handle unknown options on non-<SYN>
segments (<xref target="Medina04"/>, <xref target="Medina05"/>). But it
is still prudent to be conservative in what you send, and avoiding buggy
TCP implementation is not the only reason for negotiating TCP options on
<SYN> segments.
</t>
<t>The window scale option negotiates fundamental parameters of the TCP
session. Therefore, it is only sent during the initial handshake.
Furthermore, the window scale option will be sent in a <SYN,ACK>
segment only if the corresponding option was received in the initial
<SYN> segment.
</t>
<t> The Timestamps option may appear in any data or <ACK> segment,
adding 10 bytes (up to 12 bytes including padding) to the 20-byte TCP
header. It is required that this TCP
option will be sent on all non-<SYN> segments after an exchange of
options on the <SYN> segments has indicated that both sides
understand this extension.
</t>
<t>Research has shown that the use of the Timestamps option to take
additional RTT samples within each RTT has little
effect on the ultimate retransmission timeout value <xref
target="Allman99"/>. However, there are other uses of the Timestamps
option, such as the Eifel mechanism <xref target="RFC3522"/>, <xref
target="RFC4015"/>, and PAWS (see <xref target="sec4"/>) which improve
overall TCP security and performance. The extra header bandwidth used by
this option should be evaluated for the gains in performance and
security in an actual deployment.
</t>
<t><xref target="AppA"/> contains a recommended layout of the options in
TCP headers to achieve reasonable data field alignment.
</t>
<t>Finally, we observe that most of the mechanisms defined in this
document are important for LFNs 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.
</t>
</section>
<section title="Terminology" anchor="secTerm">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
<t>In this document, these words will appear with that interpretation only
when in UPPER CASE. Lower case uses of these words are not to be
interpreted as carrying <xref target="RFC2119"/> significance.
<vspace blankLines="30"/>
</t>
</section>
</section>
<section anchor="sec2" title="TCP Window Scale option">
<section anchor="sec21" title="Introduction">
<t>The window scale extension expands the definition of the TCP
window to 30 bits and then uses an implicit scale factor to
carry this 30-bit value in the 16-bit Window field of the TCP
header (SEG.WND in <xref target="RFC0793"/>). The exponent of
the scale factor is carried in a TCP option, Window Scale.
This option is sent only in a <SYN> segment (a segment
with the SYN bit on), hence the window scale is fixed in
each direction when a connection is opened.
</t>
<t>The maximum receive window, and therefore the scale factor, is
determined by the maximum receive buffer space. In a typical
modern implementation, this maximum buffer space is set by default
but can be overridden by a user program before a TCP connection is
opened. This determines the scale factor, and therefore no new
user interface is needed for window scaling.
</t>
</section>
<section anchor="sec22" title="Window Scale option">
<t>The three-byte Window Scale option MAY be sent in a <SYN>
segment by a TCP. It has two purposes: (1) indicate that the
TCP is prepared to both send and receive window scaling, and
(2) communicate the exponent of a scale factor to be applied to
its receive window. Thus, a TCP that is prepared to scale
windows SHOULD send the option, even if its own scale factor
is 1 and the exponent 0. The scale factor is limited to a power
of two and encoded logarithmically, so it may be implemented by
binary shift operations. The maximum scale exponent is limited
to 14 for a maximum permissible receive window size of 1 GiB
(2^(14+16)).
</t>
<t>
<figure align="left">
<preamble>TCP Window Scale option (WSopt):</preamble>
<artwork align="left"><![CDATA[
Kind: 3
Length: 3 bytes
+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+
1 1 1
]]></artwork>
</figure>
</t>
<t>This option is an offer, not a promise; both sides MUST send Window
Scale options in their <SYN> segments to enable window scaling in
either direction. If window scaling is enabled, then the TCP that sent
this option will right-shift its true receive-window values by
'shift.cnt' bits for transmission in SEG.WND. The value 'shift.cnt' MAY
be zero (offering to scale, while applying a scale factor of 1 to the
receive window).
</t>
<t>This option MAY be sent in an initial <SYN> segment (i.e., a
segment with the SYN bit on and the ACK bit off).
If a Window Scale option was received in the initial <SYN> segment,
then this option MAY be sent in the <SYN,ACK> segment.
<!-- It MAY also be sent
in a <SYN,ACK> segment, but only if a Window Scale option was
received in the initial <SYN> segment. -->
A Window Scale option in a
segment without a SYN bit MUST be ignored.
</t>
<t>The window field in a segment where the SYN bit is set (i.e., a
<SYN> or <SYN,ACK>) MUST NOT be scaled.
</t>
</section>
<section anchor="sec23" title="Using the Window Scale option">
<t>A model implementation of window scaling is as follows, using the
notation of <xref target="RFC0793"/>:
<list style="symbols">
<!--
<t>All windows MUST be treated as 32-bit quantities for storage in the
connection control block and for local calculations. This includes
the send-window (SND.WND) and the receive-window (RCV.WND) values,
as well as the congestion window.
</t>-->
<t>The connection state is augmented by two window shift counters,
Snd.Wind.Shift and Rcv.Wind.Shift, to be applied to the incoming and
outgoing window fields, respectively.
</t>
<t>If a TCP receives a <SYN> segment containing a Window Scale
option, it SHOULD send its own Window Scale option in the <SYN,ACK>
segment.
</t>
<t>The Window Scale option MUST be sent with shift.cnt = R, where R is the
value that the TCP would like to use for its receive window.
</t>
<t>Upon receiving a <SYN> segment with a Window Scale option
containing shift.cnt = S, a TCP MUST set Snd.Wind.Shift to S and MUST set
Rcv.Wind.Shift to R; otherwise, it MUST set both Snd.Wind.Shift and
Rcv.Wind.Shift to zero.
</t>
<t>The window field (SEG.WND) in the header of every incoming segment,
with the exception of <SYN> segments, MUST be left-shifted by
Snd.Wind.Shift bits before updating SND.WND:
<figure align="center">
<artwork align="center"><![CDATA[
SND.WND = SEG.WND << Snd.Wind.Shift
]]></artwork>
</figure>
(assuming the other conditions of <xref target="RFC0793"/> are met,
and using the "C" notation "<<" for left-shift).
</t>
<t>The window field (SEG.WND) of every outgoing segment, with the
exception of <SYN> segments, MUST be right-shifted by
Rcv.Wind.Shift bits:
<figure align="center">
<artwork align="center"><![CDATA[
SEG.WND = RCV.WND >> Rcv.Wind.Shift
]]></artwork>
</figure>
</t>
</list>
</t>
<t>TCP determines if a data segment is "old" or "new" by testing whether
its sequence number is within 2^31 bytes of the left edge of the window,
and if it is not, discarding the data as "old". To insure that new data
is never mistakenly considered old and vice versa, the left edge of the
sender's window has to be at most 2^31 away from the right edge of the
receiver's window. Similarly with the sender's right edge and receiver's
left edge. Since the right and left edges of either the sender's or
receiver's window differ by the window size, and since the sender and
receiver windows can be out of phase by at most the window size, the
above constraints imply that two times the maximum window size must be
less than 2^31, or
<figure align="center">
<artwork align="center"><![CDATA[
max window < 2^30
]]></artwork>
</figure>
</t>
<t>Since the max window is 2^S (where S is the scaling shift count) times
at most 2^16 - 1 (the maximum unscaled window), the maximum window is
guaranteed to be < 2^30 if S <= 14. Thus, the shift count MUST be
limited to 14 (which allows windows of 2^30 = 1 GiB). If a Window Scale
option is received with a shift.cnt value larger than 14, the TCP SHOULD
log the error but MUST use 14 instead of the specified value. This is
safe as a sender can always choose to only partially use any signaled
receive window. If the receiver is scaling by a factor larger than 14 and
the sender is only scaling by 14 then the receive window used by the
sender will appear smaller than it is in reality.
</t>
<t>The scale factor applies only to the Window field as transmitted in the
TCP header; each TCP using extended windows will maintain the window
values locally as 32-bit numbers. For example, the "congestion window"
computed by Slow Start and Congestion Avoidance (see <xref
target="RFC5681"/>) is not affected by the scale factor, so window
scaling will not introduce quantization into the congestion window.
</t>
</section>
<section anchor="sec24" title="Addressing Window Retraction">
<t>When a non-zero scale factor is in use, there are instances when a
retracted window can be offered - see <xref target="AppH"/> for a
detailed example. The end of the window will be on a boundary based on
the granularity of the scale factor being used. If the sequence number
is then updated by a number of bytes smaller than that granularity, the
TCP will have to either advertise a new window that is beyond what it
previously advertised (and perhaps beyond the buffer), or will have to
advertise a smaller window, which will cause the TCP window to shrink.
Implementations MUST ensure that they handle a shrinking window, as
specified in section 4.2.2.16 of <xref target="RFC1122"/>.
</t>
<t>For the receiver, this implies that:
<list style="format %d)" counter="WinRetract">
<t>The receiver MUST honor, as in-window, any segment that would have
been in-window for any <ACK> sent by the receiver.
</t>
<t>When window scaling is in effect, the receiver SHOULD track the
actual maximum window sequence number (which is likely to be greater
than the window announced by the most recent <ACK>, if more
than one segment has arrived since the application consumed any data
in the receive buffer).
</t>
</list>
On the sender side:
<list style="format %d)" counter="WinRetract">
<t>The initial transmission MUST be within the window announced by the
most recent <ACK>.
</t>
<t>On first retransmission, or if the sequence number is out-of-window
by less than 2^Rcv.Wind.Shift then do normal retransmission(s)
without regard to receiver window as long as the original segment
was in window when it was sent.
</t>
<t>Subsequent retransmissions MAY only be sent, if they are within the
window announced by the most recent <ACK>.
</t>
</list>
<vspace blankLines="30"/>
</t>
</section>
</section>
<section anchor="sec3" title="TCP Timestamps option">
<section anchor="sec31" title="Introduction">
<t>The Timestamps option is introduced to address some of the issues
mentioned in <xref target="sec11"/> and <xref target="sec12"/>.
The Timestamps option is specified in a symmetrical manner, so that
TSval timestamps
are carried in both data and <ACK> segments and are echoed in
TSecr fields carried in returning <ACK> or data segments.
Originally used primarily for timestamping individual segments, the
properties of the Timestamps option allow not only the use for taking time
measurements (<xref target="sec33"/>), but additional
uses as well (<xref target="sec4"/>).
</t>
<t>It is necessary to remember that there is a distinction between the
Timestamps option conveying timestamp information, and the use of that
information. In particular, the Round Trip Time Measurement (RTTM)
mechanism must be viewed independently from updating the Retransmission
Timeout (RTO) (see <xref target="sec331"/>). In this case, the sample
granularity also needs to be taken into account. Other mechanisms, such
as PAWS, or Eifel, are not built upon the timestamp information itself,
but are based on the intrinsic property of monotonically non-decreasing values.
</t>
<t>The Timestamps option is important when large receive windows are used,
to allow the use of the PAWS mechanism (see <xref target="sec4"/>).
Furthermore, the option may be useful for all TCPs, since it simplifies the
sender and allows the use of additional optimizations such as Eifel
(<xref target="RFC3522"/>, <xref target="RFC4015"/>) and others
(<xref target="RFC6817"/>, <xref target="Kuzmanovic03"/>, <xref target="Kuehlewind10"/>.
</t>
</section>
<section anchor="sec32" title="Timestamps option">
<t>TCP is a symmetric protocol, allowing data to be sent at any time in
either direction, and therefore timestamp echoing may occur in either
direction. For simplicity and symmetry, we specify that timestamps
always be sent and echoed in both directions. For efficiency, we
combine the timestamp and timestamp reply fields into a single TCP
Timestamps option.
</t>
<t>
<figure align="left">
<preamble>TCP Timestamps option (TSopt):</preamble>
<artwork align="left"><![CDATA[
Kind: 8
Length: 10 bytes
+-------+-------+---------------------+---------------------+
|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
+-------+-------+---------------------+---------------------+
1 1 4 4
]]></artwork>
</figure>
</t>
<t>The Timestamps 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.
</t>
<t>The Timestamp Echo Reply (TSecr) field is valid if the ACK bit
is set in the TCP header. If the ACK bit is not set in the
outgoing TCP header, the sender of that segment SHOULD set the
TSecr field to zero. When the ACK bit is set in an outgoing
segment, the sender MUST echo a recently received Timestamp Value (TSval) sent
by the remote TCP in the TSval field of a Timestamps option. The
exact rules on which TSval MUST be echoed are given in <xref
target="sec34"/>. When the ACK bit is not set, the receiver MUST
ignore the value of the TSecr field.
<!--
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. However, a value of zero does not imply TSecr being invalid.
The TSecr value will generally be from the most recent Timestamps
option that was received; however, there are exceptions that are
explained below.-->
</t>
<t>A TCP MAY send the Timestamps option (TSopt) in an initial
<SYN> segment (i.e., segment containing a SYN bit and no ACK
bit), and MAY send a TSopt in <SYN,ACK> only if it received a
TSopt in the initial <SYN> segment for the connection.
</t>
<t>Once TSopt has been successfully negotiated, that is both
<SYN>, and <SYN,ACK> contain TSopt, the TSopt MUST be
sent in every non-<RST> segment for the duration of the
connection, and SHOULD be sent in an <RST> segment (see
<xref target="sec42"/> for details). The TCP SHOULD remember this
state by setting a flag, referred to as Snd.TS.OK, to one. If a non-<RST> segment
is received without a TSopt, a TCP SHOULD silently drop the
segment. A TCP MUST NOT abort a TCP connection because any segment
lacks an expected TSopt.
</t>
<t>Implementations are strongly encouraged to follow the above
rules for handling a missing Timestamps option, and the order of
precedence mentioned in <xref target="sec421"/> when deciding on
the acceptance of a segment.
</t>
<t>If a receiver chooses to accept a segment without an expected
Timestamps option, it must be clear that undetectable data
corruption may occur.
</t>
<t>Such a TCP receiver may experience undetectable wrapped-
sequence effects, such as data (payload) corruption or session
stalls. In order to maintain the integrity of the payload data, in
particular on high speed networks, it is paramount to follow the
described processing rules.
</t>
<t>However, it has been mentioned that under some circumstances,
the above guidelines are too strict, and some paths sporadically
suppress the Timestamps option, while maintaining payload
integrity. A path behaving in this manner should be deemed
unacceptable, but it has been noted that some implementations
relax the acceptance rules as a workaround, and allow TCP to run
across such paths <xref target="Oppermann13"/>
</t>
<t>If a TSopt is received on a connection where TSopt was not
negotiated in the initial three-way handshake, the TSopt MUST be
ignored and the packet processed normally.
</t>
<t>In the case of crossing <SYN> segments where one <SYN>
contains a TSopt and the other doesn't, both sides MAY send a TSopt in
the <SYN,ACK> segment.
</t>
<t>TSopt is required for the two mechanisms described in sections <xref
target="sec33" format="counter"/> and <xref target="sec4"
format="counter"/>. There are also other mechanisms that rely on the
presence of the TSopt, e.g. <xref target="RFC3522"/>. If a TCP stopped
sending TSopt at any time during an established session, it interferes
with these mechanisms. This update to <xref target="RFC1323"/>
describes explicitly the previous assumption (see <xref
target="sec42"/>), that each TCP segment must have TSopt, once
negotiated.
<vspace blankLines="30"/>
</t>
</section>
</section>
<section anchor="sec33" title="The RTTM Mechanism">
<section anchor="sec330" title="Introduction">
<t>One use of the Timestamps option is to measure the round trip time of
virtually every packet acknowledged. The Round Trip Time Measurement
(RTTM) mechanism requires a Timestamps option in every measured segment, with a TSval that is
obtained from a (virtual) "timestamp clock". Values of this clock MUST
be at least approximately proportional to real time, in order to measure
actual RTT.
</t>
<t>TCP measures the round trip time (RTT), primarily for the purpose of
arriving at a reasonable value for the Retransmission Timeout (RTO)
timer interval. Accurate and current RTT estimates are necessary to
adapt to changing traffic conditions, while a conservative estimate of
the RTO interval is necessary to minimize spurious RTOs.
</t>
<t>These TSval values are echoed in TSecr values in the reverse direction.
The difference between a received TSecr value and the current timestamp
clock value provides an RTT measurement.
</t>
<t>When timestamps are used, every segment that is received will contain a
TSecr value. However, these values cannot all be used to update the
measured RTT. The following example illustrates why. It shows a one-way
data flow with segments arriving in sequence without loss. Here A, B,
C... represent data blocks occupying successive blocks of sequence
numbers, and ACK(A),... represent the corresponding cumulative
acknowledgments. The two timestamp fields of the Timestamps option are
shown symbolically as <TSval=x,TSecr=y>. Each TSecr field
contains the value most recently received in a TSval field.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
TCP A TCP B
<A,TSval=1,TSecr=120> ----->
<---- <ACK(A),TSval=127,TSecr=1>
<B,TSval=5,TSecr=127> ----->
<---- <ACK(B),TSval=131,TSecr=5>
. . . . . . . . . . . . . . . . . . . . . .
<C,TSval=65,TSecr=131> ---->
<---- <ACK(C),TSval=191,TSecr=65>
(etc.)
]]></artwork>
</figure>
<t>The dotted line marks a pause (60 time units long) in which A had
nothing to send. Note that this pause inflates the RTT which B could
infer from receiving TSecr=131 in data segment C. Thus, in one-way data
flows, RTTM in the reverse direction measures a value that is inflated
by gaps in sending data. However, the following rule prevents a
resulting inflation of the measured RTT:
<list style="hanging" hangIndent="11">
<t hangText="RTTM Rule:"> A TSecr value received in a segment MAY be
used to update the averaged RTT measurement only if the segment
advances the left edge of the send window, i.e. SND.UNA is
increased.
</t>
</list>
</t>
<t>Since TCP B is not sending data, the data segment C does not
acknowledge any new data when it arrives at B. Thus, the inflated RTTM
measurement is not used to update B's RTTM measurement.
</t>
</section>
<section anchor="sec331" title="Updating the RTO value">
<t>When <xref target="RFC1323"/> was originally written, it was perceived
that taking RTT measurements for each segment, and also during
retransmissions, would contribute to reduce spurious RTOs, while
maintaining the timeliness of necessary RTOs. At the time, RTO was also
the only mechanism to make use of the measured RTT. It has been shown,
that taking more RTT samples has only a very limited effect to optimize
RTOs <xref target="Allman99"/>.
</t>
<t>Implementers should note that with timestamps multiple RTTMs can be
taken per RTT. The <xref target="RFC6298"/> RTO estimator has weighting
factors, alpha and beta, based on an implicit assumption that at most
one RTTM will be sampled per RTT. When multiple RTTMs per RTT are
available to update the RTO estimator, an implementation SHOULD try to
adhere to the spirit of the history specified in <xref target="RFC6298"/>.
An implementation suggestion is detailed in <xref target="AppI"/>.
</t>
<t><xref target="Ludwig00"/> and <xref target="Floyd05"/> have highlighted
the problem that an unmodified RTO calculation, which is updated with
per-packet RTT samples, will truncate the path history too soon. This
can lead to an increase in spurious retransmissions, when the path
properties vary in the order of a few RTTs, but a high number of RTT
samples are taken on a much shorter timescale.
</t>
</section>
<section anchor="sec34" title="Which Timestamp to Echo">
<t>If more than one Timestamps option is received before a reply segment
is sent, the TCP must choose only one of the TSvals to echo, ignoring
the others. To minimize the state kept in the receiver (i.e., the
number of unprocessed TSvals), the receiver should be required to retain
at most one timestamp in the connection control block.
</t>
<t>There are three situations to consider:
<list style="format (%C)">
<t>Delayed ACKs.
<vspace blankLines="1"/>
Many TCPs acknowledge only every second segment out of a group of
segments arriving within a short time interval; this policy is known
generally as "delayed ACKs". The data-sender TCP must measure the
effective RTT, including the additional time due to delayed ACKs, or
else it will retransmit unnecessarily. Thus, when delayed ACKs are
in use, the receiver SHOULD reply with the TSval field from the
earliest unacknowledged segment.
</t>
<t>A hole in the sequence space (segment(s) have been lost).
<vspace blankLines="1"/>
The sender will continue sending until the window is filled, and the
receiver may be generating <ACK>s as these out-of-order
segments arrive (e.g., to aid "fast retransmit").
<vspace blankLines="1"/>
The lost segment is probably a sign of congestion, and in that
situation the sender should be conservative about retransmission.
Furthermore, it is better to overestimate than underestimate the
RTT. An <ACK> for an out-of-order segment SHOULD therefore
contain the timestamp from the most recent segment that advanced
RCV.NXT.
<vspace blankLines="1"/>
The same situation occurs if segments are re-ordered by the network.
</t>
<t>A filled hole in the sequence space.
<vspace blankLines="1"/>
The segment that fills the hole and advances the window represents
the most recent measurement of the network characteristics. An RTT
computed from an earlier segment would probably include the sender's
retransmit time-out, badly biasing the sender's average RTT
estimate. Thus, the timestamp from the latest segment (which filled
the hole) MUST be echoed.
</t>
</list>
</t>
<t>An algorithm that covers all three cases is described in the following
rules for Timestamps option processing on a synchronized connection:
<list style="format (%d)">
<t>The connection state is augmented with two 32-bit slots:
<vspace blankLines="1"/>
TS.Recent holds a timestamp to be echoed in TSecr whenever a segment
is sent, and Last.ACK.sent holds the ACK field from the last segment
sent. Last.ACK.sent will equal RCV.NXT except when <ACK>s
have been delayed.
</t>
<t>If:
<figure align="center">
<artwork align="center"><![CDATA[
SEG.TSval >= TS.recent and SEG.SEQ <= Last.ACK.sent
]]></artwork>
</figure>
then SEG.TSval is copied to TS.Recent; otherwise, it is ignored.
</t>
<t>When a TSopt is sent, its TSecr field is set to the current
TS.Recent value.
</t>
</list>
</t>
<t>The following examples illustrate these rules. Here A, B, C...
represent data segments occupying successive blocks of sequence numbers,
and ACK(A),... represent the corresponding acknowledgment segments.
Note that ACK(A) has the same sequence number as B. We show only one
direction of timestamp echoing, for clarity.
<list style="symbols">
<t>Segments arrive in sequence, and some of the <ACK>s are
delayed.
<vspace blankLines="1"/>
By case (A), the timestamp from the oldest unacknowledged segment is
echoed.
<figure align="center">
<artwork align="center"><![CDATA[
TS.Recent
<A, TSval=1> ------------------->
1
<B, TSval=2> ------------------->
1
<C, TSval=3> ------------------->
1
<---- <ACK(C), TSecr=1>
(etc)
]]></artwork>
</figure>
</t>
<t>Segments arrive out of order, and every segment is acknowledged.
<vspace blankLines="1"/>
By case (B), the timestamp from the last segment that advanced the
left window edge is echoed, until the missing segment arrives; it is
echoed according to Case (C). The same sequence would occur if
segments B and D were lost and retransmitted.
<figure align="center">
<artwork align="center"><![CDATA[
TS.Recent
<A, TSval=1> ------------------->
1
<---- <ACK(A), TSecr=1>
1
<C, TSval=3> ------------------->
1
<---- <ACK(A), TSecr=1>
1
<B, TSval=2> ------------------->
2
<---- <ACK(C), TSecr=2>
2
<E, TSval=5> ------------------->
2
<---- <ACK(C), TSecr=2>
2
<D, TSval=4> ------------------->
4
<---- <ACK(E), TSecr=4>
(etc)
]]></artwork>
</figure>
</t>
</list>
<vspace blankLines="30"/>
</t>
</section>
</section>
<section anchor="sec4" title="PAWS - Protection Against Wrapped Sequence Numbers">
<section anchor="sec41" title="Introduction">
<t>Another use for the Timestamps options is the mechanism to Protect Against
Wrapped Sequence numbers (PAWS). <xref target="sec42"/> describes a
simple mechanism to reject old
duplicate segments that might corrupt an open TCP connection. PAWS
operates within a single TCP connection, using state that is saved in
the connection control block. <xref target="sec43"/> and <xref
target="AppC"/> discuss the implications of the PAWS mechanism for
avoiding old duplicates from previous incarnations of the same
connection.
</t>
</section>
<section anchor="sec42" title="The PAWS Mechanism">
<t>PAWS uses the TCP Timestamps option
described earlier, and assumes that every received TCP segment
(including data and <ACK> segments) contains a timestamp SEG.TSval
whose values are monotonically non-decreasing in time. The basic idea
is that a segment can be discarded as an old duplicate if it is received
with a timestamp SEG.TSval less than some timestamp recently received on
this connection.
</t>
<t>In the PAWS mechanism, the "timestamps" are 32-bit
unsigned integers in a modular 32-bit space. Thus, "less than" is
defined the same way it is for TCP sequence numbers, and the same
implementation techniques apply. If s and t are timestamp values,
<figure align="center">
<artwork align="center"><![CDATA[
s < t if 0 < (t - s) < 2^31,
]]></artwork>
</figure>
computed in unsigned 32-bit arithmetic.
</t>
<t>The choice of incoming timestamps to be saved for this comparison MUST
guarantee a value that is monotonically non-decreasing. For example, an implementation
might save the timestamp from the segment that last advanced the left
edge of the receive window, i.e., the most recent in-sequence segment.
For simplicity, the value TS.Recent introduced in <xref
target="sec34"/> is used instead, as using a common value for
both PAWS and RTTM simplifies the implementation. As <xref
target="sec34"/> explained, TS.Recent differs from the timestamp from
the last in-sequence segment only in the case of delayed <ACK>s,
and therefore by less than one window. Either choice will therefore
protect against sequence number wrap-around.
</t>
<t> PAWS
submits all incoming segments to the same test, and therefore protects
against duplicate <ACK> segments as well as data segments. (An
alternative non-symmetric algorithm would protect against old duplicate
<ACK>s: the sender of data would reject incoming <ACK>
segments whose TSecr values were less than the TSecr saved from the last
segment whose ACK field advanced the left edge of the send window. This
algorithm was deemed to lack economy of mechanism and symmetry.)
</t>
<t>TSval timestamps sent on <SYN> and <SYN,ACK> segments are
used to initialize PAWS. PAWS protects against old duplicate non-
<SYN> segments, and duplicate <SYN> segments received while
there is a synchronized connection. Duplicate <SYN> and
<SYN,ACK> segments received when there is no connection will be
discarded by the normal 3-way handshake and sequence number checks of
TCP.
</t>
<t><xref target="RFC1323"/> recommended that <RST> segments NOT
carry timestamps, and that they be acceptable regardless of their
timestamp. At that time, the thinking was that old duplicate
<RST> segments should be exceedingly unlikely, and their cleanup
function should take precedence over timestamps. More recently,
discussions about various blind attacks on TCP connections have raised
the suggestion that if the Timestamps option is present, SEG.TSecr could
be used to provide stricter acceptance tests for <RST> segments.
</t>
<t>
While still under discussion, to enable research into this area it is
now RECOMMENDED that when generating an <RST>, that if the segment
causing the <RST> to be generated contained a Timestamps option,
that the <RST> also contain a Timestamps option. In the
<RST> segment, SEG.TSecr SHOULD be set to SEG.TSval from the
incoming segment and SEG.TSval SHOULD be set to zero. If an <RST>
is being generated because of a user abort, and Snd.TS.OK is set, then a
Timestamps option SHOULD be included in the <RST>. When an
<RST> segment is received, it MUST NOT be subjected to the PAWS
check by verifying an acceptable value in SEG.TSval, and information from
the Timestamps option MUST NOT be used to
update connection state information. SEG.TSecr MAY be used to provide
stricter <RST> acceptance checks.
</t>
</section>
<section anchor="sec421" title="Basic PAWS Algorithm">
<t>If the PAWS algorithm is used, the following processing MUST be
performed on all incoming segments for a synchronized connection. Also,
PAWS processing MUST take precedence over the regular TCP acceptabiltiy
check (Section 3.3 in <xref target="RFC0793"/>), which is performed
after verification of the received Timestamps option:
<list style="format R%d)">
<t>If there is a Timestamps option in the arriving segment, SEG.TSval
< TS.Recent, TS.Recent is valid (see later discussion) and the
RST bit is not set, then treat the arriving segment as not
acceptable:
<list style="empty">
<t>Send an acknowledgment in reply as specified in <xref
target="RFC0793"/> page 69 and drop the segment.
</t>
<t>Note: it is necessary to send an <ACK> segment in order
to retain TCP's mechanisms for detecting and recovering from
half- open connections. For example, see Figure 10 of <xref
target="RFC0793"/>.
</t>
</list>
</t>
<t>If the segment is outside the window, reject it (normal TCP
processing)
</t>
<t>If an arriving segment satisfies: SEG.SEQ <= Last.ACK.sent (see
<xref target="sec34"/>), then record its timestamp in TS.Recent.
</t>
<t>If an arriving segment is in-sequence (i.e., at the left window
edge), then accept it normally.
</t>
<t>Otherwise, treat the segment as a normal in-window, out-of-sequence
TCP segment (e.g., queue it for later delivery to the user).
</t>
</list>
</t>
<t>Steps R2, R4, and R5 are the normal TCP processing steps specified by
<xref target="RFC0793"/>.
</t>
<t>It is important to note that the timestamp MUST be checked only when a
segment first arrives at the receiver, regardless of whether it is in-
sequence or it must be queued for later delivery.
</t>
<t>Consider the following example.
<list style="empty">
<t>Suppose the segment sequence: A.1, B.1, C.1, ..., Z.1 has been
sent, where the letter indicates the sequence number and the digit
represents the timestamp. Suppose also that segment B.1 has been
lost. The timestamp in TS.Recent is 1 (from A.1), so C.1, ..., Z.1
are considered acceptable and are queued. When B is retransmitted
as segment B.2 (using the latest timestamp), it fills the hole and
causes all the segments through Z to be acknowledged and passed to
the user. The timestamps of the queued segments are *not* inspected
again at this time, since they have already been accepted. When B.2
is accepted, TS.Recent is set to 2.
</t>
</list>
</t>
<t>This rule allows reasonable performance under loss. A full window of
data is in transit at all times, and after a loss a full window less one
segment will show up out-of-sequence to be queued at the receiver (e.g.,
up to ~2^30 bytes of data); the Timestamps option must not result in
discarding this data.
</t>
<t>In certain unlikely circumstances, the algorithm of rules R1-R5 could
lead to discarding some segments unnecessarily, as shown in the
following example:
<list style="empty">
<t>Suppose again that segments: A.1, B.1, C.1, ..., Z.1 have been sent
in sequence and that segment B.1 has been lost. Furthermore, suppose
delivery of some of C.1, ... Z.1 is delayed until *after* the
retransmission B.2 arrives at the receiver. These delayed segments
will be discarded unnecessarily when they do arrive, since their
timestamps are now out of date.
</t>
</list>
</t>
<t>This case is very unlikely to occur. If the retransmission was
triggered by a timeout, some of the segments C.1, ... Z.1 must have been
delayed longer than the RTO time. This is presumably an unlikely event,
or there would be many spurious timeouts and retransmissions. If B's
retransmission was triggered by the "fast retransmit" algorithm, i.e.,
by duplicate <ACK>s, then the queued segments that caused these
<ACK>s must have been received already.
</t>
<t>Even if a segment were delayed past the RTO, the Fast Retransmit
mechanism <xref target="Jacobson90c"/> will cause the delayed segments
to be retransmitted at the same time as B.2, avoiding an extra RTT and
therefore causing a very small performance penalty.
</t>
<t>We know of no case with a significant probability of occurrence in
which timestamps will cause performance degradation by unnecessarily
discarding segments.
</t>
</section>
<section anchor="sec422" title="Timestamp Clock">
<t>It is important to understand that the PAWS algorithm does not
require clock synchronization between sender and receiver. The
sender's timestamp clock is used as a source of monotonic
non-decreasing values to stamp the segments. The receiver
treats the timestamp value as simply a monotonically
non-decreasing serial number, without any connection to
time. From the receiver's viewpoint, the timestamp is
acting as a logical extension of the high-order bits of the
sequence number.
</t>
<t>The receiver algorithm does place some requirements on the
frequency of the timestamp clock.
<list style="format (%c)">
<t>The timestamp clock must not be "too slow".
<vspace blankLines="1"/>
It MUST tick at least once for each 2^31 bytes sent. In
fact, in order to be useful to the sender for round trip
timing, the clock SHOULD tick at least once per window's
worth of data, and even with the window extension defined
in <xref target="sec22"/>, 2^31 bytes must be at least two
windows.
<vspace blankLines="1"/>
To make this more quantitative, any clock faster than 1
tick/sec will reject old duplicate segments for link
speeds of ~8 Gbps. A 1 ms timestamp clock will work at
link speeds up to 8 Tbps (8*10^12) bps!
</t>
<t>The timestamp clock must not be "too fast".
<vspace blankLines="1"/>
The recycling time of the timestamp clock MUST be greater than MSL seconds.
Since the clock (timestamp) is 32 bits and the worst-case
MSL is 255 seconds, the maximum acceptable clock frequency
is one tick every 59 ns.
<vspace blankLines="1"/>
However, it is desirable to establish a much longer
recycle period, in order to handle outdated timestamps on
idle connections (see <xref target="sec423"/>), and to
relax the MSL
requirement for preventing sequence number wrap-around.
With a 1 ms timestamp clock, the 32-bit timestamp will
wrap its sign bit in 24.8 days. Thus, it will reject old
duplicates on the same connection if MSL is 24.8 days or
less. This appears to be a very safe figure; an MSL of
24.8 days or longer can probably be assumed in the Internet
without requiring precise MSL enforcement.
</t>
</list>
</t>
<t>Based upon these considerations, we choose a timestamp clock
frequency in the range 1 ms to 1 sec per tick. This range also
matches the requirements of the RTTM mechanism, which does not
need much more resolution than the granularity of the
retransmit timer, e.g., tens or hundreds of milliseconds.
</t>
<t>The PAWS mechanism also puts a strong monotonicity requirement
on the sender's timestamp clock. The method of implementation
of the timestamp clock to meet this requirement depends upon
the system hardware and software.
<list style="symbols">
<t>Some hosts have a hardware clock that is guaranteed to be
monotonic between hardware resets.
</t>
<t>A clock interrupt may be used to simply increment a binary
integer by 1 periodically.
</t>
<t>The timestamp clock may be derived from a system clock
that is subject to being abruptly changed, by adding a
variable offset value. This offset is initialized to
zero. When a new timestamp clock value is needed, the
offset can be adjusted as necessary to make the new value
equal to or larger than the previous value (which was
saved for this purpose).
</t>
<t>A random offset may be added to the timestamp clock on a
per connection basis. See <xref target="RFC6528"/>,
section 3, on randomizing the initial sequence number
(ISN). The same function with a different
secret key can be used to generate the per connection
timestamp offset.
</t>
</list>
</t>
</section>
<section anchor="sec423" title="Outdated Timestamps">
<t>If a connection remains idle long enough for the timestamp
clock of the other TCP to wrap its sign bit, then the value
saved in TS.Recent will become too old; as a result, the PAWS
mechanism will cause all subsequent segments to be rejected,
freezing the connection (until the timestamp clock wraps its
sign bit again).
</t>
<t>With the chosen range of timestamp clock frequencies (1 sec to
1 ms), the time to wrap the sign bit will be between 24.8 days
and 24800 days. A TCP connection that is idle for more than 24
days and then comes to life is exceedingly unusual. However,
it is undesirable in principle to place any limitation on TCP
connection lifetimes.
</t>
<t>We therefore require that an implementation of PAWS include a
mechanism to "invalidate" the TS.Recent value when a connection
is idle for more than 24 days. (An alternative solution to the
problem of outdated timestamps would be to send keep-alive
segments at a very low rate, but still more often than the
wrap-around time for timestamps, e.g., once a day. This would
impose negligible overhead. However, the TCP specification has
never included keep-alives, so the solution based upon
invalidation was chosen.)
</t>
<t>Note that a TCP does not know the frequency, and therefore, the
wraparound time, of the other TCP, so it must assume the worst.
The validity of TS.Recent needs to be checked only if the basic
PAWS timestamp check fails, i.e., only if SEG.TSval <
TS.Recent. If TS.Recent is found to be invalid, then the
segment is accepted, regardless of the failure of the timestamp
check, and rule R3 updates TS.Recent with the TSval from the
new segment.
</t>
<t>To detect how long the connection has been idle, the TCP MAY
update a clock or timestamp value associated with the
connection whenever TS.Recent is updated, for example. The
details will be implementation-dependent.
</t>
</section>
<section anchor="sec424" title="Header Prediction">
<t>"Header prediction" <xref target="Jacobson90a"/> is
a high-performance
transport protocol implementation technique that is most
important for high-speed links. This technique optimizes the
code for the most common case, receiving a segment correctly
and in order. Using header prediction, the receiver asks the
question, "Is this segment the next in sequence?" This
question can be answered in fewer machine instructions than the
question, "Is this segment within the window?"
</t>
<t>Adding header prediction to our timestamp procedure leads to
the following recommended sequence for processing an arriving
TCP segment:
<list style="format H%d)">
<t>Check timestamp (same as step R1 above)
</t>
<t>Do header prediction: if segment is next in sequence and
if there are no special conditions requiring additional
processing, accept the segment, record its timestamp, and
skip H3.
</t>
<t>Process the segment normally, as specified in RFC 793.
This includes dropping segments that are outside the
window and possibly sending acknowledgments, and queuing
in-window, out-of-sequence segments.
</t>
</list>
</t>
<t>Another possibility would be to interchange steps H1 and H2,
i.e., to perform the header prediction step H2 *first*, and
perform H1 and H3 only when header prediction fails. This
could be a performance improvement, since the timestamp check
in step H1 is very unlikely to fail, and it requires unsigned
modulo arithmetic. To
perform this check on every single segment is contrary to the
philosophy of header prediction. We believe that this change
might produce a measurable reduction in CPU time for TCP
protocol processing on high-speed networks.
</t>
<t>However, putting H2 first would create a hazard: a segment from
2^32 bytes in the past might arrive at exactly the wrong time
and be accepted mistakenly by the header-prediction step. The
following reasoning has been introduced in <xref target="RFC1185"/>
<!--xref target="Jacobson90b"/--> to show
that the probability of this failure is negligible.
<list style="empty">
<t>If all segments are equally likely to show up as old
duplicates, then the probability of an old duplicate
exactly matching the left window edge is the maximum
segment size (MSS) divided by the size of the sequence
space. This ratio must be less than 2^-16, since MSS
must be < 2^16; for example, it will be (2^12)/(2^32) =
2^-20 for a 100 Mbit/s link. However, the older a segment is,
the less likely it is to be retained in the Internet, and
under any reasonable model of segment lifetime the
probability of an old duplicate exactly at the left window
edge must be much smaller than 2^-16.
</t>
<t>The 16 bit TCP checksum also allows a basic unreliability
of one part in 2^16. A protocol mechanism whose
reliability exceeds the reliability of the TCP checksum
should be considered "good enough", i.e., it won't
contribute significantly to the overall error rate. We
therefore believe we can ignore the problem of an old
duplicate being accepted by doing header prediction before
checking the timestamp.
</t>
</list>
</t>
<t>However, this probabilistic argument is not universally
accepted, and the consensus at present is that the performance
gain does not justify the hazard in the general case. It is
therefore recommended that H2 follow H1.
</t>
</section>
<section anchor="sec425" title="IP Fragmentation">
<t>At high data rates, the protection against old segments provided
by PAWS can be circumvented by errors in IP fragment reassembly
(see <xref target="RFC4963"/><!--xref target="Heffner07"/-->).
The only way to protect against incorrect IP
fragment reassembly is to not allow the segments to be
fragmented. This is done by setting the Don't Fragment (DF)
bit in the IP header. Setting the DF bit implies the use of
Path MTU Discovery as described in
<xref target="RFC1191"/>, <xref target="RFC1981"/>, and <xref target="RFC4821"/>, thus any
TCP implementation that implements PAWS MUST also implement
Path MTU Discovery.
</t>
</section>
<section anchor="sec43" title="Duplicates from Earlier Incarnations of Connection">
<t>The PAWS mechanism protects against errors due to sequence number
wrap-around on high-speed connections. Segments from an earlier
incarnation of the same connection are also a potential cause of
old duplicate errors. In both cases, the TCP mechanisms to
prevent such errors depend upon the enforcement of a maximum
segment lifetime (MSL) by the Internet (IP) layer (see Appendix of
RFC 1185 for a detailed discussion). Unlike the case of sequence
space wrap-around, the MSL required to prevent old duplicate
errors from earlier incarnations does not depend upon the transfer
rate. If the IP layer enforces the recommended 2 minute MSL of
TCP, and if the TCP rules are followed, TCP connections will be
safe from earlier incarnations, no matter how high the network
speed. Thus, the PAWS mechanism is not required for this case.
</t>
<t>We may still ask whether the PAWS mechanism can provide additional
security against old duplicates from earlier connections, allowing
us to relax the enforcement of MSL by the IP layer. <xref target="AppB"/>
explores this question, showing that further assumptions and/or
mechanisms are required, beyond those of PAWS. This is not part
of the current extension.
</t>
</section>
</section>
<section anchor="sec5" title="Conclusions and Acknowledgments">
<t>This memo presented a set of extensions to TCP to provide efficient
operation over large bandwidth * delay product paths and reliable
operation over very high-speed paths. These extensions are designed
to provide compatible interworking with TCP stacks that do not implement
the extensions.
</t>
<t>These mechanisms are implemented using TCP options for scaled
windows and timestamps. The timestamps are used for two distinct
mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protection
Against Wrapped Sequences).
</t>
<t>The Window Scale option was originally suggested by Mike St. Johns of
USAF/DCA. The present form of the option was suggested by Mike
Karels of UC Berkeley in response to a more cumbersome scheme defined
by Van Jacobson. Lixia Zhang helped formulate the PAWS mechanism
description in <xref target="RFC1185"/>.
</t>
<t>Finally, much of this work originated as the result of discussions
within the End-to-End Task Force on the theoretical limitations of
transport protocols in general and TCP in particular. Task force
members and other on the end2end-interest list have made valuable
contributions by pointing out flaws in the algorithms and the
documentation. Continued discussion and development since the
publication of <xref target="RFC1323"/> originally occurred in the IETF TCP Large
Windows Working Group, later on in the End-to-End Task Force, and
most recently in the IETF TCP Maintenance Working Group. The authors
are grateful for all these contributions.
</t>
</section>
<section anchor="sec6" title="Security Considerations">
<t>The TCP sequence space is a fixed size, and as the window becomes
larger it becomes easier for an attacker to generate forged packets
that can fall within the TCP window, and be accepted as valid
segments. While use of timestamps and PAWS can help to mitigate this,
when using PAWS, if an attacker is able to forge a packet that is
acceptable to the TCP connection, a timestamp that is in the future
would cause valid segments to be dropped due to PAWS checks. Hence,
implementers should take care to not open the TCP window drastically
beyond the requirements of the connection.
</t>
<t>See <xref target="RFC5961"/> for mitigation strategies to blind
in-window attacks.
</t>
<t>A naive implementation that derives the timestamp clock value
directly from a system uptime clock may unintentionally leak this
information to an attacker. This does not directly compromise any
of the mechanisms described in this document. However, this may
be valuable information to a potential attacker. <!-- An implementer
should evaluate the potential impact and mitigate this accordingly
(i.e. by using a random offset for the timestamp clock on each
connection, or using an external, real-time derived timestamp clock source).-->
It is
therefore RECOMMENDED to generate a random, per-connection offset to
be used with the clock source when generating the Timestamps option
value (see <xref target="sec422"/>). By carefully choosing this
random offset, further improvements as described in
<xref target="RFC6191"/> are possible.
</t>
<t>Expanding the TCP window beyond 64 KiB for IPv6 allows Jumbograms
<xref target="RFC2675"/> to be used when the local network supports
packets larger than 64 KiB. When larger TCP segments are used, the
TCP checksum becomes weaker.
</t>
<t>Mechanisms to protect the TCP header from modification should also
protect the TCP options.
</t>
<t>Middleboxes and TCP options:
<list>
<t>Some middleboxes have been known to remove the TCP options
described in this document from TCP segments <xref target="Honda11"/>.
Middleboxes that remove TCP options described in this document
from the <SYN> segment interfere with the selection of
parameters appropriate for the session. Removing any of these
options in a <SYN,ACK> segment will leave the end hosts in
a state that destroys the proper operation of the protocol.
<list style="symbols">
<t>If a Window Scale option is removed from a
<SYN,ACK> segment, the end hosts will not
negotiate the window scaling factor correctly.
Middleboxes must not remove or modify the Window Scale
option from <SYN,ACK> segments.
</t>
<t>If a stateful firewall uses the window field to
detect whether a received segment is inside the
current window, and does not support the Window
Scale option, it will not be able to correctly
determine whether or not a packet is in the
window. These middle boxes must also support
the Window Scale option and apply the scale factor
when processing segments. If the window scale factor
cannot be determined, it must not do window
based processing.
</t>
<t>If the Timestamps option is removed from the
<SYN> or <SYN,ACK> segment, high
speed connections that need PAWS would not
have that protection. Successful negotiation of
Timestamps option enforces a stricter verification
of incoming segments at the receiver. If the
Timestamps option was removed from a subsequent
data segment after a successful negotiation (e.g.
as part of re-segmentation), the segment is
discarded by the receiver without further
processing. Middleboxes should not remove the
Timestamps option.
</t>
<t>It must be noted that <xref target="RFC1323"/> doesn't
address the case of the Timestamps option being dropped or
selectively omitted after being negotiated, and that the
update in this document may cause some broken middlebox
behavior to be detected (potentially unresponsive TCP
sessions).
</t>
</list>
</t>
</list>
</t>
<t>Implementations that depend on PAWS could provide a mechanism for the
application to determine whether or not PAWS is in use on the connection,
and chose to terminate the connection if that protection doesn't exist.
This is not just to protect the connection against middleboxes that might
remove the Timestamps option, but also against remote hosts that do not
have Timestamp support.
</t>
<section anchor="sec61" title="Privacy Considerations">
<t>The TCP options described in this document do not expose individual
users data. However, a naive implementation simply using the system
clock as source for the Timestamps option will reveal characteristics
of the TCP potentially allowing more targeted attacks. It is therefore
RECOMMENDED to generate a random, per-connection offset to be used
with the clock source when generating the Timestamps option value
(see <xref target="sec422"/>).
</t>
<t>Furthermore, the combination, relative ordering and padding of the
TCP options described in <xref target="sec22"/> and
<xref target="sec32"/> will reveal additional clues to allow the
fingerprinting of the system.
</t>
</section>
</section>
<section anchor="sec7" title="IANA Considerations">
<t>The described TCP options are
well known from the superceded <xref target="RFC1323"/>.
IANA is requested to update the "TCP Option Kind Numbers" table under
"TCP parameters" to list
<!-- ********* -->
<!-- RFC Editor: please insert this RFC's number here -->
<!-- ********* -->
<this-RFC-to-be>
as the reference for the
options "WSopt - Window Scale Option" and "TSopt - Timestamps Option".
<vspace blankLines="5"/>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC0793;
&RFC1191;
&RFC2119;
</references>
<references title="Informative References">
<!-- &RFC0896; -->
&RFC1072;
<!-- &RFC1110; -->
&RFC1122;
&RFC1185;
&RFC1323;
&RFC1981;
&RFC2018;
<!-- &RFC2581; -->
&RFC2675;
&RFC2883;
&RFC3522;
&RFC4015;
&RFC4821;
&RFC4963;
&RFC5681;
&RFC5961;
&RFC6298;
&RFC6528;
&RFC6675;
&RFC6691;
&RFC6817;
&RFC6191;
<reference anchor="Garlick77" target="http://www.rfc-editor.org/ien/ien12.txt">
<front>
<title>Issues in Reliable Host-to-Host Protocols</title>
<author initials="L." surname="Garlick"/>
<author initials="R." surname="Rom"/>
<author initials="J." surname="Postel"/>
<date month="May" year="1977" />
</front>
<seriesInfo name="Proc." value="Second Berkeley Workshop
on Distributed Data Management and Computer Networks"/>
</reference>
<!--
<reference anchor="Hamming77" target="">
<front>
<title>Digital Filters</title>
<author initials="R." surname="Hamming"/>
<date year="1977"/>
</front>
<seriesInfo name="Prentice Hall, Englewood Cliffs, N.J."
value="ISBN 0-13-212571-4"/>
</reference>
-->
<reference anchor="Jacobson88a" target="http://ee.lbl.gov/papers/congavoid.pdf">
<front>
<title>Congestion Avoidance and Control</title>
<author initials="V." surname="Jacobson"/>
<date month="August" year="1988"/>
</front>
<seriesInfo name="SIGCOMM '88, Stanford," value=" CA."/>
</reference>
<reference anchor="Jacobson90a" target="">
<front>
<title>4BSD Header Prediction</title>
<author initials="V." surname="Jacobson"/>
<date month="April" year="1990"/>
</front>
<seriesInfo name="ACM" value="Computer Communication Review"/>
</reference>
<reference anchor="Jacobson90c" target="ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail">
<front>
<title>Modified TCP congestion avoidance algorithm</title>
<author initials="V." surname="Jacobson"/>
<date month="April" year="1990" day="30"/>
</front>
<seriesInfo name="Message to the" value="end2end-interest mailing list"/>
</reference>
<reference anchor="Allman99" target="http://aciri.org/mallman/papers/estimation-la.pdf">
<front>
<title>On Estimating End-to-End Network Path Properties</title>
<author initials="M." surname="Allman"/>
<author initials="V." surname="Paxson"/>
<date month="September" year="1999"/>
</front>
<seriesInfo name="Proc." value="ACM SIGCOMM Technical Symposium, Cambridge, MA"/>
</reference>
<!--
<reference anchor="Jain86" target="http://arxiv.org/ftp/cs/papers/9809/9809097.pdf">
<front>
<title>Divergence of Timeout Algorithms for Packet
Retransmissions</title>
<author initials="R." surname="Jain"/>
<date month="March" year="1986"/>
</front>
<seriesInfo name="Proc." value="Fifth Phoenix Conf. on Comp. and Comm.,
Scottsdale, Arizona"/>
</reference>
-->
<reference anchor="Karn87" target="">
<front>
<title>Estimating Round-Trip Times
in Reliable Transport Protocols</title>
<author initials="P." surname="Karn"/>
<author initials="C." surname="Partridge"/>
<date month="August" year="1987"/>
</front>
<seriesInfo name="Proc." value="SIGCOMM '87"/>
</reference>
<reference anchor="Martin03" target="http://www.ietf.org/mail-archive/web/tsvwg/current/msg04435.html">
<front>
<title>[Tsvwg] RFC 1323.bis</title>
<author initials="D." surname="Martin"/>
<date month="September" year="2003" day="30"/>
</front>
<seriesInfo name="Message to the" value="tsvwg mailing list"/>
</reference>
<reference anchor="Medina04" target="http://www.icir.net/tbit/tbit-Aug2004.pdf">
<front>
<title>Measuring Interactions Between Transport Protocols and Middleboxes</title>
<author initials="A." surname="Medina"/>
<author initials="M." surname="Allman"/>
<author initials="S." surname="Floyd"/>
<date month="August" year="2004"/>
</front>
<seriesInfo name="Proc." value="ACM SIGCOMM/USENIX Internet Measurement Conference. October 2004"/>
</reference>
<reference anchor="Medina05" target="http://icir.net/floyd/papers/TCPevolution-Mar2005.pdf">
<front>
<title>Measuring the Evolution of Transport Protocols in the Internet</title>
<author initials="A." surname="Medina"/>
<author initials="M." surname="Allman"/>
<author initials="S." surname="Floyd"/>
<date month="April" year="2005"/>
</front>
<seriesInfo name="ACM Computer Communication Review" value="35(2)"/>
</reference>
<reference anchor="Ludwig00" target="http://ccr.sigcomm.org/archive/2000/july00/LudwigFinal.pdf">
<front>
<title>The Eifel Retransmission Timer</title>
<author initials="R." surname="Ludwig"/>
<author initials="K." surname="Sklower"/>
<date month="July" year="2000"/>
</front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review" value="Volume 30 Issue 3"/>
</reference>
<!--
<reference anchor="Ekstroem04" target="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.76.2748&rep=rep1&type=pdf">
<front>
<title>The Peak-Hopper: A New End-to-End Retransmission Timer for Reliable Unicast Transport</title>
<author initials="H." surname="Ekstroem"/>
<author initials="R." surname="Ludwig"/>
<date month="March" year="2004"/>
</front>
<seriesInfo name="INFOCOM 2004" value="IEEE"/>
</reference>
-->
<reference anchor="Oppermann13" target="http://www.ietf.org/mail-archive/web/tcpm/current/msg08001.html">
<front>
<title>[tcpm] Explanation to the relaxation of TSopt acceptance rules</title>
<author initials="A." surname="Oppermann"/>
<date month="Jun" year="2013" day="1"/>
</front>
<seriesInfo name="Message to the" value="tcpm mailing list"/>
</reference>
<!--
<reference anchor="Mathis08" target="http://www.ietf.org/mail-archive/web/tcpm/current/msg03564.html">
<front>
<title>[tcpm] Example of 1323 window retraction
problem</title>
<author initials="M." surname="Mathis"/>
<date month="March" year="2008" day="11"/>
</front>
<seriesInfo name="Message to the" value="tcpm mailing list"/>
</reference>
-->
<reference anchor="Floyd05" target="http://www.ietf.org/mail-archive/web/tcpm/current/msg02508.html">
<front>
<title>[tcpm] How the RTO should be estimated with timestamps</title>
<author initials="S." surname="Floyd"/>
<date month="August" year="2005" day="09"/>
</front>
<seriesInfo name="Message from 26.Jan.2007 to the" value="tcpm mailing list"/>
</reference>
<reference anchor="Honda11" target="">
<front>
<title>Is it still possible to extend TCP?</title>
<author initials="M." surname="Honda"/>
<author initials="Y." surname="Nishida"/>
<author initials="C." surname="Raiciu"/>
<author initials="A." surname="Greenhalgh"/>
<author initials="M." surname="Handley"/>
<author initials="H." surname="Tokuda"/>
<date month="November" year="2011"/>
</front>
<seriesInfo name="Proc. of ACM Internet Measurement Conference" value="(IMC) '11"/>
</reference>
<reference anchor="Kuzmanovic03" target="www.cs.northwestern.edu/~akuzma/doc/TCP-LP-ToN.pdf">
<front>
<title>TCP-LP: Low-Priority Service via End-Point Congestion Control</title>
<author initials="A." surname="Kuzmanovic"/>
<author initials="E." surname="Knightly"/>
<date year="2003"/>
</front>
</reference>
<reference anchor="Kuehlewind10" target="bobbriscoe.net/projects/netsvc_i-f/chirp_pfldnet10.pdf">
<front>
<title>Chirping for Congestion Control -
Implementation Feasibility</title>
<author initials="M." surname="Kuehlewind"/>
<author initials="B." surname="Briscoe"/>
<date month="November" year="2010"/>
</front>
</reference>
<!--
<reference anchor="Watson81" target="">
<front>
<title>Timer-based Mechanisms in Reliable
Transport Protocol Connection Management</title>
<author initials="R." surname="Watson"/>
<date year="1981"/>
</front>
<seriesInfo name="Computer Networks," value="Vol. 5"/>
</reference>
-->
<!--
<reference anchor="Zhang86" target="">
<front>
<title>Why TCP Timers Don't Work Well</title>
<author initials="L." surname="Zhang"/>
<date month="August" year="1986"/>
</front>
<seriesInfo name="Proc." value="SIGCOMM '86, Stowe, VT"/>
</reference>
-->
</references>
<section anchor="AppA" title="Implementation Suggestions">
<t>TCP Option Layout
<list>
<t>The following layout is recommended for sending options on
non-<SYN> segments, to achieve maximum feasible alignment of
32-bit and 64-bit machines.
<figure align="center">
<artwork align="center"><![CDATA[
+--------+--------+--------+--------+
| NOP | NOP | TSopt | 10 |
+--------+--------+--------+--------+
| TSval timestamp |
+--------+--------+--------+--------+
| TSecr timestamp |
+--------+--------+--------+--------+
]]></artwork>
</figure>
</t>
</list>
</t>
<t>Interaction with the TCP Urgent Pointer
<list>
<t>The TCP Urgent pointer, like the TCP window, is a 16 bit value.
Some of the original discussion for the TCP Window Scale option
included proposals to increase the Urgent pointer to 32 bits.
As it turns out, this is unnecessary. There are two
observations that should be made:
<list style="format (%d)">
<t>With IP Version 4, the largest amount of TCP data that can
be sent in a single packet is 65495 bytes (64 KiB - 1 -- size
of fixed IP and TCP headers).
</t>
<t>Updates to the urgent pointer while the user is in "urgent
mode" are invisible to the user.
</t>
</list>
</t>
<t>This means that if the Urgent Pointer points beyond the end of
the TCP data in the current segment, then the user will remain in
urgent mode until the next TCP segment arrives. That segment will
update the urgent pointer to a new offset, and the user will
never have left urgent mode.
</t>
<t>Thus, to properly implement the Urgent Pointer, the sending TCP
only has to check for overflow of the 16 bit Urgent Pointer
field before filling it in. If it does overflow, than a value
of 65535 should be inserted into the Urgent Pointer.
</t>
<t>The same technique applies to IP Version 6, except in the case
of IPv6 Jumbograms. When IPv6 Jumbograms are supported,
<xref target="RFC2675"/><!--xref target"Borman99"/--> requires
additional steps for dealing with the
Urgent Pointer, these are described in section 5.2 of
<xref target="RFC2675"/>.
</t>
</list>
</t>
</section>
<section anchor="AppB" title="Duplicates from Earlier Connection Incarnations">
<t>There are two cases to be considered: (1) a system crashing (and
losing connection state) and restarting, and (2) the same connection
being closed and reopened without a loss of host state. These will
be described in the following two sections.
</t>
<section anchor="AppB1" title="System Crash with Loss of State">
<t>TCP's quiet time of one MSL upon system startup handles the loss
of connection state in a system crash/restart. For an
explanation, see for example "When to Keep Quiet" in the TCP
protocol specification <xref target="RFC0793"/><!--xref target="Postel81"/-->. The MSL that is required here
does not depend upon the transfer speed. The current TCP MSL of 2
minutes seemed acceptable as an operational compromise, when many
host systems used to take this long to boot after a crash. Current
host systems can boot considerably faster.
</t>
<t>The Timestamps option may be used to ease the MSL
requirements (or to provide additional security against data
corruption). If timestamps are being used and if the timestamp
clock can be guaranteed to be monotonic over a system
crash/restart, i.e., if the first value of the sender's timestamp
clock after a crash/restart can be guaranteed to be greater than
the last value before the restart, then a quiet time is
unnecessary.
</t>
<t>To dispense totally with the quiet time would require that the
host clock be synchronized to a time source that is stable over
the crash/restart period, with an accuracy of one timestamp clock
tick or better. We can back off from this strict requirement to
take advantage of approximate clock synchronization. Suppose that
the clock is always re-synchronized to within N timestamp clock
ticks and that booting (extended with a quiet time, if necessary)
takes more than N ticks. This will guarantee monotonicity of the
timestamps, which can then be used to reject old duplicates even
without an enforced MSL.
</t>
</section>
<section anchor="AppB2" title="Closing and Reopening a Connection">
<t>When a TCP connection is closed, a delay of 2*MSL in TIME-WAIT
state ties up the socket pair for 4 minutes (see Section 3.5 of
<xref target="RFC0793"/><!--xref target="Postel81"/-->. Applications built upon TCP that close one connection
and open a new one (e.g., an FTP data transfer connection using
Stream mode) must choose a new socket pair each time. The
TIME-WAIT delay serves two different purposes:
<list style="format (%c)">
<t>Implement the full-duplex reliable close handshake of TCP.
<vspace blankLines="1"/>
The proper time to delay the final close step is not really
related to the MSL; it depends instead upon the RTO for the
FIN segments and therefore upon the RTT of the path. (It
could be argued that the side that is sending a FIN knows
what degree of reliability it needs, and therefore it should
be able to determine the length of the TIME-WAIT delay for
the FIN's recipient. This could be accomplished with an
appropriate TCP option in FIN segments.)
<vspace blankLines="1"/>
Although there is no formal upper-bound on RTT, common
network engineering practice makes an RTT greater than 1
minute very unlikely. Thus, the 4 minute delay in TIME-WAIT
state works satisfactorily to provide a reliable full-duplex
TCP close. Note again that this is independent of MSL
enforcement and network speed.
<vspace blankLines="1"/>
The TIME-WAIT state could cause an indirect performance
problem if an application needed to repeatedly close one
connection and open another at a very high frequency, since
the number of available TCP ports on a host is less than
2^16. However, high network speeds are not the major
contributor to this problem; the RTT is the limiting factor
in how quickly connections can be opened and closed.
Therefore, this problem will be no worse at high transfer
speeds.
</t>
<t>Allow old duplicate segments to expire.
<vspace blankLines="1"/>
To replace this function of TIME-WAIT state, a mechanism
would have to operate across connections. PAWS is defined
strictly within a single connection; the last timestamp
(TS.Recent) is kept in the connection control block, and
discarded when a connection is closed.
<vspace blankLines="1"/>
An additional mechanism could be added to the TCP, a per-host
cache of the last timestamp received from any connection.
This value could then be used in the PAWS mechanism to reject
old duplicate segments from earlier incarnations of the
connection, if the timestamp clock can be guaranteed to have
ticked at least once since the old connection was open. This
would require that the TIME-WAIT delay plus the RTT together
must be at least one tick of the sender's timestamp clock.
Such an extension is not part of the proposal of this RFC.
<vspace blankLines="1"/>
Note that this is a variant on the mechanism proposed by
Garlick, Rom, and Postel <xref target="Garlick77"/>,
which required each
host to maintain connection records containing the highest
sequence numbers on every connection. Using timestamps
instead, it is only necessary to keep one quantity per remote
host, regardless of the number of simultaneous connections to
that host.
</t>
</list>
</t>
</section>
</section>
<section anchor="AppD" title="Summary of Notation">
<?rfc subcompact="yes" ?>
<t>The following notation has been used in this document.
</t>
<t>Options
<list><t>
<list hangIndent="18" style="hanging">
<t hangText="WSopt:">TCP Window Scale option</t>
<t hangText="TSopt:">TCP Timestamps option</t>
</list></t>
</list>
</t>
<t>Option Fields
<list><t>
<list hangIndent="18" style="hanging">
<t hangText="shift.cnt:">Window scale byte in WSopt</t>
<t hangText="TSval:">32-bit Timestamp Value field in TSopt</t>
<t hangText="TSecr:">32-bit Timestamp Reply field in TSopt</t>
</list></t>
</list>
</t>
<t>Option Fields in Current Segment
<list><t>
<list hangIndent="18" style="hanging">
<t hangText="SEG.TSval:">TSval field from TSopt in current segment</t>
<t hangText="SEG.TSecr:">TSecr field from TSopt in current segment</t>
<t hangText="SEG.WSopt:">8-bit value in WSopt</t>
</list></t>
</list>
</t>
<t>Clock Values
<list><t>
<list hangIndent="18" style="hanging">
<t hangText="my.TSclock:">System wide source of 32-bit timestamp values</t>
<t hangText="my.TSclock.rate:">Period of my.TSclock (1 ms to 1 sec)</t>
<t hangText="Snd.TSoffset:">A offset for randomizing Snd.TSclock</t>
<t hangText="Snd.TSclock:">my.TSclock + Snd.TSoffset</t>
</list></t>
</list>
</t>
<t>Per-Connection State Variables
<list><t>
<list hangIndent="18" style="hanging">
<t hangText="TS.Recent:">Latest received Timestamp</t>
<t hangText="Last.ACK.sent:">Last ACK field sent</t>
<t hangText="Snd.TS.OK:">1-bit flag</t>
<t hangText="Snd.WS.OK:">1-bit flag</t>
<t hangText="Rcv.Wind.Shift:">Receive window scale exponent</t>
<t hangText="Snd.Wind.Shift:">Send window scale exponent</t>
<t hangText="Start.Time:">Snd.TSclock value when segment being
timed was sent (used by pre-1323 code).</t>
</list></t>
</list>
</t>
<t>Procedure
<list><t>
<list hangIndent="18" style="hanging">
<t hangText="Update_SRTT(m)">Procedure to update the smoothed RTT
and RTT variance estimates, using the rules of
<xref target="Jacobson88a"/>, given m, a new RTT measurement</t>
</list></t>
</list>
</t>
<?rfc subcompact="no" ?>
</section>
<!--
<section anchor="AppE" title="Pseudo-code Summary">
<t>
<figure align="left">
<artwork align="left"><![CDATA[
Create new TCB => {
Rcv.wind.scale =
MIN(14, MAX(0, floor(log2(receive buffer space)) - 15));
Snd.wind.scale = 0;
Last.ACK.sent = 0;
Snd.TS.OK = Snd.WS.OK = FALSE;
Snd.TSoffset = random 32 bit value
}
Send initial <SYN> segment => {
SEG.WND = MIN( RCV.WND, 65535 );
Include in segment: TSopt(TSval=Snd.TSclock, TSecr=0);
Include in segment: WSopt = Rcv.wind.scale;
}
Send <SYN,ACK> segment => {
SEG.ACK = Last.ACK.sent = RCV.NXT;
SEG.WND = MIN( RCV.WND, 65535 );
if (Snd.TS.OK) then
Include in segment:
TSopt(TSval=Snd.TSclock, TSecr=TS.Recent);
if (Snd.WS.OK) then
Include in segment:
WSopt = Rcv.wind.scale;
}
Receive <SYN> or <SYN,ACK> segment => {
if (Segment contains TSopt) then {
TS.Recent = SEG.TSval;
Snd.TS.OK = TRUE;
if (is <SYN,ACK> segment) then
Update_SRTT(
(Snd.TSclock - SEG.TSecr)/my.TSclock.rate);
}
if (Segment contains WSopt) then {
Snd.wind.scale = SEG.WSopt;
Snd.WS.OK = TRUE;
if (the ACK bit is not set, and Rcv.wind.scale has not
been initialized by the user) then
Rcv.wind.scale = Snd.wind.scale;
}
else
Rcv.wind.scale = Snd.wind.scale = 0;
}
Send non-SYN segment => {
SEG.ACK = Last.ACK.sent = RCV.NXT;
SEG.WND = MIN( RCV.WND >> Rcv.wind.scale, 65535 );
if (Snd.TS.OK) then
Include in segment:
TSopt(TSval=Snd.TSclock, TSecr=TS.Recent);
}
Receive non-SYN segment in (state >= ESTABLISHED) => {
Window = (SEG.WND << Snd.wind.scale);
/* Use 32-bit 'Window' instead of 16-bit 'SEG.WND'
* in rest of processing.
*/
if (Segment contains TSopt) then {
if (SEG.TSval < TS.Recent &&
Idle less than 24 days) then {
if (Send.TS.OK AND (NOT RST) ) then {
/* Timestamp too old =>
* segment is unacceptable.
*/
Send ACK segment;
Discard segment and return;
}
}
else {
if (SEG.SEQ <= Last.ACK.sent) then
TS.Recent = SEG.TSval;
}
}
if (SEG.ACK > SND.UNA) then {
/* (At least part of) first segment in
* retransmission queue has been ACKed
*/
if (Segment contains TSopt) then
Update_SRTT(
(Snd.TSclock - SEG.TSecr)/my.TSclock.rate);
else
Update_SRTT( /* for compatibility */
(Snd.TSclock - Start.Time)/my.TSclock.rate);
}
}
]]></artwork>
</figure>
</t>
</section>
-->
<section anchor="AppF" title="Event Processing Summary">
<t>OPEN Call
<list>
<t>...
</t>
<t>An initial send sequence number (ISS) is selected.
Send a <SYN> segment of the form:
<figure align="center">
<artwork align="center"><![CDATA[
<SEQ=ISS><CTL=SYN><TSval=Snd.TSclock><WSopt=Rcv.Wind.Shift>
]]></artwork>
</figure>
</t>
<t>...
</t>
</list>
</t>
<t>SEND Call
<list>
<t>CLOSED STATE (i.e., TCB does not exist)
<list>
<t>...
</t>
</list>
</t>
<t>LISTEN STATE
<list>
<t>If the foreign socket is specified, then change
the connection from passive to active, select an ISS.
Send a <SYN> segment containing the options:
<TSval=Snd.TSclock> and <WSopt=Rcv.Wind.Shift>.
Set SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state.
...
</t>
</list>
</t>
<t>SYN-SENT STATE<vspace blankLines="0"/>
SYN-RECEIVED STATE
<list>
<t>...
</t>
</list>
</t>
<t>ESTABLISHED STATE<vspace blankLines="0"/>
CLOSE-WAIT STATE
<list>
<t>Segmentize the buffer and send it with a piggybacked
acknowledgment (acknowledgment value = RCV.NXT). ...
</t>
<t>If the urgent flag is set ...
</t>
<t>If the Snd.TS.OK flag is set, then include the TCP
Timestamps option
<TSval=Snd.TSclock,TSecr=TS.Recent> in each
data segment.
</t>
<t>Scale the receive window for transmission in the
segment header:
<figure align="center">
<artwork align="center"><![CDATA[
SEG.WND = (RCV.WND >> Rcv.Wind.Shift).
]]></artwork>
</figure>
</t>
</list>
</t>
</list>
</t>
<t>SEGMENT ARRIVES
<list>
<t>...
</t>
<t>If the state is LISTEN then
<list>
<t>first check for an RST
<list>
<t>...
</t>
</list>
</t>
<t>second check for an ACK
<list>
<t>...
</t>
</list>
</t>
<t>third check for a SYN
<list>
<t>if the SYN bit is set, check the security. If the ...
<list>
<t>...
</t>
</list>
</t>
<t>if the SEG.PRC is less than the TCB.PRC then continue.
</t>
<t>Check for a Window Scale option (WSopt); if one is
found, save SEG.WSopt in Snd.Wind.Shift and set
Snd.WS.OK flag on. Otherwise, set both Snd.Wind.Shift
and Rcv.Wind.Shift to zero and clear Snd.WS.OK flag.
</t>
<t>Check for a TSopt option; if one is found, save
SEG.TSval in the variable TS.Recent and turn on the
Snd.TS.OK bit.
</t>
<t>Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and
any other control or text should be queued for
processing later. ISS should be selected and a <SYN>
segment sent of the form:
<figure align="center">
<artwork align="center"><![CDATA[
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
]]></artwork>
</figure>
</t>
<t>If the Snd.WS.OK bit is on, include a WSopt option
<WSopt=Rcv.Wind.Shift> in this segment. If the
Snd.TS.OK bit is on, include a TSopt
<TSval=Snd.TSclock, TSecr=TS.Recent> in this
segment. Last.ACK.sent is set to RCV.NXT.
</t>
<t>SND.NXT is set to ISS+1 and SND.UNA to ISS. The
connection state should be changed to SYN-RECEIVED.
Note that any other incoming control or data (combined
with SYN) will be processed in the SYN-RECEIVED state,
but processing of SYN and ACK should not be repeated.
If the listen was not fully specified (i.e., the foreign
socket was not fully specified), then the unspecified
fields should be filled in now.
</t>
</list>
</t>
<t>fourth other text or control
<list>
<t>...
</t>
</list>
</t>
</list>
</t>
<t>If the state is SYN-SENT then
<list>
<t>first check the ACK bit
<list>
<t>...
</t>
</list>
</t>
<t>...
</t>
<t>fourth check the SYN bit
<list>
<t>...
</t>
<t>If the SYN bit is on and the security/compartment and
precedence are acceptable then, RCV.NXT is set to
SEG.SEQ+1, IRS is set to SEG.SEQ, and any
acknowledgments on the retransmission queue which
are thereby acknowledged should be removed.
</t>
<t>Check for a Window Scale option (WSopt); if it<!--[###]-->
is found, save SEG.WSopt in Snd.Wind.Shift; otherwise,
set both Snd.Wind.Shift and Rcv.Wind.Shift to zero.
</t>
<t>Check for a TSopt option; if one is found, save
SEG.TSval in variable TS.Recent and turn on the
Snd.TS.OK bit in the connection control block. If
the ACK bit is set, use Snd.TSclock - SEG.TSecr as
the initial RTT estimate.
</t>
<t>If SND.UNA > ISS (our <SYN> has been ACKed), change the
connection state to ESTABLISHED, form an <ACK> segment:
<figure align="center">
<artwork align="center"><![CDATA[
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
]]></artwork>
</figure>
and send it. If the Snd.Echo.OK bit is on, include
a TSopt option <TSval=Snd.TSclock,TSecr=TS.Recent>
in this <ACK> segment. Last.ACK.sent is set to RCV.NXT.
</t>
<t>Data or controls which were queued for transmission
may be included. If there are other controls or text
in the segment then continue processing at the sixth
step below where the URG bit is checked, otherwise
return.
</t>
<t>Otherwise enter SYN-RECEIVED, form a <SYN,ACK> segment:
<figure align="center">
<artwork align="center"><![CDATA[
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
]]></artwork>
</figure>
and send it. If the Snd.Echo.OK bit is on, include
a TSopt option <TSval=Snd.TSclock,TSecr=TS.Recent>
in this segment. If the Snd.WS.OK bit is on, include
a WSopt option <WSopt=Rcv.Wind.Shift> in this
segment. Last.ACK.sent is set to RCV.NXT.
</t>
<t>If there are other controls or text in the segment,
queue them for processing after the ESTABLISHED state
has been reached, return.
</t>
</list>
</t>
<t>fifth, if neither of the SYN or RST bits is set then
drop the segment and return.
</t>
</list>
</t>
<t>Otherwise,
</t>
<t>First, check sequence number
<list>
<t>SYN-RECEIVED STATE<vspace blankLines="0"/>
ESTABLISHED STATE<vspace blankLines="0"/>
FIN-WAIT-1 STATE<vspace blankLines="0"/>
FIN-WAIT-2 STATE<vspace blankLines="0"/>
CLOSE-WAIT STATE<vspace blankLines="0"/>
CLOSING STATE<vspace blankLines="0"/>
LAST-ACK STATE<vspace blankLines="0"/>
TIME-WAIT STATE
<list>
<t>Segments are processed in sequence. Initial tests
on arrival are used to discard old duplicates, but
further processing is done in SEG.SEQ order. If a
segment's contents straddle the boundary between old
and new, only the new parts should be processed.
</t>
<t>Rescale the received window field:
<figure align="center">
<artwork align="center"><![CDATA[
TrueWindow = SEG.WND << Snd.Wind.Shift,
]]></artwork>
</figure>
and use "TrueWindow" in place of SEG.WND in the
following steps.
</t>
<t>Check whether the segment contains a Timestamps
option and bit Snd.TS.OK is on. If so:
<list>
<t>If SEG.TSval < TS.Recent and the RST bit
is off, then test whether connection has been
idle less than 24 days; if all are true, then
the segment is not acceptable; follow steps
below for an unacceptable segment.
</t>
<t>If SEG.SEQ is less than or equal to Last.ACK.sent, then
save SEG.TSval in variable TS.Recent.
</t>
</list>
</t>
<t>There are four cases for the acceptability test
for an incoming segment:
<list>
<t>...
</t>
</list>
</t>
<t>If an incoming segment is not acceptable, an
acknowledgment should be sent in reply (unless
the RST bit is set, if so drop the segment and
return):
<figure align="center">
<artwork align="center"><![CDATA[
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
]]></artwork>
</figure>
</t>
<t>Last.ACK.sent is set to SEG.ACK of the
acknowledgment. If the Snd.Echo.OK bit is on,
include the Timestamps option
<TSval=Snd.TSclock,TSecr=TS.Recent> in this
<ACK> segment. Set Last.ACK.sent to SEG.ACK and send
the <ACK> segment. After sending the acknowledgment,
drop the unacceptable segment and return.
</t>
</list>
</t>
</list>
</t>
<t>...
</t>
<t>fifth check the ACK field.
<list>
<t>if the ACK bit is off drop the segment and return.
</t>
<t>if the ACK bit is on
<list>
<t>...
</t>
<t>ESTABLISHED STATE
<list>
<t>If SND.UNA < SEG.ACK <= SND.NXT then, set
SND.UNA <-<!--[###]--> SEG.ACK. Also compute a new estimate
of round-trip time. If Snd.TS.OK bit is on, use
Snd.TSclock - SEG.TSecr; otherwise use the
elapsed time since the first segment in the
retransmission queue was sent. Any segments on
the retransmission queue which are thereby entirely
acknowledged...
</t>
</list>
</t>
</list>
</t>
</list>
</t>
<t>...
</t>
<t>Seventh, process the segment text.
<list>
<t>ESTABLISHED STATE<vspace blankLines="0"/>
FIN-WAIT-1 STATE<vspace blankLines="0"/>
FIN-WAIT-2 STATE
<list>
<t>...
</t>
<t>Send an acknowledgment of the form:
<figure align="center">
<artwork align="center"><![CDATA[
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
]]></artwork>
</figure>
</t>
<t>If the Snd.TS.OK bit is on, include Timestamps
option <TSval=Snd.TSclock,TSecr=TS.Recent>
in this <ACK> segment. Set Last.ACK.sent to SEG.ACK
of the acknowledgment, and send it. This
acknowledgment should be piggy-backed on a segment
being transmitted if possible without incurring
undue delay.
</t>
<t>...
</t>
</list>
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="AppG" title="Timestamps Edge Cases">
<t>While the rules laid out for when to calculate RTTM produce the
correct results most of the time, there are some edge cases where an
incorrect RTTM can be calculated. All of these situations involve
the loss of segments. It is felt that these scenarios are rare, and
that if they should happen, they will cause a single RTTM measurement
to be inflated, which mitigates its effects on RTO calculations.
</t>
<t><xref target="Martin03"/> cites two similar cases when the
returning <ACK> is lost,
and before the retransmission timer fires, another returning <ACK> segment
arrives, which aknowledges the data. In this case, the RTTM calculated will
be inflated:
<figure align="center">
<artwork align="center"><![CDATA[
clock
tc=1 <A, TSval=1> ------------------->
tc=2 (lost) <---- <ACK(A), TSecr=1, win=n>
(RTTM would have been 1)
(receive window opens, window update is sent)
tc=5 <---- <ACK(A), TSecr=1, win=m>
(RTTM is calculated at 4)
]]></artwork>
</figure>
</t>
<t>One thing to note about this situation is that it is somewhat bounded
by RTO + RTT, limiting how far off the RTTM calculation will be.
While more complex scenarios can be constructed that produce larger
inflations (e.g., retransmissions are lost), those scenarios involve
multiple segment losses, and the connection will have other more
serious operational problems than using an inflated RTTM in the RTO
calculation.
</t>
</section>
<section anchor="AppH" title="Window Retraction Example">
<t>Consider an established TCP connection using a scale factor
of 128, Snd.Wind.Shift=7 and Rcv.Wind.Shift=7, that is running
with a very small window because the receiver
is bottlenecked and both ends are doing small reads and writes.
</t>
<t>Consider the ACKs coming back:
<figure align="center">
<artwork align="left"><![CDATA[
SEG.ACK SEG.WIN computed SND.WIN receiver's actual window
1000 2 1256 1300
]]></artwork>
</figure>
</t>
<t>The sender writes 40 bytes and receiver ACKs:
<figure align="center">
<artwork align="left"><![CDATA[
1040 2 1296 1300
]]></artwork>
</figure>
</t>
<t>The sender writes 5 additional bytes and the receiver has a problem.
Two choices:
<figure align="center">
<artwork align="left"><![CDATA[
1045 2 1301 1300 - BEYOND BUFFER
1045 1 1173 1300 - RETRACTED WINDOW
]]></artwork>
</figure>
</t>
<t>This is a general problem and can happen
any time the sender does a write which is smaller
than the window scale factor.
</t>
<t>In most stacks it is at least partially obscured when the window
size is larger than some small number of segments because the stacks
prefer to announce windows that are an integral number of segments,
rounded up to the next scale factor. This plus silly window
suppression tends to cause less frequent, larger window updates.
If the window was rounded down to a segment size there is more
opportunity to advance the window, the BEYOND BUFFER case above,
rather than retracting it.
</t>
</section>
<section anchor="AppI" title="RTO calculation modification">
<t>
Taking multiple RTT samples per window would shorten the history
calculated by the RTO mechanism in <xref target="RFC6298"/>, and
the below algorithm aims to maintain a similar history as originally
intended by <xref target="RFC6298"/>.
</t>
<t>
It is roughly known how many samples
a congestion window worth of data will yield, not accounting
for ACK compression, and ACK losses. Such events will result in
more history of the path being reflected in the final value
for RTO, and are uncritical. This modification will ensure
that a similar amount of time is taken into account for the
RTO estimation, regardless of how many samples are taken per
window:
<list>
<t>ExpectedSamples = ceiling(FlightSize / (SMSS * 2))
</t>
<t>alpha' = alpha / ExpectedSamples
</t>
<t>beta' = beta / ExpectedSamples
</t>
</list>
Note that the factor 2 in ExpectedSamples is due to "Delayed ACKs".
</t>
<t>Instead of using alpha and beta in the algorithm of
<xref target="RFC6298"/>, use alpha' and beta' instead:
<list>
<t>RTTVAR <- (1 - beta') * RTTVAR + beta' * |SRTT - R'|
</t>
<t>SRTT <- (1 - alpha') * SRTT + alpha' * R'
</t>
<t>(for each sample R')
</t>
</list>
</t>
<!--
<t>
Alternatively, an implementation could choose to just use one sample
per RTT to update the RTO estimator. By using the statistical
properties of the additional samples, , e.g. use the maximum devation
in that window to update RTTVAR, and the last RTT sample to update
SRTT . In the second approach, the expected number of samples can be
estimated by FlightSize / (SMSS * 2), accounting for delayed ACKs.
</t>
-->
</section>
<!--
<section anchor="AppC" title="Changes from RFC 1072, RFC 1185, and RFC 1323">
-->
<section anchor="AppC" title="Changes from RFC 1323">
<!--
<t>The protocol extensions defined in RFC 1323 document differ in
several important ways from those defined in RFC 1072 and RFC 1185.
<list style="format (%c)">
<t>SACK has been split off into a separate document,
<xref target="RFC2018"/><!-xref target="Mathis96"/->.
</t>
<t>The detailed rules for sending timestamp replies (see
<xref target="sec34"/>) differ in important ways. The earlier
rules could result in an under-estimate of the RTT in certain
cases (packets dropped or out of order).
</t>
<t>The same value TS.Recent is now shared by the two distinct
mechanisms RTTM and PAWS. This simplification became possible
because of change (b).
</t>
<t>An ambiguity in RFC 1185 was resolved in favor of putting
timestamps on ACK as well as data segments. This supports the
symmetry of the underlying TCP protocol.
</t>
<t>The echo and echo reply options of RFC 1072 were combined into a
single Timestamps option, to reflect the symmetry and to
simplify processing.
</t>
<t>The problem of outdated timestamps on long-idle connections,
discussed in <xref target="sec422"/>, was realized and resolved.
</t>
<t>RFC 1185 recommended that header prediction take precedence over
the timestamp check. Based upon some skepticism about the
probabilistic arguments given in <xref target="sec424"/>,
it was decided
to recommend that the timestamp check be performed first.
</t>
<t>The spec was modified so that the extended options will be sent
on <SYN,ACK> segments only when they are received in the
corresponding <SYN> segments. This provides the most
conservative possible conditions for interoperation with
implementations without the extensions.
</t>
</list>
</t>
<t>In addition to these substantive changes, the present RFC
attempts to specify the algorithms unambiguously by presenting
modifications to the Event Processing rules of RFC 793;
see <xref target="AppF"/>.
</t>
<t>There are additional changes in this document from RFC 1323. These
changes are:-->
<t>Several important updates and clarifications to the specification
in RFC 1323 are made in these document. The technical changes are
summarized below:
<list style="format (%c)">
<t><!-- -13:2.3 -->A wrong reference to SND.WND was corrected
to SEG.WND in <xref target="sec23"/>
</t>
<t><!-- -08:2.4 --><xref target="sec24"/> was added describing
the unavoidable window retraction issue, and explicitly
describing the mitigation steps necessary.
</t>
<t><!-- -08:3.2 -->In <xref target="sec32"/> the wording how
the Timestamps option negotiation is to be performed was
updated with RFC2119 wording. Further, a number of paragraphs
were added to clarify the expected behavior with a compliant
implementation using TSopt, as RFC1323 left room for
interpretation - e.g. potential late enablement of TSopt.
</t>
<t><!-- -08:3.3 -->The description of which TSecr values can be
used to update the measured RTT has been clarified.
Specifically, with timestamps, the Karn algorithm
<xref target="Karn87"/> is disabled. The Karn algorithm
disables all RTT measurements during retransmission, since it
is ambiguous whether the <ACK> is for the original
segment, or the retransmitted segment. With timestamps,
that ambiguity is removed since the TSecr in the <ACK>
will contain the TSval from whichever data segment made it
to the destination.
</t>
<t><!-- -08:3.3 -->RTTM update processing explicitly excludes
segments not updating SND.UNA. The original text could be
interpreted to allow taking RTT samples when SACK acknowledges
some new, non-continuous data.
</t>
<t><!-- -08:3.4 -->In RFC1323, section 3.4, step (2) of the
algorithm to control which timestamp is echoed was incorrect
in two regards:
<list style="format (%d)">
<t>It failed to update TS.recent for a retransmitted segment
that resulted from a lost <ACK>.
</t>
<t>It failed if SEG.LEN = 0.
</t>
</list>
In the new algorithm, the case of SEG.TSval >= TS.recent is
included for consistency with the PAWS test.
</t>
<t><!-- -08:4.2 -->It is now recommended that the Timestamps
option is included in <RST> segments if the incoming
segment contained a Timestamps option.
</t>
<t><!-- -08:4.2,4.3 --><RST> segments are explicitly
excluded from PAWS processing.
</t>
<t><!-- -08:4.3 -->Added text to clarify the precedence between
regular TCP <xref target="RFC0793"/> and this document
Timestamps option / PAWS processing. Discussion about combined
acceptability checks are ongoing.
</t>
<t><!-- -08:4.4,6,AppC -->Snd.TSoffset and Snd.TSclock variables
have been added. Snd.TSclock is the sum of my.TSclock and
Snd.TSoffset. This allows the starting points for timestamp
values to be randomized on a per-connection basis. Setting
Snd.TSoffset to zero yields the same results as
<xref target="RFC1323"/>. Text was added to guide implementers
to the proper selection of these offsets, as entirely random
offsets for each new connection will conflict with PAWS.
</t>
<t><!-- -8:AppA --><xref target="AppA"/> has been expanded with
information about the TCP Urgent Pointer. An earlier revision
contained text around the TCP MSS option, which was split off
into <xref target="RFC6691"/>.
</t>
<t><!-- -08:AppD -->One correction was made to the Event
Processing Summary in <xref target="AppF"/>. In SEND
CALL/ESTABLISHED STATE, RCV.WND is used to fill in the SEG.WND
value, not SND.WND.
</t>
<t><xref target="AppI"/> was added to exemplify how an RTO
calculation might be updated to properly take the much higher
RTT sampling frequency enabled by the Timestamps option
into account.
</t>
</list>
</t>
<t>Editorial changes of the document, that don't impact the
implementation or function of the mechanisms described in this
document include:
<list style="format (%c)">
<t><!-- -08:1.1,1.2,1.3 -->Removed much of the discussion in
<xref target="sec1"/> to streamline the document. However,
detailed examples and discussions in <xref target="sec2"/>,
<xref target="sec3"/> and <xref target="sec4"/> are kept as
guideline for implementers.
</t>
<t>Added short text that the use of WS increases the chances of sequence number wrap, thus the PAWS mechanism is required in certain environments.</t>
<t><!-- -08:1.3 -->Removed references to "new" options, as
the options were introduced in <xref target="RFC1323"/>
already. Changed the text in <xref target="sec13"/> to
specifically address TS and WS options.
</t>
<t><!-- -08:1.4 --><xref target="secTerm"/> was added for
<xref target="RFC2119"/> wording. Normative text was updated with the
appropriate phrases.
</t>
<t><!-- docwide -->Added < > brackets to mark specific
types of segments, and replaced most occurences of "packet"
with "segment", where TCP segments are referred to.
</t>
<t><!-- -12:3 -->Updated the text in <xref target="sec3"/>
to take into account what has been learned since
<xref target="RFC1323"/>.
</t>
<t>Removed some unused references.
</t>
<t><!-- AppC -->Removed the list of changes between
<xref target="RFC1323"/> and prior versions. These changes
are mentioned in Appendix C of <xref target="RFC1323"/>.
</t>
<t><!-- -08:AppG -->Moved Appendix
<xref target="AppC" format="title"/> to the end of the
appendices for easier lookup. In addition, the entries were
split into a technical and an editorial part, and sorted to
roughly correspond with the sections in the text where they
apply.
</t>
</list>
</t>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-21 21:06:25 |