Frequently Asked Questions about
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?
- 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.
- 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.
- 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.
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:
- "Fast timer" code. In order to get fine enough granularity in
the timer for reasonably precise delay emulation, the timer chip is
reprogrammed to interrupt at a faster rate. In order not to affect
kernel code which relies on the normal rate, the interrupt handler
was somewhat reworked. This would have been rather difficult to do
outside this code.
- Network interface export. Not all the kernel network code
interfaces needed by the emulator were exported, for some reason.
There was also no interface to find existing packet handlers, for
cases (like this one) where we want to supplement, not replace,
the existing handler.
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.
[
Home Page]
[Installing NISTNet]
[Using NISTNet]
[NISTNet FAQ]