--- 1/draft-ietf-tcpm-fastopen-04.txt 2013-10-14 21:14:28.286550130 -0700 +++ 2/draft-ietf-tcpm-fastopen-05.txt 2013-10-14 21:14:28.334551384 -0700 @@ -1,17 +1,17 @@ Internet Draft Y. Cheng -draft-ietf-tcpm-fastopen-04.txt J. Chu +draft-ietf-tcpm-fastopen-05.txt J. Chu Intended status: Experimental S. Radhakrishnan Expiration date: February, 2014 A. Jain Google, Inc. - July 15, 2013 + October 14, 2013 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. @@ -44,24 +44,24 @@ 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. 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 saving up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However - TFO deviates from the standard TCP semantics in that the data in the - SYN could be replayed to an application in some rare circumstances. - Applications should not use TFO unless they can tolerate this issue, - which is detailed in the Applicability section. + TFO deviates from the standard TCP semantics; the data in the SYN + could be replayed to an application in some rare circumstances. + Applications should not use TFO unless they can tolerate this issue + detailed in the Applicability section. 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. Table of Contents @@ -75,127 +75,130 @@ 4.1. Fast Open Cookie . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. TCP Options . . . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Server Cookie Handling . . . . . . . . . . . . . . . . 8 4.1.3. Client Cookie Handling . . . . . . . . . . . . . . . . 9 4.2. Fast Open Protocol . . . . . . . . . . . . . . . . . . . . 9 4.2.1. Fast Open Cookie Request . . . . . . . . . . . . . . . 10 4.2.2. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 13 5.1. Resource Exhaustion Attack by SYN Flood with Valid Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.1.1 Attacks from behind Sharing Public IPs (NATs) . . . . . 14 + 5.1.1 Attacks from behind Shared Public IPs (NATs) . . . . . . 14 5.2. Amplified Reflection Attack to Random Host . . . . . . . . 15 6. TFO's Applicability . . . . . . . . . . . . . . . . . . . . . . 16 6.1 Duplicate Data in SYNs . . . . . . . . . . . . . . . . . . . 16 6.2 Potential Performance Improvement . . . . . . . . . . . . . 16 6.3. Example: Web Clients and Servers . . . . . . . . . . . . . 16 6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 16 - 6.3.2. Comparison with HTTP Persistent Connections . . . . . . 17 - 7. Open Areas for Experimentation . . . . . . . . . . . . . . . . 17 + 6.3.2. Speculative Connections by the Applications . . . . . . 17 + 6.3.2. HTTP over TLS (HTTPS) . . . . . . . . . . . . . . . . . 17 + 6.3.3. Comparison with HTTP Persistent Connections . . . . . . 17 + 7. Open Areas for Experimentation . . . . . . . . . . . . . . . . 18 7.1. Performance impact due to middle-boxes and NAT . . . . . . 18 7.2. Cookie-less Fast Open . . . . . . . . . . . . . . . . . . . 18 - 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 19 8.3. TCP Cookie Transaction (TCPCT) . . . . . . . . . . . . . . 19 - 8.4. Speculative Connections by the Applications . . . . . . . . 19 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Example Socket API Changes to support TFO . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 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, potential new security vulnerabilities and their mitigation, and the new socket API. TFO is motivated by the performance needs of today's Web applications. Current TCP only permits data exchange after 3WHS [RFC793], which adds one RTT to network latency. For short Web transfers this additional RTT is a significant portion of overall - network latency [THK98], even when HTTP persistent connection is - widely used. For example, the Chrome browser keeps TCP connections - idle for up to 5 minutes but 35% of Chrome HTTP requests are made on - new TCP connections [RCCJR11]. For such Web and Web-like applications - placing data in the SYN can yield significant latency improvements. - Next we describe how we resolve the challenges that arise upon doing - so. + network latency, even when HTTP persistent connection is widely used. + For example, the Chrome browser keeps TCP connections idle for up to + 5 minutes but 35% of Chrome HTTP requests are made on new TCP + connections [RCCJR11]. For such Web and Web-like applications placing + data in the SYN can yield significant latency improvements. Next we + describe how we resolve the challenges that arise upon doing so. 2. Data In SYN Standard TCP already allows data to be carried in SYN packets ([RFC793], section 3.4) but forbids the receiver from delivering it to the application until 3WHS is completed. This is because TCP's initial handshake serves to capture old or duplicate SYNs. - Allowing data in SYN packets to be delivered raises two issues - discussed in the following subsections. These issues make TFO - unsuitable for certain applications. Therefore TCP implementations - MUST NOT use TFO by default, but only use TFO if requested explicitly - by the application on a per service port basis. Applications need to - evaluate TFO applicability described in Section 6 before using TFO. + To enable applications exchange data in TCP handshake, TFO removes + the constraint and allows data in SYN packets to be delivered to + application. This change of TCP semantic raises two issues discussed + in the following subsections, making TFO unsuitable for certain + applications. + + Therefore TCP implementations MUST NOT use TFO by default, but only + use TFO if requested explicitly by the application on a per service + port basis. Applications need to evaluate TFO applicability described + in Section 6 before using TFO. 2.1 Relaxing TCP Semantics on Duplicated SYNs TFO allows data to be delivered to the application before 3WHS is completed, thus opening itself to a data integrity issue in either of the two cases below: a) the receiver host receives data in a duplicate SYN after it has forgotten it received the original SYN (e.g. due to a reboot); b) the duplicate is received after the connection created by the original SYN has been closed and the close was initiated by the sender (so the receiver will not be protected by the 2MSL TIMEWAIT state). The now obsoleted T/TCP [RFC1644] attempted to address these issues. It is not successful and not deployed due to various vulnerabilities - [PHRACK98]. Rather than trying to capture all dubious SYN packets to - make TFO 100% compatible with TCP semantics, we made a design - decision early on to accept old SYN packets with data, i.e., to - restrict TFO use to a class of applications (Section 6) that are - tolerant of duplicate SYN packets with data. We believe this is the - right design trade-off balancing complexity with usefulness. + as described in the Related Work section. Rather than trying to + capture all dubious SYN packets to make TFO 100% compatible with TCP + semantics, we made a design decision early on to accept old SYN + packets with data, i.e., to restrict TFO use to a class of + applications (Section 6) that are tolerant of duplicate SYN packets + with data. We believe this is the right design trade-off balancing + complexity with usefulness. 2.2. SYNs with Spoofed IP Addresses - Standard TCP suffers from the SYN flood attack [RFC4987] because - bogus SYN packets, i.e., SYN packets with spoofed source IP addresses - can easily fill up a listener's small queue, causing a service port - to be blocked completely until timeouts. Secondary damage comes from - these SYN requests taking up memory space. Though this is less of an - issue today as servers typically have plenty of memory. + Standard TCP suffers from the SYN flood attack [RFC4987] because SYN + packets with spoofed source IP addresses can easily fill up a + listener's small queue, causing a service port to be blocked + completely until timeouts. TFO goes one step further to allow server-side TCP to send up data to the application layer before 3WHS is completed. This opens up serious new vulnerabilities. Applications serving ports that have TFO enabled may waste lots of CPU and memory resources processing the requests and producing the responses. If the response is much larger than the request, the attacker can further mount an amplified reflection attack against victims of choice beyond the TFO server itself. Numerous mitigation techniques against regular SYN flood attacks exist and have been well documented [RFC4987]. Unfortunately none are applicable to TFO. We propose a server-supplied cookie to mitigate - these new vulnerabilities in Section 3 and evaluate the effectiveness - of the defense in Section 7. + these new vulnerabilities in the next Section and evaluate the + effectiveness of the defense in Section 7. 3. Protocol Overview The key component of TFO is the Fast Open Cookie (cookie), a message authentication code (MAC) tag generated by the server. The client requests a cookie in one regular TCP connection, then uses it for future TCP connections to exchange data during 3WHS: Requesting a Fast Open Cookie: @@ -432,21 +435,21 @@ 3. If the SYN-ACK contains a Fast Open Cookie option, the client replaces the cookie and other information as described in the "Client Cookie Handling" section. Otherwise, if the SYN-ACK is first seen, i.e.,not a (spurious) retransmission, the client MAY remove the server information from the cookie cache. If the SYN- ACK is a spurious retransmission without valid Fast Open Cookie Option, the client does nothing to the cookie cache for the reasons below. The network or servers may drop the SYN or SYN-ACK packets with the - new cookie options, which will causes 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- ACK without the cookie options on timeouts. This ensures the connections of cookie requests will go through and lowers the latency penalty (of dropped SYN/SYN-ACK packets). The obvious downside for maximum compatibility is that any regular SYN drop will fail the cookie (although one can argue the delay in the data transmission till after 3WHS is justified if the SYN drop is due to network congestion). Next section describes a heuristic to detect such drops when the client receives the SYN-ACK. @@ -615,21 +618,21 @@ may combine the two, e.g., by continuing to account for those connection requests that have just been reset against the listener's PendingFastOpenRequests until a timeout period has passed. Limiting the maximum number of pending TFO connection requests does make it easy for an attacker to overflow the queue, causing TFO to be disabled. We argue that causing TFO to be disabled is unlikely to be of interest to attackers because the service will remain intact without TFO hence there is hardly any real damage. -5.1.1 Attacks from behind Sharing Public IPs (NATs) +5.1.1 Attacks from behind Shared Public IPs (NATs) An attacker behind NAT can easily obtain valid cookies to launch the above attack to hurt other clients that share the path. [BRISCOE12] suggested that the server can extend cookie generation to include the TCP timestamp---GetCookie(IP_Address, Timestamp)---and implement it by encrypting the concatenation of the two values to generate the cookie. The client stores both the cookie and its corresponding timestamp, and echoes both in the SYN. The server then implements IsCookieValid(IP_Address, Timestamp, Cookie) by encrypting the IP and timestamp data and comparing it with the cookie value. @@ -675,22 +678,24 @@ The best defense is for the server not to respond with data until handshake finishes. In this case the risk of amplification reflection attack is completely eliminated. But the potential latency saving from TFO may diminish if the server application produces responses earlier before the handshake completes. 6. TFO's Applicability This section is to help applications considering TFO to evaluate TFO's benefits and drawbacks using the Web client and server - applications as an example throughout. A proposed socket API change - is in the Appendix. + applications as an example throughout. Applications here refer + specifically to the process that writes data into the socket, i.e., a + java script process that sends data to the server. A proposed socket + API change is in the Appendix. 6.1 Duplicate Data in SYNs It is possible, though uncommon, that using TFO results in the first data written to a socket to be delivered more than once to the application on the remote host(Section 2.1). This replay potential only applies to data in the SYN but not subsequent data exchanges. The client MUST NOT use TFO to send data in the SYN, and the server MUST NOT accept data in the SYN if it cannot handle receiving the same SYN data more than once, due to reasons described before. @@ -700,48 +705,64 @@ TFO is designed for latency-conscious applications that are sensitive 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 more than TCP's maximum segment size (minus options used in SYN). Otherwise the remote server can only process the client's application data unit once the rest of it is delivered after the initial handshake, diminishing TFO's benefit. To the extent possible, applications SHOULD reuse the connection to take advantage of TCP's built-in congestion control and reduce - connection setup overhead. An application employs too many short- - lived connections will negatively impact network stability, as these - connections often exit before TCP's congestion control algorithm - takes effect. + connection setup overhead. An application that employs too many + short-lived connections will negatively impact network stability, as + these connections often exit before TCP's congestion control + algorithm takes effect. 6.3. Example: Web Clients and Servers 6.3.1. HTTP Request Replay While TFO is motivated by Web applications, the browser should not use TFO to send requests in SYNs if those requests cannot tolerate replays. One example is POST requests without application-layer transaction protection (e.g., a unique identifier in the request header). - TFO is particularly useful for GET requests. Even though not all GET - requests are idempotent, GETs are frequently replayed today across - striped TCP connections. After a server receives an HTTP request but - before the ACKs of the requests reach the browser, the browser may - timeout and retry the same request on another (possibly new) TCP - connection. This differs from a TFO replay only in that the replay is - initiated by the browser, not by the TCP stack. + On the other hand, TFO is particularly useful for GET requests. + Although not all GET requests are idempotent, GETs are frequently + replayed today across striped TCP connections: after a server + receives an HTTP request but before the ACKs of the requests reach + the browser, the browser may timeout and retry the same request on + another (possibly new) TCP connection. This differs from a TFO replay + only in that the replay is initiated by the browser, not by the TCP + stack. - Finally, TFO is safe and useful for HTTPS requests because it saves - the first SSL handshake RTT and the HTTP request is sent after the - connection establishes. +6.3.2. Speculative Connections by the Applications -6.3.2. Comparison with HTTP Persistent Connections + Some Web browsers maintain a history of the domains for frequently + visited web pages. The browsers then speculatively pre-open TCP + connections to these domains before the user initiates any requests + for them [BELSHE11]. While this technique also saves the handshake + latency, it wastes server and network resources by initiating and + maintaining idle connections. + +6.3.2. HTTP over TLS (HTTPS) + + For TLS over TCP, it is safe and useful to include TLS CLIENT_HELLO + in the SYN packet to save 1-RTT in TLS handshake. There is no concern + about violating idempotency. In particular it can be used alone with + the speculative connection above. While HTTPS adoption is still low, + it will increase over time (especially given the context of recent + revelations). Thus the potential importance of TCP Fast Open in + decreasing user perceived latency in HTTPS. + +6.3.3. Comparison with HTTP Persistent Connections Is TFO useful given the wide deployment of HTTP persistent connections? The short answer is yes. Studies [RCCJR11][AERG11] show that the average number of transactions per connection is between 2 and 4, based on large-scale measurements from both servers and clients. In these studies, the servers and clients both kept idle connections up to several minutes, well into "human think" time. Keeping connections open and idle even longer risks a greater performance penalty. [HNESSK10][MQXMZ11] show that the majority of @@ -754,25 +775,23 @@ To circumvent this problem, some applications send frequent TCP keep- alive probes. However, this technique drains power on mobile devices [MQXMZ11]. In fact, power has become such a prominent issue in modern LTE devices that mobile browsers close HTTP connections within seconds or even immediately [SOUDERS11]. [RCCJR11] studied Chrome browser performance based on 28 days of global statistics. The Chrome browser keeps idle HTTP persistent connections for 5 to 10 minutes. However the average number of the transactions per connection is only 3.3 and TCP 3WHS accounts for up - to 25% of the HTTP transaction network latency. The authors tested a - Linux TFO implementation with TFO enabled Chrome browser on popular - web sites in emulated environments such as residential broadband and - mobile networks. They showed that TFO improves page load time by 10% - to 40%. + to 25% of the HTTP transaction network latency. The authors estimated + that TFO TFO improves page load time by 10% to 40% on selected + popular Web sites. 7. Open Areas for Experimentation We now outline some areas that need experimentation in the Internet and under different network scenarios. These experiments should help the community evaluate Fast Open benefits and risks towards further standardization and implementation of Fast Open and its related protocols. 7.1. Performance impact due to middle-boxes and NAT @@ -851,36 +871,26 @@ 8.3. TCP Cookie Transaction (TCPCT) TCPCT [RFC6013] eliminates server state during initial handshake and 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 of data during the handshake instead of the initial congestion window unlike TFO. Therefore applications like Web may not receive the latency benefit as TFO. -8.4. Speculative Connections by the Applications - - Some Web browsers maintain a history of the domains for frequently - visited web pages. The browsers then speculatively pre-open TCP - connections to these domains before the user initiates any requests - for them [BELSHE11]. The downside of this approach is that it wastes - server and network resources by initiating and maintaining idle - connections; It is also subject to the NAT timeout issues described - in Section 6.3.2. TFO offers similar performance improvement without - the added overhead. - 9. IANA Considerations + The Fast Open Cookie Option and Fast Open Cookie Request Option define no new namespace. The options require IANA to allocate one value from the TCP option Kind namespace. Early implementation before - the IANA allocation SHOULD follow [EXPOPT] and use experimental + the IANA allocation SHOULD follow [RFC6994] and use experimental option 254 and magic number 0xF989 (16 bits), then migrate to the new option after the allocation accordingly. 10. Acknowledgement We thank Rick Jones, Bob Briscoe, Adam Langley, Matt Mathis, Neal Cardwell, Roberto Peon, William Chan, Eric Dumazet, and Tom Herbert for their feedbacks. We especially thank Barath Raghavan for his contribution on the security design of Fast Open and proofreading this draft numerous times. @@ -899,33 +909,31 @@ [RFC5681] Allman, M., Paxson, V. and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009. [RFC6298] Paxson, V., Allman, M., Chu, J. and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011. [RFC6928] Chu, J., Dukkipati, N., Cheng, Y. and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, April 2013. + [RFC6994] Touch, Joe, "Shared Use of Experimental TCP Options", + RFC 6694, August 2013. + 11.2. Informative References [AERG11] M. Al-Fares, K. Elmeleegy, B. Reed, and I. Gashinsky, "Overclocking the Yahoo! CDN for Faster Web Page Loads". In Proceedings of Internet Measurement Conference, November 2011. - [EXPOPT] Touch, Joe, "Shared Use of Experimental TCP Options", - Internet-Draft draft-ietf-tcpm-experimental-options (work - in progress), June 2013. - [HNESSK10] S. Haetoenen, A. Nyrhinen, L. Eggert, S. Strowes, P. - Sarolahti, M. Kojo., "An Experimental Study of Home Gateway Characteristics". In Proceedings of Internet Measurement Conference. Octobor 2010 [HNRGHT11] M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M. Handley, H. Tokuda, "Is it Still Possible to Extend TCP?". In Proceedings of Internet Measurement Conference. November 2011. [LANGLEY06] Langley, A, "Probing the viability of TCP extensions", @@ -959,70 +967,91 @@ [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007. [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC6013, January 2011. [SOUDERS11] S. Souders. "Making A Mobile Connection". http://www.stevesouders.com/blog/2011/09/21/making-a- mobile-connection/ - [THK98] Touch, J., Heidemann, J., Obraczka, K., "Analysis of HTTP - Performance", USC/ISI Research Report 98-463. December - 1998. - [BRISCOE12] Briscoe, B., "Some ideas building on draft-ietf-tcpm- fastopen-01", tcpm list, http://www.ietf.org/mail-archive/web/tcpm/current/ January 16, 2014msg07192.html [BELSHE12] Belshe, M., "The era of browser preconnect.", http://www.belshe.com/2011/02/10/ the-era-of-browser-preconnect/ Appendix A. Example Socket API Changes to support TFO - The design rationale is to minimize changes to the socket API and - hence applications, in order to reduce the deployment hurdle. The - following changes have been implemented in Linux 3.7 or later - kernels. + A.1 Active Open - A.1 MSG_FASTOPEN flag for sendto() or sendmsg() + The active open side involves changing or replacing the connect() + call, which does not take a user data buffer argument. We recommend + replacing connect() call to minimize API changes and hence + applications to reduce the deployment hurdle. - MSG_FASTOPEN marks the attempt to send data in SYN like a combination - of connect() and sendto(), by performing an implicit connect() - operation. It blocks until the handshake has completed and the data - is buffered. + One solution implemented in Linux 3.7 is introducing a new flag + MSG_FASTOPEN for sendto() or sendmsg(). MSG_FASTOPEN marks the + attempt to send data in SYN like a combination of connect() and + sendto(), by performing an implicit connect() operation. It blocks + until the handshake has completed and the data is buffered. For non-blocking socket it returns the number of bytes buffered and sent in the SYN packet. If the cookie is not available locally, it returns -1 with errno EINPROGRESS, and sends a SYN with TFO cookie request automatically. The caller needs to write the data again when - the socket is connected. + the socket is connected. On errors, it returns the same errno as + connect() if the handshake fails. - It returns the same errno as connect() if the handshake fails. + An implementation may prefer not to change the sendmsg() because TFO + is a TCP specific feature. A solution is to add a new socket option + TCP_FASTOPEN for TCP sockets. When the option is enabled before a + connect operation, sendmsg() or sendto() will perform Fast Open + operation similar to the MSG_FASTOPEN flag described above. This + approach however requires an extra setsockopt() system call. - A.2 TCP_FASTOPEN setsockopt() Socket Option + A.2 Passive Open + + The passive open side change is simpler compared to active open side. + The application only needs to enable the reception of Fast Open + requests via a new TCP_FASTOPEN setsockopt() socket option before + listen(). The option enables Fast Open on the listener socket. The option value specifies the PendingFastOpenRequests threshold, i.e., the maximum length of pending SYNs with data payload. Once enabled, the TCP implementation will respond with TFO cookies per request. - Previously accept() returns only after a socket is connected. But for - a Fast Open connection, accept() returns upon receiving a SYN with a - valid Fast Open cookie and data, and the data is available to be read - through, e.g., recvmsg(), read(). + Traditionally accept() returns only after a socket is connected. But + for a Fast Open connection, accept() returns upon receiving a SYN + with a valid Fast Open cookie and data, and the data is available to + be read through, e.g., recvmsg(), read(). Authors' Addresses - Yuchung Cheng Google, Inc. 1600 Amphitheatre Parkway Mountain View, - CA 94043, USA EMail: ycheng@google.com - Jerry Chu Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA - 94043, USA EMail: hkchu@google.com + Yuchung Cheng + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043, USA + EMail: ycheng@google.com - Sivasankar Radhakrishnan Department of Computer Science and - Engineering University of California, San Diego 9500 Gilman Dr La - Jolla, CA 92093-0404 EMail: sivasankar@cs.ucsd.edu + Jerry Chu + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043, USA + EMail: hkchu@google.com - Arvind Jain Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA - 94043, USA EMail: arvind@google.com + Sivasankar Radhakrishnan + Department of Computer Science and Engineering + University of California, San Diego + 9500 Gilman Dr + La Jolla, CA 92093-0404 + EMail: sivasankar@cs.ucsd.edu + + Arvind Jain + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043, USA + EMail: arvind@google.com