rfc2041.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   incoming and outgoing packets.  With PaM, we've built a testbed that
   can repeatably, reliably mimic live systems under certain mobile
   scenarios.

   There are three main components to PaM. First, we've built a kernel
   capable of delaying, dropping, and corrupting packets to match the
   characteristics of some observed network.  Second, we've defined a
   modulation trace format to describe how such a kernel should modulate
   packets.  Third, we've built a tool to generate modulation traces
   from certain classes of raw traces collected by mobile hosts.

5.2.1. Packet Modulation

   The PaM modulation tool has been placed in the kernel between the IP
   layer and the underlying interfaces.  The tool intercepts incoming
   and outgoing packets, and may choose to drop it, corrupt it, or delay
   it.  Dropping an incoming or outgoing packet is easy, simply don't
   forward it along.  Similarly, we can corrupt a packet by flipping
   some bits in the packet before forwarding it.

   Correctly delaying a packet is slightly more complicated.  We model
   the delay a packet experiences as the time it takes the sender to put
   the packet onto the network interface plus the time it takes for the
   last byte to propagate to the receiver.  The former, the transmission
   time, is the size of the packet divided by the available bandwidth;
   the latter is latency.

   Our approach at delay modulation is simple -- we assume that the
   actual network over which packets travel is much faster and of better
   quality than the one we are trying to emulate, and can thus ignore
   it.  We delay the packet according to our latency and bandwidth
   targets, and then decide whether to drop or corrupt it.  We take care
   to ensure that packet modulation does not unduly penalize other
   system activity, using the internal system clock to schedule packets.
   Since this clock is at a large granularity compared to delay
   resolution, we try to keep the average error in scheduling to a
   minimum, rather than scheduling each packet at exactly the right
   time.



Noble, et. al.               Informational                     [Page 17]

RFC 2041                 Mobile Network Tracing             October 1996


5.2.2. Modulation Traces

   To tell the PaM kernel how the modulation parameters change over
   time, we provide it with a series of modulation-trace entries.  Each
   of these entries sets loss and corruption percentages, as well as
   network latency and inter-byte time, which is 1/bandwidth.  These
   entries are stored in a trace file, the format of which is much
   simpler than record-format traces, and is designed for efficiency in
   playback.  The format of modulation traces is shown in Figure 10.

      struct tr_rep_hdr_t {
          u_int32_t        rh_magic;
          u_int32_t        rh_size;
          u_int32_t        rh_time_fmt;         /* nsec or used */
          struct tr_time_t rh_ts;
          char             rh_date[TR_DATESZ];
          char             rh_agent[TR_NAMESZ];
          u_int32_t        rh_ip;
          u_int32_t        rh_ibt_ticks;        /* units/sec, ibt */
          u_int32_t        rh_lat_ticks;        /* units/sec, lat */
          u_int32_t        rh_loss_max;         /* max loss rate */
          u_int32_t        rh_crpt_max;         /* max corrupt rate */
          char             rh_desc[0];          /* variable size */
      };

      struct tr_rep_ent_t {
          u_int32_t         re_magic;
          struct tr_time_t  re_dur;          /* duration of entry */
          u_int32_t         re_lat;          /* latency */
          u_int32_t         re_ibt;          /* inter-byte time */
          u_int32_t         re_loss;         /* loss rate */
          u_int32_t         re_crpt;         /* corrupt rate */
      };


                   Figure 10: Modulation trace format

   Modulation traces begin with a header that is much like that found in
   record-format trace headers.  Modulation headers additionally carry
   the units in which latency and inter-byte time are expressed, and the
   maximum values for loss and corruption rates.  Individual entries
   contain the length of time for which the entry applies as well as the
   latency, inter-byte time, loss rate, and corruption rate.








Noble, et. al.               Informational                     [Page 18]

RFC 2041                 Mobile Network Tracing             October 1996


5.2.3. Trace Transformation

   How can we generate these descriptive modulation traces from the
   recorded observational traces described in Section 4?  To ensure a
   high-quality modulation trace, we limit ourselves to a very narrow
   set of source traces.  As our experience with modulation traces is
   limited, we use a simple but tunable algorithm to generate them.

   Our basic strategy for determining latency and bandwidth is tied
   closely to our model of packet delays:  delay is equal to
   transmission time plus latency.  We further assume that packets which
   traversed the network near one another in time experienced the same
   latency and bandwidth during transit.  Given this, we look for two
   packets of different size that were sent close to one another along
   the same path; from the transit times and sizes of these packets, we
   can determine the near-instantaneous bandwidth and latency of the
   end-to-end path covered by those packets.  If traced packet traffic
   contains sequence numbers, loss rates are fairly easy to calculate.
   Likewise, if the protocol is capable of marking corrupt packets,
   corruption information can be stored and then extracted from recorded
   traces.

   Using timestamped packet observations to derive network latency and
   bandwidth requires very accurate timing.  Unfortunately, the laptops
   we have on hand have clocks that drift non-negligibly.  We have
   chosen not to use protocols such as NTP [9] for two reasons.  First,
   they produce network traffic above and beyond that in the known
   traced workload.  Second, and perhaps more importantly, they can
   cause the clock to speed up or slow down during adjustment.  Such
   clock movements can play havoc with careful measurement.

   As a result, we can only depend on the timestamps of a single machine
   to determine packet transit times.  So, we use the ICMP ECHO service
   to provide workloads on traced machines; the ECHO request is
   timestamped on it's way out, and the corresponding ECHOREPLY is
   traced.  We have modified the ping program to alternate between small
   and large packets.  Traces that capture such altered ping traffic can
   then be subject to our transformation tool.

   The tool itself uses a simple sliding window scheme to generate
   modulation entries.  For each window position in the recorded trace,
   we determine the loss rate, and the average latency and bandwidth
   experienced by pairs of ICMP ECHO packets.  The size and granularity
   of the sliding window are parameters of the transformation; as we
   gain experience both in analysis and modulation of wireless traces,
   we expect to be able to recommend good window sizes.





Noble, et. al.               Informational                     [Page 19]

RFC 2041                 Mobile Network Tracing             October 1996


   Unfortunately, our wireless devices do not report corrupt packets;
   they are dropped by the hardware without operating system
   notification.  However, our modulation system will also coerce any
   such corruptions to an increased loss rate, duplicating the behavior
   in the original network.

5.3. Trace Analysis Tools

   A trace is only as useful as its processing tools.  The requirements
   for such tools tools include robustness, flexibility, and
   portability.  Having an extensible trace format places additional
   emphasis on the ability to work with future versions.  To this end,
   we provide a general processing library as a framework for users to
   easily develop customized processing tools; this library is designed
   to provide both high portability and good performance.

   In this section, we first present the trace library.  We then
   describe a set of tools for simple post-processing and preparing the
   trace for further analyses.  We conclude with a brief description of
   our analysis tools that are applied to this minimally processed data.

5.3.1. Trace Library

   The trace library provides an interface that applications can use to
   simplify interaction with network traces, including functions to
   read, write, and print trace records.  The trace reading and writing
   functions manage byte swapping as well as optional integrity checking
   of the trace as it is read or written.  The library employs a
   buffering strategy that is optimized to trace I/O. Trace printing
   facilities are provided for both debugging and parsing purposes.

5.3.2. Processing Tools

   The processing tools are generally the simplest set of tools we have
   built around the trace format.  By far the most complicated one is
   the modulation-trace transformation tool described in Section 5.2.3;
   the remainder are quite simple in comparison.  The first such tool is
   a parser that prints the content of an entire trace.  With the trace
   library, it is less than a single page of C code.  For each record,
   it prints the known data fields along with their textual names,
   followed by all the optional properties and values.

   Since many analysis tasks tend to work with records of the same type,
   an enhanced version of the parser can split the trace data by tracks
   into many files, one per track.  Each line of the output text files
   contains a time stamp followed by the integer values of all the
   optional data in a track entry; in this form traces are amenable to
   further analysis be scripts written in an interpreted language such



