[e2e] a means to an end
pekka.nikander at nomadiclab.com
Sat Nov 8 23:25:38 PST 2008
A few potential ingredients.
Path-specific locators seem to have lower overall utility, as such,
but have the large benefit of not being directly useful for DDoS.
Obviously, they need to be updated also when the receiver moves, not
only when the sender moves. Overall, they share many of the problems
with source routing, but when properly designed perhaps not the most
blatant security vulnerabilities. People seem to do just fine with
Path-specific locators can be more easily converted to time-specific
ones than universal locators....
A market of competing services usually seems to yield better dynamics
than one centrally controlled service. If scalability is an issue,
breaking down the service into smaller pieces may make it more
manageable. Besides, aren't we more bowing to Reed's law than
Metcalfe's law these days? A service per community, perhaps?
As someone else already pointed out, once you have an end-to-end
association, updating the locators becomes easier than finding the
other party in the first place. Especially if you can make before
break, which of course is useful for any hard end-to-end services
Aren't we moving away from end-to-end to some variant of store-and-
forward? Or, it is all just time scales? For 200 ms end-to-end
latency the tricks needed are different from those you need with a
2000 ms time budget; most of today's Internet traffic seems to do just
fine with 2-4s perceived latency. (TCP duh, but that's a detail.)
Convert queues to opportunistic caches, observe that the prices of
storage still go down much faster than bandwidth, and realise that
soon you'd better send all the time on those precious long hauls even
if you don't have an immediate paying receiver.
--Pekka, ducking for tomatoes
On 7 Nov 2008, at 11:31, Jon Crowcroft wrote:
> my and my big mouth -
> i knew this would get hijacked into a philosohpy discussion.
> I am talking about this as I think the internet community is in denial
> and uses philopshy as an escape valve to avoid discussing the actual
> elephant in the room
> We need a new kind of network layer _service_ - to support finding
> end systems
> as they move around and so on.
> We have an idea of the workload on the service.
> It is unusual kind of service for the internet community as it isnt
> an overlay,
> it has to work inside the IP layer
> as it is something end systems and routers need to share state/fate
> (we hit this before implicity with multicast, and couldn't ever
> face up to it properly)
> It would be nice to capitalise on the last ten years of
> internet scale content service research,
> since the actual _volume_ of data in this service system is low,
> but the churn is very high.
> The service _might_ be implemented by some sort of 1-hop DHT
> but it needs to support consistency and security.
> It isnt DNS based and it isnt BGP
> based because both of those technologies
> have major design flaws and surive
> only due to heroic bandaids
> we need a Mocapetris for the 21st century, clearly
> it aint me....it might be Van:)
More information about the end2end-interest