Subject: RE: where the indirection layer belongs

From: "Yuri Ismailov (KI/EAB)" <[email-masked]>
Date: Fri, 29 Aug 2003 11:10:19 +0200

Well, I fully support the idea of a new layer above the transport with new names and whatever names resolution system requires. I think that because the idea is hanging in the air during so long time and being researched by academy during number of years, there is definitely a need for a new group.

There are few, however quite strong arguments for that. First of all why limit ourselves with the question "where the indirection layer belongs?" There is no any indication that more than one indirection layer is possible in the stack and if right design assumed, there will be no collision rather addition of new functionality.

Secondly, looking far back in time (end of 70's, beginning of 80's) the right problem was already addressed by lets say V.Serf, J. Saltzer, D. Reed, D. Clark, .... It was identified that the current bundling of IP addresses and TCP port numbers "allows to connect but not allows to reconnect". End-to-end principal, besides all, states that the function distribution between layers is one of the most important system design principals. Given that, given the fact of multihoming, given the need for mobility support, given the need for v6-v4 internetworking, etc., there is a bunch of new stack features, which are desirable to implement. New layer design becomes more and more demanding.

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. Just an example (there are hundreds of such examples), support for multihoming does not negate move of a flow from one interface to another (the reason does not really matter and this is a reasonable service for applications). Staying below transport and using current, de-facto "endpoint" - socket, which bundles IP address with port numbers we will not get any further in doing that in a good way. 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? ....

Next, what really surprises, is that all talking about new functionality but none of the existing implementations should be changed. If so, we will and already are stuck with virtual interfaces, multiple IP addresses (even per interface), sending multiple IP headers in packets and end up with hacks configuring and reconfiguring routing table without even giving a try to understand that it is not always possible and in the cases when possible might be harmful for applications not willing to use those services requiring all imaginable reconfigurations.

/Yuri

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 29 Aug 2003 14:30:56 +0200

[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

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Aug 2003 14:54:44 -0400

> Regarding this discussion about an indirection layer, I am thinking we
> really should propose the formation of some forum for discussion of
> these issues. [...] Call it an indirection layer or a stabilisation
> layer or whatever you want, but we need a forum where we can specify
> the problem we are trying to solve and to consider the possible
> solutions for it.  Does anybody agree?

I don't disagree with the need for a forum at some point, just with the
presumption that a single layer can reasonably solve all of the problems
associated with the various sources of address changes.  So I'd really
push back against an effort to try to accomplish the latter.

Also, experience with the IRTF "name space research group" (which was
tasked to work on a similar problem, though phrased somewhat
differently) has probably left some people (including probably myself)
feeling a bit ...  well, hesitant.  If a relatively small, select
group of very talented experts couldn't agree on how to solve a problem,
is an open forum consisting of an arbitrary number of people with
varying levels of expertise likely to do better?  Bottom line is that
it's very difficult to reconcile the views of people with experience in
very different parts of the network - apps vs. routing vs. transport -
even if they're all highly competent.  It's probably even more difficult
if you have larger numbers of people and you can't assume the competence
level.

Obviously we need to solve this problem.  We just need to be careful
about how we go about it if we hope to be successful.

Personally I think a forum might be a bit premature, as it would
distract various peoples' energy away from efforts to draft strawman
architectures, and instead tempt them to spend time getting in sync with
the group.  Maybe we could have a BOF in Minneapolis and wait for after
that to formally organize a discussion group?

Ketih

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Aug 2003 17:06:27 -0400

> (b),

No.  A client can't tell whether multiple addresses associated with an
DNS name indicate multiple hosts or multiple addresses for the same
host.  No matter where the stabilization layer(s) live, using DNS as a
means to map from identity to locations simply won't work.  It might be
good enough for initial connection (assuming that if a service exists on
multiple hosts, any of them will do), but it's not good enough for
re-establishing an already-open connection, because you might get a
different host the next time.

>  hence the insanity claims because a solution for (a), 

I don't know whether Tony assumes (a) or not.  But that has nothing to
do with why I made that particular claim.

> convinced that such a solution will provide many benefits and should
> be developed and implemented.

And I'm equally convinced that a solution that assumes (b) is a
nonstarter.  There is already too much practice that conflicts with
it.  Like it or not, DNS names are no longer "host" names in practice;
they're "service" names.  A service can be a host but it's not
reasonable to assume that a service _is_ a host.

> maintained by developers. 

No it doesn't.  What it allows "us" to do is impose subtle changes in
the behavior of lower layers, and introduce new failure modes, without
giving applications any way to deal with them. 

> layer? 

It depends on which "thing" you are talking about.  For the L3-L4 thing,
it's either a new layer or a change to an existing layer.  If you
have both the L4-L7 thing and the L3-L4 thing, the former is either a
new layer or (my personal opinion) a new API that knowledgable apps
call explicitly.

---

From: jfcm <[email-masked]>
Date: Fri, 29 Aug 2003 22:08:05 +0200

>that to formally organize a discussion group?

Dear Keith,
I fully agree with that. However I feel that the IPv6 numbering plan and 
all the related issues are /  have beein discussed a lot in different fora 
without addressing my expectations - and since I am just one inter pares - 
without probably addressong many other ones expectations. This makes all of 
us uncertain about what has been discussed, where, how specialists have 
decided things we think we have to disagree with, where we can contribute 
in wasting the minium time for everyone.

Might I suggest a preliminary approach: instead of trying to propose 
solutions now, why not to try to list all the demands. Independently from 
any solution. Then to try to put some order into them by possible 
solutions. Such a step could be open to everyone. I am sure that many of us 
would leave the rest to specialists should we be sure that our pet needs 
will be supported or will be considered.

Also, I understand that many feel there is a possible need for multiple 
numbering plans. It would be better to clarify that now.

jfc

I must say that this mail is also a test to see if I am flamed because I 
would be - as many other here who do not tell it - ignoring what I should 
know. A good way to learn. IPv6 is not something for specialists to define: 
it concerns everyone, and everything in the network archiecture.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 30 Aug 2003 09:24:53 +0200

> host.

Right. And a session can't jump from one address to another either. So 
when we implement the latter, we also address the former.

> it.

To be more precise: the idea is to have transport sessions move from 
one address to another when there is a rehoming event. Obviously there 
will be changes to the process of publishing additional addresses.

>> It would make sense to
>> namespaces or new address formats without any pain

> giving applications any way to deal with them.

Well if we make a new API that allows applications to set up sessions 
based on FQDNs, and then later we decide that the next version of IP 
really needs variable length addresses where the address length in bits 
is a prime number, existing applications _should_ continue to work. 
Experience shows there are always cases where things aren't as simple 
as all this in practice, but I don't see how this can be worse than 
being 100% positive that the applications won't work and must be 
changed to support the new address format.

> It depends on which "thing" you are talking about.

New API and/or mechanisms to distribute operations over multiple hosts.

> For the L3-L4 thing, it's either a new layer or a change to an 
> existing layer.

Agree: both ends must cooperate, so a layer (new or modifications to an 
existing one) makes sense.

> If you have both the L4-L7 thing and the L3-L4 thing, the former is 
> either a new layer or (my personal opinion) a new API that 
> knowledgable apps
> call explicitly.

Right, and API != layer.

---

From: Keith Moore <[email-masked]>
Date: Sat, 30 Aug 2003 07:56:44 -0400

> will be changes to the process of publishing additional addresses.

I'm also interested in ways of doing this.  I just don't think it's 
appropriate to use FQDNs as the identifiers.

Keith