[e2e] a means to an end

[Scott Brim]

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
>