Best way to Fast Reconnect TCP with dynamic IP

Question

I am aware of TCP Fast Open, all though, I'm pretty sure it doesn't apply when the IP of the server changes dynamically. Getting the IP of the server quickly isn't the problem.

The problem is that I need TCP Fast Open to recognize that this new IP that I'm connecting to is the exact same connection that I was just connected to (just with a different IP). I also need the tcp window to not be re-trained, and instead return back to the previous window size of the last connection..

Yes, I am willing to use other more suitable protocols, but it has to be error free, operate on wireless without errors, and be less than 10ms latency, and all data must be delivered uncorrupted and in the correct order. TCP is the obvious answer over UDP. But as for other custom IP protocols, that is out of my range of expertise.

Answer 1

That won't work with classic TCP alone.

On an end system, (a bit oversimplified) TCP exposes a "socket interface" towards the upper layer, the application. Such a "socket" is defined by the tuple of "src port - destination port - src IP - dst IP".

If any of these four parameters changes, the new set of parameters fails to be matched against the existing socket's parameter set. It mandates establishing a new TCP conneciton/socket - and eventually the old socket will be torn down and its TCP connection will die along with it. There is no way to have the "next" TCP connection be detected as "continuation of the old one" - this would be against the very concept of TCP.

So, If the requirement is to keep a "session" alive while underlaying transport's parameters may change over time, you have options like the ones below (the list certainly not exhaustive)

Note: They all share the idea that the concept of "session" is no longer bound to a "classic" TCP connection and its state(s), but to an abstraction layer.

• Move the notion, establishment and tracking of a "session" to the application layer. REST-APIs and the likes spring to mind. Discussing upper layer application behaviour will leave the scope of this board.
• Some of the features and capabilites of Multipath TCP might help in this context, as MultipathTCP abstracts a host-to-host TCP connection from the underlying "classic" interface-to-interface (or IP-to-IP) TCP connection(s). Also: MultipathTCP exposes the classic socket interface to the application layer, so the application can be left unaware of what happens "downstairs". Disclaimer: I have no pratctical experience with Multipath TCP. Multipath TCP and what it can do might just still be on-topic, here.
• Consider a tunneling mechanism (for example GRE or even IPSec) where end systems have virtual internal IP addresses (stable, unchanging), which are the endpoints of the "classic" TCP connection. This "inner" connection is then transported through the underlying tunnel. The virtual host-internal interfaces should be coupled somewhat loosely to the tunnel's state (in extenso: don't go "down" immediately when the tunnel goes down). Then, the tunnel may undergo up/downs and re-establishments even with changing "outer" parameters such as IP address or even egress/ingress interfaces (Wifi, Mobile, Wired.. ). Also, if tuned well, down-detection, teardown and re-establishment of the tunnel can be made fast enough for the the "inner" end-to-end TCP connection not to detect a timeout. Some packet loss, some retransmissions and probably window scaling effects might be unavoidable during transitions, though. I am aware that this might violate some of the requirements such as tcp window to not be re-trained. Host-to-Host tunneling mechanisms are certainly off-topic for this board.

---

Answer 2

TFO only works when the server's IP address doesn't change.

4.1.3. Client Cookie Handling

The client MUST cache cookies from servers for later Fast Open connections. For a multihomed client, the cookies are dependent on the client and server IP addresses. Hence, the client should cache at most one (most recently received) cookie per client and server IP address pair.

(RFC 7413)

The easy answer to your problem is do not let the server address change. Since you seem to be operating inside your own network, that's rather easy to accomplish.

If the dynamic IP address is issued by your ISP you need to change your plan.