[e2e] a means to an end

[Jon Crowcroft]

yep - common service model - but disparate implementatin - a bit loke
ip forwarding service versus ip route algorithms

In missive <491487FC.40607 at employees.org>, Scott Brim typed:

 >>On 11/7/08 1:10 PM, Jon Crowcroft allegedly wrote:
 >>> did i say it was centralised? nope - 
 >>
 >>Well, I carefully said (this time) "a widely coordinated infrastructure
 >>mechanism by which IDs can be mapped directly to locators".  Don't you
 >>want that?  You drew parallels between what you want and DNS or a 1-hop
 >>DHT.
 >>
 >>> did you say you want end systems to implement multiple APIs?
 >>
 >>I don't think I did.
 >>
 >>> why? why not just have one API (a.k.a. service) and multiple strageies
 >>> for distribution/cacheing/pre-fetching/localisation/aggregation 
 >>> based n the demand pattern?
 >>
 >>Oh, so you're talking about an API, not something out in the network
 >>like DNS?  In that case I think we agree.
 >>
 >>swb
 >>
 >>> 
 >>> In missive <49147FDA.1000309 at employees.org>, Scott Brim typed:
 >>> 
 >>>  >>On 11/5/08 4:48 AM, Jon Crowcroft allegedly wrote:
 >>>  >>> the "level of indirection" is exactly what I am talking about but
 >>>  >>> noone appears to be designing a service that implements this with a
 >>>  >>> view to the workload (including secure update rate) it should
 >>>  >>> sustain.
 >>>  >>
 >>>  >>I'm saying it doesn't have to be "a service".  Or technically I suppose
 >>>  >>I'm saying that it can be many independent "services", but there doesn't
 >>>  >>have to be a widely coordinated infrastructure mechanism by which IDs
 >>>  >>can be mapped directly to locators.  Relatively slow-moving, public
 >>>  >>nodes can update their location directly in a mapping service (including
 >>>  >>DNS), but fast-moving or more security-conscious nodes can use a level
 >>>  >>of indirection, for example a "home agent" or a rendezvous point, in
 >>>  >>which case the central mechanism does not know where the node actually
 >>>  >>is.  So I'm questioning the requirements for updating a central service,
 >>>  >>and pointing out that a level of indirection via the rendezvous points
 >>>  >>has advantages.
 >>>  >>
 >>>  >>> the two way mapping is needed  because of audit/accountability
 >>>  >>> trails
 >>>  >>
 >>>  >>Generally that's privileged information, and should _not_ be publicly
 >>>  >>available in a general service.  If you need to know who was involved
 >>>  >>in a communication, for example to arrest him, you do need a mapping
 >>>  >>from locator to originating site, and you need to request coordination
 >>>  >>with the node's home site, etc.  I don't believe that has anything to
 >>>  >>do with a general mechanism for mapping from locator-of-the-moment to
 >>>  >>ID-of-the-moment.
 >>>  >>
 >>>  >>
 >>>  >>On 11/5/08 7:26 AM, Ali Ghodsi allegedly wrote:
 >>>  >>> Can DHTs be part of the solution, and if not, what are the essential
 >>>  >>> features which they are lacking? (trying to fish for research
 >>>  >>> problems)
 >>>  >>
 >>>  >>Yes but again IMHO you can either keep locators up-to-date in the DHT
 >>>  >>-- Jon's approach -- or you can keep the information relatively
 >>>  >>stable, pointing to a set of nodes which need to be accessed to get
 >>>  >>the current answer (and which might be DHT nodes or not).
 >>>  >>
 >>>  >>
 >>>  >>On 11/7/08 4:31 AM, Jon Crowcroft allegedly wrote:
 >>>  >>> my and my big mouth -
 >>>  >>>
 >>>  >>> i knew this would get hijacked into a philosohpy discussion.
 >>>  >>
 >>>  >>I'm going to split all that out into a different reply.  This one is
 >>>  >>just about your idea.
 >>>  >>
 >>>  >>Scott
 >>>  >>
 >>> 
 >>>  cheers
 >>> 
 >>>    jon
 >>> 

 cheers

   jon