[Ns-developers] Importance of processing delays accounting.

[Elena Buchatskaya]

Whether models are designed with the objective of measuring
performance or analyzing behavior, it is often important to accurately
model delays associated with key actions to obtain representative
results. Common performance metrics, such as links resource
utilization and end-to-end delay of messages, are largely a function
of various delays.

Behavior of the system is also tied to delays, because timing of
communications between components may critically affect the order in
which actions are taken, and even which ones are taken. So now all
re-transmissions of broadcast packets  occur simultaneously in the
ns-3 simulator. Large number of exactly simultaneous transmissions
leads to significantly overestimated collision probability and even to
wrong protocol operation. For example, this is the place for RREQ and
RERR (in the case where there is more than one precursor) messages
when using AODV routing and leads to poor protocol performance. One
solution of this problem is jittering periodic broadcast transmissions
(as already done for AODV Hello messages). Also  applying randomness
was proposed for all packets sent in response to the reception of a
broadcast packet. For example, Kevin Peters manually added randomness
in AODV RERR transmissions for more correct AODV simulation. However,
it are a significant protocol improvements and make the implementation
not compliant with the RFC. Note that this is not only AODV issue, but
apply to all protocols which perform broadcast packet re-transmissions
and/or periodically send broadcast packets.

Generally speaking none of the ns-3 models account for processing
delays. The necessity of adding random delay in Wi-Fi module has
already been discussed (see bug 912), but I think the more general
solution is desirable. We need to model  non-deterministic processing
delays at various OSI layers. I propose to add a adjustable delay:
1) between the IP  and Wi-Fi MAC layers to accommodate the processing
time at the IP layer. This is the time needed to to look up routes in
a routing table, to recompute the checksum of the IP header as well as
the time needed to prepare the packet for further transmission.
2) between MAC and PHY layers to accommodate the processing time at
the MAC layer and time required to copy packet for kernel space to the
device.

It is also necessary to select meaningful default value of delays and
their distributions. Note that some default values for the Wi-Fi
module delay are given in bug 912 description.

I will appreciate your comments on this proposal.

--
Best regards,

Elena Buchatskaya