Subject: Re: [arch-d] thoughts

From: [email-masked] (Noel Chiappa)
Date: Sat, 18 Nov 2006 10:28:13 -0500 (EST)

> From: John Day <[email-masked]>

Let me start with a few thoughts of my own, and then I'll reply to some
points in your message.

I think the best way to start is by totally divorcing the questions of:

- 1) What classes of things do we name, and
- 2) What do the names of those things look like.

Too much (all?) of the discussion here mushes the two together, which has a
whole range of problems. (One big one is that it's hard to clearly think
about the issues when it's just one big knotted ball of string.)

So I think it's wise to first thing about what are the things that need
names. Once that's settled, I think it becomes a lot easier to figure out
what the names look like, because by then you are thinking about how you want
to use the names, what you want to be able to do with them, and so makes it
clear what characteristics those names need to have.

When I think like this, it's clear that we need a class of objects which is
"place to deliver packets to", but it's not totally clear what higher-level
objects we need to name; do we need to name transport-level entities, or
should we go straight a higher-level thing (some sort of application name)?

    > This is just like OSs. You need a logical and physical address spaces
    > under the application name space.

Not necessarily (although perhaps I'm misunderstanding what you're trying to
say). In OS's, we have classes of objects (disk blocks) which only have
physical names; other objects (e.g. files) only have logical names. Sure, they
are both names for permanent storage, but their semantics are very different.

    > The point of attachment id does not have to be global.

I would argue that it does, in practise, because otherwise path computation
becomes a nightmare. To find a path from any arbitrary point to any other,
you really need names that are global in scope.

    > You keep talking about nodes having more than one identifier. No. There
    > may be more than one point of attachment (interface) bound to a node.

I tend to not like the term "node" because it makes a lot of people think of
"physical machine", and the classes of designs you come up with to handle that
then have issues when it comes to things like virtul machine OS's
(particularly ones where you have a pool of physical machines, and application
VM's can get moved from physical machine to machine, to balance load).

E.g. how about one interface having more than one node attached to it? How
about having the binding to the interface of one of those nodes changing, but
not the others? Etc... Are you sold on naming machines, for some reason, or
are you OK with a more abstract thing?

    > The Loc/Id discussion is misleading. It is a red-herring. It isn't the
    > real issue.

(Added later: I think I see what your point was here, and it wasn't what I
thought it was, so the rest of this bit is probably stuff you already agree
with, but I'll leave it for now.)

Well, I partly agree with that, if you come at it the way I suggested, because
first you need to think about what kinds of things you are naming, and yes,
there, the characteristics of the name aren't in play yet.  At the same time,
I disagree, when it comes to the part about what the names are like.

If we are naming two different classes of thing, then you get more bang for
your naming buck if one class of name is location-dependent (well, something
at some level has to be, to get the packets there :-), and the other is
location-independent, so that the binding between the two gives you all sorts
of useful tools (e.g. the ability to support multiple location-names, while
hiding all the details of that).

    > The architecture you are working in only has point of attachment
    > identifiers.

Currently, yes. But the current architecture's not that much of an issue,
since we're trying to go beyond it. It's only an issue insofar it's a legacy
we have to manage to work with.

    > Your endpoints are what I would have to call names for instances of
    > application-protocols, not applications.

True, but I'd go further - they are really (depending on which definition of
"endpoint" you are using :-) names for transport-level entities. We no doubt
have use for both i) names for applications, and ii) names for instances of
applicataions, but the question I am pondering is whether we need
transport-level names as well...

    > That makes your Loc/Id discussion about the mapping of identifiers
    > between application-protocol-instances and points of attachments.

Um, no, I think - I think most people are proposing naming transport-level
entities in some location-independent way, and having some sort of binding
between those and location-dependent point-of-attachment names.

