Subject: Issues...

From: "M. Scott Corson" <[email-masked]>
Date: Mon, 6 Apr 1998 11:50:36 -0400 (EDT)

Folks,

First of all, I'd like to thank everyone that came and presented at the 
meeting, and I'd like to thank Eric Guttman for once again taking the 
minutes (Eric, is this the *third* time?..THANKS!).  

I think the meeting was informative, but accomplished less than hoped 
principally because there was not enough time for discussion. I'd like 
to summarize what was discussed (not presented) and possibly begin some 
discussions on the list regarding topics that I had hoped to address in 
the meeting.

Summary:

1) IP Routing Fabric:  The question was put to the group as to whether 
it was agreed that the principle reason for performing *IP-layer* 
routing in MANETs was to enable simultaneous usage of a multihop routing 
topology (or fabric) consisting of multiple physical-layer technologies.  
There was no disagreement.

2) Node Architectures:  A generic MANET addressing scheme was put forth 
which adheres to existing IP practices by labeling interfaces with IP 
addresses and permits identification of MANET routers with identifiers 
termed "Router IDs".  Along with this was presented the notion of two 
principle types of MANET routers: I) a host acting as a router and II) a 
pure router.  Associated with the notion of a type-I *host-router* is 
the issue as to whether a host IP kernel's source code must be modified 
to enable MANET operation, or whether MANET operation can be realized 
via other mechanisms not requiring kernel source code modification.  

Source code modification is a possible impediment to rapid deployment 
and usage of MANET technology regarding hosts possessing *monolithic* IP 
kernels (e.g. windows boxes) that cannot be easily modified.  It is 
clear that there are near-term limitations in using monolithic kernels, 
and this is not to say that a *wrong* long-term approach should be taken 
to enable operation in this fashion, but approaches that are consistent 
and which can operate in both modes (monolithic or custom kernels) 
appear to be advantageous from the perspective of widespread, near-term 
deployment.  Comments?

During this discussion, there was a side discussion regarding the 
usefulness of subnet address advertisement.  This issue arises when 
there may be multiple hosts attached to a MANET router and, in a 
traditional fashion, subnet-based address aggregation may be used to 
reduce routing overhead.  It is clear that there exist networking 
contexts in which this may be desirable.  Approaches which prohibit 
subnet address advertisement require full host routes to be stored for 
every host--a potentially costly approach in any non-trivial network.  
Approaches which do not prohibit subnet address advertisement may still 
use full host routes if desirable, but are not required to do so.  The 
latter approaches may require slightly more overhead (advertisement of 
one or more subnet addresses associated with a given router) on a per-
router basis, but the per-host overhead is potentially greatly reduced.  
Comments from the group?

Transport/Network/MAC-Layer Interaction: Following on the heels of 
Mario's presentation of the effect of various MAC schemes on the 
performance of TCP, there was discussion regarding the extent to which 
TCP modifications should be suggested for better operation in MANETs, or 
whether MANET operation should be tailored to specific traffic types to 
provide better support for specific transport layer protocols and 
traffic classes.  The general feeling was that modification of TCP was 
the choice of last resort, and that MANETs (and the gateways to them) 
should be tailored--to the extent possible--to support TCP and upper 
layer protocols in general.  This might involve traffic-specific 
queueing and retransmission policies.

This was as far as the discussion progressed before time ran out.  There 
are many issues that need discussion, and I would like to raise several 
of them now here:

1) Simulation Models/Contexts for Protocol Comparison

It is desirable to understand how the various proposed routing protocols 
compare with one another in terms of performance, and to know in which 
networking contexts certain approaches are preferred.  To do so, we 
first need to identify what are the networking contexts of interest to 
this group.  

Possible networking contexts are:

* small-scale, ad hoc meeting
* medium-sized, conference context
* large-scale, military context

Can people suggest others?

We also need to choose suitable values/models for each of the following 
parameters to define a context.

Some relevant parameters are:
* network size
* number of physical-layer technologies
* available bandwidth/power for each technology
* nodal degree per technology
* fraction of unidirectional links per technology
* router motion models
* traffic models/patterns
* fraction of sleeping routers
 
 Comments?  Have any significant characteristics been overlooked?

Ideally, it would be nice if everyone in the working group used the same 
simulation package.  Then individual protocol developers could code 
their protocols and distribute the models to the rest of the group for 
mutual comparison.  Short of this, significant recoding of protocols 
will be required for each simulation package.  Different participants 
seem to be using different packages: Opnet, NS2 and Maisie are the three 
of which I'm aware.  Each has strengths and weaknesses.  Maisie and 
Opnet lack detailed upper level protocol support.  Opnet also lacks a 
good wireless mobility/topology model for MANETs, and the simulations 
which have used it tend to use a fixed topology.  NS2 has great upper 
level protocol support, and may now have a good wireless 
mobility/topology model depending on what Dave has developed.  This 
makes usage of NS2 very promising as its missing ingredient--the network 
layer routing code--is what each protocol proponent can develop and 
distribute to the others.  

Dave: You mentioned in the meeting that this might be available by 
Summer.  Why not now? ;-)  If you've done what the group requires, it 
would be great to get everyone using it ASAP.

2) Security

The working group is chartered to consider network-layer security issues 
appropriate for MANETs.  These may or may not be used on top of link-
layer encryption/security techniques.  Several approaches have been 
suggested by various people:

