idnits 2.17.1 draft-ietf-tcpimpl-tools-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 165 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1997) is 9782 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'DJ94' on line 407 looks like a reference -- Missing reference section? 'DJM96a' on line 412 looks like a reference -- Missing reference section? 'DJM96b' on line 417 looks like a reference -- Missing reference section? 'Pax97a' on line 422 looks like a reference -- Missing reference section? 'Pax97b' on line 426 looks like a reference -- Missing reference section? 'She91' on line 429 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Steve Parker 3 Internet Draft Chris Schmechel 4 Expiration Date: December 1997 Sun Microsystems, Inc. 5 July 1997 7 Some Testing Tools for TCP Implementors 8 10 1. Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months, and may be updated, replaced, or obsoleted by other docu- 19 ments at any time. It is inappropriate to use Internet Drafts as 20 reference material or to cite them other than as ``work in pro- 21 gress''. 23 To learn the current status of any Internet Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet 25 Drafts shadow directories on ftp.is.co.za (Africa), 26 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West 28 Coast). 30 This memo provides information for the Internet community. This 31 memo does not specify an Internet standard of any kind. Distri- 32 bution of this memo is unlimited. 34 2. Introduction 36 Available tools for testing TCP implementations are catalogued by 37 this memo. Hopefully disseminating this information will 38 encourage those responsible for building and maintaing TCP to 39 make the best use of available tests. The type of testing the 40 tool provides, the type of tests it is capable of doing, and its 41 availability is enumerated. 43 Each tools is defined as follows: 45 Name 47 The name associated with the testing tool. 49 Category 51 One or more categories of tests which the tools is capable of 52 providing. Categories used so far: functional correctness, per- 53 formance, stress. 55 Description 57 A description of the tools construction, and the implementation 58 methodology of the tests. 60 Automation 62 What steps are required to complete the test? What human inter- 63 vention is required? 65 Availability 67 How do you retrieve this tool and get more information about it? 69 Required Environment 71 Compilers, OS version, etc. required to build and/or run the 72 associated tool. 74 3. Tools 76 3.1. Netperf 78 Author 79 Rick Jones 81 Category 82 Performance 84 Description 85 Single connection bandwidth or latency tests for TCP, UDP, and 86 DLPI. Includes provisions for CPU utilization measurement. 88 Automation 89 Requires compilation (K&R C sufficient for all but -DHISTOGRAM, 90 may require ANSI C in the future) if starting from source. Execu- 91 tion as child of inetd requires editing of /etc/services and 92 /etc/inetd.conf. Scripts are provided for a quick look 93 (snapshot_script), bulk throughput of TCP and UDP, and latency 94 for TCP and UDP. It is command-line driven. 96 Availability 97 See http://www.cup.hp.com/netperf/NetperfPage.html or e-mail Rick 98 Jones (raj@hpisrdq.cup.hp.com). Binaries are available here for 99 HP/UX Irix, Solaris, and Win32. 101 Required Environment 102 C language compiler, POSIX.1, sockets. 104 3.2. Orchestra 106 Author 107 Scott Dawson, Farnam Jahanian, and Todd Mitton 109 Category 110 Functional Correctness / Performance 112 Description 113 This tool is a library which provides the user with an ability to 114 build a protocol layer capable of performing fault injection on 115 protocols. Several fault injection layers have been built using 116 this library, one of which has been used to test different vendor 117 implementations of TCP. This is accomplished by probing the ven- 118 dor implementation from one machine containing a protocol stack 119 that has been instrumented with Orchestra. A connection is 120 opened from the vendor TCP implementation to the machine which 121 has been instrumented. Faults may then be injected at the 122 Orchestra side of the connection and the vendor TCP's response 123 may be monitored. The most recent version of Orchestra runs 124 inside the X-kernel protocol stack on the OSF MK operating sys- 125 tem. 127 When using Orchestra to test a protocol, the fault injection 128 layer is placed below the target protocol in the protocol stack. 129 This can either be done on one machine on the network, if proto- 130 col stacks on the other machines cannot be modified (as in the 131 case of testing TCP), or can be done on all machines on the net- 132 work (as in the case of testing a protocol under development). 133 Once the fault injection layer is in the protocol stack, all mes- 134 sages sent by and destined for the target protocol pass through 135 it on their way to/from the network. The Orchestra fault injec- 136 tion layer can manipulate these messages. In particular, it can 137 drop, delay, re-order, duplicate, or modify messages. It can 138 also introduce new messages into the system if desired. 140 The actions of the Orchestra fault injection layer on each mes- 141 sage are determined by a script, written in Tcl. This script is 142 interpreted by the fault injection layer when the message enters 143 the layer. The script has access to the header information about 144 the message, and can make decisions based on header values. It 145 can also keep information about previous messages, counters, or 146 any other data which the script writer deems useful. Users of 147 Orchestra may also define their own actions to be taken on mes- 148 sages, written in C, that may be called from the fault injection 149 scripts. 151 Automation 152 Scripts can be specified either using a graphical user interface 153 which generates Tcl, or by writing Tcl directly. At this time, 154 post-analysis of the results of the test must also be performed 155 by the user. Essentially this consists of looking at a packet 156 trace that Orchestra generates for (in)correct behavior. Must 157 compile and link fault generated layer with the protocol stack. 159 Availability 160 See http://www.eecs.umich.edu/RTCL/projects/orchestra/ or e-mail 161 Scott Dawson (sdawson@eecs.umich.edu). 163 Required Environment 164 OSF MK operating system, or X-kernel like network architecture, 165 or adapted to network stack. 167 3.3. Packet Shell 169 Author 170 Steve Parker and Chris Schmechel 172 Category 173 Functional Correctness / Performance 175 Description 176 An extensible Tcl/Tk based software toolset for protocol develop- 177 ment and testing. Tcl (Tool Command Language) is an embeddable 178 scripting language and Tk is a graphical user interface toolkit 179 based on Tcl. The Packet Shell creates Tcl commands that allow 180 you to create, modify, send, and receive packets on networks. 181 The operations for each protocol are supplied by a dynamic linked 182 library called a protocol library. These libraries are silently 183 linked in from a special directory when the Packet Shell begins 184 execution. The current protocol libraries are: IP, IPv6, IPv6 185 extensions, ICMP, ICMPv6, Ethernet layer, data layer, file layer 186 (snoop and tcpdump support), socket layer, TCP, TLI. 188 It includes harness, which is a Tk based graphical user interface 189 for creating test scripts within the Packet Shell. It includes 190 tests for no initial slow start, and retain out of sequence data 191 as TCP test cases mentioned in Vern Paxon's first I-D. 193 It includes tcpgraph, which is used with a snoop or tcpdump cap- 194 ture file to produce a TCP time-sequence plot using xplot. 196 Automation 197 Command-line driven through Tcl commands, or graphical user 198 interface models are available through the harness format. 200 Availability 201 See http://playground.sun.com/psh/ or e-mail Steve Parker 202 (sparker@Eng.Sun.COM) or Chris Schmechel (cschmec@Eng.Sun.COM). 204 Required Environment 205 Solaris 2.4 or higher. Porting required for other operating sys- 206 tems. 208 3.4. Tcpanaly 210 Author 211 Vern Paxson 213 Category 214 Functional Correctness / Performance 216 Description 217 This is a tool for automatically analyzing a TCP implementation's 218 behavior by inspecting packet traces of the TCP's activity. It 219 does so through packet filter traces produced by tcpdump. It has 220 coded within it knowledge of a large number of TCP implementa- 221 tions. Using this, it can determine whether a given trace 222 appears consistent with a given implementation, and, if so, 223 exactly why the TCP chose to transmit each packet at the time it 224 did. If a trace is found inconsistent with a TCP, tcpanaly 225 either diagnoses a likely measurement error present in the trace, 226 or indicates exactly whether the activity in the trace deviates 227 from that of the TCP, which can greatly aid in determining how 228 the traced implementation behaves. 230 Tcpanaly's category is somewhat difficult to classify, since it 231 attempts to profile the behavior of an implementation, rather 232 than to explicitly test specific correctness or performance 233 issues. However, this profile identifies correctness and perfor- 234 mance problems. 236 Adding new implmentations of TCP behavior is possible with tcpa- 237 naly through the use of C++ classes. 239 Automation 240 Command-line driven and only the traces of the TCP sending and 241 receiving bulk data transfers are needed as input. 243 Availability 244 See Vern Paxson (vern@ee.lbl.gov). 246 Required Environment 247 C++ compiler. 249 3.5. Tcptrace 251 Author 252 Shawn Ostermann 254 Category 255 Functional Correctness / Performance 257 Description 258 This is a TCP trace file analysis tool. It reads output trace 259 files in the formats of : tcpdump, snoop, etherpeek, and netm. 261 For each connection, it keeps track of elapsed time, 262 bytes/segments sent and received, retransmissions, round trip 263 times, window advertisements, throughput, etc from simple to very 264 detailed output. 266 It can also produce three different types of graphs: 268 Time Sequence Graph (shows the segments sent and ACKs returned as 269 a function of time) 271 Instantaneous Throughput (shows the instantaneous, averaged over 272 a few segments, throughput of the connection as a function of 273 time). 275 Round Trip Times (shows the round trip times for the ACKs as a 276 function of time) 278 Automation 279 Command-line driven, and uses the xplot program to view the 280 graphs. 282 Availability 283 Source code is available, and Solaris binary along with sample 284 traces. See 285 http://jarok.cs.ohiou.edu/software/tcptrace/tcptrace.html or e- 286 mail Shawn Ostermann (ostermann@cs.ohiou.edu). 288 Required Environment 289 C compiler, Solaris, FreeBSD, NetBSD, HPUX, Linux. 291 3.6. Tracelook 293 Author 294 Greg Minshall 296 Category 297 Functional Correctness / Performance 299 Description 300 This is a Tcl/Tk program for graphically viewing the contents of 301 tcpdump trace files. 303 Automation 304 Command-line driven with a graphical user interface for the 305 graph. 307 Availability 308 See http://www.ipsilon.com/~minshall/sw/tracelook/tracelook.html 309 or e-mail Greg Minshall (minshall@ipsilon.com). 311 Required Environment 312 A modern version of awk, and Tcl/Tk (Tk version 3.6 or higher). 313 The program xgraph is required to view the graphs under X11. 315 3.7. TReno 317 Author 318 Matt Mathis and Jamshid Mahdavi 320 Category 321 Performance 323 Description 324 This is a TCP Internet throughput measurement tool based on send- 325 ing UDP or ICMP packets in patterns that are controlled at the 326 user-level so that their timing reflects what would be sent by a 327 TCP that observes proper congestion control (and implements 328 SACK). This allows it to measure throughput independent of the 329 TCP implementation of end hosts and serve as a useful platform 330 for prototyping TCP changes. 332 Automation 333 Command-line driven. No "server" is required, and it only 334 requires a single argument of the machine to run the test to. 336 Availability 337 See http://www.psc.edu/networking/treno_info.html or e-mail Matt 338 Mathis (mathis@psc.edu) or Jamshid Mahdavi (mahdavi@psc.edu). 340 Required Environment 341 C compiler, POSIX.1, raw sockets. 343 3.8. Ttcp 345 Author 346 Unknown 348 Category 349 Performance 351 Description 352 Originally written to move files around, ttcp became the classic 353 throughput benchmark or load generator, with the addition of sup- 354 port for sourcing to/from memory. It has spawned many variants, 355 recent ones include support for UDP, data pattern generation, 356 page alignment, and even alignment offset control. 358 Automation 359 Command-line driven. 361 Availability 362 See ftp://ftp.arl.mil/pub/ttcp/ or e-mail ARL (ftp@arl.mil) which 363 include the most common variants available. 365 Required Environment 366 C compiler, BSD sockets. 368 3.9. Xplot 370 Author 371 Tim Shepard 373 Category 374 Functional Correctness / Performance 376 Description 377 This is a fairly conventional graphing/plotting tool (xplot 378 itself), a script to turn tcpdump output into xplot input, and 379 some sample code to generate xplot commands to plot collected TCP 380 data. 382 Automation 383 Command-line driven with a graphical user interface for the plot. 385 Availability 386 See ftp://mercury.lcs.mit.edu/pub/shep/xplot.tar.gz or e-mail Tim 387 Shepard (shep@lcs.mit.edu). 389 Required Environment 390 C compiler, X11. 392 4. Summary 393 This draft lists all TCP tests and testing tools reported to the 394 authors as part of TCP Implementer's working group and is not 395 exhaustive. These tools have been verified as available by the 396 authors. 398 5. Security Considerations 400 This version of this memo does not discuss any security-related 401 issues though general packet manipulation and packet tracing can 402 raise significant security issues. These issues may be covered 403 in a later draft. 405 6. References 407 [DJ94] Scott Dawson and Farnam Jahanian, "Probing and Fault 408 Injection of Distributed Protocol Implementations", 409 University of Michigan Technical Report CSE-TR-217-94, 410 EECS Department. 412 [DJM96a] Scott Dawson, Farnam Jahanian, and Todd Mitton, 413 "ORCHESTRA: A Fault Injection Environment for Distri- 414 buted Systems", University of Michigan Technical Report 415 CSE-TR-318-96, EECS Department. 417 [DJM96b] Scott Dawson, Farnam Jahanian, and Todd Mitton, "Exper- 418 iments on Six Commercial TCP Implementations Using a 419 Software Fault Injection Tool", University of Michigan 420 Technical Report CSE-TR-298-96, EECS Department. 422 [Pax97a] Vern Paxson, "Automated Packet Trace Analysis of TCP 423 Implementations", ACM SIGCOMM '97, September 1997, 424 Cannes, France. 426 [Pax97b] Vern Paxson, "Known TCP Implementation Problems", 427 Internet Draft, March, 1997. 429 [She91] Tim Shepard, "TCP Packet Trace Analysis", MIT Labora- 430 tory for Computer Science MIT-LCS-TR-494, February, 431 1991. 433 7. Author's Address 435 Steve Parker 436 Sun Microsystems, Inc. 437 901 San Antonio Road, UMPK17-202 438 Palo Alto, CA 94043 439 USA 440 Phone: (415) 786-5176 441 Chris Schmechel 442 Sun Microsystems, Inc. 443 901 San Antonio Road, UMPK17-202 444 Palo Alto, CA, 94043 445 USA 446 Phone: (415) 786-4053