draft-ietf-tcpm-fastopen-08.txt   draft-ietf-tcpm-fastopen-09.txt 
Internet Draft Y. Cheng Internet Draft Y. Cheng
draft-ietf-tcpm-fastopen-08.txt J. Chu draft-ietf-tcpm-fastopen-09.txt J. Chu
Intended status: Experimental S. Radhakrishnan Intended status: Experimental S. Radhakrishnan
Expiration date: August, 2014 A. Jain Expiration date: January, 2015 A. Jain
Google, Inc. Google, Inc.
March 11, 2014 June 30, 2014
TCP Fast Open TCP Fast Open
Abstract Abstract
This document describes an experimental TCP mechanism TCP Fast Open This document describes an experimental TCP mechanism TCP Fast Open
(TFO). TFO allows data to be carried in the SYN and SYN-ACK packets (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
and consumed by the receiving end during the initial connection and consumed by the receiving end during the initial connection
handshake, thus saving up to one full round trip time (RTT) compared handshake, thus saving up to one full round trip time (RTT) compared
to the standard TCP, which requires a three-way handshake (3WHS) to to the standard TCP, which requires a three-way handshake (3WHS) to
skipping to change at page 2, line 29 skipping to change at page 2, line 29
2. Data In SYN . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Data In SYN . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Relaxing TCP Semantics on Duplicated SYNs . . . . . . . . . 4 2.1 Relaxing TCP Semantics on Duplicated SYNs . . . . . . . . . 4
2.2. SYNs with Spoofed IP Addresses . . . . . . . . . . . . . . 4 2.2. SYNs with Spoofed IP Addresses . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Fast Open Cookie . . . . . . . . . . . . . . . . . . . . . 7 4.1. Fast Open Cookie . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. TCP Options . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. TCP Options . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Server Cookie Handling . . . . . . . . . . . . . . . . 8 4.1.2. Server Cookie Handling . . . . . . . . . . . . . . . . 8
4.1.3. Client Cookie Handling . . . . . . . . . . . . . . . . 9 4.1.3. Client Cookie Handling . . . . . . . . . . . . . . . . 9
4.1.3.1 Client Caching Negative Responses . . . . . . . . . 9 4.1.3.1 Client Caching Negative Responses . . . . . . . . . 9
4.2. Fast Open Protocol . . . . . . . . . . . . . . . . . . . . 10 4.2. Fast Open Protocol . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Fast Open Cookie Request . . . . . . . . . . . . . . . 10 4.2.1. Fast Open Cookie Request . . . . . . . . . . . . . . . 11
4.2.2. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 14
5.1. Resource Exhaustion Attack by SYN Flood with Valid 5.1. Resource Exhaustion Attack by SYN Flood with Valid
Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1 Attacks from behind Shared Public IPs (NATs) . . . . . . 14 5.1.1 Attacks from behind Shared Public IPs (NATs) . . . . . . 15
5.2. Amplified Reflection Attack to Random Host . . . . . . . . 15 5.2. Amplified Reflection Attack to Random Host . . . . . . . . 16
6. TFO's Applicability . . . . . . . . . . . . . . . . . . . . . . 16 6. TFO's Applicability . . . . . . . . . . . . . . . . . . . . . . 17
6.1 Duplicate Data in SYNs . . . . . . . . . . . . . . . . . . . 16 6.1 Duplicate Data in SYNs . . . . . . . . . . . . . . . . . . . 17
6.2 Potential Performance Improvement . . . . . . . . . . . . . 16 6.2 Potential Performance Improvement . . . . . . . . . . . . . 17
6.3. Example: Web Clients and Servers . . . . . . . . . . . . . 17 6.3. Example: Web Clients and Servers . . . . . . . . . . . . . 18
6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 17 6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 18
6.3.2. Speculative Connections by the Applications . . . . . . 17 6.3.2. Speculative Connections by the Applications . . . . . . 18
6.3.3. HTTP over TLS (HTTPS) . . . . . . . . . . . . . . . . . 17 6.3.3. HTTP over TLS (HTTPS) . . . . . . . . . . . . . . . . . 18
6.3.4. Comparison with HTTP Persistent Connections . . . . . . 17 6.3.4. Comparison with HTTP Persistent Connections . . . . . . 18
7. Open Areas for Experimentation . . . . . . . . . . . . . . . . 18 7. Open Areas for Experimentation . . . . . . . . . . . . . . . . 19
7.1. Performance impact due to middle-boxes and NAT . . . . . . 18 7.1. Performance impact due to middle-boxes and NAT . . . . . . 19
7.2. Cookie-less Fast Open . . . . . . . . . . . . . . . . . . . 19 7.2. Cookie-less Fast Open . . . . . . . . . . . . . . . . . . . 20
7.3 Impact on congestion control . . . . . . . . . . . . . . . . 19 7.3 Impact on congestion control . . . . . . . . . . . . . . . . 20
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 20 8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 21
8.3. TCP Cookie Transaction (TCPCT) . . . . . . . . . . . . . . 20 8.3. TCP Cookie Transaction (TCPCT) . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Example Socket API Changes to support TFO . . . . . . 23 Appendix A. Example Socket API Changes to support TFO . . . . . . 25
A.1 Active Open . . . . . . . . . . . . . . . . . . . . . . . . 23 A.1 Active Open . . . . . . . . . . . . . . . . . . . . . . . . 25
A.2 Passive Open . . . . . . . . . . . . . . . . . . . . . . . . 23 A.2 Passive Open . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
TCP Fast Open (TFO) is an experimental update to TCP that enables TCP Fast Open (TFO) is an experimental update to TCP that enables
data to be exchanged safely during TCP's connection handshake. This data to be exchanged safely during TCP's connection handshake. This
document describes a design that enables applications to save a round document describes a design that enables applications to save a round
trip while avoiding severe security ramifications. At the core of TFO trip while avoiding severe security ramifications. At the core of TFO
is a security cookie used by the server side to authenticate a client is a security cookie used by the server side to authenticate a client
initiating a TFO connection. This document covers the details of initiating a TFO connection. This document covers the details of
exchanging data during TCP's initial handshake, the protocol for TFO exchanging data during TCP's initial handshake, the protocol for TFO
cookies, potential new security vulnerabilities and their mitigation, cookies, potential new security vulnerabilities and their mitigation,
and the new socket API. and the new socket API.
TFO is motivated by the performance needs of today's Web TFO is motivated by the performance needs of today's Web
applications. Current TCP only permits data exchange after the 3-way applications. Current TCP only permits data exchange after the 3-way
handshake (3WHS)[RFC793], which adds one RTT to network latency. For handshake (3WHS)[RFC793], which adds one RTT to network latency. For
short Web transfers this additional RTT is a significant portion of short Web transfers this additional RTT is a significant portion of
overall network latency, even when HTTP persistent connection is overall network latency, even when HTTP persistent connection is
widely used. For example, the Chrome browser keeps TCP connections widely used. For example, the Chrome browser [Chrome] keeps TCP
idle for up to 5 minutes but 35% of Chrome HTTP requests are made on connections idle for up to 5 minutes but 35% of HTTP requests are
new TCP connections [RCCJR11]. For such Web and Web-like applications made on new TCP connections [RCCJR11]. For such Web and Web-like
placing data in the SYN can yield significant latency improvements. applications placing data in the SYN can yield significant latency
Next we describe how we resolve the challenges that arise upon doing improvements. Next we describe how we resolve the challenges that
so. arise upon doing so.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. 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 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. side and server refers to the TCP's passive open side.
2. Data In SYN 2. Data In SYN
Standard TCP already allows data to be carried in SYN packets Standard TCP already allows data to be carried in SYN packets
([RFC793], section 3.4) but forbids the receiver from delivering it ([RFC793], section 3.4) but forbids the receiver from delivering it
to the application until 3WHS is completed. This is because TCP's to the application until 3WHS is completed. This is because TCP's
initial handshake serves to capture old or duplicate SYNs. initial handshake serves to capture old or duplicate SYNs.
skipping to change at page 7, line 33 skipping to change at page 7, line 33
server in subsequent SYN packets. server in subsequent SYN packets.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length | | Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Cookie ~ ~ Cookie ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: constant TBD (assigned by IANA) Kind 1 byte: constant-TBD (to be assigned by IANA)
Length 1 byte: range 6 to 18 (bytes); limited by Length 1 byte: range 6 to 18 (bytes); limited by
remaining space in the options field. remaining space in the options field.
The number MUST be even. The number MUST be even.
Cookie 4 to 16 bytes (Length - 2) Cookie 4 to 16 bytes (Length - 2)
Options with invalid Length values or without SYN flag set MUST be Options with invalid Length values or without SYN flag set MUST be
ignored. The minimum Cookie size is 4 bytes. Although the diagram ignored. The minimum Cookie size is 4 bytes. Although the diagram
shows a cookie aligned on 32-bit boundaries, alignment is not shows a cookie aligned on 32-bit boundaries, alignment is not
required. required.
Fast Open Cookie Request Option Fast Open Cookie Request Option
The client uses this option in the SYN packet to request a cookie The client uses this option in the SYN packet to request a cookie
from a TFO-enabled server from a TFO-enabled server
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length | | Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: same as the Fast Open Cookie option Kind 1 byte: constant-TBD (same value as the Fast Open
Cookie option)
Length 1 byte: constant 2. This distinguishes the option Length 1 byte: constant 2. This distinguishes the option
from the Fast Open cookie option. from the Fast Open cookie option.
Options with invalid Length values, without SYN flag set, or with ACK Options with invalid Length values, without SYN flag set, or with ACK
flag set MUST be ignored. flag set MUST be ignored.
4.1.2. Server Cookie Handling 4.1.2. Server Cookie Handling
The server is in charge of cookie generation and authentication. The The server is in charge of cookie generation and authentication. The
cookie SHOULD be a message authentication code tag with the following cookie SHOULD be a message authentication code tag with the following
properties: properties:
skipping to change at page 9, line 15 skipping to change at page 9, line 16
If only one valid cookie is allowed per-IP and the server can If only one valid cookie is allowed per-IP and the server can
regenerate the cookie independently, the best validation process is regenerate the cookie independently, the best validation process is
to simply regenerate a valid cookie and compare it against the to simply regenerate a valid cookie and compare it against the
incoming cookie. In that case if the incoming cookie fails the check, incoming cookie. In that case if the incoming cookie fails the check,
a valid cookie is readily available to be sent to the client. a valid cookie is readily available to be sent to the client.
4.1.3. Client Cookie Handling 4.1.3. Client Cookie Handling
The client MUST cache cookies from servers for later Fast Open The client MUST cache cookies from servers for later Fast Open
connections. For a multi-homed client, the cookies are both client connections. For a multi-homed client, the cookies are dependent on
and server IP dependent. Beside the cookie we RECOMMEND that the the client and server IP addresses. Hence the client should cache at
client caches the MSS to the server to enhance performance. most one (most recently received) cookie per client and server IP
addresses pair.
The MSS advertised by the server is stored in the cache to determine Beside the cookie we RECOMMEND that the client caches the MSS to the
the maximum amount of data that can be supported in the SYN packet. server to enhance performance. The MSS advertised by the server is
This information is needed because data is sent before the server stored in the cache to determine the maximum amount of data that can
announces its MSS in the SYN-ACK packet. Without this information, be supported in the SYN packet. This information is needed because
the data size in the SYN packet is limited to the default MSS of 536 data is sent before the server announces its MSS in the SYN-ACK
bytes for IPv4 [RFC1122] and 1240 bytes for IPv6 [RFC2460]. In packet. Without this information, the data size in the SYN packet is
particular it's known an IPv4 receiver advertised MSS less than 536 limited to the default MSS of 536 bytes for IPv4 [RFC1122] and 1240
bytes would result in transmission of an unexpected large segment. If bytes for IPv6 [RFC2460]. In particular it's known an IPv4 receiver
the cache MSS is larger than the typical 1460 bytes, the extra large advertised MSS less than 536 bytes would result in transmission of an
data in SYN segment may have issues that offsets the performance unexpected large segment. If the cache MSS is larger than the typical
benefit of Fast Open. For examples, the super-size SYN may trigger IP 1460 bytes, the extra large data in SYN segment may have issues that
fragmentation and may confuse firewall or middle-boxes, causing SYN offsets the performance benefit of Fast Open. For examples, the
retransmission and other side-effects. Therefore the client MAY limit super-size SYN may trigger IP fragmentation and may confuse firewall
the cached MSS to 1460 bytes. or middle-boxes, causing SYN retransmission and other side-effects.
Therefore the client MAY limit the cached MSS to 1460 bytes.
4.1.3.1 Client Caching Negative Responses 4.1.3.1 Client Caching Negative Responses
The client MUST cache negative responses from the server in order to The client MUST cache negative responses from the server in order to
avoid potential connection failures. Negative responses include avoid potential connection failures. Negative responses include
server not acknowledging the data in SYN, ICMP error messages, and server not acknowledging the data in SYN, ICMP error messages, and
most importantly no response (SYN/ACK) from the server at all, i.e., most importantly no response (SYN/ACK) from the server at all, i.e.,
connection timeout. The last case is likely due to incompatible connection timeout. The last case is likely due to incompatible
middle-boxes or firewall blocking the connection completely after it middle-boxes or firewall blocking the connection completely after it
sees data in SYN. If the client does not react to these negative sees data in SYN. If the client does not react to these negative
skipping to change at page 10, line 11 skipping to change at page 11, line 11
at least temporarily. Since TFO is enabled on a per-service port at least temporarily. Since TFO is enabled on a per-service port
basis but cookies are independent of service ports, the client's basis but cookies are independent of service ports, the client's
cache should include remote port numbers too. cache should include remote port numbers too.
4.2. Fast Open Protocol 4.2. Fast Open Protocol
One predominant requirement of TFO is to be fully compatible with One predominant requirement of TFO is to be fully compatible with
existing TCP implementations, both on the client and the server existing TCP implementations, both on the client and the server
sides. sides.
The server keeps two variables per listening port: The server keeps two variables per listening socket (IP address &
port):
FastOpenEnabled: default is off. It MUST be turned on explicitly by FastOpenEnabled: default is off. It MUST be turned on explicitly by
the application. When this flag is off, the server does not perform the application. When this flag is off, the server does not perform
any TFO related operations and MUST ignore all cookie options. any TFO related operations and MUST ignore all cookie options.
PendingFastOpenRequests: tracks number of TFO connections in SYN-RCVD PendingFastOpenRequests: tracks number of TFO connections in SYN-RCVD
state. If this variable goes over a preset system limit, the server state. If this variable goes over a preset system limit, the server
MUST disable TFO for all new connection requests until MUST disable TFO for all new connection requests until
PendingFastOpenRequests drops below the system limit. This variable PendingFastOpenRequests drops below the system limit. This variable
is used for defending some vulnerabilities discussed in the "Security is used for defending some vulnerabilities discussed in the "Security
skipping to change at page 11, line 9 skipping to change at page 12, line 10
The network or servers may drop the SYN or SYN-ACK packets with the The network or servers may drop the SYN or SYN-ACK packets with the
new cookie options, which will cause SYN or SYN-ACK timeouts. We new cookie options, which will cause SYN or SYN-ACK timeouts. We
RECOMMEND both the client and the server to retransmit SYN and SYN- RECOMMEND both the client and the server to retransmit SYN and SYN-
ACK without the cookie options on timeouts. This ensures the ACK without the cookie options on timeouts. This ensures the
connections of cookie requests will go through and lowers the latency connections of cookie requests will go through and lowers the latency
penalty (of dropped SYN/SYN-ACK packets). The obvious downside for penalty (of dropped SYN/SYN-ACK packets). The obvious downside for
maximum compatibility is that any regular SYN drop will fail the maximum compatibility is that any regular SYN drop will fail the
cookie (although one can argue the delay in the data transmission cookie (although one can argue the delay in the data transmission
till after 3WHS is justified if the SYN drop is due to network till after 3WHS is justified if the SYN drop is due to network
congestion). Next section describes a heuristic to detect such drops congestion). The next section describes a heuristic to detect such
when the client receives the SYN-ACK. drops when the client receives the SYN-ACK.
We also RECOMMEND the client to record the set of servers that failed We also RECOMMEND the client to record the set of servers that failed
to respond to cookie requests and only attempt another cookie request to respond to cookie requests and only attempt another cookie request
after certain period. after certain period.
An alternate proposal is to request a TFO cookie in the FIN instead, An alternate proposal is to request a TFO cookie in the FIN instead,
since FIN-drop by incompatible middle-boxes does not affect latency. since FIN-drop by incompatible middle-boxes does not affect latency.
However paths that block SYN cookies may be more likely to drop a However paths that block SYN cookies may be more likely to drop a
later SYN packet with data, and many applications close a connection later SYN packet with data, and many applications close a connection
with RST instead anyway. with RST instead anyway.
skipping to change at page 12, line 51 skipping to change at page 13, line 51
client in SYN-SENT state. The protocol remains the same because client in SYN-SENT state. The protocol remains the same because
[RFC793] already supports both data in SYN and simultaneous open. But [RFC793] already supports both data in SYN and simultaneous open. But
the client's socket may have data available to read before it's the client's socket may have data available to read before it's
connected. This document does not cover the corresponding API change. connected. This document does not cover the corresponding API change.
Client: Receiving SYN-ACK Client: Receiving SYN-ACK
The client SHOULD perform the following steps upon receiving the SYN- The client SHOULD perform the following steps upon receiving the SYN-
ACK: ACK:
1. Update the cookie cache if the SYN-ACK has a Fast Open Cookie 1. If the SYN-ACK has a Fast Open Cookie Option or MSS option or both,
Option or MSS option or both. update the corresponding cookie and MSS information in the cookie cache.
2. Send an ACK packet. Set acknowledgment number to RCV.NXT and 2. Send an ACK packet. Set acknowledgment number to RCV.NXT and
include the data after SND.UNA if data is available. include the data after SND.UNA if data is available.
3. Advance to the ESTABLISHED state. 3. Advance to the ESTABLISHED state.
Note there is no latency penalty if the server does not acknowledge Note there is no latency penalty if the server does not acknowledge
the data in the original SYN packet. The client SHOULD retransmit any the data in the original SYN packet. The client SHOULD retransmit any
unacknowledged data in the first ACK packet in step 2. The data unacknowledged data in the first ACK packet in step 2. The data
exchange will start after the handshake like a regular TCP exchange will start after the handshake like a regular TCP
skipping to change at page 16, line 29 skipping to change at page 17, line 29
in the SYN but not subsequent data exchanges. in the SYN but not subsequent data exchanges.
Empirically [JIDKT07] showed the packet duplication on a Tier-1 Empirically [JIDKT07] showed the packet duplication on a Tier-1
network is rare. Since the replay only happens specifically when the network is rare. Since the replay only happens specifically when the
SYN data packet is duplicated and also the duplicate arrives after SYN data packet is duplicated and also the duplicate arrives after
the receiver has cleared the original SYN's connection state, the the receiver has cleared the original SYN's connection state, the
replay is thought to be uncommon in practice. Neverthless a client replay is thought to be uncommon in practice. Neverthless a client
that cannot handle receiving the same SYN data more than once MUST that cannot handle receiving the same SYN data more than once MUST
NOT enable TFO to send data in a SYN. Similarly a server that cannot NOT enable TFO to send data in a SYN. Similarly a server that cannot
accept receiving the same SYN data more than once MUST NOT enable TFO accept receiving the same SYN data more than once MUST NOT enable TFO
to receive data in a SYN. to receive data in a SYN. Further investigation is needed to judge
about the probability of receiving duplicated SYN or SYN-ACK with
data in non-Tier 1 networks.
6.2 Potential Performance Improvement 6.2 Potential Performance Improvement
TFO is designed for latency-conscious applications that are sensitive TFO is designed for latency-conscious applications that are sensitive
to TCP's initial connection setup delay. To benefit from TFO, the to TCP's initial connection setup delay. To benefit from TFO, the
first application data unit (e.g., an HTTP request) needs to be no first application data unit (e.g., an HTTP request) needs to be no
more than TCP's maximum segment size (minus options used in SYN). more than TCP's maximum segment size (minus options used in SYN).
Otherwise the remote server can only process the client's application Otherwise the remote server can only process the client's application
data unit once the rest of it is delivered after the initial data unit once the rest of it is delivered after the initial
handshake, diminishing TFO's benefit. handshake, diminishing TFO's benefit.
skipping to change at page 18, line 14 skipping to change at page 19, line 14
timeout idle connections within 30 minutes. End hosts, unaware of timeout idle connections within 30 minutes. End hosts, unaware of
silent middle-box timeouts, suffer multi-minute TCP timeouts upon silent middle-box timeouts, suffer multi-minute TCP timeouts upon
using those long-idle connections. using those long-idle connections.
To circumvent this problem, some applications send frequent TCP keep- To circumvent this problem, some applications send frequent TCP keep-
alive probes. However, this technique drains power on mobile devices alive probes. However, this technique drains power on mobile devices
[MQXMZ11]. In fact, power has become such a prominent issue in modern [MQXMZ11]. In fact, power has become such a prominent issue in modern
LTE devices that mobile browsers close HTTP connections within LTE devices that mobile browsers close HTTP connections within
seconds or even immediately [SOUDERS11]. seconds or even immediately [SOUDERS11].
[RCCJR11] studied Chrome browser performance based on 28 days of [RCCJR11] studied Chrome browser [Chrome] performance based on 28
global statistics. The Chrome browser keeps idle HTTP persistent days of global statistics. The Chrome browser keeps idle HTTP
connections for 5 to 10 minutes. However the average number of the persistent connections for 5 to 10 minutes. However the average
transactions per connection is only 3.3 and TCP 3WHS accounts for up number of the transactions per connection is only 3.3 and TCP 3WHS
to 25% of the HTTP transaction network latency. The authors estimated accounts for up to 25% of the HTTP transaction network latency. The
that TFO improves page load time by 10% to 40% on selected popular authors estimated that TFO improves page load time by 10% to 40% on
Web sites. selected popular Web sites.
7. Open Areas for Experimentation 7. Open Areas for Experimentation
We now outline some areas that need experimentation in the Internet We now outline some areas that need experimentation in the Internet
and under different network scenarios. These experiments should help and under different network scenarios. These experiments should help
the community evaluate Fast Open benefits and risks towards further the community evaluate Fast Open benefits and risks towards further
standardization and implementation of Fast Open and its related standardization and implementation of Fast Open and its related
protocols. protocols.
7.1. Performance impact due to middle-boxes and NAT 7.1. Performance impact due to middle-boxes and NAT
skipping to change at page 20, line 45 skipping to change at page 21, line 45
TCPCT [RFC6013] eliminates server state during initial handshake and TCPCT [RFC6013] eliminates server state during initial handshake and
defends spoofing DoS attacks. Like TFO, TCPCT allows SYN and SYN-ACK defends spoofing DoS attacks. Like TFO, TCPCT allows SYN and SYN-ACK
packets to carry data. But the server can only send up to MSS bytes packets to carry data. But the server can only send up to MSS bytes
of data during the handshake instead of the initial congestion window of data during the handshake instead of the initial congestion window
unlike TFO. Therefore the latency of applications such as Web may be unlike TFO. Therefore the latency of applications such as Web may be
worse than with TFO. worse than with TFO.
9. IANA Considerations 9. IANA Considerations
The Fast Open Cookie Option and Fast Open Cookie Request Option IANA is requested to allocate one value from the TCP Option Kind
define no new namespace. The options require IANA to allocate one Numbers: The constant-TBD in Section Section 4.1.1 has to be replaced
value from the TCP option Kind namespace. Early implementation before with the newly assigned value. The length of the new TCP option Kind
the IANA allocation SHOULD follow [RFC6994] and use experimental is variable and the Meaning should be set to "TCP Fast Open Cookie".
option 254 and magic number 0xF989 (16 bits), then migrate to the new Early implementation before the IANA allocation SHOULD follow
option after the allocation accordingly. [RFC6994] and use experimental option 254 and magic number 0xF989 (16
bits), then migrate to the new option after the allocation
accordingly.
10. Acknowledgement 10. Acknowledgement
We thank Bob Briscoe, Michael Scharf, Gorry Fairhurst, Rick Jones, We thank Bob Briscoe, Michael Scharf, Gorry Fairhurst, Rick Jones,
Roberto Peon, William Chan, Adam Langley, Neal Cardwell, Eric Roberto Peon, William Chan, Adam Langley, Neal Cardwell, Eric
Dumazet, and Matt Mathis for their feedbacks. We especially thank Dumazet, and Matt Mathis for their feedbacks. We especially thank
Barath Raghavan for his contribution on the security design of Fast Barath Raghavan for his contribution on the security design of Fast
Open and proofreading this draft numerous times. Open and proofreading this draft numerous times.
11. References 11. References
skipping to change at page 23, line 11 skipping to change at page 25, line 11
[BELSHE11] Belshe, M., "The era of browser preconnect.", [BELSHE11] Belshe, M., "The era of browser preconnect.",
http://www.belshe.com/2011/02/10/ http://www.belshe.com/2011/02/10/
the-era-of-browser-preconnect/ the-era-of-browser-preconnect/
[JIDKT07] Jaiswal, S., Iannaccone, G., Diot, C., Kurose, J., [JIDKT07] Jaiswal, S., Iannaccone, G., Diot, C., Kurose, J.,
Towsley, D., "Measurement and classification of Towsley, D., "Measurement and classification of
out-of-sequence packets in a tier-1 IP backbone.". out-of-sequence packets in a tier-1 IP backbone.".
IEEE/ACM Transactions on Networking (TON), 15(1), 54-66. IEEE/ACM Transactions on Networking (TON), 15(1), 54-66.
[Chrome] Chrome Browser. https://www.google.com/intl/en-US/chrome/browser/
Appendix A. Example Socket API Changes to support TFO Appendix A. Example Socket API Changes to support TFO
A.1 Active Open A.1 Active Open
The active open side involves changing or replacing the connect() The active open side involves changing or replacing the connect()
call, which does not take a user data buffer argument. We recommend call, which does not take a user data buffer argument. We recommend
replacing connect() call to minimize API changes and hence replacing connect() call to minimize API changes and hence
applications to reduce the deployment hurdle. applications to reduce the deployment hurdle.
One solution implemented in Linux 3.7 is introducing a new flag One solution implemented in Linux 3.7 is introducing a new flag
 End of changes. 19 change blocks. 
79 lines changed or deleted 91 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/