TCP Maintenance & Minor Extensions (tcpm) J. Harris, Ed.
Internet-Draft None
Updates: 1323 (if approved) October 31, 2016
Intended status: Experimental
Expires: May 4, 2017

WSCALE options in established TCP connections


The TCP Window Scale option modifies the interpretation of packets in a flow but is transmitted only at the start of the connection. As such there is a problem for observability and fault-finding, since a packet capture by a third party may miss the start of a relevant connection. This document describes the use of TCP options to provide the scale values during a connection.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 4, 2017.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

The TCP WSCALE option [RFC1323] provides a means for scaling the effective value of window size value in the TCP header. This is needed for high bandwidth-delay product connections for adequate performance as large window sizes must be used. Use of the facility is negotiated by the presence in both SYN-bearing packets at the start of the connection of WSCALE options, and is valid with the shift values presented there for the remainder of the connection. When debugging network problems it is common to take a packet capture and heuristically interpret it. If a TCP connection is captured without the initiating SYN packets the window scale information will not be available. The TCP extension usage defined here makes it available for such debugging purposes.

1.1. Requirements Language

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 RFC 2119 [RFC2119].


2.1. Format

The wire format of the option is as defined in [RFC1323].

2.2. Sender

A TCP endpoint which has both sent and received WSCALE options in SYN-bearing packet MAY send a WSCALE option in a subsequent non-SYN-bearing packet for that connection. Any such option MUST carry the same content as the original sent by the endpoint.

[Discussion: I'd like to see these advisory WSCALE options at about the rate of one in a thousand packets. Deferring for other use of option-space, eg SACK, might be wise; the absolute rate is unimportant.]

A sender which supports this facility MUST provide a means for disabling it. This means MAY act on a per-connection basis.

[Discussion: The usual one about middleboxes failing on non-understood protocol features.]

2.3. Receiver

A TCP endpoint MUST ignore any WSCALE option received on a non-SYN-bearing packet.

3. IANA Considerations

This memo includes no request to IANA.

4. Security Considerations

This facility does not introduce any new security issues.

5. Normative References

[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

Author's Address

Jeremy Harris (editor) None 20 Lodge Lane Chalfont St.Gile, Bucks UK EMail: