Re: Solving the right problems ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]