[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hierarchical, multicast routing etc




On Wed, 30 Sep 1998, Lloyd Wood wrote:

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

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

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

Well, if $link cost isn't called to set link costs, all the links are
automatically set to cost 1. I.e., the routes are shotest in hop count.

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

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

-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<[email protected]>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>