Actually, let me take that back! Now that I think about it, David and Ran are
both (if I understand them correctly) talking about having the names for
transport-level entities say a little bit about where they are (within a
local scope), and those names are also to some degree naming
point-of-attachments, so yeah, I guess you are right.

    > You are still tying everything to the physical. You have still failed
    > to create the logical address space you need.

When I first read this, I didn't understand your point, until the penny
dropped that neither scheme clearly separates out what is being named, and
also doesn't give each one names with clearly different characteristics.

On the other hand, we may be stuck with that kind of ugliness, given that we
have to modify an existing, deployed architecture...

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: John Day <[email-masked]>
Date: Sat, 18 Nov 2006 11:48:46 -0500

>should we go straight a higher-level thing (some sort of application name)?

Agreed that we need to distinguish the two things.  However, I would 
characterize what we need to name a little differently.  We need a 
name for every locus of shared state with a different scope.  As near 
as I can tell, we have a minimum of three different scopes. What we 
have traditionally called data link, network and application.

>are both names for permanent storage, but their semantics are very different.

I was thinking more of memory management, as was Saltzer.

>you really need names that are global in scope.

It does if the mistake was made of only naming points of attachments, 
which we did with the IMPs and have promulgated.  Point of 
attachments should correspond to data link addresses.  As I mentioned 
in another email to you, Saltzer missed (legitimately, I think) that 
one might have more than one path between hops.  To find a route from 
any arbitrary point to any other, you do indeed names with scope of 
the layer in which they reside.  In some specific cases that is 
global.  But these should be node addresses not point of attachment 
addresses, unless it is a fairly small network.

>VM's can get moved from physical machine to machine, to balance load).

;-)  I was using node because it was the fairly neutral term that 
Salzter used that didn't really apply to any particular object.  I 
still contend that the physical machine is not relevant to this 
discussion. It is nice it is there to execute the code, but it 
doesn't impinge on this issue at all.

>are you OK with a more abstract thing?

As I said I have no desire and have found no requirement to name 
machines for the purposes of creating and maintaining communications. 
I am not sure what you mean by interface.  I do understand local 
bindings between protocol machines (PM) with different scope.  And 
have no problems with a PM of smaller scope having bindings with more 
than one PM (having greater scope) in the same system.

>with, but I'll leave it for now.)

;-)

>hiding all the details of that).

Agreed.

>transport-level names as well...

No. we don't.  It turns out that transport isn't as important as we 
thought. ;-)  All we need in transport is a connection-id to 
distinguish flows.  And we have that.

The application naming does need to be a bit richer, but we don't 
need to go into that here, now.

>between those and location-dependent point-of-attachment names.

That is because the community seems to have blinders on and believes 
that the only two layers they know they have are network and 
transport so everything has to be solved there.

>also doesn't give each one names with clearly different characteristics.

This is hard.  And it is really hard with email.  The points are 
subtle and they require screwing your head around where it hasn't 
been.  Believe me, I know!  It was hell figuring it out!

>have to modify an existing, deployed architecture...

That is entirely different question.

Take care,
John

---

From: Jefsey_Morfin <[email-masked]>
Date: Sat, 18 Nov 2006 18:03:35 +0100

>- 1) What classes of things do we name, and

OK.
except that who is the "we". Is that a unique plan, or is it a 
multiple plan? With registrar attached to the "things" or to "ends"?
I think it is a thrid point only to be addressed at the time you 
consider how addresses look like.

>- 2) What do the names of those things look like.

Except that they must be universal, hence numerics.

>should we go straight a higher-level thing (some sort of application name)?

IMHO you go too fast. Are you sure that all the transport-level are 
equal. Think of MTAs and UAs.

>     > under the application name space.

Correct.
All the /etc/named directories will work the same, whatever the 
machine and where they are located on disks. And all the 
.../db.mit.edu will be treated by Bind the same whatever the physical 
address of the machine/disk and the logical directory you chose to 
put in named.conf.

This permits to see that the data in these three layers are orthogonal.

>are both names for permanent storage, but their semantics are very different.

