[e2e] a means to an end
Jon Crowcroft
Jon.Crowcroft at cl.cam.ac.uk
Fri Nov 7 10:38:29 PST 2008
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
More information about the end2end-interest
mailing list