headers
Iljitsch van Beijnum | 2 Aug 00:08
Favicon

Identification, layering, transactions and universal connectivity

Identity is a very interesting concept. What exactly makes a person, an 
object or some piece of information exactly that person, object or  
information and not someone or something else?

One school of thought is that the total of all attributes provides 
identity. Then there is the notion that some attributes are fundamental 
while others are inconsequential to the identity of the person, object 
or information. Finally, there is the view that identity is a 
fundamental property that doesn't depend on any attributes that may or 
may not be present.

In the real world the first method of identification works to some 
degree, as it is impossible for two objects to be identical in all 
aspects, including occupying the same place at the same time. However, 
for information this doesn't work so well, since this way the identity 
of a piece of information is identical to the information itself, so 
referring to information by its identifier becomes useless.

The latter two concepts of identification surface in relational 
databases and object oriented databases respectively. In a relational 
database model, links between objects are made using one or more key 
attributes in the destination object, while in object oriented 
databases objects are assigned an identifier that remains stable 
regardless of changes to any or all of an object's attributes.

So what do we use on the internet today?

At first glance it seems that we use a relatively ephemeral attribute 
as the identifier: the host address. The FQDNs we generally use can be 
seen as simple mnemonics for addresses. However, I think over the years
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Li | 2 Aug 00:56

RE: Identification, layering, transactions and universal connectivity


|    - Work on the address selection problem.

I don't want to discourage all of the metaphysics, but I would
like to mumble a bit about this part of the problem.  What are
the boundaries of the solution space for this particular area?
Ultimately, in a utopian world, we'd like an oracle that gives
us the perfect pair of addresses to use for any given communication.
These addresses would not only provide reachability, but would
provide optimality in routing, latency etc.

Back in realityland, we have no such oracle.  If we want to 
make an intelligent decision, we need to have data to base that
decision upon.  Without the data, possibly via indirect access,
we are guessing, tho that's not necessarily a bad thing.  See
Ethernet.  

The data that we would like to have includes topological connectivity,
including policy constraints, available bandwidth, latency, QoS
availability, etc. ad nauseum.   Where is that data today?
Some of it is in the routing subsystem.  Most of it is not
collected today.  Much of it is real-time information, so 
not maintaining a 'current' copy would make the information
worthless.  And the overhead of storing the information and
distributing it is pretty clearly daunting.  

Instead of trying to swallow this huge mountain of data, we
have a very simple alternative: perform experiments.  By
simply trying the addresses that we get from our addressing
system and actually sending the packets, we are, in effect,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Iljitsch van Beijnum | 2 Aug 10:48
Favicon

Re: Identification, layering, transactions and universal connectivity

On zaterdag, aug 2, 2003, at 00:56 Europe/Amsterdam, Tony Li wrote:

> |    - Work on the address selection problem.

> I don't want to discourage all of the metaphysics, but I would
> like to mumble a bit about this part of the problem.  What are
> the boundaries of the solution space for this particular area?
> Ultimately, in a utopian world, we'd like an oracle that gives
> us the perfect pair of addresses to use for any given communication.
> These addresses would not only provide reachability, but would
> provide optimality in routing, latency etc.

> Back in realityland, we have no such oracle.

Not something that magically knows which address pairs are good and 
which are bad, no. But it should be possible to leverage information 
that exists already or discover information when needed.

> If we want to
> make an intelligent decision, we need to have data to base that
> decision upon.  Without the data, possibly via indirect access,
> we are guessing, tho that's not necessarily a bad thing.  See
> Ethernet.

Ethernet is not a bad thing???

I think blindly guessing is pretty pathetic, especially if you consider 
that in large sites, many other hosts may be doing the same thing a 
little earlier or a little later. And the same host will very likely 
done the same thing before.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Li | 2 Aug 11:26

RE: Identification, layering, transactions and universal connectivity


|    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?
(Continue reading)

Permalink | Reply | 576 comments |
headers
Iljitsch van Beijnum | 2 Aug 18:35
Favicon

Re: Identification, layering, transactions and universal connectivity

On zaterdag, aug 2, 2003, at 11:26 Europe/Amsterdam, Tony Li wrote:

> Well, you're already into developing a global policy language
> 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
> implementation detail.

Ok.

> |    ???

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

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Li | 2 Aug 20:04

RE: Identification, layering, transactions and universal connectivity


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

Good point.  I consider that to be a different problem, however:
insuring that the packet departs via the ISP matching the source
locator.  We'd really like routing to choose the right ISP once
the host has chosen its source locator.  Unfortunately, we don't
have a great deal of control.  Most enterprises simply have an
internal default that points 'thataway' and may or may not fail
over when an SBR or its link fails.

[Aside: solving this with the 'little' proposal was actually
a bit easier.  The SBR simply changed the locator to match the
ISP as the packet exited.]

A simple approach here would be to give the host a 'hint' as to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Spencer Dawkins | 2 Aug 22:21
Favicon

Re: Identification, layering, transactions and universal connectivity

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
(Continue reading)

Permalink | Reply | 574 comments |
headers
Tony Li | 2 Aug 22:59

RE: Identification, layering, transactions and universal connectivity


One note: multiple experiments can be performed in
parallel, if the host is willing to devote the
resources and complexity to it.  This can be used 
to hide the latency of experimenting.

Tony
Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 4 Aug 00:20
Favicon

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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Pekka Nikander | 6 Aug 17:09

Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes)

[Slowly catching up some old e-mail]

Pekka Nikander wrote:
>> What comes to crypto binding, I am only aware of two possibilities:
>> Using asymmetric keys (or something similar) as primary identifiers,
>> or using CGA (or something similar).  All the other solutions that
>> I know about require some kind of infrastructure, some kind of
>> an enrollment procedure, or both.

Erik Nordmark wrote:
 > I guess I don't really understand your categorization.

Maybe I have to set up some context for the statement of mine above.
Firstly, my understanding is that we are still discussing the proposed
identifier/locator separation.  There are certainly several possible
ways of achieving the separation, some of which involve existing
higher level identifiers.  However, I tend to think more in the
line of just "splitting" the IP address roles, and perhaps
introducing a new name space for the identifiers.

Secondly, the question at hand was how to secure a binding between
a given identifier and a set of locators.  (There are documents that
include descriptions of at least some of the threats involved, see
draft-nikander-mobileip-v6-ro-sec-01.txt and
draft-nikander-hip-mm-00.txt)

Now, for making secure the binding between the identifiers (entities
that applications use to denote their peers) and the locators (routing
location identifiers), I am aware of two basic mechanisms:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane