Tuesday, October 28, 2008

Resilient Overlay Networks

Streaming thoughts as I read:

An application level networking protocol that sits on top of traditional IP and performs better both in the face of failures and generally (in terms of loss rate, latency, throughput).

-in the abstract they say that RON proved to be highly resilient to 32 outages, each over 30 minutes. However, they don't tell us how the traditional routing protocols (i.e. BGP) fared at handling the same failures. They get to this in the introduction, but I think they should cover it in the abstract.

-Is the performance of a twelve-node RON, representing 132 measured paths, representative? does this scale?

-plausibility of use in real world when ASs _are_ competing businesses? good for schools or other cooperating ASs i guess.

-they list some applications: overlay vpn and overlay ISP. has anybody built either of these?

-is a 5 percent loss probability improvement in 5 percent of samples significant enough to brag about? Did they see _any_ improvement of the same metric in RON_2 as well? if not why not?

-they found cases where RONs latency and throughput optimizing path selection algorithms found different paths? Couldn't this just be correlation and not causation (probably/hopefully addressed in the evaluation section)

-Because routing is done at a higher level, routers can make routing decisions based on metrics which are relevant to the service they are supporting.

-Uses Link-state routing by default.

-RON allows for a lot of policy to be specified as part of the routing policy.

-They implemented RON as a c++ library. They implemented a RON IP forwarder.

-Summarized nicely in table 1, they looked at three things: 1) RONs ability to detect/recover from dropped links. 2) RONs performance improvements in latency, throughput, loss rate. 3) stability of RON routes.

-Re 1, how big of a problem is this really? I am not convinced that this is a real problem with traditional BPG routing. Re 2, the improvements were good, but not great.

-They address problems that RON introduces with NATing, trust issues (RONs require trust), and scalability ("the RON design trades scalability for improved reliability")

1 comment:

Randy H. Katz said...

you seem to have missed a few blog postings over the last couple of weeks ...

Well they do compare RON against normal Internet paths in Fig 9. The lossy paths along the Y axis in this figure are suggested by BGP problems as they persisted for relatively long periods of time.