[e2e] a means to an end

[Pekka Nikander]

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  
MPLS stacks...

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  
anyway.


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  
> with,
> (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:)
>
> cheers
>
>   jon
>
>