[e2e] Naming (was: MAC addresses)

John Day day at std.com
Tue Apr 18 10:56:42 PDT 2006

At 10:38 -0400 2006/04/18, David Andersen wrote:
>On Apr 18, 2006, at 9:54 AM, John Day wrote:
>>Saltzer says that a complete addressing architecture needs 
>>Application Names, Node Addresses, Point of Attachment Addresses 
>>and from all of this we get routes.  There is one refinement I 
>>would make to Saltzer which I think was overlooked because it 
>>hadn't occurred when he wrote the paper.  Salzter talks about the 
>>mappings of application names to node addresses, node addresses to 
>>point of attachment addresses and points of attachments to routes.
>I think there are others, and I may be missing some.  User names and 
>content names come immediately to mind.  Without them, things like 
>Web pages are inextricably bound to either a particular application 
>instance (obviously bad), a node address (how do you akamize?  how 
>do you change to a different akamai w/out renaming?), or a point of 
>attachment address (erk).  Of course, this is pretty much the 
>situation today, but it doesn't have to be.
>   SFR (Semantic Free References) - http://nms.lcs.mit.edu/projects/sfr/
>   Walfish, Balakrishnan, and Shenker
>   ->  Human *un*readable permanent identifiers for content, resolved 
>through a flat naming infrastructure.  Allows things like web links 
>or email addresses to persist through name changes, business 
>reorganization, etc.
>   DOT (Data-Oriented Transfer) - http://www.cs.cmu.edu/~dga/dot/
>   (Myself, Kaminsky, Tolia, Patil)
>   -> Decouples data transfer from endpoints and applications by 
>going indirectly through a content-hash (a'la what BitTorrent does, 
>but generalized in an application-independent manner for 
>point-to-point transfers).  Benefit:  Makes things like caching, 
>akamizing, mirroring, etc., ridiculously simple.  Has other cool 
>benefits too, but I'll stop beating that drum. :)

Ahhh, yes.  All of that.  I was trying to keep it simple in the first 
approximation. ;-)

  There is a need to distinguish applications, multiple instances of 
applications, something I prefer to call the application-protocol (of 
which an application can have more than one) and multiple instances 
of these.  As well as various sets of these things, which I have 
usually called group addresses and generic addresses. Others have 
called the latter anycast addresses but I think usually in a narrower 
sense than I have in mind.

>>(For those who were worrying about an identifier that doesn't 
>>change, it is the application name.  All the others do change.)
>I'm not sure this is correct.  If the application name is an 
>unchanging, long-term identifier, then you're not able to 
>distinguish between a session identifier (e.g., tcp migrate, bits of 
>sctp, etc.) and a persistent content ID.  Or I'm wrong. :)

Yea, this is where the instance level naming is required.  ;-)

Actually, one thing I didn't mention in that first email is that that 
application names are supposedly location-independent and node 
addresses and point of attachment addresses are location-dependent. 
Of course the problem with this characterization is what the heck 
does location-dependent mean in an arbitrary graph.  Over time, I 
have come to the conclusion that it translates to topologically 
dependent, but I do mean *topological* and not graph.  This field 
tends to abuse the word topology because it sounds so much more 

Upon reflection, one realizes that application names are 
topologically dependent as well, just in a very different topology. 
In fact, virtually all identifiers in computer science are used to 
"locate" things in some sense.  We really have very little use for 
names. Some but not much.

Take care,

More information about the end2end-interest mailing list