draft-ietf-tcpm-1323bis-13.txt   draft-ietf-tcpm-1323bis-14.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: November 19, 2013 University of Southern Expires: November 24, 2013 University of Southern
California California
V. Jacobson V. Jacobson
Packet Design Packet Design
R. Scheffenegger, Ed. R. Scheffenegger, Ed.
NetApp, Inc. NetApp, Inc.
May 18, 2013 May 23, 2013
TCP Extensions for High Performance TCP Extensions for High Performance
draft-ietf-tcpm-1323bis-13 draft-ietf-tcpm-1323bis-14
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
TCP options for scaled windows and timestamps. The timestamps are TCP options for scaled windows and timestamps. The timestamps are
used for two distinct mechanisms, RTTM (Round Trip Time Measurement) used for two distinct mechanisms, RTTM (Round Trip Time Measurement)
and PAWS (Protection Against Wrapped Sequences). and PAWS (Protection Against Wrapped Sequences).
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 November 19, 2013. This Internet-Draft will expire on November 24, 2013.
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
skipping to change at page 13, line 25 skipping to change at page 13, line 25
received; 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., segment containing a SYN bit and no ACK bit), and MAY segment (i.e., segment containing a SYN bit and no ACK bit), and MAY
send a TSopt in other segments only if it received a TSopt in the send a TSopt in other segments only if it received a TSopt in the
initial <SYN> or <SYN,ACK> segment for the connection. initial <SYN> or <SYN,ACK> segment for the connection.
Once TSopt has been successfully negotiated (sent and received) Once TSopt has been successfully negotiated (sent and received)
during the <SYN>, <SYN,ACK> exchange, TSopt MUST be sent in every during the <SYN>, <SYN,ACK> exchange, TSopt MUST be sent in every
non-<RST> segment for the duration of the connection, and SHOULD be non-<RST> segment for the duration of the connection, and SHOULD be
sent in a <RST> segment (see Section 4.2 for details). If a non- sent in an <RST> segment (see Section 4.2 for details). If a non-
<RST> segment is received without a TSopt, a TCP MAY drop the segment <RST> segment is received without a TSopt, a TCP MUST drop the
and send an <ACK> for the last in-sequence segment. A TCP MUST NOT segment and MAY also send an <ACK> for the last in-sequence segment.
abort a TCP connection if a non-<RST> segment is received without a A TCP MUST NOT abort a TCP connection because any segment lacks an
TSopt. expected TSopt.
If a TSopt is received on a connection where TSopt was not negotiated If a TSopt is received on a connection where TSopt was not negotiated
in the initial three-way handshake, the TSopt MUST be ignored and the in the initial three-way handshake, the TSopt MUST be ignored and the
packet processed normally. packet processed normally.
In the case of crossing <SYN> segments where one <SYN> contains a In the case of crossing <SYN> segments where one <SYN> contains a
TSopt and the other doesn't, both sides MAY send a TSopt in the TSopt and the other doesn't, both sides MAY send a TSopt in the
<SYN,ACK> segment. <SYN,ACK> segment.
TSopt is required for the two mechanisms described in sections 3.3 TSopt is required for the two mechanisms described in sections 3.3
skipping to change at page 19, line 26 skipping to change at page 19, line 26
[RFC1323] recommended that <RST> segments NOT carry timestamps, and [RFC1323] recommended that <RST> segments NOT carry timestamps, and
that they be acceptable regardless of their timestamp. At that time, that they be acceptable regardless of their timestamp. At that time,
the thinking was that old duplicate <RST> segments should be the thinking was that old duplicate <RST> segments should be
exceedingly unlikely, and their cleanup function should take exceedingly unlikely, and their cleanup function should take
precedence over timestamps. More recently, discussions about various precedence over timestamps. More recently, discussions about various
blind attacks on TCP connections have raised the suggestion that if blind attacks on TCP connections have raised the suggestion that if
the Timestamps option is present, SEG.TSecr could be used to provide the Timestamps option is present, SEG.TSecr could be used to provide
stricter acceptance tests for <RST> segments. While still under stricter acceptance tests for <RST> segments. While still under
discussion, to enable research into this area it is now RECOMMENDED discussion, to enable research into this area it is now RECOMMENDED
that when generating a <RST>, that if the segment causing the <RST> that when generating an <RST>, that if the segment causing the <RST>
to be generated contained a Timestamps option, that the <RST> also to be generated contained a Timestamps option, that the <RST> also
contain a Timestamps option. In the <RST> segment, SEG.TSecr SHOULD contain a Timestamps option. In the <RST> segment, SEG.TSecr SHOULD
be set to SEG.TSval from the incoming segment and SEG.TSval SHOULD be be set to SEG.TSval from the incoming segment and SEG.TSval SHOULD be
set to zero. If a <RST> is being generated because of a user abort, set to zero. If an <RST> is being generated because of a user abort,
and Snd.TS.OK is set, then a Timestamps option SHOULD be included in and Snd.TS.OK is set, then a Timestamps option SHOULD be included in
the <RST>. When a <RST> segment is received, it MUST NOT be the <RST>. When an <RST> segment is received, it MUST NOT be
subjected to PAWS checks, and information from the Timestamps option subjected to PAWS checks, and information from the Timestamps option
MUST NOT be used to update connection state information. SEG.TSecr MUST NOT be used to update connection state information. SEG.TSecr
MAY be used to provide stricter <RST> acceptance checks. MAY be used to provide stricter <RST> acceptance checks.
4.3. Basic PAWS Algorithm 4.3. 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. Also, PAWS on all incoming segments for a synchronized connection. Also, PAWS
processing MUST take precedence over the regular TCP acceptablitiy processing MUST take precedence over the regular TCP acceptablitiy
check (Section 3.3 in [RFC0793]), which is performed after check (Section 3.3 in [RFC0793]), which is performed after
skipping to change at page 45, line 9 skipping to change at page 45, line 9
(a) Removed much of the discussion in Section 1 to streamline the (a) Removed much of the discussion in Section 1 to streamline the
document. However, detailed examples and discussions in document. However, detailed examples and discussions in
Section 2, Section 3 and Section 4 are kept as guideline for Section 2, Section 3 and Section 4 are kept as guideline for
implementers. implementers.
(b) Removed references to "new" options, as the options were (b) 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.
(c) Section 1.4 was added for RFC2119 wording. Normative text was (c) Section 1.4 was added for [RFC2119] wording. Normative text was
updated with the appropriate phrases. updated with the appropriate phrases.
(d) Added < > brackets to mark specific types of segments, and (d) Added < > brackets to mark specific types of segments, and
replaced most occurances of "packet" with "segment", where TCP replaced most occurances of "packet" with "segment", where TCP
segments are referred to. segments are referred to.
(e) Updated the text in Section 3 to take into account what has been (e) Updated the text in Section 3 to take into account what has been
learned since [RFC1323]. learned since [RFC1323].
(f) Removed the list of changes between [RFC1323] and prior (f) 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].
(g) Moved Appendix Changes from RFC 1323 at the end of the (g) 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. 10 change blocks. 
14 lines changed or deleted 14 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/