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-10-22
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-02.txt                                   J. Chu
Intended status: Experimental                           S. Radhakrishnan
Expiration date: April, 2013                                     A. Jain
                                                            Google, Inc.
                                                        Octobor 22, 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 April 2013                   [Page 1]
Internet Draft               TCP Fast Open                  Octobor 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 saving up to one full round trip time
   (RTT) compared to standard TCP which requires 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's
   connection handshake.

   This document describes a design that enables applications to save a
   round trip 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. This 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 of deployment issues and
   related proposals. TFO requires extensions to the socket API but this
   document does not cover that.

   TFO is motivated by the performance needs 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 propagation delay and queuing delay. Network
   bandwidth has grown substantially over the past two decades, reducing
   queuing 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
   adds one RTT to the network latency. For short transfers (e.g., web
   objects) this additional RTT is 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 constraints. For
   example, the Chrome browser keeps TCP connections idle up to 5

Cheng, et. al.             Expires April 2013                   [Page 2]
Internet Draft               TCP Fast Open                  Octobor 2012
Show full document text