RE: [tcpm] Feedback on TCP Fast Open?

Hi Yuchung, inline...

> -----Original Message-----
> From: Yuchung Cheng [mailto:ycheng@google.com] 
> Sent: Saturday, August 10, 2013 1:38 AM
> To: Scharf, Michael (Michael)
> Cc: William Chan (³ÂÖDzý); tcpm@ietf.org; ietf-http-wg@w3.org
> Subject: Re: [tcpm] Feedback on TCP Fast Open?
> 
> 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
> 
> http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-04#section-6.3


Yes, of course I've seen this. My question is whether advantages of TFO for HTTPS could be ***better*** described in the document, for instance, by ***separate applicability sections*** for HTTP and TLS/HTTPS.

For instance, I was thinking of two separate sections for the content that is now in section 6.3.1: 

6.3.1 Applicability for HTTP

6.3.2 Applicability for TLS/HTTPS

To me, Will's explanation on the applicability to TLS seems useful information, and currently this is somehow hidden at the very end of section 6.3.1. If possible, a reference why idempotency does not matter for TLS would be a great plus - but I am not a TLS expert myself and cannot provide that reference out of my head.

Michael (as individual)


> > 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, 23 August 2013 18:18:54 UTC