[e2e] Naming (was: MAC addresses)

[David Andersen]

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

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

   -Dave, adding a level of indirection.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060418/c9eb1aed/PGP.bin