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(_at_)muada(_dot_)com]
Sent: Friday, August 29, 2003 2:31 PM
To: Yuri Ismailov (KI/EAB)
Cc: ietf(_at_)ietf(_dot_)org; multi6(_at_)ops(_dot_)ietf(_dot_)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