TCP Fast Open
draft-ietf-tcpm-fastopen-01
| The information below is for an old version of the document |
| Document |
Type |
|
Active Internet-Draft (tcpm WG)
|
|
Last updated |
|
2012-07-16
|
|
Replaces |
|
draft-cheng-tcpm-fastopen
|
|
Stream |
|
IETF
|
|
Intended RFC status |
|
Experimental
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
None
|
| IESG |
IESG state |
|
AD is watching
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Wesley Eddy
|
|
Send notices to |
|
tcpm-chairs@tools.ietf.org, draft-ietf-tcpm-fastopen@tools.ietf.org
|
Internet Draft Y. Cheng
draft-ietf-tcpm-fastopen-01.txt J. Chu
Intended status: Experimental S. Radhakrishnan
Expiration date: Feburary, 2013 A. Jain
Google, Inc.
July 16, 2012
TCP Fast Open
Status of this Memo
Distribution of this memo is unlimited.
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), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire in August, 2012.
Copyright Notice
Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) 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.
Cheng, et. al. Expires Feburary 2013 [Page 1]
Internet Draft TCP Fast Open July 2012
Abstract
TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK
packets and consumed by the receiving end during the initial
connection handshake, thus providing a saving of up to one full round
trip time (RTT) compared to standard TCP requiring a three-way
handshake (3WHS) to complete before data can be exchanged.
Terminology
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].
TFO refers to TCP Fast Open. Client refers to the TCP's active open
side and server refers to the TCP's passive open side.
1. Introduction
TCP Fast Open (TFO) enables data to be exchanged safely during TCP
connection handshake.
This document describes a design that enables qualified applications
to attain a round trip saving while avoiding severe security
ramifications. At the core of TFO is a security cookie used by the
server side to authenticate a client initiating a TFO connection. The
document covers the details of exchanging data during TCP's initial
handshake, the protocol for TFO cookies, and potential new security
vulnerabilities and their mitigation. It also includes discussions on
deployment issues and related proposals. TFO requires extensions to
the existing socket API, which will be covered in a separate
document.
TFO is motivated by the performance need of today's Web applications.
Network latency is determined by the round-trip time (RTT) and the
number of round trips required to transfer application data. RTT
consists of transmission delay and propagation delay. Network
bandwidth has grown substantially over the past two decades, much
reducing the transmission delay, while propagation delay is largely
constrained by the speed of light and has remained unchanged.
Therefore reducing the number of round trips has become the most
effective way to improve the latency of Web applications [CDCM11].
Standard TCP only permits data exchange after 3WHS [RFC793], which
introduces one RTT delay to the network latency. For short transfers,
e.g., web objects, this additional RTT becomes a significant portion
of the network latency [THK98]. One widely deployed solution is HTTP
persistent connections. However, this solution is limited since hosts
and middle boxes terminate idle TCP connections due to resource
Show full document text