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.

  • Changing an address (IP or port) on either end breaks the connection. See RFC 793, Transmission Control Protocol: "...the TCP provides a set of addresses or ports within each host. Concatenated with the network and host addresses from the internet communication layer, this forms a socket. A pair of sockets uniquely identifies each connection."
    – Ron Maupin
    Feb 14, 2020 at 14:01

2 Answers 2


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.


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.

  • Hm.. TCP Fast Open (TFO) is an extension to speed up the opening of successive Transmission Control Protocol (TCP) connections between two endpoints (Wikipedia). While certainly helping to speed things up, l don't think that TFO will keep the previous TCP session alive (requirement ...is the exact same connection...) on either end system. So the notion and the tracking tracking of what a "session" is still needs to "move up the stack", away from the individual transport layer session(s) - no matter how fast these can be torn down or re-established. Feb 14, 2020 at 6:54
  • @Marc'netztier'Luethi The point is that the TFO option uses client/server IP combinations to track and associate its cookies. If the server address changes it won't work.
    – Zac67
    Feb 14, 2020 at 7:18
  • The server's IP always changes. But I guess I could just turn it into a client that connects to a proxy server, but that isn't ideal from a latency standpoint.
    – user8079
    Feb 14, 2020 at 16:11
  • If you cannot get a static address, Marc's tunneling suggestion is the best approach imho. It'll require quite a bit of tuning though.
    – Zac67
    Feb 14, 2020 at 16:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.