Re: where the indirection layer belongs

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

[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