draft-ietf-tcpm-1323bis-17.txt   draft-ietf-tcpm-1323bis-18.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 Obsoletes: 1323 (if approved) B. Braden
Expires: May 19, 2014 University of Southern Intended status: Standards Track University of Southern
California Expires: June 8, 2014 California
V. Jacobson V. Jacobson
Google, Inc. Google, Inc.
R. Scheffenegger, Ed. R. Scheffenegger, Ed.
NetApp, Inc. NetApp, Inc.
November 15, 2013 December 5, 2013
TCP Extensions for High Performance TCP Extensions for High Performance
draft-ietf-tcpm-1323bis-17 draft-ietf-tcpm-1323bis-18
Abstract Abstract
This document specifies a set of TCP extensions to improve This document specifies a set of TCP extensions to improve
performance over paths with a large bandwidth * delay product and to performance over paths with a large bandwidth * delay product and to
provide reliable operation over very high-speed paths. It defines provide reliable operation over very high-speed paths. It defines
the TCP Window Scale (WS) option and the TCP Timestamps (TS) option the TCP Window Scale (WS) option and the TCP Timestamps (TS) option
and their semantics. The Window Scale option is used to support and their semantics. The Window Scale option is used to support
larger receive windows, while the Timestamps option can be used for larger receive windows, while the Timestamps option can be used for
at least two distinct mechanisms, PAWS (Protection Against Wrapped at least two distinct mechanisms, PAWS (Protection Against Wrapped
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 May 19, 2014. This Internet-Draft will expire on June 8, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 33 skipping to change at page 3, line 33
4.3. Which Timestamp to Echo . . . . . . . . . . . . . . . . . 16 4.3. Which Timestamp to Echo . . . . . . . . . . . . . . . . . 16
5. PAWS - Protection Against Wrapped Sequence Numbers . . . . . . 20 5. PAWS - Protection Against Wrapped Sequence Numbers . . . . . . 20
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. The PAWS Mechanism . . . . . . . . . . . . . . . . . . . . 20 5.2. The PAWS Mechanism . . . . . . . . . . . . . . . . . . . . 20
5.3. Basic PAWS Algorithm . . . . . . . . . . . . . . . . . . . 21 5.3. Basic PAWS Algorithm . . . . . . . . . . . . . . . . . . . 21
5.4. Timestamp Clock . . . . . . . . . . . . . . . . . . . . . 23 5.4. Timestamp Clock . . . . . . . . . . . . . . . . . . . . . 23
5.5. Outdated Timestamps . . . . . . . . . . . . . . . . . . . 25 5.5. Outdated Timestamps . . . . . . . . . . . . . . . . . . . 25
5.6. Header Prediction . . . . . . . . . . . . . . . . . . . . 25 5.6. Header Prediction . . . . . . . . . . . . . . . . . . . . 25
5.7. IP Fragmentation . . . . . . . . . . . . . . . . . . . . . 27 5.7. IP Fragmentation . . . . . . . . . . . . . . . . . . . . . 27
5.8. Duplicates from Earlier Incarnations of Connection . . . . 27 5.8. Duplicates from Earlier Incarnations of Connection . . . . 27
6. Conclusions and Acknowledgements . . . . . . . . . . . . . . . 28 6. Conclusions and Acknowledgments . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 30 7.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Implementation Suggestions . . . . . . . . . . . . . 34 Appendix A. Implementation Suggestions . . . . . . . . . . . . . 34
Appendix B. Duplicates from Earlier Connection Incarnations . . . 35 Appendix B. Duplicates from Earlier Connection Incarnations . . . 35
B.1. System Crash with Loss of State . . . . . . . . . . . . . 36 B.1. System Crash with Loss of State . . . . . . . . . . . . . 35
B.2. Closing and Reopening a Connection . . . . . . . . . . . . 36 B.2. Closing and Reopening a Connection . . . . . . . . . . . . 35
Appendix C. Summary of Notation . . . . . . . . . . . . . . . . . 37 Appendix C. Summary of Notation . . . . . . . . . . . . . . . . . 37
Appendix D. Event Processing Summary . . . . . . . . . . . . . . 38 Appendix D. Event Processing Summary . . . . . . . . . . . . . . 38
Appendix E. Timestamps Edge Cases . . . . . . . . . . . . . . . . 44 Appendix E. Timestamps Edge Cases . . . . . . . . . . . . . . . . 43
Appendix F. Window Retraction Example . . . . . . . . . . . . . . 45 Appendix F. Window Retraction Example . . . . . . . . . . . . . . 44
Appendix G. RTO calculation modification . . . . . . . . . . . . 45 Appendix G. RTO calculation modification . . . . . . . . . . . . 44
Appendix H. Changes from RFC 1323 . . . . . . . . . . . . . . . . 46 Appendix H. Changes from RFC 1323 . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
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. Over the delay, corruption, duplication, or reordering of segments. Over the
years, advances in networking technology have resulted in ever-higher years, advances in networking technology have resulted in ever-higher
transmission speeds, and the fastest paths are well beyond the domain transmission speeds, and the fastest paths are well beyond the domain
for which TCP was originally engineered. for which TCP was originally engineered.
skipping to change at page 5, line 22 skipping to change at page 5, line 22
Packet losses in an LFN can have a catastrophic effect on Packet losses in an LFN can have a catastrophic effect on
throughput. throughput.
To generalize the Fast Retransmit / Fast Recovery mechanism to To generalize the Fast Retransmit / Fast Recovery mechanism to
handle multiple packets dropped per window, Selective handle multiple packets dropped per window, Selective
Acknowledgments are required. Unlike the normal cumulative Acknowledgments are required. Unlike the normal cumulative
acknowledgments of TCP, Selective Acknowledgments give the acknowledgments of TCP, Selective Acknowledgments give the
sender a complete picture of which segments are queued at the sender a complete picture of which segments are queued at the
receiver and which have not yet arrived. receiver and which have not yet arrived.
Selective acknowledgements and their use are specified in Selective acknowledgments and their use are specified in
separate documents, "TCP Selective Acknowledgment options" separate documents, "TCP Selective Acknowledgment options"
[RFC2018], "An Extension to the Selective Acknowledgement (SACK) [RFC2018], "An Extension to the Selective Acknowledgement (SACK)
option for TCP" [RFC2883], and "A Conservative Selective option for TCP" [RFC2883], and "A Conservative Selective
Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP" Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP"
[RFC6675], and not further discussed in this document. [RFC6675], and not further discussed in this document.
1.2. TCP Reliability 1.2. TCP Reliability
An especially serious kind of error may result from an accidental An especially serious kind of error may result from an accidental
reuse of TCP sequence numbers in data segments. TCP reliability reuse of TCP sequence numbers in data segments. TCP reliability
skipping to change at page 6, line 8 skipping to change at page 6, line 8
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 specification, as enforcing the current fixed MSL of the TCP specification, as
explained in Section 5.8 and Appendix B. In addition, the randmizing explained in Section 5.8 and Appendix B. In addition, the
of ephemeral ports can also help to probabilistically reduce the randomizing of ephemeral ports can also help to probabilistically
chances of duplicates from earlier connections. However, case (1), reduce the chances of duplicates from earlier connections. However,
avoiding the reuse of sequence numbers within the same connection, case (1), avoiding the reuse of sequence numbers within the same
requires an upper bound on MSL that depends upon the transfer rate, connection, requires an upper bound on MSL that depends upon the
and at high enough rates, a dedicated mechanism is required. transfer rate, and at high enough rates, a dedicated mechanism is
required.
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 5 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
skipping to change at page 7, line 18 skipping to change at page 7, line 19
other uses of the Timestamps option, such as the Eifel mechanism other uses of the Timestamps option, such as the Eifel mechanism
[RFC3522], [RFC4015], and PAWS (see Section 5) which improve overall [RFC3522], [RFC4015], and PAWS (see Section 5) which improve overall
TCP security and performance. The extra header bandwidth used by TCP security and performance. The extra header bandwidth used by
this option should be evaluated for the gains in performance and this option should be evaluated for the gains in performance and
security in an actual deployment. security in an actual deployment.
Appendix A contains a recommended layout of the options in TCP Appendix A contains a recommended layout of the options in TCP
headers to achieve reasonable data field alignment. headers to achieve reasonable data field alignment.
Finally, we observe that most of the mechanisms defined in this Finally, we observe that most of the mechanisms defined in this
document are important for LFN's and/or very high-speed networks. document are important for LFNs and/or very high-speed networks. For
For low-speed networks, it might be a performance optimization to NOT low-speed networks, it might be a performance optimization to NOT use
use these mechanisms. A TCP vendor concerned about optimal these mechanisms. A TCP vendor concerned about optimal performance
performance over low-speed paths might consider turning these over low-speed paths might consider turning these extensions off for
extensions off for low- speed paths, or allow a user or installation low- speed paths, or allow a user or installation manager to disable
manager to disable them. them.
1.4. Terminology 1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
In this document, these words will appear with that interpretation In this document, these words will appear with that interpretation
only when in UPPER CASE. Lower case uses of these words are not to only when in UPPER CASE. Lower case uses of these words are not to
be interpreted as carrying [RFC2119] significance. be interpreted as carrying [RFC2119] significance.
skipping to change at page 12, line 30 skipping to change at page 12, line 30
that information. In particular, the Round Trip Time Measurement that information. In particular, the Round Trip Time Measurement
(RTTM) mechanism must be viewed independently from updating the (RTTM) mechanism must be viewed independently from updating the
Retransmission Timeout (RTO) (see Section 4.2). In this case, the Retransmission Timeout (RTO) (see Section 4.2). In this case, the
sample granularity also needs to be taken into account. Other sample granularity also needs to be taken into account. Other
mechanisms, such as PAWS, or Eifel, are not built upon the timestamp mechanisms, such as PAWS, or Eifel, are not built upon the timestamp
information itself, but are based on the intrinsic property of information itself, but are based on the intrinsic property of
monotonically non-decreasing values. monotonically non-decreasing values.
The Timestamps option is important when large receive windows are The Timestamps option is important when large receive windows are
used, to allow the use of the PAWS mechanism (see Section 5). used, to allow the use of the PAWS mechanism (see Section 5).
Furthermore, the option may be useful for all TCP's, since it Furthermore, the option may be useful for all TCPs, since it
simplifies the sender and allows the use of additional optimizations simplifies the sender and allows the use of additional optimizations
such as Eifel ([RFC3522], [RFC4015]) and others ([RFC6817], such as Eifel ([RFC3522], [RFC4015]) and others ([RFC6817],
[Kuzmanovic03], [Kuehlewind10]. [Kuzmanovic03], [Kuehlewind10].
3.2. Timestamps option 3.2. 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
skipping to change at page 15, line 11 skipping to change at page 15, line 11
This update to [RFC1323] describes explicitly the previous assumption This update to [RFC1323] describes explicitly the previous assumption
(see Section 5.2), that each TCP segment must have TSopt, once (see Section 5.2), that each TCP segment must have TSopt, once
negotiated. negotiated.
4. The RTTM Mechanism 4. The RTTM Mechanism
4.1. Introduction 4.1. Introduction
One use of the Timestamps option is to measure the round trip time of One use of the Timestamps option is to measure the round trip time of
virtually every packet acknowledged. The Round Trip Time Measurement virtually every packet acknowledged. The Round Trip Time Measurement
(RTTM) mechansim requires a Timestamps option in every measured (RTTM) mechanism requires a Timestamps option in every measured
segment, with a TSval that is obtained from a (virtual) "timestamp segment, with a TSval that is obtained from a (virtual) "timestamp
clock". Values of this clock MUST be at least approximately clock". Values of this clock MUST be at least approximately
proportional to real time, in order to measure actual RTT. proportional to real time, in order to measure actual RTT.
TCP measures the round trip time (RTT), primarily for the purpose of TCP measures the round trip time (RTT), primarily for the purpose of
arriving at a reasonable value for the Retransmission Timeout (RTO) arriving at a reasonable value for the Retransmission Timeout (RTO)
timer interval. Accurate and current RTT estimates are necessary to timer interval. Accurate and current RTT estimates are necessary to
adapt to changing traffic conditions, while a conservative estimate adapt to changing traffic conditions, while a conservative estimate
of the RTO interval is necessary to minimize spurious RTOs. of the RTO interval is necessary to minimize spurious RTOs.
skipping to change at page 17, line 11 skipping to change at page 17, line 11
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 second segment out of a group Many TCPs acknowledge only every second segment out of a group
of segments arriving within a short time interval; this policy of segments arriving within a short time interval; this policy
is known generally as "delayed ACKs". The data-sender TCP must is 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
skipping to change at page 21, line 43 skipping to change at page 21, line 43
received, it MUST NOT be subjected to the PAWS check by verifying an received, it MUST NOT be subjected to the PAWS check by verifying an
acceptable value in SEG.TSval, and information from the Timestamps acceptable value in SEG.TSval, and information from the Timestamps
option MUST NOT be used to update connection state information. option MUST NOT be used to update connection state information.
SEG.TSecr MAY be used to provide stricter <RST> acceptance checks. SEG.TSecr MAY be used to provide stricter <RST> acceptance checks.
5.3. Basic PAWS Algorithm 5.3. Basic PAWS Algorithm
If the PAWS algorithm is used, the following processing MUST be If the PAWS algorithm is used, the following processing MUST be
performed on all incoming segments for a synchronized connection. performed on all incoming segments for a synchronized connection.
Also, PAWS processing MUST take precedence over the regular TCP Also, PAWS processing MUST take precedence over the regular TCP
acceptablitiy check (Section 3.3 in [RFC0793]), which is performed acceptabiltiy check (Section 3.3 in [RFC0793]), which is performed
after verification of the received Timestamps option: after verification of the received Timestamps option:
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 [RFC0793] Send an acknowledgment in reply as specified in [RFC0793]
page 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 half- open connections. For example, see Figure 10 of
[RFC0793]. [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)
skipping to change at page 28, line 5 skipping to change at page 28, line 5
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.
6. Conclusions and Acknowledgements 6. Conclusions and Acknowledgments
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 stacks that do not to provide compatible interworking with TCP stacks that do not
implement the extensions. implement the extensions.
These mechanisms are implemented using TCP options for scaled windows These mechanisms are implemented using TCP options for scaled windows
and timestamps. The timestamps are used for two distinct mechanisms: and timestamps. 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 31, line 14 skipping to change at page 31, line 14
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[Allman99] [Allman99]
Allman, M. and V. Paxson, "On Estimating End-to-End Allman, M. and V. Paxson, "On Estimating End-to-End
Network Path Properties", Proc. ACM SIGCOMM Technical Network Path Properties", Proc. ACM SIGCOMM Technical
Symposium, Cambridge, MA, September 1999, Symposium, Cambridge, MA, September 1999,
<http://aciri.org/mallman/papers/estimation-la.pdf>. <http://aciri.org/mallman/papers/estimation-la.pdf>.
[Ekstroem04]
Ekstroem, H. and R. Ludwig, "The Peak-Hopper: A New End-
to-End Retransmission Timer for Reliable Unicast
Transport", INFOCOM 2004 IEEE, March 2004, <http://
citeseerx.ist.psu.edu/viewdoc/
download?doi=10.1.1.76.2748&rep=rep1&type=pdf>.
[Floyd05] Floyd, S., "[tcpm] How the RTO should be estimated with [Floyd05] Floyd, S., "[tcpm] How the RTO should be estimated with
timestamps", Message from 26.Jan.2007 to the tcpm mailing timestamps", Message from 26.Jan.2007 to the tcpm mailing
list, August 2005, <http://www.ietf.org/mail-archive/web/ list, August 2005, <http://www.ietf.org/mail-archive/web/
tcpm/current/msg02508.html>. tcpm/current/msg02508.html>.
[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]
Hamming, R., "Digital Filters", Prentice Hall, Englewood
Cliffs, N.J. ISBN 0-13-212571-4, 1977.
[Honda11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., [Honda11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
Handley, M., and H. Tokuda, "Is it still possible to Handley, M., and H. Tokuda, "Is it still possible to
extend TCP?", Proc. of ACM Internet Measurement extend TCP?", Proc. of ACM Internet Measurement
Conference (IMC) '11, November 2011. Conference (IMC) '11, November 2011.
[Jacobson88a] [Jacobson88a]
Jacobson, V., "Congestion Avoidance and Control", SIGCOMM Jacobson, V., "Congestion Avoidance and Control", SIGCOMM
'88, Stanford, CA., August 1988, '88, Stanford, CA., August 1988,
<http://ee.lbl.gov/papers/congavoid.pdf>. <http://ee.lbl.gov/papers/congavoid.pdf>.
[Jacobson90a] [Jacobson90a]
Jacobson, V., "4BSD Header Prediction", ACM Computer Jacobson, V., "4BSD Header Prediction", ACM Computer
Communication Review, April 1990. Communication Review, April 1990.
[Jacobson90c] [Jacobson90c]
Jacobson, V., "Modified TCP congestion avoidance Jacobson, V., "Modified TCP congestion avoidance
algorithm", Message to the end2end-interest mailing list, algorithm", Message to the end2end-interest mailing list,
April 1990, April 1990,
<ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail>. <ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail>.
[Jain86] Jain, R., "Divergence of Timeout Algorithms for Packet
Retransmissions", Proc. Fifth Phoenix Conf. on Comp. and
Comm., Scottsdale, Arizona, March 1986,
<http://arxiv.org/ftp/cs/papers/9809/9809097.pdf>.
[Karn87] Karn, P. and C. Partridge, "Estimating Round-Trip Times in [Karn87] Karn, P. and C. Partridge, "Estimating Round-Trip Times in
Reliable Transport Protocols", Proc. SIGCOMM '87, Reliable Transport Protocols", Proc. SIGCOMM '87,
August 1987. August 1987.
[Kuehlewind10] [Kuehlewind10]
Kuehlewind, M. and B. Briscoe, "Chirping for Congestion Kuehlewind, M. and B. Briscoe, "Chirping for Congestion
Control - Implementation Feasibility", November 2010, Control - Implementation Feasibility", November 2010,
<bobbriscoe.net/projects/netsvc_i-f/chirp_pfldnet10.pdf>. <bobbriscoe.net/projects/netsvc_i-f/chirp_pfldnet10.pdf>.
[Kuzmanovic03] [Kuzmanovic03]
skipping to change at page 32, line 38 skipping to change at page 32, line 22
Ludwig, R. and K. Sklower, "The Eifel Retransmission Ludwig, R. and K. Sklower, "The Eifel Retransmission
Timer", ACM SIGCOMM Computer Communication Review Volume Timer", ACM SIGCOMM Computer Communication Review Volume
30 Issue 3, July 2000, <http://ccr.sigcomm.org/archive/ 30 Issue 3, July 2000, <http://ccr.sigcomm.org/archive/
2000/july00/LudwigFinal.pdf>. 2000/july00/LudwigFinal.pdf>.
[Martin03] [Martin03]
Martin, D., "[Tsvwg] RFC 1323.bis", Message to the tsvwg Martin, D., "[Tsvwg] RFC 1323.bis", Message to the tsvwg
mailing list, September 2003, <http://www.ietf.org/ mailing list, September 2003, <http://www.ietf.org/
mail-archive/web/tsvwg/current/msg04435.html>. mail-archive/web/tsvwg/current/msg04435.html>.
[Mathis08]
Mathis, M., "[tcpm] Example of 1323 window retraction
problem", Message to the tcpm mailing list, March 2008, <h
ttp://www.ietf.org/mail-archive/web/tcpm/current/
msg03564.html>.
[Medina04] [Medina04]
Medina, A., Allman, M., and S. Floyd, "Measuring Medina, A., Allman, M., and S. Floyd, "Measuring
Interactions Between Transport Protocols and Middleboxes", Interactions Between Transport Protocols and Middleboxes",
Proc. ACM SIGCOMM/USENIX Internet Measurement Conference. Proc. ACM SIGCOMM/USENIX Internet Measurement Conference.
October 2004, August 2004, October 2004, August 2004,
<http://www.icir.net/tbit/tbit-Aug2004.pdf>. <http://www.icir.net/tbit/tbit-Aug2004.pdf>.
[Medina05] [Medina05]
Medina, A., Allman, M., and S. Floyd, "Measuring the Medina, A., Allman, M., and S. Floyd, "Measuring the
Evolution of Transport Protocols in the Internet", ACM Evolution of Transport Protocols in the Internet", ACM
Computer Communication Review 35(2), April 2005, Computer Communication Review 35(2), April 2005,
<http://icir.net/floyd/papers/TCPevolution-Mar2005.pdf>. <http://icir.net/floyd/papers/TCPevolution-Mar2005.pdf>.
[Oppermann13] [Oppermann13]
Oppermann, A., "[tcpm] Explanation to the relaxation of Oppermann, A., "[tcpm] Explanation to the relaxation of
TSopt acceptance rules", Message to the tcpm mailing list, TSopt acceptance rules", Message to the tcpm mailing list,
Jun 2013, <http://www.ietf.org/mail-archive/web/tcpm/ Jun 2013, <http://www.ietf.org/mail-archive/web/tcpm/
current/msg08001.html>. current/msg08001.html>.
[RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984.
[RFC1072] Jacobson, V. and R. Braden, "TCP extensions for long-delay [RFC1072] Jacobson, V. and R. Braden, "TCP extensions for long-delay
paths", RFC 1072, October 1988. paths", RFC 1072, October 1988.
[RFC1110] McKenzie, A., "Problem with the TCP big window option",
RFC 1110, August 1989.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1185] Jacobson, V., Braden, B., and L. Zhang, "TCP Extension for [RFC1185] Jacobson, V., Braden, B., and L. Zhang, "TCP Extension for
High-Speed Paths", RFC 1185, October 1990. High-Speed Paths", RFC 1185, October 1990.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996. Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999. RFC 2675, August 1999.
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, July 2000. for TCP", RFC 2883, July 2000.
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm
for TCP", RFC 3522, April 2003. for TCP", RFC 3522, April 2003.
skipping to change at page 34, line 36 skipping to change at page 34, line 5
Based on Selective Acknowledgment (SACK) for TCP", Based on Selective Acknowledgment (SACK) for TCP",
RFC 6675, August 2012. RFC 6675, August 2012.
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
RFC 6691, July 2012. RFC 6691, July 2012.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
December 2012. December 2012.
[Watson81]
Watson, R., "Timer-based Mechanisms in Reliable Transport
Protocol Connection Management", Computer Networks, Vol.
5, 1981.
[Zhang86] Zhang, L., "Why TCP Timers Don't Work Well", Proc. SIGCOMM
'86, Stowe, VT, August 1986.
Appendix A. Implementation Suggestions Appendix A. Implementation Suggestions
TCP Option Layout TCP Option Layout
The following layout is recommended for sending options on non- The following layout is recommended for sending options on non-
<SYN> segments, to achieve maximum feasible alignment of 32-bit <SYN> segments, to achieve maximum feasible alignment of 32-bit
and 64-bit machines. and 64-bit machines.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| NOP | NOP | TSopt | 10 | | NOP | NOP | TSopt | 10 |
skipping to change at page 41, line 23 skipping to change at page 40, line 32
... ...
... ...
fourth check the SYN bit fourth check the SYN bit
... ...
If the SYN bit is on and the security/compartment and If the SYN bit is on and the security/compartment and
precedence are acceptable then, RCV.NXT is set to SEG.SEQ+1, precedence are acceptable then, RCV.NXT is set to SEG.SEQ+1,
IRS is set to SEG.SEQ, and any acknowledgements on the IRS is set to SEG.SEQ, and any acknowledgments on the
retransmission queue which are thereby acknowledged should retransmission queue which are thereby acknowledged should
be removed. be removed.
Check for a Window Scale option (WSopt); if it is found, Check for a Window Scale option (WSopt); if it is found,
save SEG.WSopt in Snd.Wind.Shift; otherwise, set both save SEG.WSopt in Snd.Wind.Shift; otherwise, set both
Snd.Wind.Shift and Rcv.Wind.Shift to zero. Snd.Wind.Shift and Rcv.Wind.Shift to zero.
Check for a TSopt option; if one is found, save SEG.TSval in 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 variable TS.Recent and turn on the Snd.TS.OK bit in the
connection control block. If the ACK bit is set, use connection control block. If the ACK bit is set, use
skipping to change at page 47, line 37 skipping to change at page 46, line 45
(i) Added text to clarify the precedence between regular TCP (i) Added text to clarify the precedence between regular TCP
[RFC0793] and this document Timestamps option / PAWS processing. [RFC0793] and this document Timestamps option / PAWS processing.
Discussion about combined acceptability checks are ongoing. Discussion about combined acceptability checks are ongoing.
(j) Snd.TSoffset and Snd.TSclock variables have been added. (j) 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 timestamp values to be randomized allows the starting points for timestamp values to be randomized
on a per-connection basis. Setting Snd.TSoffset to zero yields on a per-connection basis. Setting Snd.TSoffset to zero yields
the same results as [RFC1323]. Text was added to guide the same results as [RFC1323]. Text was added to guide
implementors to the proper selection of these offsets, as implementers to the proper selection of these offsets, as
entirly random offsets for each new connection will conflict entirely random offsets for each new connection will conflict
with PAWS. with PAWS.
(k) Appendix A has been expanded with information about the TCP (k) Appendix A has been expanded with information about the TCP
Urgent Pointer. An earlier revision contained text around the Urgent Pointer. An earlier revision contained text around the
TCP MSS option, which was split off into [RFC6691]. TCP MSS option, which was split off into [RFC6691].
(l) One correction was made to the Event Processing Summary in (l) One correction was made to the Event Processing Summary in
Appendix D. In SEND CALL/ESTABLISHED STATE, RCV.WND is used to Appendix D. In SEND CALL/ESTABLISHED STATE, RCV.WND is used to
fill in the SEG.WND value, not SND.WND. fill in the SEG.WND value, not SND.WND.
skipping to change at page 48, line 30 skipping to change at page 47, line 34
certain environments. certain environments.
(c) Removed references to "new" options, as the options were (c) Removed references to "new" options, as the options were
introduced in [RFC1323] already. Changed the text in introduced in [RFC1323] already. Changed the text in
Section 1.3 to specifically address TS and WS options. Section 1.3 to specifically address TS and WS options.
(d) Section 1.4 was added for [RFC2119] wording. Normative text was (d) Section 1.4 was added for [RFC2119] wording. Normative text was
updated with the appropriate phrases. updated with the appropriate phrases.
(e) Added < > brackets to mark specific types of segments, and (e) Added < > brackets to mark specific types of segments, and
replaced most occurances of "packet" with "segment", where TCP replaced most occurences of "packet" with "segment", where TCP
segments are referred to. segments are referred to.
(f) Updated the text in Section 3 to take into account what has been (f) Updated the text in Section 3 to take into account what has been
learned since [RFC1323]. learned since [RFC1323].
(g) Removed the list of changes between [RFC1323] and prior (g) Removed some unused references.
(h) Removed the list of changes between [RFC1323] and prior
versions. These changes are mentioned in Appendix C of versions. These changes are mentioned in Appendix C of
[RFC1323]. [RFC1323].
(h) Moved Appendix Changes from RFC 1323 to the end of the (i) Moved Appendix Changes from RFC 1323 to the end of the
appendices for easier lookup. In addition, the entries were appendices for easier lookup. In addition, the entries were
split into a technical and an editorial part, and sorted to split into a technical and an editorial part, and sorted to
roughly correspond with the sections in the text where they roughly correspond with the sections in the text where they
apply. apply.
Authors' Addresses Authors' Addresses
David Borman David Borman
Quantum Corporation Quantum Corporation
Mendota Heights MN 55120 Mendota Heights MN 55120
 End of changes. 29 change blocks. 
77 lines changed or deleted 41 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/