Re: Identification, layering, transactions and universal connectivity

["Spencer Dawkins" <spencer@mcsr-labs.org>]

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" <Tony.Li@procket.com>
To: "Iljitsch van Beijnum" <iljitsch@muada.com>
Cc: <multi6@ops.ietf.org>
Sent: Saturday, August 02, 2003 4:26 AM
Subject: RE: Identification, layering, transactions and universal
connectivity

|    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.