(In reply to comment #0)
> Consider:
>    - Two applications are started at precisely t seconds;
>    - Applications generate packets that require arp at precisely the same time;
>    - LOOP:
>    - Both arp protocols schedule retransmission for precisely t+timeout
> seconds;
>    - Generated arp packets are sent at precisely t seconds;
>    - Device/channel mechanism causes arp packets to collide and be 
> discarded;
>    - At t+timeout seconds, arp protocols retry on both nodes (at precisely the
> same simulation time);
>    - t = t+timeout;
>    - goto LOOP.
> 
> The result is that ARP retransmissions happen at precisely the same time and
> collide over and over again.
> 
> Our models may be "too deterministic" in some cases.  Should models such as arp
> be configurable to add a random "fuzz" to their timeouts to simulate real
> timing uncertainties?

There are some cases where, indeed, this sort of thing is really needed (for
example, TCP timeouts might need some random fuzzing because, if you use a
500ms timeout synchronized on time zero, all nodes will be making tcp decisions
at the same time which is pretty bad).

Here, however, I see no reason to do this in ARP. The problem is simply that
the applications are fully synchronized and a user should be able to spot this
and react to it. I understand that we could avoid the problem in the first
place by adding this fuzzyness somewhere but I would argue that experienced
simulation users would find this extremely surprising in this case.

i.e., if we wanted to add some sort of fuzzyness, I would make that a
NetDevice-specific tx random delay to modelize the non-deterministic transfer
time from host memory to device memory.