paper 13 - routing RON

the main goal of a RON is to enable a group of nodes to communicate with
each other in the face of problems with the underlying Internet paths
connecting them.

RON nodes exchange information about the quality of the path among
themselves via a link-state routing protocol and build forwarding tables
on a variety of metrics. In order to constrain the amount of bandwidth
overhead, the authors suggest limiting the RON to less than 50 nodes.
This scheme is not scalable for networks with very large peers.
it also requires each node or a local group of nodes to create databases
to store samples related to various metrics. the databases ( in case of a
group of nodes) serve as a single point of failure and attack.


It assumes that nodes in a RON will not be malicious since malicious
behavior could be easily detected in a such small world. the paper does
not explicitly deal with such detection mechanisms especially in the case
of nodes who might forward garbage information (related to path quality).


Optimizations are achieved using flow-cache entries.



One-hop Source Routing

the paper carries out experiments to determine the location of path
failures while routing. the authors distinguish between a true pah failure
and short-lived congestion using multiple probes. TCP-ACK packets were
used instead of UDP for various reasons such as firewalls and routers
dropping them.


 basic idea:
once a node detects a path failure, it selects k intermediaries and
attempts to reroute packets through them. If the new indirect path is
sufficiently disjoint from the older direct path, the faulty component
will be avoided resulting in successful communication.

better policies:
maintain a history of the intermediary that correctly forwarded to a
particular destination and set this intermediary as the k th intermediary
for subsequent routing to the same destination.
(although the authors do not discuss as to how a node detects that a
particular intermediary was successful given that it forwards to all the
intermediaries in parallel - does the response returned from the
destination indicate this intermediary ?  - or does the intermediary
himself inform about successful routing ?)

experiments show that for 3000 nodes random-4 (k=4 here) provides good
results and it should be invoked after having observed just a single
packet drop.


the value of the k would be different for different sized networks. The
authors have not provided mathematical equations for the value of k and
the frequency/eagerness of invoke for different sized networks.
k should be set based on the number of nodes in the network for optimal
performance.
(randomly choosing k will improve performance by a small amount only)
Knowing the number of nodes in the network (since it can change
dynamically) seems difficult.












