Re: Feedback on TCP Fast Open?

On Fri, Aug 02, 2013 at 08:47:05AM -0700, William Chan (?????????) wrote:
> Hey Willy!
> 
> Your description sounds very familiar. Please see this bug:
> https://code.google.com/p/chromium/issues/detail?id=85229.

Indeed, thanks for the link. Next time I get such a report, I'll pass it.

> I am hesitant to open to the door to turning off preconnect in favor of TFO
> (although it's definitely on the table). Preconnect has shown substantial
> improvements in page load time. Indeed, it's one of our hugest improvements
> ever. But I'm super sensitive to harming servers, and would love to get
> details from any servers that are encountering issues. Please contact me if
> you have details to share here.

No problem. Till now that was only speculation by me but as you can guess
it's quite hard to get anything relevant in this situation. Also, users
who experience this tend to enable logging for the first time while debugging
the issue, so you cannot even compare the IP address with the last that was
logged to get info about the UA.

> And yes, the concern about the reliability of TFO is totally valid. And
> that's another reason I'm hesitant to switch preconnect over to TFO because
> preconnect Just Works from a client's perspective (yes, it may cost the
> server).

I understand. I still find that TFO has some uses on the local network, to
save round trips and packets, in fact to make it as cheap as a keep-alive
connection, but with less permanent states. I intend to experiment with
it between haproxy and some static servers for example. It can be nice
between clients and proxies probably.

I'm having some ideas that could be interesting to investigate with preconnect.
Indeed, instead of keeping a connection in idle for a long time, maybe sending
an "OPTIONS * HTTP/1.1" request would be useful :

  1) it would allow the server to know the UA
  2) it would make the server switch to the keep-alive timeout instead of the
     request timeout, meaning that the connections would probably be maintained
     less time (at least the server would regain the control over the connection
     time).
  3) a loaded server could still disable keep-alive or block these requests and
     save vast amounts of resources
  4) if combined with TFO, you'd get the information in advance about TFO 
     support along the path :-)

If "OPTIONS * HTTP/1.1" doesn't work often enough, then maybe sending a
"GET /favicon.ico" would be more appropriate (and the response could be
cached BTW, saving one round trip later).

Just a few ideas :-)

Willy

Received on Friday, 2 August 2013 15:59:47 UTC