< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/