Subject: Re: Simulations & Comparisons

From: Nitin H Vaidya <[email-masked]>
Date: Tue, 22 Sep 1998 09:06:28 -0500 (CDT)

Scott:

Trying to combine two somewhat dependent metrics into
one (e.g., routing power) is an inherently hopeless effort,
although this has been attempted before in other contexts.

As you have pointed out, protocol choice is somewhat
application-specific. In any case, from an application standpoint,
are the application requirements expected to be much
different for MANET than any other networked application?

At the risk of saying something obvious ...
end-to-end throughput is important for some applications
(particularly, non-real time), and delay parameters (latency,
jitter) would also be important for others (soft real
time - read, audio/video).

I am not sure we need to prioritize throughput
over delay (or vice versa).

Best regards.

- nitin

  >> From [email-masked] Mon Sep 21 22:20:08 1998
  >> X-Authentication-Warning: manet.isr.umd.edu: corson owned process doing -bs
  >> Date: Mon, 21 Sep 1998 23:01:50 -0400 (EDT)
  >> From: "M. Scott Corson" <[email-masked]>
  >> X-Sender: [email-masked]
  >> To: MANET WG <[email-masked]>
  >> Subject: Re: Simulations & Comparisons
  >> MIME-Version: 1.0
  >> 
  >> On Mon, 21 Sep 1998, M. Scott Corson wrote:
  >> 
  >> > Routing Power rates B more highly than A due to B's relatively lesser delay.
  >> > 
  >> 
  >> On second reading, RP is not all that useful either...sigh... ;-(, 
  >> as it tries to quantify a trade-off which is inherently application-specific.
  >> 
  >> Being in a good throughput-delay trade-off cannot necessarily be indicated by 
  >> their ratio.  These two algorithms with T/D metrics
  >> 
  >> 100kbps / 1 sec = 100 (measured in Rout. Power)
  >> 10kbps / .1 sec = 100 (measured in Rout. Power)
  >> 
  >> give the same RP, but either might be better-suited for a given application
  >> depending on its throughput and delay requirements.
  >> 
  >> So...as a group, what do we want to target in terms of initial performance 
  >> trade-offs?  
  >> 
  >> Do we want to primarily maximize network-layer throughput whenever possible 
  >> (to minimize the need for end-to-end retransmissions), and secondly minimize
  >> latency?  This would seem to be better-suited for supporting 
  >> file transfer and the like.  Is that a reasonable near-term goal?  
  >> If not...what?  Should such be added to the applicability statement 
  >> for each protcoll...indicating perhaps the types of applications that 
  >> might be favored by a given approach?  
  >> 
  >> There was significant discussion concerning an applicability statment
  >> during the meeting, but very little since I posted that initial cut.
  >> Is everyone happy with the version I sent a week or so ago?
  >> 
  >> -Scott
  >> 
  >> *******************************************************************************
  >> 
  >> M. Scott Corson                                 Institute for Systems Research
  >> [email-masked]                              A.V. Williams Bldg. (115)
  >> Phone: 301-405-6630 (Rm. 2205 AVW)              University of Maryland     
  >> Fax:   301-314-8586                             College Park, MD  20742
  >> 
  >> *******************************************************************************
  >> 
  >> 
  >>

---

From: "M. Scott Corson" <[email-masked]>
Date: Tue, 22 Sep 1998 11:14:17 -0400 (EDT)

> over delay (or vice versa).

Yes, in general you're right.  I was probably thinking too near term.

I guess what I was hinting at (somewhat indirectly) is that over
certain link layers and radios, attempting to do much more than
file transfer may not be feasible right now...would it make sense
to add in the applicability statement something like...

The XYZ protocol is best-suited for usage in a BLAH, BLAH network context
defined as...________________
to support applications (or for purposes of)...______________.

This may be unnecessary, as the data latency over multiple hops may
immediately rule out many applications.  It may also be unwise, as
the performance envelope of a MANET protocol may change as link
layers evolve.

I think the intent of the applicability statement is to aid those who are
unfamiliar with the details of a given approach in understanding:
(1) the basic characteristics and mechanisms of an approach, and 
(2) its range of applicability and usefulness.  
I guess I'm wondering how closely we want to try and characterize 
the latter, as it's something of a moving target.

-Scott

---

From: Joe Macker <[email-masked]>
Date: Tue, 22 Sep 1998 15:29:10 -0400

Scott:

Clarification issue. I don't think that "file transfer" is accurate
terminology above. Do you mean a somewhat best-effort or a low complexity
forwarding services is the only thing potentially feasible in the near term?
I see file transfer as a small piece of this domain from the application
viewpoint. Are we sort of on the same page here?

Back to the previous thread, I believe that both throughput and delay are
both important basic factors and should be included in discussions.  These
measurements will of course be relevant only when including other
situational factors in the discussion (e.g., traffic model, traffic
distribution, network and mobility models used).  All the more reason we
need some consensus here on a rough set of scenarios and flight school
conditions.

>the performance envelope of a MANET protocol may change as link

I would like to see drafts contain suitability discussions based upon
network context parameters (e.g., population, density, traffic models,
mobility, bandwidth, link layer assumptions, etc). I believe you had some
good coverage of these issues in your initial draft applicability posting!

I have trouble with detailed statements of application appropriateness
since its a huge moving target and also network context dependent.
As an example, the range of real-time network audio covers huge ground from
~600 bps (highly compressed speech) to greater than 1 Mbps (uncompressed
high fidelity audio).  I also believe application designers are building
more adaptive applications for mobile networks so the classification "of
when something breaks {jitter,delay,etc}" becomes less clear.  If the
routing approach provides end-to-end delay improvements or traffic handling
advantages, I would suggest specifying these as generally as possible
relative to the network context.  Network designers can draw there own
conclusions from general performance and functional characteristics.

As an example to illustrate what I mean about application statements,
Saying the following is highly unclear to me, yet I have seen such
statements thrown around like "cheese" at a wine party.

- Protocol A is inappropriate for supporting voice applications.

Argh!?

>the latter, as it's something of a moving target.

I believe (1) and (2) is the right vision and would personally be careful
about detailed upper layer applicability for the previous reasons given
above.  The tough part here I believe is detailing the required network
context discussions so all (or at least most) of the bases are covered.

-Joe

---

From: Chip Elliott <[email-masked]>
Date: Tue, 22 Sep 1998 15:55:28 -0400

At 03:29 PM 09/22/1998 -0400, Joe Macker wrote:
>.... yet I have seen such

Joe,

Please invite us all to NRL's next wine party. I think
we'd fit right in.

-- ch.

---

From: "M. Scott Corson" <[email-masked]>
Date: Tue, 22 Sep 1998 21:35:58 -0400 (EDT)

> viewpoint. Are we sort of on the same page here?

Yeah sure...simple, low complexity forwarding services for shipping around
data over low capacity, contention-based link layers without strict time 
constraints.

> need some consensus here on a rough set of scenarios and flight school

"flight school"...now that's a technical term  :-)

Regarding scenarios...if I recall correctly, the scenario from the 
CMU paper models nodes wandering around a 1500m x 300m rectangle, 
possibly students on the CMU campus.

CMU folks...what say you?  I don't have the paper here, what it is
intended to represent?

> good coverage of these issues in your initial draft applicability posting!

Did I? ;-)  I don't recall addressing traffic models, but I wrote the
thing quickly.  Actually, I don't recall addressing half of what you mention, 
unless all of that falls under the networking context description, which I
did not break down into characteristics.  I suppose I could.

> context discussions so all (or at least most) of the bases are covered.

OK...we can specify rather exactly how a protocol works
and what characteristics it possesses (1)...no problem there.
For reasons we've both said, (2) should be probably be looser.

-Scott

---

From: Joe Macker <[email-masked]>
Date: Wed, 23 Sep 1998 09:59:13 -0400

>thing quickly.  Actually, I don't recall addressing half of what you mention,

My above statement is unclear.

More of my opinion was that the applicability statement summarize
suitability from considerations of the above (e.g., broad traffic model
simulation results,etc) and attempt to summarize characteristics and
requirements. I wouldn't want to overcomplicate the applicability statement
framework (which could quickly get out of hand), but there should be
technical meat behind any rationale provided. This rationale then gets
debated which is healthy.

-joe