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

David G. Andersen dga at lcs.mit.edu
Fri Oct 19 08:45:51 PDT 2001


Jonathan M. Smith just mooed:
> 
> It's just nice to see people trying to do active networking!

Q:  What's the difference between RON and active networking?
A:  Dave runs his SSH sessions over RON and finds it very useful.

 :)  But seriously, RON really isn't active networking - the
real point is more about doing better routing for people who
are actively talking together.  Because this set is much smaller
(tiny) than the set of possible communicating pairs (2^32^2),
I think you can get away with doing things like actively probing
end-to-end connectivity, not aggregating the daylights out of
routing information, and so on.

> 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
> > [...]

  It's quite unclear from the IWAN paper what in SOAR is actually
implemented, and how it performs on real networks.  Do you have
any data about it?  I'd love to see how an app-level routing
approach performs on a different set of machines than those I
used for my tests.

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

  Ahh, thanks.  I agree with you;  in fact, one of the premises of RON
is that providers will generally be able to do a pretty tight job
of routing within their domain - OSPF, I _believe_, doesn't suffer some 
of the problems as BGP in terms of convergence times.  RON was designed
more for inter-AS communication, where the scalability and heterogeneity
problems start to creep in.

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

  And fairly easily deployed.  The incentives to 3rd parties could
take the form of pay-per-packet, which is at least easier than trying
to come up with a generic form of payment for the rent-a-server model
when people are running arbitrary code.

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

  I agree completely.  I don't think the policy constraints are
the cause of slow convergence;  I think that policy constraints take
away some links you might want to use for failover.  Flipping that
on its head, I think that _inflexible_ policy constraints are another
cause -- you can't say "Let dave go through MIT to get to his
cable modem from anywhere," you have to direct that policy at entire
remote networks.  Small application-layer overlays seem a better place
to implement these fine-grained policies, because you don't have
the scaling problem.

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

  Packetdesign's "Towards milisecond IGP convergence" paper addresses
things you can do within a link-state protocol to speed things up. 
RON is all about taking link-state protocol performance to the wide-area;
I have no illusions that a provider running OSPF can't beat the pants
off of RON for failures _inside their network_.  

  The only suggestions I've seen about improving BGP convergence come
from Labovitz.  If there are others, I'd be interested in seeing them.

  Thanks for the comments, and the pointer to the SOAR paper!

  -Dave



More information about the end2end-interest mailing list