Rmst Filter README
May 30, 2005

The code in this directory constitutes the third release of the Rmst
Filter. The Rmst filter provides guranteed delivery and fragmentation
/ reassembly of large blobs. Rmst has had limited deployment in an
actual sensor network.  It has been "tuned" to the environment in
which it was deployed (the ISI testbed). New environments may present
traffic scenerios that cause Rmst to have sub-optimal behavior. The
best way to optimize Rmst for your environment is to run the filter
with the "-d 10" command line option and capture the DiffPrint screen
output at key nodes (like sources and sinks), then analyze them and
modify the Rmst filter accordingly.

Major Caveats:

Rmst has only been tested in conjunction with the "two_phase_pull"
routing algorithm in Diffusion.

This third release has ns-2 support thanks to:
Feng Zhenhua
Clarkson University
fengz@clarkson.edu

Rmst has only been tested with a single sink.

This release is only intended to run on top of an ARQ MAC layer like
S-MAC that provides hop-by-hop repair.  Rmst "caching mode" support
(in which each node caches fragments rather than just sources and
sinks) must be configured.

Rmst has a coarse grained pacing mechanism for applications. After
sources call sendRmst, they should not send another large blob until
they get an RMST_CONT message from the filter.

Users may need to manually adjust certain parameters to tailor Rmst to
their particular environment. Down the road these parameters may
become self adjusting or adaptive. The most important are enumerated
here:

1.) If you want to run RMST in caching mode (hop by hop repair
  at the transport layer), you must modify one line of code
  in rmst_filter.cc (line 1777). The RmstFilter constructor
  sets caching_mode_ to false; you must set it to true.

2.) Refer to the Diffusion API and sample rmst application code in
  this release. You must adjust the fragment size so it does not
  exceed your network MTU. Different sensor nets have
  different MTU limitations.  Even MAC layers that do
  fragmentation/reassembly can only handle a modest sized payload.
  You must adjust fragment_size such that the combination of all your
  attributes, packet overhead, and payload do not exceed your network
  MTU. Rmst will break up any blob that is larger than the
  fragment_size into multiple fragments.

3.) In rmst_filter.hh you will find some tunable parameters. Most
  notable is the "SEND_INTERVAL." This dictates how often packets are
  injected into the sensor network at the source.  The fragment send
  rate is not controlled by the application when sending a large
  blob. Rmst must interleave NAK responses and new packets while
  pacing the overall load that it presents to the network. This rate
  could be made adaptive given the addition of some sort of
  backpressure mechanism to diffusion.

4.) Rmst is best run over high quality paths. The paths selected by
  diffusion may be suboptimal if all nodes within transmission range
  are considered during routing. A better approach is to run diffusion
  on the EmStar stack and enable neighbor blacklisting. Please see
  the EmStar page at http://cvs.cens.ucla.edu/emstar/

Thanks,
Fred Stann
