W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: [tcpm] Feedback on TCP Fast Open?

From: Yuchung Cheng <ycheng@google.com>
Date: Fri, 9 Aug 2013 16:37:56 -0700
Message-ID: <CAK6E8=f06LsU42TFsxModmmzNzHrsqbkPPF8VvKui0omSE5Zkg@mail.gmail.com>
To: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
Cc: (wrong string) ™ˆ™˜Œ) <willchan@chromium.org>, "tcpm@ietf.org" <tcpm@ietf.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Mon, Aug 5, 2013 at 4:50 AM, Scharf, Michael (Michael)
<michael.scharf@alcatel-lucent.com> wrote:
> Hi Will (and the others in this thread),
> Thanks a lot for this excellent feedback and the insights! This is very much appreciated.
> @Authors: Actually, I wonder if the specific advantages of TFO for HTTPS could be better described in the document, i.e., in Section 6.3? For instance, by separate applicability sections for HTTP and HTTPS? If idempotency is not an issue for HTTPS, it would be worthwile to explicitly stress that.
It's already in -04

> Just as a thought...
> Michael
>> -----Original Message-----
>> From: willchan@google.com [mailto:willchan@google.com] On
>> Behalf Of William Chan (???)
>> Sent: Friday, August 02, 2013 3:52 PM
>> To: Scharf, Michael (Michael)
>> Cc: ietf-http-wg@w3.org; tcpm@ietf.org
>> Subject: 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-o
>> pen-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)
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
Received on Friday, 9 August 2013 23:38:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC