diff -r 9e060dd421fa doc/tutorial/building-topologies.texi --- a/doc/tutorial/building-topologies.texi Thu Apr 08 23:01:34 2010 +0900 +++ b/doc/tutorial/building-topologies.texi Fri Apr 09 17:27:35 2010 -0700 @@ -694,6 +694,99 @@ @end verbatim @c ======================================================================== +@c Models, Attributes and Reality +@c ======================================================================== +@node Models, Attributes and Reality +@section Models, Attributes and Reality + +This is a convenient place to make a small excursion and make an important +point. It may or may not be obvious to you, but whenever one is using a +simulation, it is important to understand exactly what is being modeled and +what is not. It is tempting, for example, to think of the CSMA devices +and channels used in the previous section as if they were real Ethernet +devices; and to expect a simulation result to directly reflect what will +happen in a real Ethernet. This is not the case. + +A model is, by definition, an abstraction of reality. It is ultimately the +responsibility of the simulation script author to determine the so-called +``range of accuracy'' and ``domain of applicability'' of the simulation as +a whole, and therefore its consitiuent parts. + +In some cases, like @code{Csma}, it can be fairly easy to determine what is +@emph{not} modeled. By reading the model description (@code{csma.h}) you +can find that there is no collision detection in the CSMA model and decide +on how applicable its use will be in your simulation or what caveats you +may want to include with your results. In other cases, it can be quite easy +to configure behaviors that might not agree with any reality you can go out +and buy. It will prove worthwhile to spend some time investigating a few +such instances, and how easily you can swerve outside the bounds of reality +in your simulations. + +As you have seen, @command{ns-3} provides @code{Attributes} which a user +can easily set to change model behavior. Consider two of the @code{Attributes} +of the @code{CsmaNetDevice}: @code{Mtu} and @code{EncapsulationMode}. +The @code{Mtu} attribute indicates the Maximum Transmission Unit to the +device. This is the size of the largest Protocol Data Unit (PDU) that the +device can send. + +The MTU defaults to 1500 bytes in the @code{CsmaNetDevice}. This default +corresponds to a number found in RFC 894, ``A Standard for the Transmission +of IP Datagrams over Ethernet Networks.'' The number is actually derived +from the maximum packet size for 10Base5 (full-spec Ethernet) networks -- +1518 bytes. If you subtract the DIX encapsulation overhead for Ethernet +packets (18 bytes) you will end up with a maximum possible data size (MTU) +of 1500 bytes. One can also find that the @code{MTU} for IEEE 802.3 networks +is 1492 bytes. This is because LLC/SNAP encapsulation adds an extra eight +bytes of overhead to the packet. In both cases, the underlying hardware can +only send 1518 bytes, but the data size is different. + +In order to set the encapsulation mode, the @code{CsmaNetDevice} provides +an @code{Attribute} called @code{EncapsulationMode} which can take on the +values @code{Dix} or @code{Llc}. These correspond to Ethernet and LLC/SNAP +framing respectively. + +If one leaves the @code{Mtu} at 1500 bytes and changes the encapsulation mode +to @code{Llc}, the result will be a network that encapsulates 1500 byte PDUs +with LLC/SNAP framing resulting in packets of 1526 bytes, which would be +illegal in many networks, since they can transmit a maximum of 1518 bytes per +packet. This would most likely result in a simulation that quite subtly does +not reflect the reality you might be expecting. + +Just to complicate the picture, there exist jumbo frames (1500 < MTU <= 9000 bytes) +and super-jumbo (MTU > 9000 bytes) frames that are not officially sanctioned +by IEEE but are avialable in some high-speed (Gigabit) networks and NICs. One +could leave the encapsulation mode set to @code{Dix}, and set the @code{Mtu} +@code{Attribute} on a @code{CsmaNetDevice} to 64000 bytes -- even though an +associated @code{CsmaChannel DataRate} was set at 10 megabits per second. +This would essentially model an Ethernet switch made out of vampire-tapped +1980s-style 10Base5 networks that support super-jumbo datagrams. This is +certainly not something that was ever made, nor is likely to ever be made, +but it is quite easy for you to configure. + +In the previous example, you used the command line to create a simulation that +had 100 @code{Csma} nodes. You could have just as easily created a simulation +with 500 nodes. If you were actually modeling that 10Base5 vampire-tap network, +the maximum length of a full-spec Ethernet cable is 500 meters, with a minimum +tap spacing of 2.5 meters. That means there could only be 200 taps on a +real network. You could have quite easily built an illegal network in that +way as well. This may or may not result in a meaningful simulation depending +on what you are trying to model. + +Similar situations can occur in many places in @command{ns-3} and in any +simulator. For example, you may be able to position nodes in such a way that +they occupy the same space at the same time, or you may be able to configure +amplifiers or noise levels that violate the basic laws of physics. + +@command{ns-3} generally favors flexibility, and many models will allow freely +setting @code{Attributes} without trying to enforce any arbitrary consistency +or particular underlying spec. + +The thing to take home from this is that @command{ns-3} is going to provide a +super-flexible base for you to experiment with. It is up to you to understand +what you are asking the system to do and to make sure that the simulations you +create have some meaning and some connection with a reality defined by you. + +@c ======================================================================== @c Building a Wireless Network Topology @c ======================================================================== @node Building a Wireless Network Topology