[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Identification, layering, transactions and universal connectivity

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

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

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

(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

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


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

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


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