idnits 2.17.1 draft-harris-estab-wscale-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC1323, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1323, updated by this document, for RFC5378 checks: 1992-05-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 31, 2016) is 2734 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance & Minor Extensions (tcpm) J. Harris, Ed. 3 Internet-Draft None 4 Updates: 1323 (if approved) October 31, 2016 5 Intended status: Experimental 6 Expires: May 4, 2017 8 WSCALE options in established TCP connections 9 draft-harris-estab-wscale-00 11 Abstract 13 The TCP Window Scale option modifies the interpretation of packets in 14 a flow but is transmitted only at the start of the connection. As 15 such there is a problem for observability and fault-finding, since a 16 packet capture by a third party may miss the start of a relevant 17 connection. This document describes the use of TCP options to 18 provide the scale values during a connection. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 4, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 56 2. TCP WINDOW SCALE OPTION . . . . . . . . . . . . . . . . . . . 2 57 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2.2. Sender . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2.3. Receiver . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 62 5. Normative References . . . . . . . . . . . . . . . . . . . . 3 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1. Introduction 67 The TCP WSCALE option [RFC1323] provides a means for scaling the 68 effective value of window size value in the TCP header. This is 69 needed for high bandwidth-delay product connections for adequate 70 performance as large window sizes must be used. Use of the facility 71 is negotiated by the presence in both SYN-bearing packets at the 72 start of the connection of WSCALE options, and is valid with the 73 shift values presented there for the remainder of the connection. 74 When debugging network problems it is common to take a packet capture 75 and heuristically interpret it. If a TCP connection is captured 76 without the initiating SYN packets the window scale information will 77 not be available. The TCP extension usage defined here makes it 78 available for such debugging purposes. 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. TCP WINDOW SCALE OPTION 88 2.1. Format 90 The wire format of the option is as defined in [RFC1323]. 92 2.2. Sender 94 A TCP endpoint which has both sent and received WSCALE options in 95 SYN-bearing packet MAY send a WSCALE option in a subsequent non-SYN- 96 bearing packet for that connection. Any such option MUST carry the 97 same content as the original sent by the endpoint. 99 [Discussion: I'd like to see these advisory WSCALE options at about 100 the rate of one in a thousand packets. Deferring for other use of 101 option-space, eg SACK, might be wise; the absolute rate is 102 unimportant.] 104 A sender which supports this facility MUST provide a means for 105 disabling it. This means MAY act on a per-connection basis. 107 [Discussion: The usual one about middleboxes failing on non- 108 understood protocol features.] 110 2.3. Receiver 112 A TCP endpoint MUST ignore any WSCALE option received on a non-SYN- 113 bearing packet. 115 3. IANA Considerations 117 This memo includes no request to IANA. 119 4. Security Considerations 121 This facility does not introduce any new security issues. 123 5. Normative References 125 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 126 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 127 1992, . 129 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 130 Requirement Levels", BCP 14, RFC 2119, 131 DOI 10.17487/RFC2119, March 1997, 132 . 134 Author's Address 136 Jeremy Harris (editor) 137 None 138 20 Lodge Lane 139 Chalfont St.Gile, Bucks 140 UK 142 Email: j16759@wizmail.org