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

Re: where the indirection layer belongs



[CC'ing multi6 as I don't think everyone there knows about this thread on the IETF discussion list, but please remove either ietf or multi6 if this discussion continues.]

On vrijdag, aug 29, 2003, at 11:10 Europe/Amsterdam, Yuri Ismailov (KI/EAB) wrote:

Thirdly, if to stay below transport layer all efforts will not let go beyond a device (host) level. Obviously, there is a need for naming users, devices, content, services or anything else one might think about.

But aren't we squarely inside the application domain here?


This is still multihoming of devices, what about "multideviced" users? If one has more than one device and wants to move a flow between devices would this be possible if implemented below transport layer? ....

That's a good point.


But first of all: let's not get too carried away with new and interesting problems thereby forgetting about actual needs that users have today. We need a way to allow multihoming in IPv6 that doesn't have the scaling problems our current IPv4 multihoming practices have.

It's not uncommon to see a FQDN point to several IP addresses so that the service identified by the FQDN can be provided either by

(a) multiple hosts, or
(b) a host with multiple addresses.

Now if we want to support moving from one addresses to another in the middle of an (application level) session, we have two choices: build a mechanism that assumes (a) and by extension also works with (b), or focus on (b) exclusively.

It looks like Tony Hain wants to go for (a) while Keith Moore assumes (b), hence the insanity claims because a solution for (a), which by its nature can only reasonably implemented above TCP, is much more involved and less efficient than one that only supports (b), which can work on a per-packet basis below TCP and other transports.

As a member of the multi6 design team that works on a (b) solution I'm convinced that such a solution will provide many benefits and should be developed and implemented.

However, this doesn't say anything about the need for an (a) solution. Obviously (a) would be good to have. Peer to peer file sharing applications extensively use mechanisms like this, where they download parts of a file from different hosts.

Also, the current socket API isn't exactly the optimum way for applications to interact with the network. It would make sense to create something new that sits between the transport(s) and the application, and delegate some tasks that are done by applications today, most notably name resolution. This allows us to implement new namespaces or new address formats without any pain to application developers or users stuck with applications that aren't actively maintained by developers. This would also be a good opportunity to create sensible ways for applications to ask for advanced services from the network.

But the real question here is: does this new "thing" have to be a layer? In the layering system we have today, each layer talks to the underlying one on the local system, but it also interacts with the same layer on the remote end.

I'm not convinced this is called for here. For instance, a host that implements the above could use a new advanced API to open a set of TCP sessions to all the addresses that a FQDN points to, and then distribute HTTP requests for the different parts of a file over these sessions. But on the other end of one or more of these sessions, there could be a regular HTTP server that is completely unaware of the new mechanisms and uses existing socket API calls.

So yes, we need something new above the transport layer, but no, it shouldn't be a "layer".

Iljitsch