Subject: [tcpm] Few TCP Fast Open considerations

From: Ketan Kulkarni <[email-masked]>
Date: Mon, 28 Jan 2013 22:12:54 +0530

Hello TCP Experts,
This is regarding few observations and suggestion about TCP Fast Open
cookie request/response.
Part of this discussion was done on netdev mailing list here -
http://www.spinics.net/lists/netdev/msg219775.html

However, I think the same and some further discussion best belongs
here as well.

It was observed that -
  If Fast Open cookie is obtained from a server, client always
attempts Fast Open to the same server. This is ok in most of the
cases.
Suppose the server restarts without Fast Open, it will never ACK the
data in SYN from such client and never send the cookie as well.
Client will always try the Fast Open and fail - leading the
re-transmission of SYN data.
As confirmed by Yuchung on netdev, though it may not be performance
killer, it seems a little odd.

This can happen in multiple cases few of which could be -
1. Server restarts without Fast Open support
2. Network path changes or any middle box just strips out the unknown
tcp options - fast open cookie in this case
3. Server expires the cookie and client is trying with expired cookie

My view is to provide a way for fast-open client which has obtained a
cookie to fallback to initial state when it detects the server it
obtained the cookie from is no longer acking the Data in SYN.
Detecting upon such condition, the fast-open client should retry
cookie request in subsequent connection rather than trying the
SYN+Data.
Detection could be based on some thresholds but that could be
implementation specific.

Any thoughts here - I may be missing something?

If above suggestion is ok, there could probably also be a need of
sending NULL cookie (again suggested by Yuchung on netdev) from
fast-open server.
Specifically, at fast-open client, to detect the difference between
the two different scenarios -
1. server restarted without Fast Open and is no longer supporting it
(or any of the condition given above)
2. fast-open server exhausted its fast-open backlog and is temporarily
not acking the data in SYN.

In the 2nd case, server might choose to send the NULL cookie on the
receipt of which client understands the server still supports
fast-open but unable to do so temporarily.
It might also indicate cookie expiration - but I am not sure.

I will like a wider view and more thoughts on such scenarios occurring
in the network.

Thanks,
Ketan Kulkarni

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 30 Jan 2013 22:06:50 -0800

Hi Ketan,

> I will like a wider view and more thoughts on such scenarios occurring

It seems to me that 1 and 2 are mostly the same unless you can know
how long "temporarily" is.
But, I'm guessing it'll be difficult to know..

--
Yoshifumi Nishida