On woensdag, aug 27, 2003, at 20:33 Europe/Amsterdam, Keith Moore wrote:
we need to move the FQDNs and especially IP addresses away from
identifying hosts, and introduce and explicit host or "stack name"
identifier.
mostly agree, except that I suspect it works better to put the new
layer
between IP and transport than to insert a layer underneath IP.
Not sure where you got the idea that I was talking about a layer
underneath IP. The best way to do this would architecturally between
transport and IP. It should be possible to implement this in such a way
that both TCP and other transport and also IP remain unchanged, but I
expect implementers to take advantage of the TCP state to make better
rehoming decisions.
part of
this assumption is that the new layer can still be nil for hosts whose
location is fixed and that do not need unreasonably stable addresses.
Unfortunately, it's not this simple. A single homed, fixed location
host could be talking to another host that is multihomed and/or moving
around. Both ends must implement something like this for it to work.
Where necessary, FQDNs can be replaced by application specific
namespaces with a system to map those names to host identifiers to go
along with such a new space.
I don't see a need to change FQDNs themselves - but the meanings of the
IP addresses that they map to will change slightly.
There is no need to change FQDNs. But today we let an FQDN point to a
bunch of hosts and then let the application take care of selecting the
host it wants to talk to and what exactly it wants from the host. I can
imagine a system where things like files in a peer to peer file sharing
network or TV channels streamed from a network of streaming servers use
a namespace particular to that application, with an
application-specific lookup service to go with it. So I can type
something like tv://cnn/ and the lookup service for the A/V streaming
namespace returns the closest host that can stream the required
content. Obviously we can do this today using our existing protocols
and some glue here and there, but that way we don't get to take
advantage of the special properties of A/V streaming, such as a
carefully synchronized jump from one server to another in mid-stream so
there is no interruption in the image or sound.