draft-ietf-tcpm-1323bis-03.txt   draft-ietf-tcpm-1323bis-04.txt 
TCP Maintenance (TCPM) D. Borman TCP Maintenance (TCPM) D. Borman
Internet-Draft Quantum Corporation Internet-Draft Quantum Corporation
Intended status: Standards Track B. Braden Intended status: Standards Track B. Braden
Expires: January 12, 2013 University of Southern Expires: February 3, 2013 University of Southern
California California
V. Jacobson V. Jacobson
Packet Design Packet Design
R. Scheffenegger, Ed. R. Scheffenegger, Ed.
NetApp, Inc. NetApp, Inc.
July 11, 2012 August 2, 2012
TCP Extensions for High Performance TCP Extensions for High Performance
draft-ietf-tcpm-1323bis-03 draft-ietf-tcpm-1323bis-04
Abstract Abstract
This memo presents a set of TCP extensions to improve performance This memo presents a set of TCP extensions to improve performance
over large bandwidth*delay product paths and to provide reliable over large bandwidth*delay product paths and to provide reliable
operation over very high-speed paths. It defines TCP options for operation over very high-speed paths. It defines TCP options for
scaled windows and timestamps, which are designed to provide scaled windows and timestamps, which are designed to provide
compatible interworking with TCP's that do not implement the compatible interworking with TCP's that do not implement the
extensions. The timestamps are used for two distinct mechanisms: extensions. The timestamps are used for two distinct mechanisms:
RTTM (Round Trip Time Measurement) and PAWS (Protection Against RTTM (Round Trip Time Measurement) and PAWS (Protection Against
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2013. This Internet-Draft will expire on February 3, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 11 skipping to change at page 3, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. TCP Performance . . . . . . . . . . . . . . . . . . . . . 4 1.1. TCP Performance . . . . . . . . . . . . . . . . . . . . . 4
1.2. TCP Reliability . . . . . . . . . . . . . . . . . . . . . 6 1.2. TCP Reliability . . . . . . . . . . . . . . . . . . . . . 6
1.3. Using TCP options . . . . . . . . . . . . . . . . . . . . 9 1.3. Using TCP options . . . . . . . . . . . . . . . . . . . . 9
2. TCP Window Scale Option . . . . . . . . . . . . . . . . . . . 10 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 3. TCP Window Scale Option . . . . . . . . . . . . . . . . . . . 10
2.2. Window Scale Option . . . . . . . . . . . . . . . . . . . 10 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Using the Window Scale Option . . . . . . . . . . . . . . 11 3.2. Window Scale Option . . . . . . . . . . . . . . . . . . . 10
2.4. Addressing Window Retraction . . . . . . . . . . . . . . . 13 3.3. Using the Window Scale Option . . . . . . . . . . . . . . 11
3. RTTM -- Round-Trip Time Measurement . . . . . . . . . . . . . 13 3.4. Addressing Window Retraction . . . . . . . . . . . . . . . 13
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 13 4. RTTM -- Round-Trip Time Measurement . . . . . . . . . . . . . 14
3.2. TCP Timestamps Option . . . . . . . . . . . . . . . . . . 14 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. The RTTM Mechanism . . . . . . . . . . . . . . . . . . . . 15 4.2. TCP Timestamps Option . . . . . . . . . . . . . . . . . . 15
3.4. Which Timestamp to Echo . . . . . . . . . . . . . . . . . 17 4.3. The RTTM Mechanism . . . . . . . . . . . . . . . . . . . . 16
4. PAWS -- Protection Against Wrapped Sequence Numbers . . . . . 19 4.4. Which Timestamp to Echo . . . . . . . . . . . . . . . . . 17
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 19 5. PAWS -- Protection Against Wrapped Sequence Numbers . . . . . 20
4.2. The PAWS Mechanism . . . . . . . . . . . . . . . . . . . . 20 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.1. Basic PAWS Algorithm . . . . . . . . . . . . . . . . . 21 5.2. The PAWS Mechanism . . . . . . . . . . . . . . . . . . . . 20
4.2.2. Timestamp Clock . . . . . . . . . . . . . . . . . . . 23 5.2.1. Basic PAWS Algorithm . . . . . . . . . . . . . . . . . 21
4.2.3. Outdated Timestamps . . . . . . . . . . . . . . . . . 24 5.2.2. Timestamp Clock . . . . . . . . . . . . . . . . . . . 23
4.2.4. Header Prediction . . . . . . . . . . . . . . . . . . 25 5.2.3. Outdated Timestamps . . . . . . . . . . . . . . . . . 25
4.2.5. IP Fragmentation . . . . . . . . . . . . . . . . . . . 26 5.2.4. Header Prediction . . . . . . . . . . . . . . . . . . 25
4.3. Duplicates from Earlier Incarnations of Connection . . . . 27 5.2.5. IP Fragmentation . . . . . . . . . . . . . . . . . . . 27
5. Conclusions and Acknowledgements . . . . . . . . . . . . . . . 27 5.3. Duplicates from Earlier Incarnations of Connection . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Conclusions and Acknowledgements . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Implementation Suggestions . . . . . . . . . . . . . 31 Appendix A. Implementation Suggestions . . . . . . . . . . . . . 31
Appendix B. Duplicates from Earlier Connection Incarnations . . . 32 Appendix B. Duplicates from Earlier Connection Incarnations . . . 32
B.1. System Crash with Loss of State . . . . . . . . . . . . . 32 B.1. System Crash with Loss of State . . . . . . . . . . . . . 32
B.2. Closing and Reopening a Connection . . . . . . . . . . . . 33 B.2. Closing and Reopening a Connection . . . . . . . . . . . . 33
Appendix C. Changes from RFC 1072, RFC 1185, and RFC 1323 . . . . 34 Appendix C. Changes from RFC 1072, RFC 1185, and RFC 1323 . . . . 34
Appendix D. Summary of Notation . . . . . . . . . . . . . . . . . 36 Appendix D. Summary of Notation . . . . . . . . . . . . . . . . . 36
Appendix E. Pseudo-code Summary . . . . . . . . . . . . . . . . . 37 Appendix E. Pseudo-code Summary . . . . . . . . . . . . . . . . . 37
Appendix F. Event Processing Summary . . . . . . . . . . . . . . 39 Appendix F. Event Processing Summary . . . . . . . . . . . . . . 39
Appendix G. Timestamps Edge Cases . . . . . . . . . . . . . . . . 44 Appendix G. Timestamps Edge Cases . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
The TCP protocol [RFC0793] was designed to operate reliably over The TCP protocol [RFC0793] was designed to operate reliably over
almost any transmission medium regardless of transmission rate, almost any transmission medium regardless of transmission rate,
delay, corruption, duplication, or reordering of segments. delay, corruption, duplication, or reordering of segments.
Production TCP implementations currently adapt to transfer rates in Production TCP implementations currently adapt to transfer rates in
the range of 100 bps to 10^10 bps and round-trip delays in the range the range of 100 bps to 10^10 bps and round-trip delays in the range
1 ms to 100 seconds. Work on TCP performance has shown that TCP 1 ms to 100 seconds. Work on TCP performance has shown that TCP
skipping to change at page 6, line 17 skipping to change at page 6, line 17
(3) Round-Trip Measurement (3) Round-Trip Measurement
TCP implements reliable data delivery by retransmitting segments TCP implements reliable data delivery by retransmitting segments
that are not acknowledged within some retransmission timeout that are not acknowledged within some retransmission timeout
(RTO) interval. Accurate dynamic determination of an (RTO) interval. Accurate dynamic determination of an
appropriate RTO is essential to TCP performance. RTO is appropriate RTO is essential to TCP performance. RTO is
determined by estimating the mean and variance of the measured determined by estimating the mean and variance of the measured
round-trip time (RTT), i.e., the time interval between sending a round-trip time (RTT), i.e., the time interval between sending a
segment and receiving an acknowledgment for it [Jacobson88a]. segment and receiving an acknowledgment for it [Jacobson88a].
Section 3.2 introduces a new TCP option, "Timestamps", and then Section 4.2 introduces a new TCP option, "Timestamps", and then
defines a mechanism using this option that allows nearly every defines a mechanism using this option that allows nearly every
segment, including retransmissions, to be timed at negligible segment, including retransmissions, to be timed at negligible
computational cost. We use the mnemonic RTTM (Round Trip Time computational cost. We use the mnemonic RTTM (Round Trip Time
Measurement) for this mechanism, to distinguish it from other Measurement) for this mechanism, to distinguish it from other
uses of the Timestamps option. uses of the Timestamps option.
1.2. TCP Reliability 1.2. TCP Reliability
Now we turn from performance to reliability. High transfer rate Now we turn from performance to reliability. High transfer rate
enters TCP performance through the bandwidth*delay product. However, enters TCP performance through the bandwidth*delay product. However,
skipping to change at page 7, line 22 skipping to change at page 7, line 22
Suppose that a connection terminates, either by a proper close Suppose that a connection terminates, either by a proper close
sequence or due to a host crash, and the same connection (i.e., sequence or due to a host crash, and the same connection (i.e.,
using the same pair of port numbers) is immediately reopened. A using the same pair of port numbers) is immediately reopened. A
delayed segment from the terminated connection could fall within delayed segment from the terminated connection could fall within
the current window for the new incarnation and be accepted as the current window for the new incarnation and be accepted as
valid. valid.
Duplicates from earlier incarnations, Case (2), are avoided by Duplicates from earlier incarnations, Case (2), are avoided by
enforcing the current fixed MSL of the TCP spec, as explained in enforcing the current fixed MSL of the TCP spec, as explained in
Section 4.3 and Appendix B. However, case (1), avoiding the reuse of Section 5.3 and Appendix B. However, case (1), avoiding the reuse of
sequence numbers within the same connection, requires an MSL bound sequence numbers within the same connection, requires an MSL bound
that depends upon the transfer rate, and at high enough rates, a new that depends upon the transfer rate, and at high enough rates, a new
mechanism is required. mechanism is required.
More specifically, if the maximum effective bandwidth at which TCP is More specifically, if the maximum effective bandwidth at which TCP is
able to transmit over a particular path is B bytes per second, then able to transmit over a particular path is B bytes per second, then
the following constraint must be satisfied for error-free operation: the following constraint must be satisfied for error-free operation:
2^31 / B > MSL (secs) [1] 2^31 / B > MSL (secs) [1]
skipping to change at page 8, line 42 skipping to change at page 8, line 42
depend upon active enforcement of MSL for TCP connections, and it is depend upon active enforcement of MSL for TCP connections, and it is
unrealistic to imagine setting MSL's smaller than the current values unrealistic to imagine setting MSL's smaller than the current values
(e.g., 120 seconds specified for TCP). (e.g., 120 seconds specified for TCP).
A possible fix for the problem of cycling the sequence space would be 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, to increase the size of the TCP sequence number field. For example,
the sequence number field (and also the acknowledgment field) could the sequence number field (and also the acknowledgment field) could
be expanded to 64 bits. This could be done either by changing the be expanded to 64 bits. This could be done either by changing the
TCP header or by means of an additional option. TCP header or by means of an additional option.
Section 4 presents a different mechanism, which we call PAWS Section 5 presents a different mechanism, which we call PAWS
(Protection Against Wrapped Sequence numbers), to extend TCP (Protection Against Wrapped Sequence numbers), to extend TCP
reliability to transfer rates well beyond the foreseeable upper limit reliability to transfer rates well beyond the foreseeable upper limit
of network bandwidths. PAWS uses the TCP Timestamps option defined of network bandwidths. PAWS uses the TCP Timestamps option defined
in Section 3.2 to protect against old duplicates from the same in Section 4.2 to protect against old duplicates from the same
connection. connection.
1.3. Using TCP options 1.3. Using TCP options
The extensions defined in this memo all use new TCP options. We must The extensions defined in this memo all use new TCP options. We must
address two possible issues concerning the use of TCP options: (1) address two possible issues concerning the use of TCP options: (1)
compatibility and (2) overhead. compatibility and (2) overhead.
We must pay careful attention to compatibility, i.e., to We must pay careful attention to compatibility, i.e., to
interoperation with existing implementations. The only TCP option interoperation with existing implementations. The only TCP option
skipping to change at page 10, line 13 skipping to change at page 10, line 13
efficiency. efficiency.
Finally, we observe that most of the mechanisms defined in this memo Finally, we observe that most of the mechanisms defined in this memo
are important for LFN's and/or very high-speed networks. For low- are important for LFN's and/or very high-speed networks. For low-
speed networks, it might be a performance optimization to NOT use speed networks, it might be a performance optimization to NOT use
these mechanisms. A TCP vendor concerned about optimal performance these mechanisms. A TCP vendor concerned about optimal performance
over low-speed paths might consider turning these extensions off for over low-speed paths might consider turning these extensions off for
low-speed paths, or allow a user or installation manager to disable low-speed paths, or allow a user or installation manager to disable
them. them.
2. TCP Window Scale Option 2. Terminology
2.1. Introduction 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 [RFC2119].
3. TCP Window Scale Option
3.1. Introduction
The window scale extension expands the definition of the TCP window The window scale extension expands the definition of the TCP window
to 32 bits and then uses a scale factor to carry this 32-bit value in to 32 bits and then uses a scale factor to carry this 32-bit value in
the 16-bit Window field of the TCP header (SEG.WND in RFC 793). The the 16-bit Window field of the TCP header (SEG.WND in RFC 793). The
scale factor is carried in a new TCP option, Window Scale. This scale factor is carried in a new TCP option, Window Scale. This
option is sent only in a SYN segment (a segment with the SYN bit on), 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 hence the window scale is fixed in each direction when a connection
is opened. (Another design choice would be to specify the window is opened. (Another design choice would be to specify the window
scale in every TCP segment. It would be incorrect to send a window scale in every TCP segment. It would be incorrect to send a window
scale option only when the scale factor changed, since a TCP option scale option only when the scale factor changed, since a TCP option
skipping to change at page 10, line 39 skipping to change at page 10, line 45
lower overhead but the disadvantage that the scale factor cannot be lower overhead but the disadvantage that the scale factor cannot be
changed during the connection.) changed during the connection.)
The maximum receive window, and therefore the scale factor, is The maximum receive window, and therefore the scale factor, is
determined by the maximum receive buffer space. In a typical modern determined by the maximum receive buffer space. In a typical modern
implementation, this maximum buffer space is set by default but can implementation, this maximum buffer space is set by default but can
be overridden by a user program before a TCP connection is opened. be overridden by a user program before a TCP connection is opened.
This determines the scale factor, and therefore no new user interface This determines the scale factor, and therefore no new user interface
is needed for window scaling. is needed for window scaling.
2.2. Window Scale Option 3.2. Window Scale Option
The three-byte Window Scale option may be sent in a SYN segment by a 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 TCP. It has two purposes: (1) indicate that the TCP is prepared to
do both send and receive window scaling, and (2) communicate a scale do both send and receive window scaling, and (2) communicate a scale
factor to be applied to its receive window. Thus, a TCP that is 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 prepared to scale windows SHOULD send the option, even if its own
scale factor is 1. The scale factor is limited to a power of two and scale factor is 1. The scale factor is limited to a power of two and
encoded logarithmically, so it may be implemented by binary shift encoded logarithmically, so it may be implemented by binary shift
operations. operations.
TCP Window Scale Option (WSopt): TCP Window Scale Option (WSopt):
Kind: 3 Kind: 3
Length: 3 bytes Length: 3 bytes
+---------+---------+---------+ +---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt| | Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+ +---------+---------+---------+
1 1 1
This option is an offer, not a promise; both sides must send Window This option is an offer, not a promise; both sides MUST send Window
Scale options in their SYN segments to enable window scaling in Scale options in their SYN segments to enable window scaling in
either direction. If window scaling is enabled, then the TCP that either direction. If window scaling is enabled, then the TCP that
sent this option will right-shift its true receive-window values by sent this option will right-shift its true receive-window values by
'shift.cnt' bits for transmission in SEG.WND. The value 'shift.cnt' '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 MAY be zero (offering to scale, while applying a scale factor of 1 to
the receive window). the receive window).
This option may be sent in an initial <SYN> segment (i.e., a segment This option MAY be sent in an initial <SYN> segment (i.e., a segment
with the SYN bit on and the ACK bit off). It may also be sent in a with the SYN bit on and the ACK bit off). It MAY also be sent in a
<SYN,ACK> segment, but only if a Window Scale option was received in <SYN,ACK> segment, but only if a Window Scale option was received in
the initial <SYN> segment. A Window Scale option in a segment the initial <SYN> segment. A Window Scale option in a segment
without a SYN bit should be ignored. without a SYN bit SHOULD be ignored.
The Window field in a SYN (i.e., a <SYN> or <SYN,ACK>) segment itself The Window field in a SYN (i.e., a <SYN> or <SYN,ACK>) segment itself
is never scaled. is never scaled.
2.3. Using the Window Scale Option 3.3. Using the Window Scale Option
A model implementation of window scaling is as follows, using the A model implementation of window scaling is as follows, using the
notation of [RFC0793]: notation of [RFC0793]:
o All windows are treated as 32-bit quantities for storage in the o All windows are treated as 32-bit quantities for storage in the
connection control block and for local calculations. This connection control block and for local calculations. This
includes the send-window (SND.WND) and the receive-window includes the send-window (SND.WND) and the receive-window
(RCV.WND) values, as well as the congestion window. (RCV.WND) values, as well as the congestion window.
o The connection state is augmented by two window shift counts, o The connection state is augmented by two window shift counts,
skipping to change at page 12, line 13 skipping to change at page 12, line 23
shift.cnt = S, a TCP sets Snd.Wind.Scale to S and sets shift.cnt = S, a TCP sets Snd.Wind.Scale to S and sets
Rcv.Wind.Scale to R; otherwise, it sets both Snd.Wind.Scale and Rcv.Wind.Scale to R; otherwise, it sets both Snd.Wind.Scale and
Rcv.Wind.Scale to zero. Rcv.Wind.Scale to zero.
o The window field (SEG.WND) in the header of every incoming o The window field (SEG.WND) in the header of every incoming
segment, with the exception of SYN segments, is left-shifted by segment, with the exception of SYN segments, is left-shifted by
Snd.Wind.Scale bits before updating SND.WND: Snd.Wind.Scale bits before updating SND.WND:
SND.WND = SEG.WND << Snd.Wind.Scale SND.WND = SEG.WND << Snd.Wind.Scale
(assuming the other conditions of RFC 793 are met, and using the (assuming the other conditions of [RFC0793] are met, and using the
"C" notation "<<" for left-shift). "C" notation "<<" for left-shift).
o The window field (SEG.WND) of every outgoing segment, with the o The window field (SEG.WND) of every outgoing segment, with the
exception of SYN segments, is right-shifted by Rcv.Wind.Scale exception of SYN segments, is right-shifted by Rcv.Wind.Scale
bits: bits:
SND.WND = RCV.WND >> Rcv.Wind.Scale SND.WND = RCV.WND >> Rcv.Wind.Scale
TCP determines if a data segment is "old" or "new" by testing whether 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 its sequence number is within 2^31 bytes of the left edge of the
skipping to change at page 12, line 38 skipping to change at page 12, line 48
right edge and receiver's left edge. Since the right and left edges 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 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 size, and since the sender and receiver windows can be out of phase
by at most the window size, the above constraints imply that 2 * the by at most the window size, the above constraints imply that 2 * the
max window size must be less than 2^31, or max window size must be less than 2^31, or
max window < 2^30 max window < 2^30
Since the max window is 2^S (where S is the scaling shift count) 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 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 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 Gbyte). If a MUST be limited to 14 (which allows windows of 2^30 = 1 Gbyte). If a
Window Scale option is received with a shift.cnt value exceeding 14, Window Scale option is received with a shift.cnt value exceeding 14,
the TCP should log the error but use 14 instead of the specified the TCP SHOULD log the error but use 14 instead of the specified
value. value.
The scale factor applies only to the Window field as transmitted in The scale factor applies only to the Window field as transmitted in
the TCP header; each TCP using extended windows will maintain the the TCP header; each TCP using extended windows will maintain the
window values locally as 32-bit numbers. For example, the window values locally as 32-bit numbers. For example, the
"congestion window" computed by Slow Start and Congestion Avoidance "congestion window" computed by Slow Start and Congestion Avoidance
is not affected by the scale factor, so window scaling will not is not affected by the scale factor, so window scaling will not
introduce quantization into the congestion window. introduce quantization into the congestion window.
2.4. Addressing Window Retraction 3.4. Addressing Window Retraction
When a non-zero scale factor is in use, there are instances when a When a non-zero scale factor is in use, there are instances when a
retracted window can be offered [Mathis08]. The end of the window retracted window can be offered [Mathis08]. The end of the window
will be on a boundary based on the granularity of the scale factor 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 being used. If the sequence number is then updated by a number of
bytes smaller than that granularity, the TCP will have to either bytes smaller than that granularity, the TCP will have to either
advertise a new window that is beyond what it previously advertised advertise a new window that is beyond what it previously advertised
(and perhaps beyond the buffer), or will have to advertise a smaller (and perhaps beyond the buffer), or will have to advertise a smaller
window, which will cause the TCP window to shrink. Implementations window, which will cause the TCP window to shrink. Implementations
should ensure that they handle a shrinking window, as specified in MUST ensure that they handle a shrinking window, as specified in
section 4.2.2.16 of [RFC1122]. section 4.2.2.16 of [RFC1122].
For the receiver, this implies that: For the receiver, this implies that:
1) The receiver MUST honor, as in-window, any segment that would 1) The receiver MUST honor, as in-window, any segment that would
have been in-window for any ACK sent by the receiver. have been in-window for any ACK sent by the receiver.
2) When window scaling is in effect, the receiver SHOULD track the 2) When window scaling is in effect, the receiver SHOULD track the
actual maximum window sequence number (which is likely to be actual maximum window sequence number (which is likely to be
greater than the window announced by the most recent ACK, if more greater than the window announced by the most recent ACK, if more
skipping to change at page 13, line 41 skipping to change at page 14, line 5
3) The initial transmission MUST honor window on most recent ACK. 3) The initial transmission MUST honor window on most recent ACK.
4) On first retransmission, or if the sequence number is out-of- 4) On first retransmission, or if the sequence number is out-of-
window by less than (2^Rcv.Wind.Scale) then do normal window by less than (2^Rcv.Wind.Scale) then do normal
retransmission(s) without regard to receiver window as long as retransmission(s) without regard to receiver window as long as
the original segment was in window when it was sent. the original segment was in window when it was sent.
5) On subsequent retransmissions, treat such ACKs as zero window 5) On subsequent retransmissions, treat such ACKs as zero window
probes. probes.
3. RTTM -- Round-Trip Time Measurement 4. RTTM -- Round-Trip Time Measurement
3.1. Introduction 4.1. Introduction
Accurate and current RTT estimates are necessary to adapt to changing Accurate and current RTT estimates are necessary to adapt to changing
traffic conditions and to avoid an instability known as "congestion traffic conditions and to avoid an instability known as "congestion
collapse" [RFC0896] in a busy network. However, accurate measurement collapse" [RFC0896] in a busy network. However, accurate measurement
of RTT may be difficult both in theory and in implementation. of RTT may be difficult both in theory and in implementation.
Many TCP implementations base their RTT measurements upon a sample of Many TCP implementations base their RTT measurements upon a sample of
one packet per window or less. While this yields an adequate one packet per window or less. While this yields an adequate
approximation to the RTT for small windows, it results in an approximation to the RTT for small windows, it results in an
unacceptably poor RTT estimate for an LFN. If we look at RTT unacceptably poor RTT estimate for a LFN. If we look at RTT
estimation as a signal processing problem (which it is), a data estimation as a signal processing problem (which it is), a data
signal at some frequency, the packet rate, is being sampled at a signal at some frequency, the packet rate, is being sampled at a
lower frequency, the window rate. This lower sampling frequency lower frequency, the window rate. This lower sampling frequency
violates Nyquist's criteria and may therefore introduce "aliasing" violates Nyquist's criteria and may therefore introduce "aliasing"
artifacts into the estimated RTT [Hamming77]. artifacts into the estimated RTT [Hamming77].
A good RTT estimator with a conservative retransmission timeout A good RTT estimator with a conservative retransmission timeout
calculation can tolerate aliasing when the sampling frequency is calculation can tolerate aliasing when the sampling frequency is
"close" to the data frequency. For example, with a window of 8 "close" to the data frequency. For example, with a window of 8
packets, the sample rate is 1/8 the data frequency -- less than an packets, the sample rate is 1/8 the data frequency -- less than an
skipping to change at page 14, line 45 skipping to change at page 15, line 8
timestamps back in ACK segments. Then a single subtract gives the timestamps back in ACK segments. Then a single subtract gives the
sender an accurate RTT measurement for every ACK segment (which will sender an accurate RTT measurement for every ACK segment (which will
correspond to every other data segment, with a sensible receiver). correspond to every other data segment, with a sensible receiver).
We call this the RTTM (Round-Trip Time Measurement) mechanism. We call this the RTTM (Round-Trip Time Measurement) mechanism.
It is vitally important to use the RTTM mechanism with big windows; It is vitally important to use the RTTM mechanism with big windows;
otherwise, the door is opened to some dangerous instabilities due to otherwise, the door is opened to some dangerous instabilities due to
aliasing. Furthermore, the option is probably useful for all TCP's, aliasing. Furthermore, the option is probably useful for all TCP's,
since it simplifies the sender. since it simplifies the sender.
3.2. TCP Timestamps Option 4.2. TCP Timestamps Option
TCP is a symmetric protocol, allowing data to be sent at any time in TCP is a symmetric protocol, allowing data to be sent at any time in
either direction, and therefore timestamp echoing may occur in either either direction, and therefore timestamp echoing may occur in either
direction. For simplicity and symmetry, we specify that timestamps direction. For simplicity and symmetry, we specify that timestamps
always be sent and echoed in both directions. For efficiency, we always be sent and echoed in both directions. For efficiency, we
combine the timestamp and timestamp reply fields into a single TCP combine the timestamp and timestamp reply fields into a single TCP
Timestamps Option. Timestamps Option.
TCP Timestamps Option (TSopt): TCP Timestamps Option (TSopt):
Kind: 8 Kind: 8
Length: 10 bytes Length: 10 bytes
+-------+-------+---------------------+---------------------+ +-------+-------+---------------------+---------------------+
|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)| |Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
+-------+-------+---------------------+---------------------+ +-------+-------+---------------------+---------------------+
1 1 4 4 1 1 4 4
The Timestamps option carries two four-byte timestamp fields. The The Timestamps option carries two four-byte timestamp fields. The
Timestamp Value field (TSval) contains the current value of the Timestamp Value field (TSval) contains the current value of the
timestamp clock of the TCP sending the option. timestamp clock of the TCP sending the option.
The Timestamp Echo Reply field (TSecr) is valid if the ACK bit is set The Timestamp Echo Reply field (TSecr) is valid if the ACK bit is set
in the TCP header; if it is valid, it echos a timestamp value that in the TCP header; if it is valid, it echos a timestamp value that
was sent by the remote TCP in the TSval field of a Timestamps option. was sent by the remote TCP in the TSval field of a Timestamp option.
When TSecr is not valid, its value must be zero. However, a value of 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 zero does not imply TSecr being invalid. The TSecr value will
generally be from the most recent Timestamp option that was received; generally be from the most recent Timestamps Option that was
however, there are exceptions that are explained below. received; however, there are exceptions that are explained below.
A TCP may send the Timestamps option (TSopt) in an initial <SYN> A TCP MAY send the Timestamps option (TSopt) in an initial <SYN>
segment (i.e., a segment containing a SYN bit and no ACK bit). Once segment (i.e., a segment containing a SYN bit and no ACK bit). Once
a TSopt has been sent or received in a non <SYN> segment, it must be a TSopt has been sent or received in a non <SYN> segment, it MUST be
sent in all segments. Once a TSopt has been received in a non <SYN> sent in all segments. Once a TSopt has been received in a non <SYN>
segment, then any successive segment that is received without the RST segment, then any successive segment that is received without the RST
bit and without a TSopt may be dropped without further processing, bit and without a TSopt MAY be dropped without further processing,
and an ACK of the current SND.UNA generated. and an ACK of the current SND.UNA generated.
In the case of crossing SYN packets where one SYN contains a TSopt In the case of crossing SYN packets where one SYN contains a TSopt
and the other doesn't, both sides should put a TSopt in the <SYN,ACK> and the other doesn't, both sides SHOULD put a TSopt in the <SYN,ACK>
segment. segment.
3.3. The RTTM Mechanism 4.3. The RTTM Mechanism
RTTM places a Timestamps option in every segment, with a TSval that RTTM places a Timestamps option in every segment, with a TSval that
is obtained from a (virtual) "timestamp clock". Values of this clock is obtained from a (virtual) "timestamp clock". Values of this clock
values must be at least approximately proportional to real time, in values MUST be at least approximately proportional to real time, in
order to measure actual RTT. order to measure actual RTT.
These TSval values are echoed in TSecr values in the reverse These TSval values are echoed in TSecr values in the reverse
direction. The difference between a received TSecr value and the direction. The difference between a received TSecr value and the
current timestamp clock value provides an RTT measurement. current timestamp clock value provides a RTT measurement.
When timestamps are used, every segment that is received will contain When timestamps are used, every segment that is received will contain
a TSecr value; however, these values cannot all be used to update the a TSecr value; however, these values cannot all be used to update the
measured RTT. The following example illustrates why. It shows a measured RTT. The following example illustrates why. It shows a
one-way data flow with segments arriving in sequence without loss. one-way data flow with segments arriving in sequence without loss.
Here A, B, C... represent data blocks occupying successive blocks of Here A, B, C... represent data blocks occupying successive blocks of
sequence numbers, and ACK(A),... represent the corresponding sequence numbers, and ACK(A),... represent the corresponding
cumulative acknowledgments. The two timestamp fields of the cumulative acknowledgments. The two timestamp fields of the
Timestamps option are shown symbolically as <TSval=x,TSecr=y>. Each Timestamps option are shown symbolically as <TSval=x,TSecr=y>. Each
TSecr field contains the value most recently received in a TSval TSecr field contains the value most recently received in a TSval
field. field.
TCP A TCP B TCP A TCP B
<A,TSval=1,TSecr=120> ------> <A,TSval=1,TSecr=120> ----->
<---- <ACK(A),TSval=127,TSecr=1> <---- <ACK(A),TSval=127,TSecr=1>
<B,TSval=5,TSecr=127> ------> <B,TSval=5,TSecr=127> ----->
<---- <ACK(B),TSval=131,TSecr=5> <---- <ACK(B),TSval=131,TSecr=5>
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
<C,TSval=65,TSecr=131> ------> <C,TSval=65,TSecr=131> ---->
<---- <ACK(C),TSval=191,TSecr=65> <---- <ACK(C),TSval=191,TSecr=65>
(etc) (etc)
The dotted line marks a pause (60 time units long) in which A had 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 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 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 data flows, RTTM in the reverse direction measures a value that is
inflated by gaps in sending data. However, the following rule inflated by gaps in sending data. However, the following rule
prevents a resulting inflation of the measured RTT: prevents a resulting inflation of the measured RTT:
RTTM Rule: A TSecr value received in a segment is used to update RTTM Rule: A TSecr value received in a segment is used to update
the averaged RTT measurement only if the averaged RTT measurement only if
skipping to change at page 17, line 19 skipping to change at page 17, line 32
weighting factor needs to be decreased to take into account the more weighting factor needs to be decreased to take into account the more
frequent RTTMs. For example, an implementation could choose to just frequent RTTMs. For example, an implementation could choose to just
use one sample per RTT to update the RTO estimator, or vary the gain use one sample per RTT to update the RTO estimator, or vary the gain
based on the congestion window, or take an average of all the RTTM based on the congestion window, or take an average of all the RTTM
measurements received over one RTT, and then use that value to update measurements received over one RTT, and then use that value to update
the RTO estimator. This document does not prescribe any particular the RTO estimator. This document does not prescribe any particular
method for modifying the RTO estimator, the important point is that method for modifying the RTO estimator, the important point is that
the implementation should do something more than just feeding the implementation should do something more than just feeding
additional RTTM samples from one RTT into the RTO estimator. additional RTTM samples from one RTT into the RTO estimator.
3.4. Which Timestamp to Echo 4.4. Which Timestamp to Echo
If more than one Timestamps option is received before a reply segment 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 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 the others. To minimize the state kept in the receiver (i.e., the
number of unprocessed TSvals), the receiver should be required to number of unprocessed TSvals), the receiver should be required to
retain at most one timestamp in the connection control block. retain at most one timestamp in the connection control block.
There are three situations to consider: There are three situations to consider:
(A) Delayed ACKs. (A) Delayed ACKs.
Many TCP's acknowledge only every Kth segment out of a group of Many TCP's acknowledge only every Kth segment out of a group of
segments arriving within a short time interval; this policy is segments arriving within a short time interval; this policy is
known generally as "delayed ACKs". The data-sender TCP must known generally as "delayed ACKs". The data-sender TCP must
measure the effective RTT, including the additional time due to measure the effective RTT, including the additional time due to
delayed ACKs, or else it will retransmit unnecessarily. Thus, delayed ACKs, or else it will retransmit unnecessarily. Thus,
when delayed ACKs are in use, the receiver should reply with the when delayed ACKs are in use, the receiver SHOULD reply with the
TSval field from the earliest unacknowledged segment. TSval field from the earliest unacknowledged segment.
(B) A hole in the sequence space (segment(s) have been lost). (B) A hole in the sequence space (segment(s) have been lost).
The sender will continue sending until the window is filled, and The sender will continue sending until the window is filled, and
the receiver may be generating ACKs as these out-of-order the receiver may be generating ACKs as these out-of-order
segments arrive (e.g., to aid "fast retransmit"). segments arrive (e.g., to aid "fast retransmit").
The lost segment is probably a sign of congestion, and in that The lost segment is probably a sign of congestion, and in that
situation the sender should be conservative about situation the sender should be conservative about
retransmission. Furthermore, it is better to overestimate than retransmission. Furthermore, it is better to overestimate than
underestimate the RTT. An ACK for an out-of-order segment underestimate the RTT. An ACK for an out-of-order segment
should therefore contain the timestamp from the most recent SHOULD therefore contain the timestamp from the most recent
segment that advanced the window. segment that advanced the window.
The same situation occurs if segments are re-ordered by the The same situation occurs if segments are re-ordered by the
network. network.
(C) A filled hole in the sequence space. (C) A filled hole in the sequence space.
The segment that fills the hole represents the most recent The segment that fills the hole represents the most recent
measurement of the network characteristics. On the other hand, measurement of the network characteristics. On the other hand,
an RTT computed from an earlier segment would probably include an RTT computed from an earlier segment would probably include
the sender's retransmit time-out, badly biasing the sender's the sender's retransmit time-out, badly biasing the sender's
average RTT estimate. Thus, the timestamp from the latest average RTT estimate. Thus, the timestamp from the latest
segment (which filled the hole) must be echoed. segment (which filled the hole) MUST be echoed.
An algorithm that covers all three cases is described in the An algorithm that covers all three cases is described in the
following rules for Timestamps option processing on a synchronized following rules for Timestamps option processing on a synchronized
connection: connection:
(1) The connection state is augmented with two 32-bit slots: (1) The connection state is augmented with two 32-bit slots:
TS.Recent holds a timestamp to be echoed in TSecr whenever a 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 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 last segment sent. Last.ACK.sent will equal RCV.NXT except when
skipping to change at page 18, line 43 skipping to change at page 19, line 9
TS.Recent value. TS.Recent value.
The following examples illustrate these rules. Here A, B, C... The following examples illustrate these rules. Here A, B, C...
represent data segments occupying successive blocks of sequence represent data segments occupying successive blocks of sequence
numbers, and ACK(A),... represent the corresponding acknowledgment numbers, and ACK(A),... represent the corresponding acknowledgment
segments. Note that ACK(A) has the same sequence number as B. We segments. Note that ACK(A) has the same sequence number as B. We
show only one direction of timestamp echoing, for clarity. show only one direction of timestamp echoing, for clarity.
o Packets arrive in sequence, and some of the ACKs are delayed. o Packets arrive in sequence, and some of the ACKs are delayed.
By Case (A), the timestamp from the oldest unacknowledged segment By case (A), the timestamp from the oldest unacknowledged segment
is echoed. is echoed.
TS.Recent TS.Recent
<A, TSval=1> -------------------> <A, TSval=1> ------------------->
1 1
<B, TSval=2> -------------------> <B, TSval=2> ------------------->
1 1
<C, TSval=3> -------------------> <C, TSval=3> ------------------->
1 1
<---- <ACK(C), TSecr=1> <---- <ACK(C), TSecr=1>
(etc) (etc)
o Packets arrive out of order, and every packet is acknowledged. o Packets arrive out of order, and every packet is acknowledged.
By Case (B), the timestamp from the last segment that advanced the By case (B), the timestamp from the last segment that advanced the
left window edge is echoed, until the missing segment arrives; it left window edge is echoed, until the missing segment arrives; it
is echoed according to Case (C). The same sequence would occur if is echoed according to Case (C). The same sequence would occur if
segments B and D were lost and retransmitted. segments B and D were lost and retransmitted.
TS.Recent TS.Recent
<A, TSval=1> -------------------> <A, TSval=1> ------------------->
1 1
<---- <ACK(A), TSecr=1> <---- <ACK(A), TSecr=1>
1 1
<C, TSval=3> -------------------> <C, TSval=3> ------------------->
skipping to change at page 19, line 44 skipping to change at page 20, line 5
2 2
<E, TSval=5> -------------------> <E, TSval=5> ------------------->
2 2
<---- <ACK(C), TSecr=2> <---- <ACK(C), TSecr=2>
2 2
<D, TSval=4> -------------------> <D, TSval=4> ------------------->
4 4
<---- <ACK(E), TSecr=4> <---- <ACK(E), TSecr=4>
(etc) (etc)
4. PAWS -- Protection Against Wrapped Sequence Numbers 5. PAWS -- Protection Against Wrapped Sequence Numbers
4.1. Introduction 5.1. Introduction
Section 4.2 describes a simple mechanism to reject old duplicate Section 5.2 describes a simple mechanism to reject old duplicate
segments that might corrupt an open TCP connection; we call this segments that might corrupt an open TCP connection; we call this
mechanism PAWS (Protection Against Wrapped Sequence numbers). PAWS mechanism PAWS (Protection Against Wrapped Sequence numbers). PAWS
operates within a single TCP connection, using state that is saved in operates within a single TCP connection, using state that is saved in
the connection control block. Section 4.3 and Appendix C discuss the the connection control block. Section 5.3 and Appendix C discuss the
implications of the PAWS mechanism for avoiding old duplicates from implications of the PAWS mechanism for avoiding old duplicates from
previous incarnations of the same connection. previous incarnations of the same connection.
4.2. The PAWS Mechanism 5.2. The PAWS Mechanism
PAWS uses the same TCP Timestamps option as the RTTM mechanism PAWS uses the same TCP Timestamps option as the RTTM mechanism
described earlier, and assumes that every received TCP segment described earlier, and assumes that every received TCP segment
(including data and ACK segments) contains a timestamp SEG.TSval (including data and ACK segments) contains a timestamp SEG.TSval
whose values are monotonically non-decreasing in time. The basic 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 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 with a timestamp SEG.TSval less than some timestamp recently
received on this connection. received on this connection.
In both the PAWS and the RTTM mechanism, the "timestamps" are 32-bit In both the PAWS and the RTTM mechanism, the "timestamps" are 32-bit
unsigned integers in a modular 32-bit space. Thus, "less than" is 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 defined the same way it is for TCP sequence numbers, and the same
implementation techniques apply. If s and t are timestamp values, implementation techniques apply. If s and t are timestamp values,
s < t if 0 < (t - s) < 2^31, s < t if 0 < (t - s) < 2^31,
computed in unsigned 32-bit arithmetic. computed in unsigned 32-bit arithmetic.
The choice of incoming timestamps to be saved for this comparison The choice of incoming timestamps to be saved for this comparison
must guarantee a value that is monotonically increasing. For MUST guarantee a value that is monotonically increasing. For
example, we might save the timestamp from the segment that last example, we might save the timestamp from the segment that last
advanced the left edge of the receive window, i.e., the most recent advanced the left edge of the receive window, i.e., the most recent
in-sequence segment. Instead, we choose the value TS.Recent in-sequence segment. Instead, we choose the value TS.Recent
introduced in Section 3.4 for the RTTM mechanism, since using a introduced in Section 4.4 for the RTTM mechanism, since using a
common value for both PAWS and RTTM simplifies the implementation of common value for both PAWS and RTTM simplifies the implementation of
both. As Section 3.4 explained, TS.Recent differs from the timestamp both. As Section 4.4 explained, TS.Recent differs from the timestamp
from the last in-sequence segment only in the case of delayed ACKs, from the last in-sequence segment only in the case of delayed ACKs,
and therefore by less than one window. Either choice will therefore and therefore by less than one window. Either choice will therefore
protect against sequence number wrap-around. protect against sequence number wrap-around.
RTTM was specified in a symmetrical manner, so that TSval timestamps RTTM was specified in a symmetrical manner, so that TSval timestamps
are carried in both data and ACK segments and are echoed in TSecr are carried in both data and ACK segments and are echoed in TSecr
fields carried in returning ACK or data segments. PAWS submits all fields carried in returning ACK or data segments. PAWS submits all
incoming segments to the same test, and therefore protects against incoming segments to the same test, and therefore protects against
duplicate ACK segments as well as data segments. (An alternative duplicate ACK segments as well as data segments. (An alternative
non-symmetric algorithm would protect against old duplicate ACKs: the non-symmetric algorithm would protect against old duplicate ACKs: the
skipping to change at page 21, line 9 skipping to change at page 21, line 17
advanced the left edge of the send window. This algorithm was deemed advanced the left edge of the send window. This algorithm was deemed
to lack economy of mechanism and symmetry.) to lack economy of mechanism and symmetry.)
TSval timestamps sent on <SYN> and <SYN,ACK> segments are used to TSval timestamps sent on <SYN> and <SYN,ACK> segments are used to
initialize PAWS. PAWS protects against old duplicate non-SYN initialize PAWS. PAWS protects against old duplicate non-SYN
segments, and duplicate SYN segments received while there is a segments, and duplicate SYN segments received while there is a
synchronized connection. Duplicate <SYN> and <SYN,ACK> segments synchronized connection. Duplicate <SYN> and <SYN,ACK> segments
received when there is no connection will be discarded by the normal received when there is no connection will be discarded by the normal
3-way handshake and sequence number checks of TCP. 3-way handshake and sequence number checks of TCP.
RFC 1323 recommended that RST segments NOT carry timestamps, and that [RFC1323] recommended that RST segments NOT carry timestamps, and
they be acceptable regardless of their timestamp. At that time, the that they be acceptable regardless of their timestamp. At that time,
thinking was that old duplicate RST segments should be exceedingly the thinking was that old duplicate RST segments should be
unlikely, and their cleanup function should take precedence over exceedingly unlikely, and their cleanup function should take
timestamps. More recently, discussions about various blind attacks precedence over timestamps. More recently, discussions about various
on TCP connections have raised the suggestion that if the Timestamps blind attacks on TCP connections have raised the suggestion that if
option is present, SEG.TSecr could be used to provide stricter the Timestamps option is present, SEG.TSecr could be used to provide
acceptance tests for RST packets. While still under discussion, to stricter acceptance tests for RST packets. While still under
enable research into this area it is now recommended that when discussion, to enable research into this area it is now RECOMMENDED
generating a RST, that if the packet causing the RST to be generated that when generating a RST, that if the packet causing the RST to be
contained a Timestamps option that the RST also contain a Timestamps generated contained a Timestamps option that the RST also contain a
option. In the RST segment, SEG.TSecr should be set to SEG.TSval Timestamps option. In the RST segment, SEG.TSecr SHOULD be set to
from the incoming packet and SEG.TSval should be set to zero. If a SEG.TSval from the incoming packet and SEG.TSval SHOULD be set to
RST is being generated because of a user abort, and Snd.TS.OK is set, zero. If a RST is being generated because of a user abort, and
then a Timestamps option should be included in the RST. When a RST Snd.TS.OK is set, then a Timestamps option SHOULD be included in the
packet is received, it must not be subjected to PAWS checks, and RST. When a RST packet is received, it MUST NOT be subjected to PAWS
information from the Timestamps option must not be use to update checks, and information from the Timestamps option MUST NOT be used
connection state information. SEG.TSecr may be used to provide to update connection state information. SEG.TSecr MAY be used to
stricter RST acceptance checks. provide stricter RST acceptance checks.
4.2.1. Basic PAWS Algorithm 5.2.1. Basic PAWS Algorithm
The PAWS algorithm requires the following processing to be performed The PAWS algorithm requires the following processing to be performed
on all incoming segments for a synchronized connection: on all incoming segments for a synchronized connection:
R1) If there is a Timestamps option in the arriving segment, R1) If there is a Timestamps option in the arriving segment,
SEG.TSval < TS.Recent, TS.Recent is valid (see later discussion) SEG.TSval < TS.Recent, TS.Recent is valid (see later discussion)
and the RST bit is not set, then treat the arriving segment as and the RST bit is not set, then treat the arriving segment as
not acceptable: not acceptable:
Send an acknowledgement in reply as specified in RFC 793 page Send an acknowledgement in reply as specified in [RFC0793]
69 and drop the segment. page 69 and drop the segment.
Note: it is necessary to send an ACK segment in order to Note: it is necessary to send an ACK segment in order to
retain TCP's mechanisms for detecting and recovering from retain TCP's mechanisms for detecting and recovering from
half-open connections. For example, see Figure 10 of RFC half-open connections. For example, see Figure 10 of
793. [RFC0793].
R2) If the segment is outside the window, reject it (normal TCP R2) If the segment is outside the window, reject it (normal TCP
processing) processing)
R3) If an arriving segment satisfies: SEG.SEQ <= Last.ACK.sent (see R3) If an arriving segment satisfies: SEG.SEQ <= Last.ACK.sent (see
Section 3.4), then record its timestamp in TS.Recent. Section 4.4), then record its timestamp in TS.Recent.
R4) If an arriving segment is in-sequence (i.e., at the left window R4) If an arriving segment is in-sequence (i.e., at the left window
edge), then accept it normally. edge), then accept it normally.
R5) Otherwise, treat the segment as a normal in-window, out-of- R5) Otherwise, treat the segment as a normal in-window, out-of-
sequence TCP segment (e.g., queue it for later delivery to the sequence TCP segment (e.g., queue it for later delivery to the
user). user).
Steps R2, R4, and R5 are the normal TCP processing steps specified by Steps R2, R4, and R5 are the normal TCP processing steps specified by
RFC 793. [RFC0793].
It is important to note that the timestamp is checked only when a It is important to note that the timestamp is checked only when a
segment first arrives at the receiver, regardless of whether it is segment first arrives at the receiver, regardless of whether it is
in-sequence or it must be queued for later delivery. in-sequence or it must be queued for later delivery.
Consider the following example. Consider the following example.
Suppose the segment sequence: A.1, B.1, C.1, ..., Z.1 has been 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 sent, where the letter indicates the sequence number and the digit
represents the timestamp. Suppose also that segment B.1 has been represents the timestamp. Suppose also that segment B.1 has been
lost. The timestamp in TS.TStamp is 1 (from A.1), so C.1, ..., 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 Z.1 are considered acceptable and are queued. When B is
retransmitted as segment B.2 (using the latest timestamp), it retransmitted as segment B.2 (using the latest timestamp), it
fills the hole and causes all the segments through Z to be fills the hole and causes all the segments through Z to be
acknowledged and passed to the user. The timestamps of the queued acknowledged and passed to the user. The timestamps of the queued
segments are *not* inspected again at this time, since they have segments are *not* inspected again at this time, since they have
already been accepted. When B.2 is accepted, TS.Stamp is set to already been accepted. When B.2 is accepted, TS.Recent is set to
2. 2.
This rule allows reasonable performance under loss. A full window of 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 data is in transit at all times, and after a loss a full window less
one packet will show up out-of-sequence to be queued at the receiver one packet will show up out-of-sequence to be queued at the receiver
(e.g., up to ~2^30 bytes of data); the timestamp option must not (e.g., up to ~2^30 bytes of data); the timestamp option must not
result in discarding this data. result in discarding this data.
In certain unlikely circumstances, the algorithm of rules R1-R5 could In certain unlikely circumstances, the algorithm of rules R1-R5 could
lead to discarding some segments unnecessarily, as shown in the lead to discarding some segments unnecessarily, as shown in the
skipping to change at page 23, line 22 skipping to change at page 23, line 29
Even if a segment were delayed past the RTO, the Fast Retransmit Even if a segment were delayed past the RTO, the Fast Retransmit
mechanism [Jacobson90c] will cause the delayed packets to be mechanism [Jacobson90c] will cause the delayed packets to be
retransmitted at the same time as B.2, avoiding an extra RTT and retransmitted at the same time as B.2, avoiding an extra RTT and
therefore causing a very small performance penalty. therefore causing a very small performance penalty.
We know of no case with a significant probability of occurrence in We know of no case with a significant probability of occurrence in
which timestamps will cause performance degradation by unnecessarily which timestamps will cause performance degradation by unnecessarily
discarding segments. discarding segments.
4.2.2. Timestamp Clock 5.2.2. Timestamp Clock
It is important to understand that the PAWS algorithm does not It is important to understand that the PAWS algorithm does not
require clock synchronization between sender and receiver. The require clock synchronization between sender and receiver. The
sender's timestamp clock is used to stamp the segments, and the sender's timestamp clock is used to stamp the segments, and the
sender uses the echoed timestamp to measure RTTs. However, the sender uses the echoed timestamp to measure RTTs. However, the
receiver treats the timestamp as simply a monotonically increasing receiver treats the timestamp as simply a monotonically increasing
serial number, without any necessary connection to its clock. From serial number, without any necessary connection to its clock. From
the receiver's viewpoint, the timestamp is acting as a logical the receiver's viewpoint, the timestamp is acting as a logical
extension of the high-order bits of the sequence number. extension of the high-order bits of the sequence number.
The receiver algorithm does place some requirements on the frequency The receiver algorithm does place some requirements on the frequency
of the timestamp clock. of the timestamp clock.
(a) The timestamp clock must not be "too slow". (a) The timestamp clock must not be "too slow".
It must tick at least once for each 2^31 bytes sent. In fact, 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 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 clock SHOULD tick at least once per window's worth of data, and
even with the window extension defined in Section 2.2, 2^31 even with the window extension defined in Section 3.2, 2^31
bytes must be at least two windows. bytes must be at least two windows.
To make this more quantitative, any clock faster than 1 tick/sec To make this more quantitative, any clock faster than 1 tick/sec
will reject old duplicate segments for link speeds of ~8 Gbps. will reject old duplicate segments for link speeds of ~8 Gbps.
A 1ms timestamp clock will work at link speeds up to 8 Tbps
A 1 ms timestamp clock will work at link speeds up to 8 Tbps
(8*10^12) bps! (8*10^12) bps!
(b) The timestamp clock must not be "too fast". (b) The timestamp clock must not be "too fast".
Its recycling time must be greater than MSL seconds. Since the Its recycling time MUST be greater than MSL seconds. Since the
clock (timestamp) is 32 bits and the worst-case MSL is 255 clock (timestamp) is 32 bits and the worst-case MSL is 255
seconds, the maximum acceptable clock frequency is one tick seconds, the maximum acceptable clock frequency is one tick
every 59 ns. every 59 ns.
However, it is desirable to establish a much longer recycle However, it is desirable to establish a much longer recycle
period, in order to handle outdated timestamps on idle period, in order to handle outdated timestamps on idle
connections (see Section 4.2.3), and to relax the MSL connections (see Section 5.2.3), and to relax the MSL
requirement for preventing sequence number wrap-around. With a requirement for preventing sequence number wrap-around. With a
1 ms timestamp clock, the 32-bit timestamp will wrap its sign 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 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 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 a very safe figure; an MSL of 24.8 days or longer can probably
be assumed in the internet without requiring precise MSL be assumed in the internet without requiring precise MSL
enforcement. enforcement.
Based upon these considerations, we choose a timestamp clock Based upon these considerations, we choose a timestamp clock
frequency in the range 1 ms to 1 sec per tick. This range also frequency in the range 1 ms to 1 sec per tick. This range also
skipping to change at page 24, line 42 skipping to change at page 25, line 5
o A clock interrupt may be used to simply increment a binary integer o A clock interrupt may be used to simply increment a binary integer
by 1 periodically. by 1 periodically.
o The timestamp clock may be derived from a system clock that is o The timestamp clock may be derived from a system clock that is
subject to being abruptly changed, by adding a variable offset subject to being abruptly changed, by adding a variable offset
value. This offset is initialized to zero. When a new timestamp value. This offset is initialized to zero. When a new timestamp
clock value is needed, the offset can be adjusted as necessary to clock value is needed, the offset can be adjusted as necessary to
make the new value equal to or larger than the previous value make the new value equal to or larger than the previous value
(which was saved for this purpose). (which was saved for this purpose).
4.2.3. Outdated Timestamps 5.2.3. Outdated Timestamps
If a connection remains idle long enough for the timestamp clock of 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 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 will become too old; as a result, the PAWS mechanism will cause all
subsequent segments to be rejected, freezing the connection (until subsequent segments to be rejected, freezing the connection (until
the timestamp clock wraps its sign bit again). the timestamp clock wraps its sign bit again).
With the chosen range of timestamp clock frequencies (1 sec to 1 ms), 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 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 days. A TCP connection that is idle for more than 24 days and then
skipping to change at page 25, line 25 skipping to change at page 25, line 36
solution based upon invalidation was chosen.) solution based upon invalidation was chosen.)
Note that a TCP does not know the frequency, and therefore, the 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 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 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 timestamp check fails, i.e., only if SEG.TSval < TS.Recent. If
TS.Recent is found to be invalid, then the segment is accepted, TS.Recent is found to be invalid, then the segment is accepted,
regardless of the failure of the timestamp check, and rule R3 updates regardless of the failure of the timestamp check, and rule R3 updates
TS.Recent with the TSval from the new segment. TS.Recent with the TSval from the new segment.
To detect how long the connection has been idle, the TCP may update a To detect how long the connection has been idle, the TCP MAY update a
clock or timestamp value associated with the connection whenever clock or timestamp value associated with the connection whenever
TS.Recent is updated, for example. The details will be TS.Recent is updated, for example. The details will be
implementation-dependent. implementation-dependent.
4.2.4. Header Prediction 5.2.4. Header Prediction
"Header prediction" [Jacobson90a] is a high-performance transport "Header prediction" [Jacobson90a] is a high-performance transport
protocol implementation technique that is most important for high- protocol implementation technique that is most important for high-
speed links. This technique optimizes the code for the most common speed links. This technique optimizes the code for the most common
case, receiving a segment correctly and in order. Using header case, receiving a segment correctly and in order. Using header
prediction, the receiver asks the question, "Is this segment the next prediction, the receiver asks the question, "Is this segment the next
in sequence?" This question can be answered in fewer machine in sequence?" This question can be answered in fewer machine
instructions than the question, "Is this segment within the window?" instructions than the question, "Is this segment within the window?"
Adding header prediction to our timestamp procedure leads to the Adding header prediction to our timestamp procedure leads to the
skipping to change at page 26, line 49 skipping to change at page 27, line 8
enough", i.e., it won't contribute significantly to the overall enough", i.e., it won't contribute significantly to the overall
error rate. We therefore believe we can ignore the problem of an error rate. We therefore believe we can ignore the problem of an
old duplicate being accepted by doing header prediction before old duplicate being accepted by doing header prediction before
checking the timestamp. checking the timestamp.
However, this probabilistic argument is not universally accepted, and However, this probabilistic argument is not universally accepted, and
the consensus at present is that the performance gain does not the consensus at present is that the performance gain does not
justify the hazard in the general case. It is therefore recommended justify the hazard in the general case. It is therefore recommended
that H2 follow H1. that H2 follow H1.
4.2.5. IP Fragmentation 5.2.5. IP Fragmentation
At high data rates, the protection against old packets provided by At high data rates, the protection against old packets provided by
PAWS can be circumvented by errors in IP fragment reassembly (see PAWS can be circumvented by errors in IP fragment reassembly (see
[RFC4963]). The only way to protect against incorrect IP fragment [RFC4963]). The only way to protect against incorrect IP fragment
reassembly is to not allow the packets to be fragmented. This is reassembly is to not allow the packets to be fragmented. This is
done by setting the Don't Fragment (DF) bit in the IP header. 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 Setting the DF bit implies the use of Path MTU Discovery as described
in [RFC1191], [RFC1981], and [RFC4821], thus any TCP implementation in [RFC1191], [RFC1981], and [RFC4821], thus any TCP implementation
that implements PAWS must also implement Path MTU Discovery. that implements PAWS MUST also implement Path MTU Discovery.
4.3. Duplicates from Earlier Incarnations of Connection 5.3. Duplicates from Earlier Incarnations of Connection
The PAWS mechanism protects against errors due to sequence number The PAWS mechanism protects against errors due to sequence number
wrap-around on high-speed connections. Segments from an earlier wrap-around on high-speed connections. Segments from an earlier
incarnation of the same connection are also a potential cause of old incarnation of the same connection are also a potential cause of old
duplicate errors. In both cases, the TCP mechanisms to prevent such duplicate errors. In both cases, the TCP mechanisms to prevent such
errors depend upon the enforcement of a maximum segment lifetime errors depend upon the enforcement of a maximum segment lifetime
(MSL) by the Internet (IP) layer (see Appendix of RFC 1185 for a (MSL) by the Internet (IP) layer (see Appendix of RFC 1185 for a
detailed discussion). Unlike the case of sequence space wrap-around, detailed discussion). Unlike the case of sequence space wrap-around,
the MSL required to prevent old duplicate errors from earlier the MSL required to prevent old duplicate errors from earlier
incarnations does not depend upon the transfer rate. If the IP layer incarnations does not depend upon the transfer rate. If the IP layer
skipping to change at page 27, line 35 skipping to change at page 27, line 42
no matter how high the network speed. Thus, the PAWS mechanism is no matter how high the network speed. Thus, the PAWS mechanism is
not required for this case. not required for this case.
We may still ask whether the PAWS mechanism can provide additional We may still ask whether the PAWS mechanism can provide additional
security against old duplicates from earlier connections, allowing us security against old duplicates from earlier connections, allowing us
to relax the enforcement of MSL by the IP layer. Appendix B explores to relax the enforcement of MSL by the IP layer. Appendix B explores
this question, showing that further assumptions and/or mechanisms are this question, showing that further assumptions and/or mechanisms are
required, beyond those of PAWS. This is not part of the current required, beyond those of PAWS. This is not part of the current
extension. extension.
5. Conclusions and Acknowledgements 6. Conclusions and Acknowledgements
This memo presented a set of extensions to TCP to provide efficient This memo presented a set of extensions to TCP to provide efficient
operation over large-bandwidth*delay-product paths and reliable operation over large-bandwidth*delay-product paths and reliable
operation over very high-speed paths. These extensions are designed operation over very high-speed paths. These extensions are designed
to provide compatible interworking with TCP's that do not implement to provide compatible interworking with TCP's that do not implement
the extensions. the extensions.
These mechanisms are implemented using new TCP options for scaled These mechanisms are implemented using new TCP options for scaled
windows and timestamps. The timestamps are used for two distinct windows and timestamps. The timestamps are used for two distinct
mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protection mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protection
Against Wrapped Sequences). Against Wrapped Sequences).
The Window Scale option was originally suggested by Mike St. Johns of The Window Scale option was originally suggested by Mike St. Johns of
USAF/DCA. The present form of the option was suggested by Mike USAF/DCA. The present form of the option was suggested by Mike
Karels of UC Berkeley in response to a more cumbersome scheme defined Karels of UC Berkeley in response to a more cumbersome scheme defined
by Van Jacobson. Lixia Zhang helped formulate the PAWS mechanism by Van Jacobson. Lixia Zhang helped formulate the PAWS mechanism
description in RFC 1185. description in [RFC1185].
Finally, much of this work originated as the result of discussions Finally, much of this work originated as the result of discussions
within the End-to-End Task Force on the theoretical limitations of within the End-to-End Task Force on the theoretical limitations of
transport protocols in general and TCP in particular. Task force transport protocols in general and TCP in particular. Task force
members and other on the end2end-interest list have made valuable members and other on the end2end-interest list have made valuable
contributions by pointing out flaws in the algorithms and the contributions by pointing out flaws in the algorithms and the
documentation. Continued discussion and development since the documentation. Continued discussion and development since the
publication of RFC 1323 originally occurred in the IETF TCP Large publication of [RFC1323] originally occurred in the IETF TCP Large
Windows Working Group, later on in the End-to-End Task Force, and Windows Working Group, later on in the End-to-End Task Force, and
most recently in the IETF TCP Maintenance Working Group. The authors most recently in the IETF TCP Maintenance Working Group. The authors
are grateful for all these contributions. are grateful for all these contributions.
6. Security Considerations 7. Security Considerations
The TCP sequence space is a fixed size, and as the window becomes The TCP sequence space is a fixed size, and as the window becomes
larger it becomes easier for an attacker to generate forged packets larger it becomes easier for an attacker to generate forged packets
that can fall within the TCP window, and be accepted as valid that can fall within the TCP window, and be accepted as valid
packets. While use of Timestamps and PAWS can help to mitigate this, packets. 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 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 acceptable to the TCP connection, a timestamp that is in the future
would cause valid packets to be dropped due to PAWS checks. Hence, would cause valid packets to be dropped due to PAWS checks. Hence,
implementors should take care to not open the TCP window drastically implementors should take care to not open the TCP window drastically
beyond the requirements of the connection. beyond the requirements of the connection.
skipping to change at page 28, line 44 skipping to change at page 29, line 5
connection if that protection doesn't exist. connection if that protection doesn't exist.
Mechanisms to protect the TCP header from modification should also Mechanisms to protect the TCP header from modification should also
protect the TCP options. protect the TCP options.
Expanding the TCP window beyond 64K for IPv6 allows Jumbograms Expanding the TCP window beyond 64K for IPv6 allows Jumbograms
[RFC2675] to be used when the local network supports packets larger [RFC2675] to be used when the local network supports packets larger
than 64K. When larger TCP packets are used, the TCP checksum becomes than 64K. When larger TCP packets are used, the TCP checksum becomes
weaker. weaker.
7. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. References 9. References
8.1. Normative References
9.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
8.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[Garlick77] [Garlick77]
Garlick, L., Rom, R., and J. Postel, "Issues in Reliable Garlick, L., Rom, R., and J. Postel, "Issues in Reliable
Host-to-Host Protocols", Proc. Second Berkeley Workshop on Host-to-Host Protocols", Proc. Second Berkeley Workshop on
Distributed Data Management and Computer Networks, Distributed Data Management and Computer Networks,
May 1977, <http://www.rfc-editor.org/ien/ien12.txt>. May 1977, <http://www.rfc-editor.org/ien/ien12.txt>.
[Hamming77] [Hamming77]
Hamming, R., "Digital Filters", Prentice Hall, Englewood Hamming, R., "Digital Filters", Prentice Hall, Englewood
Cliffs, N.J. ISBN 0-13-212571-4, 1977. Cliffs, N.J. ISBN 0-13-212571-4, 1977.
skipping to change at page 34, line 27 skipping to change at page 34, line 38
of the number of simultaneous connections to that host. of the number of simultaneous connections to that host.
Appendix C. Changes from RFC 1072, RFC 1185, and RFC 1323 Appendix C. Changes from RFC 1072, RFC 1185, and RFC 1323
The protocol extensions defined in RFC 1323 document differ in The protocol extensions defined in RFC 1323 document differ in
several important ways from those defined in RFC 1072 and RFC 1185. several important ways from those defined in RFC 1072 and RFC 1185.
(a) SACK has been split off into a separate document, [RFC2018]. (a) SACK has been split off into a separate document, [RFC2018].
(b) The detailed rules for sending timestamp replies (see (b) The detailed rules for sending timestamp replies (see
Section 3.4) differ in important ways. The earlier rules could Section 4.4) differ in important ways. The earlier rules could
result in an under-estimate of the RTT in certain cases (packets result in an under-estimate of the RTT in certain cases (packets
dropped or out of order). dropped or out of order).
(c) The same value TS.Recent is now shared by the two distinct (c) The same value TS.Recent is now shared by the two distinct
mechanisms RTTM and PAWS. This simplification became possible mechanisms RTTM and PAWS. This simplification became possible
because of change (b). because of change (b).
(d) An ambiguity in RFC 1185 was resolved in favor of putting (d) An ambiguity in RFC 1185 was resolved in favor of putting
timestamps on ACK as well as data segments. This supports the timestamps on ACK as well as data segments. This supports the
symmetry of the underlying TCP protocol. symmetry of the underlying TCP protocol.
(e) The echo and echo reply options of RFC 1072 were combined into a (e) The echo and echo reply options of RFC 1072 were combined into a
single Timestamps option, to reflect the symmetry and to single Timestamps option, to reflect the symmetry and to
simplify processing. simplify processing.
(f) The problem of outdated timestamps on long-idle connections, (f) The problem of outdated timestamps on long-idle connections,
discussed in Section 4.2.2, was realized and resolved. discussed in Section 5.2.2, was realized and resolved.
(g) RFC 1185 recommended that header prediction take precedence over (g) RFC 1185 recommended that header prediction take precedence over
the timestamp check. Based upon some skepticism about the the timestamp check. Based upon some skepticism about the
probabilistic arguments given in Section 4.2.4, it was decided probabilistic arguments given in Section 5.2.4, it was decided
to recommend that the timestamp check be performed first. to recommend that the timestamp check be performed first.
(h) The spec was modified so that the extended options will be sent (h) The spec was modified so that the extended options will be sent
on <SYN,ACK> segments only when they are received in the on <SYN,ACK> segments only when they are received in the
corresponding <SYN> segments. This provides the most corresponding <SYN> segments. This provides the most
conservative possible conditions for interoperation with conservative possible conditions for interoperation with
implementations without the extensions. implementations without the extensions.
In addition to these substantive changes, the present RFC attempts to In addition to these substantive changes, the present RFC attempts to
specify the algorithms unambiguously by presenting modifications to specify the algorithms unambiguously by presenting modifications to
skipping to change at page 36, line 17 skipping to change at page 36, line 29
(h) Snd.TSoffset and Snd.TSclock variables have been added. (h) Snd.TSoffset and Snd.TSclock variables have been added.
Snd.TSclock is the sum of my.TSclock and Snd.TSoffset. This Snd.TSclock is the sum of my.TSclock and Snd.TSoffset. This
allows the starting points for timestamps to be randomized on a allows the starting points for timestamps to be randomized on a
per-connection basis. Setting Snd.TSoffset to zero yields the per-connection basis. Setting Snd.TSoffset to zero yields the
same results as [RFC1323]. same results as [RFC1323].
(i) RTTM update processing explicitly excludes packets containing (i) RTTM update processing explicitly excludes packets containing
SACK options. This addresses inflation of the RTT during SACK options. This addresses inflation of the RTT during
episodes of packet loss in both directions. episodes of packet loss in both directions.
(j) In Section 3.2 the if-clause allowing sending of timestamps only (j) In Section 4.2 the if-clause allowing sending of timestamps only
when received in a <SYN> or <SYN,ACK> was removed, to allow for when received in a <SYN> or <SYN,ACK> was removed, to allow for
late timestamp negotiation. late timestamp negotiation.
(k) Section 2.4 was added describing the unavoidable window (k) Section 3.4 was added describing the unavoidable window
retraction issue, and explicitly describing the mitigation steps retraction issue, and explicitly describing the mitigation steps
necessary. necessary.
(l) Section 2 was added for RFC2119 wording. Normative text was
updated with the appropriate phrases.
Appendix D. Summary of Notation Appendix D. Summary of Notation
The following notation has been used in this document. The following notation has been used in this document.
Options Options
WSopt: TCP Window Scale Option WSopt: TCP Window Scale Option
TSopt: TCP Timestamps Option TSopt: TCP Timestamps Option
Option Fields Option Fields
 End of changes. 101 change blocks. 
155 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/