Re: hierarchical, multicast routing etc

[Polly Huang <huang@catarina.usc.edu>]

> 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

Is $propdelaycost differenct from $propdelay?  Why not just assign the
cost using $propdelay? That way, the routes will always be the shortest
delay routes.

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

This is odd. THe two lines

$ns cost <node1> <node2> <cost> 
[$ns link <node1> <node2>] cost <cost>

work exactly the same.  Did you assign costs for both directions, like you
did in the '$ns cost <node1> <node2> <cost>' version?

cheers,
-Polly

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