[e2e] Revisiting RON ("traffic engineering considered harmful" thread)

[Jon Crowcroft]

so RON is cool, but not as cool as ALAN _ see our SOAR paper in
IWAN 2000

An Architecture for Application Layer Routing, Ghosh, Fry & Crowcroft,
'An Architecture for Application Layer Routing',
Yasuda, H. (Ed), Active Networks, LNCS 1942, Springer, pp 71-86. ISBN
3-540-41179-8 Springer-Verlag 
(ftp://cs.ucl.ac.uk/darpa/iwan.ps.gz

as far as i kmnow, the now oft cited idea of using padhye or floyd or
other TCP rate equation as a route choice metric originated in fact with
Curtiz Villamizar in the really nice optimized multipath routing draft
for OSPF (prob. expired now - was draft-ietf-ospf-omp-03.txt)
which would obviate the need for SOAR or RON if deployed...although an
inter-domain IP level solution of course would still elude us and
require somethign like this.

imho the actual problem is to create the right incentives for a 3rd
party to deploy open programmable (or user signalable) application
level proxies....closed ones are already there in abundance - although
in a pure open market it aint at all obvious why such application
specific, non-ISP or content server provided solutions should ever
exist, but then who says the ISP market (or any other:-) is free

RON I guess is nice and simple, which is good

of course ,there are people working on the IP repair convergence
problem - it is simply not true to say that the policy constrain
requirements in an EGP suvch as BGP4, combined with scaling are the
_cause_ of slow convergence after failure. the problem is the
baroqueness of routing _implementations_.

van et al have some suggestions on faster convergence
http://www.packetdesign.com/publications.html

while there are lots of deployment barriers to that, I dont personalyl
see why these are worse than server deployment barriers...

In message <200110172314.TAA22338 at nms.lcs.mit.edu>, "David G. Andersen" typed:

 >>Some more blatant project promotion about the RON project
 >>follows:
 >>
 >>In June, I chimed in on the "traffic engineering considered harmful"
 >>thread with a pointer to the Resilient Overlay Networks project:
 >>
 >>  http://nms.lcs.mit.edu/ron/
 >>
 >>As a refresher:  RON attempts to route around down, or terribly
 >>performing, Internet links by sending data through a friendly 
 >>computer located in some other autonomous system, in a manner
 >>inspired by the observations made in the Detour project.  If,
 >>for instance, the link between MIT and Berkeley is down,
 >>it might try sending my packets first to my home machine 
 >>on MediaOne, and from there to Berkeley, to avoid whatever
 >>bugginess was eating packets on the Internet2 connection.
 >>
 >>We found (in actual experiments where we let RON predict
 >>paths) that this kind of indirect routing was able to reduce
 >>the number of observed Internet outages by a factor of
 >>three to ten, and produced some nice improvements in latency
 >>and loss as well.
 >>
 >>The final version of the SOSP paper is now on our webpage,
 >>and we've just released the datasets we collected to peek at 
 >>its performance.  I figured the data might be useful outside
 >>of the context of just RON;  there are a few days worth
 >>of RTT and one-way loss samples between 12 and 16 nodes
 >>that may be interesting for data mining purposes.
 >>
 >>We're continuing to collect data from our testbed;  if
 >>you find this kind of data useful, and have suggestions about
 >>ways we could make it more useful to you or easier to
 >>deal with, please let me know.  And, of course, comments
 >>on the research or the paper are very, very welcome.
 >>
 >>   -Dave
 >>
 >>--
 >>work: dga at lcs.mit.edu                          me:  dga at pobox.com
 >>      MIT Laboratory for Computer Science           http://www.angio.net/

 cheers

   jon