The semantic is for looking simpler to you. All of them are actually 
pointers, like IP addresses are domain name pointers. The semantic is 
of low interest.

What counts is:
- the layer
- if there is a layer violation or not, i.e. if there is a dependance 
on an other layer.

>you really need names that are global in scope.

No. Path computation would be segmented and therefore simplified 
(distributed, fractal, iterative). You can ask it to be carried by a 
smart DNS, segment by segment in a similar way as you resolve 
iteratively a domain name. First ISP computes to the Gateway, then to 
the destionation ISP, then the destination ISP to the end, then the 
end in the intranet. Some kind of an inter-NAT protocol could be used.

>are you OK with a more abstract thing?

The notion should be: logical nodes at that layer. Physical nodes at 
machine level. Metanodes for human/application layer.

>     > The Loc/Id discussion is misleading. It is a red-herring. It isn't the

There are (at least) four layers you are to consider 
addressingplan-location-identification-application.
- the environment
- the plug
- then end
- the brain (application, user)
They are orthogonal.

You can consider more as you may refer metadata to external 
registries (ISO 11172).

>we have to manage to work with.

No. The first thing to agree is that what is involved is not a 
replacement or a transtion but an addition in parallel. Current 
operations and plans must stay untouched. There is already a problem 
no body foresaw, let not make it potentially worse in trying to fix it.

>     > application-protocols, not applications.

actually in many cases they will be metadata holes. DNS + IPv6 
addresses are particularly apt to support them.

>     > to create the logical address space you need.

I see what you name physical nodes, but I wander what you really call 
logical space here: logical nodes or deeper metanodes?

>have to modify an existing, deployed architecture...

No. You can support all this without problem using the DNS and 
numeric labels. It will only be slower and more resource consuming. 
But this permits to test and transition. The FQDN will then look like:

               http://metanode_id.logicalnode_id.physicalnode_id.testsystem_name.org

That you can map into IPv6 
testsystem_address:physicalnode_address:logicalnode_address:metanode_address
Or into an IPv4 address with an access engine sorting the vitual 
corresponding virtual_host, virtual_metaregistry addresses.

The only problem is that before developping application using that 
scheme, it is better to know about the size of the final address 
space, meaning if a /3 block is allocated to it or not or if a brand 
new core is to be built which will support 256 bytes addresses (I 
documented the interlink/syllodata issue which may mean to refer long 
numbering schemes). Otherwise everyone can make it work today. The 
only real new issue is the metadata layer.

jfc

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 18 Nov 2006 14:50:20 -0500

On  18 Nov 2006, at 10:28, Noel Chiappa wrote:
> Actually, let me take that back!
> Now that I think about it, David and Ran are both (if I understand
> them correctly) talking about having the names for transport-level
> entities say a little bit about where they are (within a

I must not have been clear.  In my mind, transport-layer entities
are oblivious to where they are (i.e. location) and only use
location-independent Identifiers (never Locators) and are NOT
naming point-of-attachment in any way.

In my concept, interfaces are named only at/within the link-layer
and the scope of the name is local to the particular link.

Nodes ("protocol stacks") have one or more Identifiers,
used only for end-to-end identity, and one or more Locators,
used only for routing/forwarding network-layer packets.

Identifiers have global scope, but are not absolutely guaranteed
to be unique.  Locators have global scope.  Unicast Locators
must be unique in order for routing/fowarding to work.  (I can
imagine having multicast Locators, but lets leave that aside
for the moment please.)

I agree with Noel that terminology for "Nodes" is very fuzzy
as soon as one talks about things like distributed systems,
virtualised systems, or MLS systems.  However, "Node" is a
pretty good description for my laptop, which is neither
distributed, virtualised, nor MLS.

> also doesn't give each one names with clearly different  

In which way is my concept not clear in separating what is being named ?

I suspect this is mostly a matter of my writing or terminology,
because in my head I think the objects being named are pretty
distinct and separate.

Thanks,

Ran