Re: old GSE idea

[Iljitsch van Beijnum <iljitsch@muada.com>]

On donderdag, apr 17, 2003, at 21:29 Europe/Amsterdam, Sean Doran wrote:

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

> Can we/do we want to aggregate several services (or clients thereof)
> 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
> 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?
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.

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