rfc2041.txt

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

Network Working Group                                           B. Noble
Request for Comments: 2041                    Carnegie Mellon University
Category: Informational                                        G. Nguyen
                                      University of California, Berkeley
                                                       M. Satyanarayanan
                                              Carnegie Mellon University
                                                                 R. Katz
                                      University of California, Berkeley
                                                            October 1996


                         Mobile Network Tracing

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   Mobile networks are both poorly understood and difficult to
   experiment with.  This RFC argues that mobile network tracing
   provides both tools to improve our understanding of wireless
   channels, as well as to build realistic, repeatable testbeds for
   mobile software and systems.  The RFC is a status report on our work
   tracing mobile networks.  Our goal is to begin discussion on a
   standard format for mobile network tracing as well as a testbed for
   mobile systems research.  We present our format for collecting mobile
   network traces, and tools to produce from such traces analytical
   models of mobile network behavior.

   We also describe a set of tools to provide network modulation based
   on collected traces.  Modulation allows the emulation of wireless
   channel latency, bandwidth, loss, and error rates on private, wired
   networks.  This allows system designers to test systems in a
   realistic yet repeatable manner.














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


1. Introduction

   How does one accurately capture and reproduce the observed behavior
   of a network?  This is an especially challenging problem in mobile
   computing because the network quality experienced by a mobile host
   can vary dramatically over time and space.  Neither long-term average
   measures nor simple analytical models can capture the variations in
   bandwidth, latency, and signal degradation observed by such a host.
   In this RFC, we describe a solution based on network tracing.  Our
   solution consists of two phases:  trace recording and trace
   modulation.

   In the trace recording phase, an experimenter with an instrumented
   mobile host physically traverses a path of interest to him.  During
   the traversal, packets from a known workload are generated from a
   static host.  The mobile host records observations of both packets
   received from the known workload as well as the device
   characteristics during the workload.  At the end of the traversal,
   the list of observations represents an accurate trace of the observed
   network behavior for this traversal.  By performing multiple
   traversals of the same path, and by using different workloads, one
   can obtain a trace family that collectively characterizes network
   quality on that path.

   In the trace modulation phase, mobile system and application software
   is subjected to the network behavior observed in a recorded trace.
   The mobile software is run on a LAN-attached host whose kernel is
   modified to read a file containing the trace (possibly postprocessed
   for efficiency,) and to delay, drop or otherwise degrade packets in
   accordance with the behavior described by the trace.  The mobile
   software thus experiences network quality indistinguishable from that
   recorded in the trace.  It is important to note that trace modulation
   is fully transparent to mobile software --- no source or binary
   changes have to be made.

   Trace-based approaches have proved to be of great value in areas such
   as file system design [2, 10, 11] and computer architecture.  [1, 5,
   13] Similarly, we anticipate that network tracing will prove valuable
   in many aspects of mobile system design and implementation.  For
   example, detailed analyses of traces can provide insights into the
   behavior of mobile networks and validate predictive models.  As
   another example, it can play an important role in stress testing and
   debugging by providing the opportunity to reproduce the network
   conditions under which a bug was originally uncovered.  As a third
   example, it enables a system under development to be subjected to
   network conditions observed in distant real-life environments.  As a
   final example, a set of traces can be used as a benchmark family for
   evaluating and comparing the adaptive capabilities of alternative



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


   mobile system designs.

   Our goal in writing this RFC is to encourage the development of a
   widely-accepted standard format for network traces.  Such
   standardization will allow traces to be easily shared.  It will also
   foster the development and widespread use of trace-based benchmarks.
   While wireless mobile networks are the primary motivation for this
   work, we have made every effort to ensure that our work is applicable
   to other types of networks.  For example, the trace format and some
   of the tools may be valuable in analyzing and modeling ATM networks.

   The rest of this RFC is organized as follows.  We begin by examining
   the properties of wireless networks and substantiating the claim that
   it is difficult to model such networks.  Next, in Section 3, we
   describe the factors that should be taken into account in designing a
   trace format.  We present the details of a proposed trace format
   standard in Section 4.  Section 5 presents a set of tools that we
   have built for the collection, analysis and replay of traces.
   Finally, we conclude with a discussion of related and future work.

