Frequently Asked Questions about NIST Net

Well, "frequently asked" is a bit of a misnomer, since no one has actually asked any of these questions yet, and now with this information provided here, presumably no one ever will. But somehow "Might Have Been Frequently Asked Questions" sounds too awkward.

Q. What is NIST Net, and what is it for?

NIST Net is a network emulation package that runs on Linux. NIST Net allows a single Linux box set up as a router to emulate a wide variety of network conditions. This allows testing of network-adaptive protocols and applications (or those which aren't, but maybe should be) in a lab setting.

Q. What is "emulation," and how does it differ from "simulation"?

As the terms are used here, "emulation" is basically testing code inserted into a "live" implementation, allowing the live implementation to emulate (imitate) the performance characteristics of other networks. "Simulation" is a totally synthetic test environment, without a live component.

Q. What do I need to run NIST Net?

  1. A Linux 2.0.30 installation. Actually, the emulator itself should work with any 2.0 kernel, while the required kernel patches install successfully on at least 2.0.27 - 2.0.30. I have personally only installed it on Slackware distributions, but can see no reason it shouldn't work on any other distribution as well.
  2. One or more network interfaces. Typically, NIST Net is installed on a box with two Ethernet cards which is routing between two subnets. This allows it to munge all traffic flowing between the two networks. It can also be set up on an end node, to munge traffic into that node. There is no dependence on the interface type; token ring or PPP should work as well as Ethernet.
  3. An X11R6 installation, for the user interface. The interface is built on the Athena widget set, but any of the drop-in replacements should work as well. I personally use the NeXT-like libneXtaw widget set, as seen in the included screen shots.

Q. What are the machine requirements for NIST Net?

Essentially, NIST Net needs enough kernel memory to store any delayed packets, and enough processor speed such that the additional overhead it introduces doesn't skew its delay properties too noticeably. (Currently, NIST Net does not account for its own overhead in computing delay factors, under the assumption this is negligible.)

Of course, NIST Net will not improve routing performance in any way, so any machine used must be capable of handling the traffic sent through it without NIST Net installed.

As a couple of data points, NIST Net has been run successfully on a 25/50 MHz 486 with 16M of memory doing emulation on 10Mb Ethernet, and on a 200MHz Pentium with 32M of memory doing emulation on 100Mb Ethernet. Measured per-packet overhead for the first configuration was around 28 microseconds, and for the second, around 5-7 microseconds. Both values are well under the usual minimum inter-packet times on these networks, so should not have any (inherent) adverse effect on packet handling. (The emulator reports average observed overhead through the HITIOCTL_GLOBALSTATS ioctl.)

Q. Will NIST Net be ported to a 2.1 kernel, or an operating system other than Linux? How about other widget sets?

The driving force to port it to 2.1 would be to run it with IPv6. This may happen at some point. There don't seem to be any compelling reasons to port it to other operating systems or widget sets at this time. When used as a router, NIST Net emulation can affect any IP traffic from any source to any destination, regardless of their operating systems.

If you want something similar that runs on SunOS, NIST Net was partially inspired by (and retains some of the interfaces of) the hitbox emulator used by USC in testing TCP/Vegas.

Q. Why does NIST Net emulation only affect incoming traffic and not outgoing traffic?

Basically because it was easier (i.e., required less disruption of the kernel code) to do it that way. When NIST Net is used on a router, catching packets at receive time suffices to affect all traffic. This isn't true on an end node, of course, but hopefully the provided capabilities will be sufficient.

Q. Why does NIST Net implement DRD (Derivative Random Drop) instead of RED (Random Early Detection) ? Isn't RED "better" even if more complicated?

For the purposes of the emulator, any congestion-dependant packet dropping mechanism is really sufficient. The main problem with DRD in a router implementation is that an instantaneous traffic burst could lead to a large number of near-simultaneous drops, and hence correlation of the subsequent restarts, from multiple TCP connections. But since this emulator can treat any source/destination pair separately, there's no need to end up with correlated drops.

Of course, if the goal is actually to test RED or some variant thereof, it can be implemented as an "add-on" packet munger.

Q. Why are kernel patches required? Couldn't it all have been done as a kernel module?

Well, in a certain sense anything could be done as a kernel module. But there were a couple of areas where patching the base kernel seemed like the most expeditious approach, even though it did add a kernel version dependence:

Q. Tell me all that good legal stuff about copyrights and warranties.

As a U.S. government publication, so to speak, NIST Net is not copyrighted. You can do whatever you want with it, including employing its code it in whole or in part in any other package or product. You need not credit me or NIST (though not doing so would be a bit rude).

As is usual for code provided on this basis, there is absolutely no warranty of any sort. I am interested in receiving any reports of problems or requests for improvements and will try to help, but can't make any specific promises!


Comments? Questions? Mail me at mark.carson@nist.gov.
[ NIST Net Home Page] [Installing NISTNet] [Using NISTNet] [NISTNet FAQ]