Subject: RE: Identification, layering, transactions and universal connectivity

From: "Tony Li" <[email-masked]>
Date: Sat, 2 Aug 2003 02:26:17 -0700

|    It's not so much that we must desperately try to find the 
|    best address 
|    pair. BGP doesn't give us that either. But it's essential 
|    that we're 
|    able to weed out the very bad pairs quickly. It would be 
|    very helpful 
|    if we had some hints in the mapping system for this, such 
|    as "this is a 
|    low bandwidth/expensive address, only use as a backup" or 
|    "this is an 
|    address with partial connectivity (ie globally unique not globally 
|    routable) so only use when you know it's reachable".

Well, you're already into developing a global policy language 
for locators.  Seems expensive.

|    80/20 rule?

Exactly.

|    Yes. But the question is: do we want to go evaluate connectivity 
|    properties for half a dozen round trips before we do 
|    anything, do we 
|    choose something and go with it until we notice it doesn't work so 
|    well, or do we combine these by starting the communication 
|    immediately 
|    using one address pair and then evaluate connectivity in 
|    the background?

If we don't proscribe or prescribe, then this is just left as an
implementation detail.

|    How much magic do we need in the application to enable this 
|    differentiation?

Or in the kernel.  It depends on whether or not you're willing to add
to the API.  If you're willing to say, make it a socket option, then
all of it just goes in the kernel once.

|    > The network control plane does not change from the functions
|    > that we have available today.  In other words, the problem
|    > is already solved.
|    
|    ???

Restated: if we don't have to distribute more/new/timely information
to support 'intelligent' locator selection, then we don't have to 
make modifications to the routing subsystem and can defer all of
the 'magic'.  This makes migration easier as even the simplest of
algorithms can be used initially to select locators and can then
become more sophisticated as time progresses.

Put yet another way: let's remove the complexity of locator selection.
If simplistic turns out to be insufficient, then let's at least take
out fancy information distribution and be a bit nearer perfection.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 2 Aug 2003 18:35:44 +0200

> for locators.  Seems expensive.

I believe that not having it will be more expensive in the long run.

> If we don't proscribe or prescribe, then this is just left as an

Ok.

> out fancy information distribution and be a bit nearer perfection.

I don't think that's good enough. Today having multiple addresses from 
different ISPs doesn't work if the ISP does ingress filtering. To solve 
this, we need to be able to change addresses for existing sessions, and 
we need to figure out the right source address reasonably fast. But we 
also need to figure out the right destination address pretty quickly or 
publishing addresses that may not be reachable (for everyone) becomes 
too expensive. This is an integral part of the multihoming package so 
we must deliver on it.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 2 Aug 2003 15:21:40 -0500

Dear Iljitsch/Tony,

You're both chewing on something that seems important -
in today's systems, a lot of the experimenting goes into
applications. Or "doesn't go into applications", to be
more precise.

My understanding of the Late Unpleasantness on site-local
was that at least some of the problem wasn't that applications
couldn't figure out what addresses to use, given time and
failures to motivate more experiments, it was that we had
decades of applications that didn't try to figure out another
address when a failure occured. (Please correct me if I'm
confused here).

(1) At the recent IAB workshop on addressing, I watched
several speakers who COULD have used the phrase
"session layer" not do so, and I'm still trying to figure out
whether this is a religious choice or a technical choice. But
at least some of what we're taking about has been described
as a "session layer" that survives transitions in transport
connections.

(2) At that workshop, I noted that I'm hearing more and
more people talking about applications that were making
interface selections (based on what? from Iljitsch's original
note, but I digress), so that applications want to switch from
GPRS to 802.11 when 802.11 becomes available, etc. My
concern here is that if we do as Tony (correctly, I think)
suggests and find some way to perform these selections
below the application level, we may find that applications
that learned how to make these selections will still want to
do so - I'm using the NAT analogy, where one might make
the case that NAT made sense in IPv4 "but now you can
get rid of your NATs in IPv6", except that network
administrators STILL want NATs in IPv6, because that's
the way they do things now...

(3) I also note that failed experiments are more painful in
some environments than in others, and are especially painful
in high-latency environments. If you get back an ICMP
Unreachable message in 50 ms, that's one view of the
world. If you take 600-800 ms to set up a GPRS uplink
channel for each experiment, that's another view of the
world. I hear what Tony is saying about the difficulty of
"knowing without experimenting", but I also hear what
Iljitsch is saying about how nice it is when we can
have enough of a clue to prune some experiments off
the decision tree a priori...

Spencer

p.s. How off-topic is this thread for multi6?

----- Original Message ----- 
From: "Tony Li" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, August 02, 2003 4:26 AM
Subject: RE: Identification, layering, transactions and universal
connectivity

|    choose something and go with it until we notice it doesn't work
so

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 4 Aug 2003 00:20:44 +0200

On zaterdag, aug 2, 2003, at 22:21 Europe/Amsterdam, Spencer Dawkins 

> address when a failure occured. (Please correct me if I'm

That is one argument against this. But I think the really bad problem 
here is that once something goes into the general application populace, 
it becomes essentially impossible to get rid of it so when something 
better is developed later, the old way of doing it must be supported 
for *many* years.

> as a "session layer" that survives transitions in transport

A session layer is an interesting idea. But I don't think there is any 
agreement on what such a new layer should look like.

Myself, I think IPsec already took us halfway there by introducing a 
negotiation mechanism for security associations. We could generalize 
this to encompass other features as well, such as address agility. But 
first we have to get rid of the limitation that you must negotiate with 
the other end directly, as this leads to security problems and it isn't 
flexible enough.

> do so

So where is this huge list of applications that do this today?

> I'm using the NAT analogy, where one might make

For this particular use NAT doesn't help at all as sessions still break.

> channel

(Aaargghh, 600 ms, who told those bellhead halfwits they were allowed 
to create data protocols in the first place?!?)

> for each experiment, that's another view of the

If the GPRS link terminates not on a router but on the host itself 
(which would be the usual case here) there shouldn't be much of a 
problem: if the application specifically asks for "high delay, low 
throughput, low reliability, high cost" then we look at addresses tied 
to the GRPS link. If not, we only try this after everything else has 
failed.

But Tony's hint system, along with some knowledge of link 
characteristics, would be good enough to get us started. We should 
leave some stuff to work on for the next generation of protocol 
designers and implementers.  :-)

> p.s. How off-topic is this thread for multi6?

There doesn't seem any other place where it is on topic, though...

Wasn't the IAB going to create a list?

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 11 Aug 2003 19:38:06 +0200

I should have sent this  mail to the list a week ago, I am on vacation 
and am having some troubles with accessing my email. Sean and Randy are 
watching instead.

> There doesn't seem any other place where it is on topic, though...

I think this is on topic for multi6

> Wasn't the IAB going to create a list?

Uhm ,where they? I thought they where going to come back with some 
comments?

- - kurtis -

---

From: Geoff Huston <[email-masked]>
Date: Thu, 21 Aug 2003 17:45:23 +1000

>Uhm ,where they? I thought they where going to come back with some

Look for the list announcement and related activity in early September.

regards,

    Geoff