Re: hierarchical, multicast routing etc

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

On Wed, 30 Sep 1998, Polly Huang wrote:

> CtrMcast will choose whatever the unicast routing table suggests the
> shortest route is from group members to RPs or sources. Note that it
> might not be the shortest path from srouces/RPs to the group members
> if the links are asymmetric. 

asymmetric duplex links, with different costs in each direction? Not a
consideration for me at present; I'm interested in propagation delay
as the link metric, and that seems to be pretty much symmetrical as
far as I'm concerned.


>  This is so called reversed shortest path mcast routing (e.g., PIM).
> 
> Did you assign $link cost according to its delay? If yes, the unicast
> routing table will be calculated according to the delay, and therfore,
> CtrMcast (strickly relying on unicast routing) will get the shortest delay
> route instead of hop count (the default. i.e. w/o setting $link cost)

Oh right, ns/tcl/ex/simple-eqp1.tcl
is quite handy in understanding the command set here.

I was doing as per nsDoc 15.1:

$ns $linktype $n($node1) $n($node2) $bandwidth $propdelay $queuemethod
$ns cost $n($node1) $n($node2) $propdelaycost
$ns cost $n($node2) $n($node1) $propdelaycost

where $linktype=="duplexlink"

which apparently did nothing, yet simple-eqp1.tcl
is using the different form: 

[$ns link $n2 $n4] cost 2

to set the costs instead, which must be what you are talking about.

So, I changed to:
[$ns link $n2 $n4] cost $propdelaycost

(where $propdelay is no larger than 31)

and now when I run my simulation with this cost code I get... no
traffic trace data to speak of, no scale in nam output, etc. Just
the topology. Suggestions?


On, and if I include the line:

Node set multiPath_ 1

with flat hierarchical routing on I will get a guaranteed error of
the form seen before:

_o175: no target for slot 170585

Hope that's another clue for tracking that down.

Further experimentation with the new single level hierarchical routing
has shown intermittent failures leading to the same 'no target for
slot' error (or the simulation running successfully but leaving nam no
traffic to simulate even without 'Node set multiPath_ 1'), so I'm back
to none-expanded addresses (and no link weighting code!) to actually
see traffic move in nam thanks to ns behaviour I can figure out.


> $link cost fuction is sufficient. But, keep in mind that hierarchial
> routing may also result in sub-optimal routes...

I'm was using hierarchical addressing, but not hierarchical routing
AFAIK. One level of address space should preclude it... 

Hints appreciated.

L.

is rather stumped.


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