RE: where the indirection layer belongs

["Yuri Ismailov (KI/EAB)" <yuri.ismailov@ericsson.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]


Regarding (a) and (b) alternatives it would be nice to have both. However it is not clear why multihoming for v6 and v4 are different issues. Handling of multiple addresses per host is the stack design issue.
The major problem is not to choose the right interface and to send data through it. Applications can do this today, for example SO_DONOTROUTE option in WinSock2. The issue is to CHANGE between interfaces. Current design is OK as long as there is no dynamics.

Honestly, I think that solving one problem at a time may create problems for solving other problems.
Given broad changes in the stack - whole IETF work essentially, creates a good opportunity to review current design and introduce changes, which allow to avoid fixes.
For example, try to implement and run at the same time more than one draft/RFC introducing IP tunneling. I have had quite fun playing around with this and seriously, if to look at the real problem, it is the fact that the same name - IP address, is horribly overloaded with different semantics.

Why layer? Because if it is not layer, then sockets, in their current form, will still be a limit due to the bundling with IP addresses.

-----Original Message-----
From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
Sent: Friday, August 29, 2003 2:31 PM
To: Yuri Ismailov (KI/EAB)
Cc: ietf@ietf.org; multi6@ops.ietf.org
Subject: 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