RE: [Ans-research] (no subject)

[Scott Corson <[e-mail]>]

Xiaoyan,

I would characterize most of what you mention as 'scenario criteria', e.g.:
* number of nodes/connectivity of nodes/mobility pattern
* traffic pattern/application mixture/traffic intensity
* node energy storage constaints/CPU cycles bound
* bandwidth constraints/link layer type(s) in use
etc...

Common definitions of the above are needed to specify 'standard' scenario
test cases that can be considered during evaluations.

As regards 'black box' performance metrics, I'm thinking more of
*protocol-independent performance measures* as seen by higher layer
applications/protocols, e.g.:
* 1st and 2nd-order latency measures (delay/jitter)
* 1st and 2nd-order throughput measures (goodput/variation)
etc...

Common definitions of these metrics are also desired. These can be broken
down per traffic aggregate (in DiffServ terms) if QoS routing is considered.
These measures apply equally to reactive, proactive or hybrid algorithms.

We are looking for contributions (Internet Drafts) on both these topics and
others by interested parties.

-Scott


> -----Original Message-----
> From: Xiaoyan Hong [mailto:[e-mail]] 
> Sent: Monday, March 31, 2003 9:32 PM
> To: Joe Macker; [e-mail]
> Cc: Xiaoyan Hong; Dr Mario Gerla
> Subject: Re: [Ans-research] (no subject)
> 
> 
> Joe,
> 
> Thank you, and I agree with you on those points. Please see below.
> 
> On Mon, 31 Mar 2003, Joe Macker wrote:
> > Xiaoyan:
> >
> > First off, I think you are describing "the black box".
> > Is that what was meant by the black box criteria.?
> 
> Yes. Thank you for clarifing this.
> 
> > (I was thinking more normalized performance metrics and evaluation
> > criteria for use on black boxes)
> > ..perhaps its both...
> >
> > I added some comments below on your scenario items.
> >
> > >In terms of the "black box criteria" to be defined by the
> > >group for routing scalability, I want to share the measures
> > >that we have used in our research with LANMAR and FSR.
> > >
> > >(1) Number of active nodes. This is the classic measure. 
> As the # of
> > >nodes becomes large, some routing schemes suffer 
> increasing o/h due to
> > >the computing, storage and communication of  the routing info.
> >
> > Just a thought.
> >
> > A combination of number of nodes and average density, gives one a
> > notion of the diameter of the network.  We needed such a 
> distinguishing
> > model in a recent study of several scalability mechanisms. Some o/h
> > reduction mechanisms (scalability related) are targeted at handling
> > neighborhood density conditions, while other perhaps tackle network
> > diameter issues better. In the case where a network approach
> > automatically adjusts network density (e.g., power control) 
> and hence
> > diameter, perhaps number of nodes is enough to specify here.
> >
> Yes. I agree. Though increasing in density and network diameter both
> involve number of nodes, the number of nodes itself is not enough to
> distinguish different o/h reduction mechanisms. A combination with
> average density makes things clear.
> 
> > It may be even more complicated (non-homogenous graph densities)...
> > this can have a signficant effect on any findings?
> >
> Depending on what mechanism is in using, I think. If a mechanism works
> only good in terms of network diameter, the non-homogenous graph
> densities will affect the performance. But may not on ANY findings.
> 
> > >(2) Traffic pattern. The nature of traffic pattern (say, number of
> > >active source/destination pairs; source destination near 
> each other vs
> > >far away from each other) will have major impact on the O/H of some
> > >routing protocols. Localized traffic patterns, for example, may not
> > >require as much routing O/H as fully distributed patterns.
> >
> > Also, the type of traffic, highly bursty vs. more uniform 
> ,etc...can affect on-demand techniques, cacheing techniques, 
> overhead vs. data delivered, etc.
> >
> > >(3) Mobility. The norm is that the higher the mobility 
> (relative to a
> > >certain transmission range) the more routing effort is needed to
> > >maintain a path.
> >
> > True, there are specifics here that need further 
> discussion, like the
> > mobile (or dynamics) model.
> >
> I'd prefer models that reflect topology changes. But if we can model
> some real scenarios... Are there any real world
> mobility and connection data for MANET?
> 
> >
> 
> Regards,
> 
> Xiaoyan
> 
> 
> _______________________________________________
> Ans-research mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ans-research
> 
_______________________________________________
Ans-research mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ans-research