[cgl_discussion] Use case - TCP session takeover

John Cherry cherry at osdl.org
Fri Mar 18 07:10:17 PST 2005

Moving this to just cgl_discussion...

On Fri, 2005-03-18 at 11:52 +0900, Takashi Ikebe wrote:
> The following is a use case for a TCP session takeover.  This
> addresses CAF.2.3 and CAF.2.4 TCP session takeover on CGL Specification
> 3.0.
> Please feel free to comment / suggestion.
> Takashi.
> -----------------------------------------------------------------------------------------------
> Description
> OSDL CGL specifies a mechanism to synchronize TCP sockets, buffer
> structures, and sequence numbers so that redundant nodes may take over
> TCP sessions originated on other nodes. A deliberate TCP session
> takeover assumes that TCP session(s) are transferred deliberately and
> not as the result of unexpected node failure(s).
> In addition to that, when a critical resource fails, such as a CPU,
> memory, or kernel, a redundant node may take over TCP sessions
> originated on the failed node. Note that when the TCP session(s) are
> assumed by a redundant node, the sessions will resume from the last
> checkpoint. TCP traffic should continue even if there is a conflict
> between the last TCP state of the failed node and the checkpointed TCP
> state on the redundant node.
> Desired Outcome
> Mainline kernel acceptance or distro acceptance.

Takashi, can you be a little more specific on what needs mainline
acceptance or distro acceptance?  I assume the project is "TCP
Connection Passing" on sourceforge (Werner Almesberger).  Is that
correct?  You also mention checkpointing the TCP state in the
description.  What checkpoint mechanism should be used for this?  Is it
part of Werner's project?

> 02i08&year=2005&month=2&srchexpr=Linux#hls1
> Participants/Roles
> Application administrators and developers use the requirement, and as a
> result, end users also use the function as a part of service.

As an administrator, what is my role with TCP session takeover?  Is it
just a matter of setting up a configuration file with policy
descriptions (checkpoint mechanisms, cluster standby definition, etc.)?
In the case of deliberate TCP takeover, what is expected of the

Is the developer's role to participate in the "TCP Connection Passing"
project or are you talking about additional development to make a system
or application TCP takover aware?

Shouldn't TCP session takeover be transparent to the user?

> Scenarios
> Basically, the requirement provide new system call and user-land library
> based APIs.
> So the requirement will be setup-ed on k02i08&year=2005&month=2&srchexpr=Linux#hls1ernel installation and also be
> used on application development phase.

Scenarios for using TCP session takeover might be things like...

- Moving connections from one system to another to allow for system
- Moving connections from one node to another to balance the load across
- TCP session failover in a performance or hiav cluster

Can you put some scenarios like this together for usage scenarios in
typical communications deployments?

Thanks a lot for doing this, Takashi.  This is a great start.


> Implementation Notes
> These Implementation Notes apply to all scenarios.  These are just
> guidelines, not cast in concrete.
> The requirement needs to provide APIs which enables below function;
> 1.Stop the indicated session.(usually indicated by file descriptor)
> 2.Get information of the indicated session.
> The information includes session status(such as address/port/sequence
> number), and receive/send data which is in socket buffer. the data in
> the socket buffer are not re-transmittable, because receive data in
> socket buffer are already finished TCP transmission (ACK sequence).
> 3.Set the information to the indicated session.
> 4.Restart the indicated session.
> The switch over sequence of HA(ACT-SBY) cluster assumption is below;
> 1.The service process on the active node use the requirement and stop
> and get the session information which wants to keep.
> 2.The service process synchronize the session information with the
> service process which on the standby node.
> 3.Change the cluster state(ACT to STOP).
> 4.The service process on the standby node set the session information.
> 5.Change the cluster state(SBY to ACT).
> References
> TCP connection passing:http://tcpcp.sourceforge.net/
> "TCP Connection Passing", Ottawa Linux Symposium, July 2004
> _______________________________________________
> cgl_discussion mailing list
> cgl_discussion at lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/cgl_discussion

More information about the cgl_discussion mailing list