More random and not so random thoughts

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

First some things I want to clarify after this morning. Note that I am 
not speaking on behalf of the design team here.

I suppose it would be a good idea to get a working definition of 
"multiaddressing". I think the idea is that a host gets more than one 
address. At some point this host will start emitting packets to the 
network. The most basic problem that we must solve in order for this to 
work is the source address selection problem. Something better than RFC 
3484 for the destination address would be very useful too. I think we 
can address this separately from whatever else we're going to do. So by 
all means, work such as NAROS should continue.

Now if hosts have more than one address (which already happens 
regularly in IPv4 and should be considered almost the norm in IPv6) 
then one of three things can happen:

1. The application doesn't know about multiple addresses, so default 
address selection kicks in. This doesn't reliably work today in the 
presence of ISP ingress filtering. This unhappiness needs to be 
resolved one way or the other, so see above. (Single homing because 
multihoming is worse isn't good.)

2. The application cycles through (a reasonable subset of) all 
addresses. This should work reasonably well, but it sessions can still 
break because of a routine routing change. So still see above. Also, 
I'm sure there are applications for which implementing all of this is 
appropriate, but I don't think it's reasonable to require handling all 
of this from application writers. And there are many reasons, both very 
pragmatic and much more fundamental, why I think this is simply the 
wrong approach for the general case.

3. Some intermediate layer handles this. This could be a special 
transport (SCTP), mobility or of course the latest and greatest loc/id 
stuff.

To me, all of this could be "multiaddressing" but I'll try to avoid 
that word from now on. If someone can come up with some new 
non-confusing terminology for all of this I promise I'll try to use it.

So here is my reasoning on where the handling of multiple addresses 
should happen:

Applications: not a good idea:

- there are many applications, doing the same work many times
- application writers usually don't understand network stuff so they 
are likely to get some of it wrong
- applications can have a surprisingly long shelf life while OSes 
_usually_ get updated at some point, and supporting legacy apps is hard 
enough as it is
- limited to things that can be done on one end most of the time

Each OS for itself: not a great idea

- makes porting applications harder
- little useful tradition in interoperation here
- again duplication of effort and often limited to doing stuff on one 
end

Transport: good and bad

- making TCP address agile would have a very siginificant benefit: TCP 
already keeps track of important end-to-end information that can be 
reused to good effect.
- doing a lot of stuff for each individual session is inefficient as 
many applications use very short-lived sessions
- doing this for each transport protocol is infeasible as protocols 
like UDP don't have the necessary hooks to do this

IP: not so bad and not so good

- this can be a general mechanism, do it once, solve the problem forever
- possibility of offloading processing to middlebox for policy, 
efficiency or speedy deployment

Ideally, we could start by implementing this in middleboxes. Yes, 
middleboxes suck but doing multihoming in the face of restrictive RIR 
policies and strange filters in far away networks isn't much fun either.

Then everything is implemented in the OSes. Now there is a tradition in 
Unix where TCP and IP are in practice completely comingled. So even 
though we define this mechanism to work at the IP layer, TCP 
implementations could easily incorporate this and start doing *really* 
interesting things such as load balancing a single session over 
multiple paths.

And if we're careful when defining all of this, it should be possible 
to drop in a new namespace if and when this is considered desirable.

Christian says implementing this would turn OSes upside down. But I 
simply don't see this. It seems to me that this could be entirely 
contained to the (TCP/)IP stack. Applications simply revert to IPv4 
behavior where they connect to a single address and if it is possible 
to set up the session, it will happen, and if not, the connection 
fails. No need to do anything complex.

Now obviously we can define one or more more advanced APIs that let 
smart applications look deeper inside the network. This would be more 
work than in the situation where we don't change anything, but I don't 
think smart applications really get to do what they need to do now 
anyway.

About the roadmap/more desing teams thing: I'm afraid of a situation 
where a good core idea doesn't take some limitations in consideration 
so the resulting proposal is flawed. It looks like this is already the 
case with e2e/lin6, but I have to read a bit more about those before I 
can say anything conclusive here. Hopefully the chairs can figure out a 
way to avoid this from happening.

Iljitsch