[e2e] a means to an end

[Jon Crowcroft]

did i say it was centralised? nope - 

did you say you want end systems to implement multiple APIs?
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?

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