Re: hierarchical, multicast routing etc

[Lloyd Wood <L.Wood@surrey.ac.uk>]

On Wed, 30 Sep 1998, Polly Huang wrote:

> CtrMcast probes the unicast routing table for next hop towards sources or
> RPs. 

That's what I'm seeing (although why I'm seeing this in particular is
detailed further below); given the choice of multiple routes to a
destination, CtrMcast appears to prefer the hop towards the
destination with the shortest delay, even if choosing a hop with a
longer delay drastically reduces the overall hop count and total
delay. 

I'm looking at mesh networks, so if CtrMcast looked at the choice of
current hops towards destination and choice of next hops towards
destination and summed delays, to allow it to work its way around the
edges of each quadrilateral as quickly as possible, it would, I think,
be near-optimum for my purposes. (Are changes necessary? How difficult
a hack would that be?  Pointers on where I should look to fiddle with
code appreciated.)

I'm tempted to generalise this and suggest that being able to specify
how many hops along a centralised computing agent that knows about the
state of the network can look is a good idea for complex topologies.
Hey, they're centralised and the state of the network is known, right?

(Apologies if this is obvious and what CtrMcast is intended to do;
 unfortunately problems encountered appear to be limiting my
 experience with CtrMcast.)


> Since the default(hierarchical as well? Padma?) unicast routing
> calculates shortest path according to hop count,

according to hop count? nsDoc 15.3 says (the default?) static routing
uses an adjacency matrix and link costs i.e. link weighting.

I'm not seeing shortest path via hop count, alas; I'm wondering if the
behaviour I'm seeing is somehow specific to mesh networks or to the
limitations of experienced problems. It's not the sort of thing you'd
observe in a tree... 


> I'm not surprised that
> you couldn't get asymmetric routes out of changing link weight. I'd expect
> CtrMcast behaves differently if you specify the unicast routing to be cost
> based(remember seeing this in the doc, but don't recall excatly where). 

The $ns cost stuff is in sections 15.1 and .2 of nsDoc; I'm explicitly
setting link cost just after creating the links. What else should I be
doing?

Do you mean that I should be explicitly setting the unicast routing
protocol to be cost-based via an appropriate rtproto? What to? If I
set either: 

#ns rtproto Static
$ns rtproto Session

using a (flat one-level) hierarchical address space with an ns with
Padma's patch I will get e.g.:
_o176: no target for slot 772376
where:
 DuplexNetInterface DuplexNetInterface DuplexNetInterface DuplexNetInterface DuplexNetInterface)
                mcastproto__o179(McastProtoArbiter)
                classifier__o176(Classifier/Addr)

This is remarkably similar to my multicast/Node Expandaddr problem. 

As a result of this, I'm either not setting an rtproto at all and
relying on the default (hey, faster simulations!), or using the
comparatively prolix and slow-to-simulate:

$ns rtproto DV

because it seems to work. (On reflection, this blind spot may go a
long way to explaining my observed CtrMcast behaviour.) 

This can't be a conflict with hierarchical routing, since hierarchical
routing only gets enabled for two or more levels of hierarchy in
ns-address.tcl. It does look like another instance of whatever is
breaking multicast with Node expandaddr for me.

Question: The agent class variable INFINITY is set at 32 (nsDoc 15.3). 
Is that ttl in terms of original intended use (in ms) or in terms of
de facto use (hop count)? Can it be altered from Tcl? 

Thanks,

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/>PGP<L.Wood@surrey.ac.uk>