rfc2398.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 844 行 · 第 1/2 页
TXT
844 行
Network Working Group S. Parker
Request for Comments: 2398 C. Schmechel
FYI: 33 Sun Microsystems, Inc.
Category: Informational August 1998
Some Testing Tools for TCP Implementors
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
1. Introduction
Available tools for testing TCP implementations are catalogued by
this memo. Hopefully disseminating this information will encourage
those responsible for building and maintaining TCP to make the best
use of available tests. The type of testing the tool provides, the
type of tests it is capable of doing, and its availability is
enumerated. This document lists only tools which can evaluate one or
more TCP implementations, or which can privde some specific results
which describe or evaluate the TCP being tested. A number of these
tools produce time-sequence plots, see
Tim Shepard's thesis [She91] for a general discussion of these plots.
Each tools is defined as follows:
Name
The name associated with the testing tool.
Category
One or more categories of tests which the tools are capable of
providing. Categories used are: functional correctness, performance,
stress. Functional correctness tests how stringent a TCP
implementation is to the RFC specifications. Performance tests how
Parker & Schmechel Informational [Page 1]
RFC 2398 Some Testing Tools for TCP Implementors August 1998
quickly a TCP implementation can send and receive data, etc. Stress
tests how a TCP implementation is effected under high load
conditions.
Description
A description of the tools construction, and the implementation
methodology of the tests.
Automation
What steps are required to complete the test? What human
intervention is required?
Availability
How do you retrieve this tool and get more information about it?
Required Environment
Compilers, OS version, etc. required to build and/or run the
associated tool.
References
A list of publications relating to the tool, if any.
2. Tools
2.1. Dbs
Author
Yukio Murayama
Category
Performance / Stress
Description
Dbs is a tool which allows multiple data transfers to be coordinated,
and the resulting TCP behavior to be reviewed. Results are presented
as ASCII log files.
Automation
Command of execution is driven by a script file.
Parker & Schmechel Informational [Page 2]
RFC 2398 Some Testing Tools for TCP Implementors August 1998
Availability
See http://www.ai3.net/products/dbs for details of precise OS
versions supported, and for download of the source code. Current
implementation supports BSDI BSD/OS, Linux, mkLinux, SunOS, IRIX,
Ultrix, NEWS OS, HP-UX. Other environments are likely easy to add.
Required Environment
C language compiler, UNIX-style socket API support.
2.2. Dummynet
Author
Luigi Rizzo
Category
Functional Correctness / Performance
Description
Dummynet is a tool which simulates the presence of finite size
queues, bandwidth limitations, and communication delays. Dummynet
inserts between two layers of the protocol stack (in the current
implementation between TCP and IP), simulating the above effects in
an operational system. This way experiments can be done using real
protocol implementations and real applications, even running on the
same host (dummynet also intercepts communications on the loopback
interface). Reconfiguration of dummynet parameters (delay, queue
size, bandwidth) can be done on the fly by using a sysctl call. The
overhead of dummynet is extremely low.
Automation
Requires merging diff files with kernel source code. Command-line
driven through the sysctl command to modify kernel variables.
Availability
See http://www.iet.unipi.it/~luigi/research.html or e-mail Luigi
Rizzo (l.rizzo@iet.unipi.it). Source code is available for FreeBSD
2.1 and FreeBSD 2.2 (easily adaptable to other BSD-derived systems).
Required Environment
C language compiler, BSD-derived system, kernel source code.
References
[Riz97]
Parker & Schmechel Informational [Page 3]
RFC 2398 Some Testing Tools for TCP Implementors August 1998
2.3. Netperf
Author
Rick Jones
Category
Performance
Description
Single connection bandwidth or latency tests for TCP, UDP, and DLPI.
Includes provisions for CPU utilization measurement.
Automation
Requires compilation (K&R C sufficient for all but-DHISTOGRAM, may
require ANSI C in the future) if starting from source. Execution as
child of inetd requires editing of /etc/services and /etc/inetd.conf.
Scripts are provided for a quick look (snapshot_script), bulk
throughput of TCP and UDP, and latency for TCP and UDP. It is
command-line driven.
Availability
See http://www.cup.hp.com/netperf/NetperfPage.html or e-mail Rick
Jones (raj@cup.hp.com). Binaries are available here for HP/UX Irix,
Solaris, and Win32.
Required Environment
C language compiler, POSIX.1, sockets.
2.4. NIST Net
Author
Mark Carson
Category
Functional Correctness / Performance
Description
NIST Net is a network emulator. The tool is packaged as a Linux
kernel patch, a kernel module, a set of programming APIs, and
command-line and X-based user interfaces.
NIST Net works by turning the system into a "selectively bad" router
- incoming packets may be delayed, dropped, duplicated, bandwidth-
constrained, etc. Packet delays may be fixed or randomly
distributed, with loadable probability distributions. Packet loss
may be uniformly distributed (constant loss probability) or
congestion-dependent (probability of loss increases with packet queue
lengths). Explicit congestion notifications may optionally be sent
Parker & Schmechel Informational [Page 4]
RFC 2398 Some Testing Tools for TCP Implementors August 1998
in place of congestion-dependent loss.
Automation
To control the operation of the emulator, there is an interactive
user interface, a non-interactive command-line interface, and a set
of APIs. Any or all of these may be used in concert. The
interactive interface is suitable for simple, spur-of-the-moment
testing, while the command-line or APIs may be used to create
scripted, non-interactive tests.
Availability
NIST Net is available for public download from the NIST Net web site,
http://www.antd.nist.gov/itg/nistnet/. The web site also has
installation instructions and documentation.
Required Environment
NIST Net requires a Linux installtion, with kernel version 2.0.27 -
2.0.33. A kernel source tree and build tools are required to build
and install the NIST Net components. Building the X interface
requires a version of XFree86 (Current Version is 3.3.2). An
Athena-replacement widget set such as neXtaw
(http://www.inf.ufrgs.br/~kojima/nextaw/) is also desirable for an
improved user interface.
NIST Net should run on any i386-compatible machine capable of running
Linux, with one or more interfaces.
2.5. Orchestra
Author
Scott Dawson, Farnam Jahanian, and Todd Mitton
Category
Functional Correctness / Performance
Description
This tool is a library which provides the user with an ability to
build a protocol layer capable of performing fault injection on
protocols. Several fault injection layers have been built using this
library, one of which has been used to test different vendor
implementations of TCP. This is accomplished by probing the vendor
implementation from one machine containing a protocol stack that has
been instrumented with Orchestra. A connection is opened from the
vendor TCP implementation to the machine which has been instrumented.
Faults may then be injected at the Orchestra side of the connection
and the vendor TCP's response may be monitored. The most recent
version of Orchestra runs inside the X-kernel protocol stack on the
OSF MK operating system.
Parker & Schmechel Informational [Page 5]
RFC 2398 Some Testing Tools for TCP Implementors August 1998
When using Orchestra to test a protocol, the fault injection layer is
placed below the target protocol in the protocol stack. This can
either be done on one machine on the network, if protocol stacks on
the other machines cannot be modified (as in the case of testing
TCP), or can be done on all machines on the network (as in the case
of testing a protocol under development). Once the fault injection
layer is in the protocol stack, all messages sent by and destined for
the target protocol pass through it on their way to/from the network.
The Orchestra fault injection layer can manipulate these messages.
In particular, it can drop, delay, re-order, duplicate, or modify
messages. It can also introduce new messages into the system if
desired.
The actions of the Orchestra fault injection layer on each message
are determined by a script, written in Tcl. This script is
interpreted by the fault injection layer when the message enters the
layer. The script has access to the header information about the
message, and can make decisions based on header values. It can also
keep information about previous messages, counters, or any other data
which the script writer deems useful. Users of Orchestra may also
define their own actions to be taken on messages, written in C, that
may be called from the fault injection scripts.
Automation
Scripts can be specified either using a graphical user interface
which generates Tcl, or by writing Tcl directly. At this time,
post-analysis of the results of the test must also be performed by
the user. Essentially this consists of looking at a packet trace
that Orchestra generates for (in)correct behavior. Must compile and
link fault generated layer with the protocol stack.
Availability
See http://www.eecs.umich.edu/RTCL/projects/orchestra/ or e-mail
Scott Dawson (sdawson@eecs.umich.edu).
Required Environment OSF MK operating system, or X-kernel like network
architecture, or adapted to network stack.
References
[DJ94], [DJM96a], [DJM96b]
Parker & Schmechel Informational [Page 6]
RFC 2398 Some Testing Tools for TCP Implementors August 1998
2.6. Packet Shell
Author
Steve Parker and Chris Schmechel
Category
Functional Correctness / Performance
Description
An extensible Tcl/Tk based software toolset for protocol development
and testing. Tcl (Tool Command Language) is an embeddable scripting
language and Tk is a graphical user interface toolkit based on Tcl.
The Packet Shell creates Tcl commands that allow you to create,
modify, send, and receive packets on networks. The operations for
each protocol are supplied by a dynamic linked library called a
protocol library. These libraries are silently linked in from a
special directory when the Packet Shell begins execution. The current
protocol libraries are: IP, IPv6, IPv6 extensions, ICMP, ICMPv6,
Ethernet layer, data layer, file layer (snoop and tcpdump support),
socket layer, TCP, TLI.
It includes harness, which is a Tk based graphical user interface for
creating test scripts within the Packet Shell. It includes tests for
no initial slow start, and retain out of sequence data as TCP test
cases mentioned in [PADHV98].
It includes tcpgraph, which is used with a snoop or tcpdump capture
file to produce a TCP time-sequence plot using xplot.
Automation
Command-line driven through Tcl commands, or graphical user interface
models are available through the harness format.
Availability
See http://playground.sun.com/psh/ or e-mail owner-packet-
shell@sunroof.eng.sun.com.
Required Environment
Solaris 2.4 or higher. Porting required for other operating systems.
Parker & Schmechel Informational [Page 7]
RFC 2398 Some Testing Tools for TCP Implementors August 1998
2.7. Tcpanaly
Author
Vern Paxson
Category
Functional Correctness / Performance
Description
This is a tool for automatically analyzing a TCP implementation's
behavior by inspecting packet traces of the TCP's activity. It does
so through packet filter traces produced by tcpdump. It has coded
within it knowledge of a large number of TCP implementations. Using
this, it can determine whether a given trace appears consistent with
a given implementation, and, if so, exactly why the TCP chose to
transmit each packet at the time it did. If a trace is found
inconsistent with a TCP, tcpanaly either diagnoses a likely
measurement error present in the trace, or indicates exactly whether
the activity in the trace deviates from that of the TCP, which can
greatly aid in determining how the traced implementation behaves.
Tcpanaly's category is somewhat difficult to classify, since it
attempts to profile the behavior of an implementation, rather than to
explicitly test specific correctness or performance issues. However,
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?