2. Modeling Wireless Networks

   Wireless channels are particularly complex to model, because of their
   inherent dependence on the physical properties of radio waves (such
   as reflections from "hard" surfaces, diffraction around corners, and
   scattering caused by small objects) and the site specific geometries
   in which the channel is formed.  They are usually modeled as a time-
   and distance-varying signal strength, capturing the statistical
   nature of the interaction among reflected radio waves.  The signal
   strength can vary by several orders of magnitude (+ or - 20-30 dB)
   within a short distance.  While there have been many efforts to
   obtain general models of radio propagation inside buildings and over
   the wide area, these efforts have yielded inherently inaccurate
   models that can vary from actual measurements by an order of
   magnitude or more.

   Signal-to-noise ratio, or SNR, is a measure of the received signal
   quality.  If the SNR is too low, the received signal will not be
   detected at the receiver, yielding bit errors and packet losses.  But
   SNR is not the only effect that can lead to losses.  Another is
   inter-symbol interference caused by delay spread, that is, the
   delayed arrival of an earlier transmitted symbol that took a
   circuitous propagation path to arrive at the receiver, thereby
   (partially) canceling out the current symbol.  Yet another problem is
   doppler shift, which causes frequency shifts in the arrived signal
   due to relative velocities of the transmitter and the receiver,
   thereby complicating the successful reception of the signal.  If
   coherent reception is being used, receiver synchronization can be



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


   lost.

   More empirically, it has been observed that wireless channels adhere
   to a two state error model.  In other words, channels are usually
   well behaved but occasionally go into a bad state in which many burst
   errors occur within a small time interval.

   Developers of network protocols and mobility algorithms must
   experiment with realistic channel parameters.  It is highly desirable
   that the wireless network be modeled in a thoroughly reproducible
   fashion.  This would allow an algorithm and its variations to be
   evaluated in a controlled and repeatable way.  Yet the above
   discussion makes it clear that whether analytical models are used or
   even actual experimentation with the network itself, the results will
   be either inaccurate or unlikely to be reproducible.  A trace-based
   approach alleviates these problems.

3. Desirable Trace Format Properties

   In designing our trace format, we have been guided by three
   principles.  First, the format should be extensible.  Second, it
   should be self-describing.  Third, traces should be easy to manage.
   This section describes how each of these principles has affected our
   design.

   Although we have found several interesting uses for network traces,
   it is certain that more will evolve over time.  As the traces are
   used in new ways, it may be necessary to add new data to the trace
   format.  Rather than force the trace format to be redesigned, we have
   structured the format to be extensible.  There is a built-in
   mechanism to add to the kinds of data that can be recorded in network
   traces.

   This extensibility is of little use if the tool set needs to change
   as the trace format is extended.  Recognizing this, we have made the
   format -- particularly the extensible portions -- self-describing.
   Thus, old versions of tools can continue to work with extended
   traces, if perhaps in a less than optimal way.

   In our experience with other tracing systems, management of trace
   files is often difficult at best.  Common problems include the need
   to manage multiple trace files as a unit, not easily being able to
   extract the salient features of large trace files, and having to use
   dedicated trace management tools to perform even the simplest tasks.
   To help cope with file management, we have designed the the traces to
   be split or merged easily.  To reduce dependence on specialized
   tools, we've chosen to store some descriptive information as ASCII
   strings, allowing minimal access to the standard UNIX tool suite.



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


4. Trace Format

   This section describes the format for network traces.  We begin by
   presenting the basic abstractions that are key to the trace format:
   the record, and the track, a collection of related records.  We then
   describe the records at the beginning and end of a trace, the header
   and footer.  The bulk of the section describes the three kinds of
   record tracks:  packet, device, and general.  These also make up the
   bulk of the actual trace.  We conclude the section with a discussion
   of two special purpose records:  the annotation and the trace data
   loss records.

4.1. Basic Abstractions

4.1.1. Records

   A record is the smallest unit of trace data.  There are several
   different types of records, each of which is discussed in Sections
   4.2 through 4.7.  All of the records share several features in
   common; these features are described here.

   Records are composed of fields, which are stored in network order.
   Most of the fields in our records are word-sized.  Although this may
   be wasteful in space, we chose to leave room to grow and keep trace
   management simple.

   The first field in each record is a magic word, a random 32 bit
   pattern that both identifies the record's type and lends some
   confidence that the record is well formed.  Many record types have
   both required and optional fields; thus they can be of variable size.
   We place every record's size in its second field.  By comparing the
   size of a record to the known constraints for the record's type, we
   can gain further confidence that a record is well-formed.  This basic
   record structure is illustrated in Figure 1.

   All records also contain a two-word timestamp.  This timestamp can
   take one of two formats:  timeval or timespec.  Only one of the two
   formats is used in any given trace, and the format is specified at
   the start of a trace file.  The first word in either format is the
   number of seconds that have elapsed since midnight, January 1, 1970.
   The second word is the additional fractions of a second.  In the
   timeval format, these fractions are expressed in microseconds, in the
   same way that many current operating systems express time.  In the
   timespec format, these fractions are expressed in nanoseconds, the
   POSIX time standard.  We've chosen these two values since they are
   convenient, cover most current and anticipated systems' notions of
   time, and offer appropriate granularity for measuring network events.




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


                          +------------------+
                          | Magic Number     |
                          | Size of Record   |
                          +------------------+
                          | Required Fields  |
                          |       ...        |
                          +------------------+
                          | Optional Fields  |
                          |       ...        |
                          +------------------+

                        Figure 1: Record format

4.1.2. Tracks

   Many of the record types have both fixed, required fields, as well as
   a set of optional fields.  It is these options that provide
   extensibility to our trace format.  However, to provide a self-