Subject: RE: old GSE idea

From: "Christian Huitema" <[email-masked]>
Date: Thu, 17 Apr 2003 10:58:38 -0700

Even if we solved MAC address collision on a single link, you have to
remember that a host can be multi-homed to several interfaces. Whatever
we do to support the survival of TCP connections should also work when
the traffic moves from interface A to interface B, e.g. from 802.11 to
GPRS. In such cases, the two interfaces are likely to belong to
different sites, and are like to use different interface identifiers
(since they indeed are different interfaces). The solution of "just
using 64 bits" will not work there.

-- Christian Huitema

---

From: Sean Doran <[email-masked]>
Date: Thu, 17 Apr 2003 20:29:42 +0100

On Thursday, Apr 17, 2003, at 18:58 Europe/London, Christian Huitema 
wrote:

> remember that a host can be multi-homed to several interfaces.

Or virtual/pseudo-interfaces, for that matter.  Hosts can do tunnels, 
VLANs, you name it.

> Whatever
> GPRS

The case of moving traffic from a single working interface
to a different single working interface is in many ways easier
than moving traffic across multiple working interfaces simultaneously.

We need to support hosts which are multiply connected within
the same local network infrastructure concurrently (and deal with
failures of some/all of those connections), as well as those which
are simultaneously connected to entirely different networks with 
entirely separate
and possibly mutually hostile administration (and deal with failures of 
some/all
of those connections), and just for fun a mix of the two.

It would be interesting to see if we could be more ambitious and
try to deal with movement/multihoming of things with finer granularity.

The multiported host model is amenable to virtualization, but do we
want to/can we have an identifier bound to a particular *service*
that may migrate around a network independently of other services
which are, at any given moment, sharing a host (virtual or real) with 
it?

Can we/do we want to aggregate several services (or clients thereof)
and have that aggregate be mobile/multihomed?   Yes, because
that's fundamentally what a host is, but can we/do we want several
*independent* aggregates of things within a given host?   Sure: that's
an interesting way of doing virtualization of hosts.   But what about
with granularity at a level other than a host or virtual host?   That 
is,
(assuming process migration is feasible) can I move my
voice over ip service, AIM,  ssh sessions, X server, and so forth
from one part of the network to another without moving the host
these are sharing with an IMAP service, ntpd, and so on?

Most of these questions go to the semantics of the lower-order bits,
how they bind with one or more sets of higher-order bits, and how
they are acquired initially.

	Sean.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 19 Apr 2003 02:39:43 +0200

> which are, at any given moment, sharing a host (virtual or real) with 

Of course we want this. Why is it that when I email someone sitting in 
the same room at (for instance) an IETF meeting, the message has to 
travel halfway across the globe? I want my mail service to be as close 
to me as possible. Sometimes that means that it has to run back home 
because I'm not connected, but at other times the service should run on 
my laptop.

> and have that aggregate be mobile/multihomed?

Do we need to aggregate services?

I'm thinking more the other way around: each service should live on its 
own address(es).

> That is, (assuming process migration is feasible) can I move my

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. Unfortunately, people are a bad 
platform for implementing network protocols.

> they are acquired initially.

I think the question of the bits will be solved soon enough once we get 
the right design team together. The question of the acquiring is more 
fundamental. How do you find something hidden behind an arbitrary 
topology, without depending on a central directory or on the help of 
strangers?

We could start by evaluating which part of the information should be 
pushed out and which part should be pulled in, and which part is static 
enough to be cached for a considerable amount of time and which part 
must be refreshed pretty much before every use.

---

From: Sean Doran <[email-masked]>
Date: Sat, 19 Apr 2003 02:24:36 +0100

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

> 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.