Re: old GSE idea

[Sean Doran <smd@ab.use.net>]

On Saturday, Apr 19, 2003, at 01:39 Europe/London, Iljitsch van Beijnum 
wrote:

> Obviously you can reroute your voice calls or instant messaging to 
> another box. But SSH sessions...? I guess this is what happens when I 
> disconnect and log in again from another box and reconnect to my 
> screen session. Doing this at the network level means that TCP 
> sessions are no longer tied to a host, but to a person.
No, they're tied to a stack of software that may migrate around, and 
just
happens (usually, but not always) to be presented to a live user
sitting in front of some sort of virtual or actual terminal.   Some 
folks
use ssh for computer-to-computer communication, such as when doing
mirroring, backups or whatnot.

If I fire up NetBSD in a Virtual PC  on my Macintoy, and have it DHCP 
up an
address on LAN A, fire up an ssh session, do a Save-All-State-and-Quit, 
copy
the image to another Macintoy and resume the VirtualPC, as long as the 
ssh
and sshd can still communicate with one another, the session survives.

The "session layer" in OSIspeak, is the VirtualPC itself.

(iPods make great VPC image transport mechanisms.)

The trick, naturally, is at least two things: (a) the moved sender must 
be able to
convince the stationary receiver that it is the same speaker in a new 
place and
(b) the moved receiver must be able to receive datagrams from the 
stationary
sender.   Right now, this can only be accomplished by remaining on the 
same LIS,
or by fiddling with the routing system (and possibly tunneling).

However, some protocols simply don't need a session layer in the 
presence of
a decoupling of "speaker/recipient-identity" and network location, 
8+8-style.
Others, naturally, could benefit from something a little more 
lightweight than
a large virtual machine, reducing the problem to 'can still communicate 
with one another',
i.e., the same as already movement-friendly/renumbering-friendly stacks 
of software.

Since movement/renumbering can be seen in the light of either or both of
fail_A-unfail_B or unfail_B-fail_A when doing multihoming, a 
generalization
of renumbering-survival/mobility which handles a long gap between the
two events in the second case, may also solve the host multihoming 
problem.

Is this a good mechanism for solving site multihoming?  That is, is 
multihoming
or moving a site merely a question of multihoming or moving each of the 
hosts
in the site?   (A site may be *large*...)

>  Unfortunately, people are a bad platform for implementing network 
> protocols.
	Sean.