[e2e] a means to an end

[Jon Crowcroft]

we have a bunch of interpretations of IP addresses today (many more
than "officially" sanctioned) and I agree that a new id-loc split is
going to have a number of interpretations (probably all the ones we
have now, and definitely some new ones)

so assuming the id part is done (without loss of generality:)
we can discuss how locators work 
and how to map from diferent kinds of id, to loc 
(and, if/when/where needed or allowed, pace, scott brim)
from loc to id - but lets leave that for now)

locators can refer to fixed points of network attachment 
(like phone landline numbers refer to sockets on the wall)
to objects (in content) where they look a bit like anycast
to groups of recipients (where they are group locs and need
recursively (and distributedly) remapping to actual locs
and to current locations of a mobile
node where we need/can have a more efficient way to 
remap when the node moves for the other node(s) 
currently in session with this one,
than we do for new nodes trying to find it...
(actually, i am not sure if this is true for both ends moving
unless you buy into router state which has to scale
order number of current mobile sessions, 
which doesn't look tracatable to me, or to 
hierarchical location thingies, which might be ok
but ....)

anyhow the API for host and router is still the same - the point is
what sort of service do you want? (there's some nice work by
colleagues here in this context ages back - viz
http://www.cl.cam.ac.uk/~pes20/nomadicpict.html


In missive <2F96E808-6A16-46A0-B836-819C220EE701 at nomadiclab.com>, Pekka Nikande
r typed:

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

 cheers

   jon