TCP Fast Open

The information below is for an old version of the document
Document Type Active Internet-Draft (tcpm WG)
Authors Yuchung Cheng  , Jerry Chu  , Sivasankar Radhakrishnan  , Arvind Jain 
Last updated 2012-03-07 (latest revision 2012-02-17)
Replaces draft-cheng-tcpm-fastopen
Stream Internent Engineering Task Force (IETF)
Formats pdf htmlized (tools) htmlized 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,
Internet Draft                                                  Y. Cheng
draft-ietf-tcpm-fastopen-00.txt                                   J. Chu
Intended status: Experimental                           S. Radhakrishnan
Expiration date: August, 2012                                    A. Jain
                                                            Google, Inc.
                                                       February 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

   The list of Internet-Draft Shadow Directories can be accessed at

   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
   ( 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 August 2012                   [Page 1]
Internet Draft               TCP Fast Open                 February 2012


   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.


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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

   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

Cheng, et. al.            Expires August 2012                   [Page 2]
Internet Draft               TCP Fast Open                 February 2012

   constraints. E.g., the Chrome browser keeps TCP connections idle up
   to 5 minutes but 35% of Chrome HTTP requests are made on new TCP
Show full document text