Re: Feedback on TCP Fast Open?

Thanks for the invitation for feedback.

I've been the primary contact on the Chromium / Google Chrome network stack
team for Yuchung and the other TCP Fast Open authors at Google, so while I
only lurk in tcpm, I've been reasonably involved in this particular
feature. I've thought a lot about how we would use this in Chromium if
available. For some detailed thoughts intended for a browser implementor
audience, you can read those details at my blog (
https://insouciant.org/tech/some-quick-thoughts-on-tcp-fast-open-and-chromium/
).

The short of it is, for vanilla HTTP, it's unclear how beneficial it would
be for us since we already have such gains for browser preconnect (our
browser feature that learns from past web browsing to speculatively
establish connections, typically just TCP connections but perhaps doing a
TLS or other handshakes too as needed). There's a fundamental tension
between our preconnect feature and TCP Fast Open for vanilla HTTP. Further
experimentation is necessary and we've been working on this. I'm hopeful we
can find a way to leverage this for our gain, but it requires more
investigation.

For TLS over TCP, there is a much more obvious win since we can squeeze the
TLS CLIENT_HELLO into the TCP SYN, and there is no concern about violating
idempotency. This combines with our preconnect feature very nicely, so I am
rather excited about the potential for this use case. While HTTPS adoption
is still low, I'm hopeful that it will increase over time (especially given
the context of recent revelations). So I think the importance of the HTTPS
use case will grow, and thus the potential importance of TCP Fast Open in
decreasing user perceived latency.

Cheers,
Will


On Fri, Aug 2, 2013 at 3:10 AM, Scharf, Michael (Michael) <
michael.scharf@alcatel-lucent.com> wrote:

> Hi all,
>
> As mentioned today on the mic, the TCPM working group has a working group
> item that allows data to be carried in the SYN and SYN-ACK packets and that
> is consumed by the receiving end during the initial connection handshake,
> which is saves TCP handshakes. The document was discussed aleady
> extensively in TCPM and will be updated. TCPM's understanding is that it is
> not far away from WGLC.
>
> The link is: http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-04
>
> In the spirit of today's session, feedback from the httpbis community
> would be very appreciated. Please note that this mechanism slightly changes
> the standard TCP semantics, as explained in the abstract:
>
>    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.
>
> Further information can be found in Section 6 of the document.
>
> Comments or reviews would be highly welcome. The discussion should take
> place on the TCPM mailing list.
>
> Thanks!
>
> Michael (TCPM co-chair)
>
>