* No security: This may be the default mode.

* Simple cleartext password: Vince refers to this as "not security but, 
rather, accident prevention."

* Keyed MD5 hashing for authentication: Essentially what is used in OSPF

* IPSEC:

* Public key-based approaches:

I'd like to solicit comments from the group regarding the 
advantages/disadvantages of the various approaches, or suggestions of 
alternative approaches.
 
3) Network/link interface
 
Presently, following IP practice, an interface can be identified simply 
by an IP address.  This is a relatively *opaque* identifier, and does 
not permit network-layer differentiation of heterogeneous physical layer 
technologies (from their external interface) for purposes of routing; 
i.e. they all appear equivalent.
 * How should this be enhanced or enriched (if at all)?
 * How can this be utilized for routing in a way that co-exists with 
existing IP kernels, or are customized kernels a prerequisite here?
 
4) Upper layer/network layer interactions
 
 Mario's presentation shed some experimental light on a fact that 
everyone probably knows already--without modification, TCP and other 
upper layer protocols may not work well in MANETs using contention-based 
MAC protocols (e.g. 802.11, Wavelan, Ricochet, etc.) unless appropriate 
measures are taken at the network layer and below to improve 
performance.

 What network-layer measures might we wish to consider for use in MANETs?
 For example, what queuing practices should be adopted?  Should these be 
traffic-specific?  Again, how much is feasible using routers based on 
monolithic IP kernels?  
 
5) Internet integration/interoperability
 
 Indirectly, the group will need to consider network-layer 
interoperability with the existing Internet when a MANET has 
connectivity via one or more MANET/Fixed Internet gateways.
 
How should we handle this?
* Mobile IP?
* DNS?
* DHCP?
* LDAP?
* SLP?

The list is long..and the combinations many.  Comments are solicited on 
a general interoperability architecture.  This group is not explicitly 
chartered to develop such an architecture, but a "best current practice" 
may in fact be realized if a coherent approach--hopefully a very 
*simple* one at first--can be implicitly developed. If needed, various 
working group members can act as ambassadors for MANET 
technology/requirements to other working groups.  However, ideally very 
few (if any) changes would be required in the existing Internet, and 
only translational gateway functionality would need to be utilized.
 
6) Architecture/addressing

Back to this again..I spent several paragraphs above describing some 
aspects of this problem.  I think it would be shortsighted to limit the 
MANET addressing architecture to advertisement of only full host 
addresses.  I think advertisement of subnets attached to MANET routers 
will be an absolute requirement in many non-trivial networking contexts.  
Some approaches may choose not to support this option, but they will be 
correspondingly limited in there range of applicability. 

There is no consensus yet as to whether the Router ID/IP addressing 
scheme should be adopted within the group, or as to how Router IDs 
should be assigned if adopted.  Any comments as to the usefulness of 
this technique, or possible RID assignment policies?

Cheers,

-Scott

---

From: Bevan Das <[email-masked]>
Date: Fri, 17 Apr 1998 09:41:17 -0500

>  Comments?  Have any significant characteristics been overlooked?

One more parameter to include:  the message size.  Both the 
absolute size (e.g. 512 bytes, 53 bytes) and the size relative
to the network size.  I.e., are messages only O(log n) size, and
hence can contain information about a few nodes?  or are messages
large enough to contain entire routes?

Also, what measures do we use to compare simulation results?  Possibilities:
* throughput
* delay
* overhead
* length of routes compared to shortest paths
* the ratio of unsuccessful route queries to overall route queries

These questions came up in our work on spine routing in ad hoc
networks,

Bevan Das
[email-masked]

---

From: Dave Johnson <[email-masked]>
Date: Sun, 19 Apr 1998 00:53:46 -0400

>...  NS2 has great upper 

Scott,

Sorry for the delay in replying -- we're planning to release our
simulation code for NS2 soon, but right now, we're working on a number
of things as fast as we can, one of which is documenting the simulator
so others besides us can install and use it, and another is actually
using the simulator :-).  We'll release the code as soon as we can,
which will be sometime in early summer, after a number of other
deadlines (and classes for this semester) are over.

For those not at the MANET meeting in Los Angeles, our extensions to
NS2 provide a detailed simulation of the physical and link layer
behavior of a wireless network, and simulate movement of nodes within
the network.  At the physical layer, we provide a realistic simulation
of factors such as free space and ground reflection propagation,
propagation delay, transmission power, antenna gain, capture, and
receiver sensitivity.  At the link layer, we simulate the complete
IEEE 802.11 wireless LAN DCF MAC protocol.  The simulator allows
programmable node mobility and communication patterns and operates on
a terrain defined by a loadable digital elevation map.

					Dave

---

From: Bora Akyol <[email-masked]>
Date: Sun, 19 Apr 1998 09:40:37 -0700

--------

Hi

Does your code also include effects such as Rayleigh and Log-normal fading?
That would be excellent.
Is your model based on the Jakes model for propagation?

Thanks

Bora

---

From: "M. Scott Corson" <[email-masked]>
Date: Mon, 20 Apr 1998 15:25:46 -0400 (EDT)

> a terrain defined by a loadable digital elevation map.

Thanks for getting back to me.

Sounds good.  *When* (and how) is the topology recomputed, and how does
this interact with the channel and node motion models?

-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

*******************************************************************************