[e2e] a means to an end

[David P. Reed]

Riffing on Pekka's opening - why not multiple competing "routing" 
layers?  In the old days, when the Internet was about tying together 
different pre-existing networks into a coherent whole, it *was* one of 
many.  (at least one other routing mechanism existed - uucp -- and it 
used some of the same pre-existing networks).  Those many differed 
rather more than they need to - there was no common "sockets" API at the 
endpoints that could unify them, for example.  But that is a result of 
their divergent heritages.  Subsequently, they entered a melting pot, 
giving us the universal culture we call the Internet Today.

The current state of the Internet is that IP is still pretty trivial and 
includes some little-used tools (loose source routing, unroutable 
addresses, ...) that can be used by convention to build alternative 
routing schemes at modest cost.  Programmable routers (Linux iptables, 
Click) and switches (OpenFlow) are becoming easy to deploy.

Rather than a "single routing strategy to rule them all" perhaps they 
should compete for business, overlaid on a universal world-wide "dumb" 
fabric that they use in creative ways?

This sort of thing is what Van is doing, what some DTNers are doing, 
what Tor is doing.  Rather than objecting to them on trivial grounds 
(saving pennies, wirespeed content inspection, need for "lawful 
intercept")  perhaps we need to do research on them leading to a routing 
layer that has emergent properties other than DDoS.

Pekka Nikander wrote:
> 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
>>
>>
>
>