Noble, et. al.               Informational                     [Page 20]

RFC 2041                 Mobile Network Tracing             October 1996


   as perl.

   We have developed a small suite of tools providing simple functions
   such as listing all the track headers and changing the trace
   description as they have been needed.  With the trace library, each
   such tool is trivial to construct.

5.3.3. Analysis Tools

   Analysis tools depend greatly on the kind of information an
   experimenter wants to extract from the trace; our tools show our own
   biases in experimentation.  Most analyses derive common statistical
   descriptions of traces, or establish some correlation between the
   trace data sets.

   As early users of the trace format and collection tools, we have
   developed a few analysis tools to study the behavior of the wireless
   networks at our disposal.  We have been particularly interested in
   loss characteristics of wireless channels and their relation to
   signal quality and the position of the mobile host.  In this section,
   we briefly present some of these tools to hint at the kind of
   experimentation possible with our trace format.

   Loss characteristics are among the most interesting aspects of
   wireless networks, and certainly among the least well understood.  To
   shed light on this area, we have created tools to extract the loss
   information from collected traces; in addition to calculating the
   standard parameters such as the packet loss rate, the tool also
   derives transitional probabilities for a two-state error model.

   This has proven to be a simple yet powerful model for capturing the
   burstiness observed in wireless loss rates due to fading signals.  To
   help visualize the channel behavior in the presence of mobility, our
   tool can replay the movement of the mobile host while plotting the
   loss rate as it changes with time.  It also allows us to zoom in the
   locations along the path and obtain detailed statistics over
   arbitrary time intervals.

   Our traces can be further analyzed to understand the relationship
   between channel behavior and the signal quality.  For wireless
   devices like the NCR WaveLAN, we can easily obtain measurements of
   signal quality, signal strength, and noise level.  We have developed
   a simple statistical tool to test the correlation between measured
   signal and the loss characteristics.  Variations of this test are
   also possible using different combinations of the three signal
   measurements and the movement of the host.





Noble, et. al.               Informational                     [Page 21]

RFC 2041                 Mobile Network Tracing             October 1996


   The question of just how mobile such mobile hosts are can also be
   investigated through our traces.  Position data are provided by
   traces that either involved GPS or user-supplied positions with our
   trace collection tools.  This data is valuable for comparing and
   validating various mobility prediction algorithms.  Given adequate
   network infrastructure and good signal measurements, we can determine
   the mobile location within a region that is significantly smaller
   than the cell size.  We are developing a tool to combine position
   information and signal measurement from many traces to identify the
   "signal quality" signature for different regions inside a building.
   Once this signature database is completed and validated, it can be
   used to generate position information for other traces that contain
   only the signal quality information.

6. Related Work

   The previous work most relevant to mobile network tracing falls into
   two camps.  The first, chiefly exemplified by tcpdump [7] and the BSD
   Packet Filter, or BPF [8], collect network traffic data.  The second,
   notably Delayline [6], and the later Probe/Fault Injection Tool [4],
   and the University of Lancaster's netowrk emulator [3], provide
   network modulation similar to PaM.

   There are many systems that record network packet traffic; the de
   facto standard is tcpdump, which works in concert with a packet
   filter such as BPF. The packet filter is given a small piece of code
   that describes packets of interest, and the first several bytes of
   each packet found to be interesting is copied to a buffer for tcpdump
   to consume.  This architecture is efficient, flexible, and has
   rightly found great favor with the networking community.

   However, tcpdump cpatures only traffic data.  It records neither
   information concerning mobile networking devices nor mobile host
   location.  Rather than adding seperate software components to a host