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

[Jonathan M. Smith]

It's just nice to see people trying to do active networking!
								-JMS


On Fri, 19 Oct 2001, Jon Crowcroft wrote:

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