Bug 388

Summary: document how to apply fuzz to models
Product: ns-3 Reporter: Tom Henderson <tomh>
Component: documentationAssignee: Tom Henderson <tomh>
Status: NEW ---    
Severity: normal CC: mathieu.lacage, ns-bugs
Priority: P3    
Version: ns-3-dev   
Hardware: All   
OS: All   

Description Tom Henderson 2008-10-23 00:32:14 UTC 
I agreed to document an idiom on how to apply fuzz where needed.


From Craig's writeup of WONTFIX bug 255:

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?
Comment 1 Tom Henderson 2008-10-30 16:35:31 UTC 
Testing email hook (bug touch)--- please ignore
Comment 2 Tom Henderson 2008-10-30 16:45:57 UTC 
another test of email hook-please ignore
Comment 3 Mathieu Lacage 2009-01-10 13:37:31 UTC 
How about implementing the following trivial API ?

class ApplicationContainer
{
public:
  void Start (RandomVariable &v);
};

app.Start (UniformVariable (0.9, 1.1));

There are lots of refinements which could be done on top of this basic idea but it seems to me that this would solve a lot of the use-cases we discussed in the past.
Comment 4 Tom Henderson 2009-01-10 21:42:44 UTC 
(In reply to comment #3)
> How about implementing the following trivial API ?
> 
> class ApplicationContainer
> {
> public:
>   void Start (RandomVariable &v);
> };
> 
> app.Start (UniformVariable (0.9, 1.1));
> 
> There are lots of refinements which could be done on top of this basic idea but
> it seems to me that this would solve a lot of the use-cases we discussed in the
> past.
> 

This is probably too limiting:
- more than "start time" is needed (mainly, timeouts)
- more than applications need to be covered (e.g. devices, operating systems, etc.)

I was thinking, maybe move timer.cc,h to src/core and add

Timer::SetFuzz (RandomVariable var);

plus, a documented suggestion for users to know how to insert fuzz time between function calls, such as e.g.
  Simulator::Schedule (UniformVariable::GetSingleValue (),
                       &function, this, arg1, arg2, ...);

(or whatever UniformVariable::GetSingleValue () equivalent is with the new random variable API).  

Application::Start () and application containers could have starting time fuzz too, like you suggest.
Comment 5 Mathieu Lacage 2009-01-11 02:06:40 UTC 
(In reply to comment #4)

> I was thinking, maybe move timer.cc,h to src/core and add
> 
> Timer::SetFuzz (RandomVariable var);

you can't move it to core because it depends on the simulator API and core does not depend on simulator: it is the other way around.

> 
> plus, a documented suggestion for users to know how to insert fuzz time between
> function calls, such as e.g.
>   Simulator::Schedule (UniformVariable::GetSingleValue (),
>                        &function, this, arg1, arg2, ...);

ok.

> 
> (or whatever UniformVariable::GetSingleValue () equivalent is with the new
> random variable API).  
> 
> Application::Start () and application containers could have starting time fuzz
> too, like you suggest.


My point, though, is that most other timers are synchronized on the first data packet going down the stack due to some implementation details so, if you do the application-level fuzz, you will get 90% of the solution in the current codebase. i.e., it's a cheap way to make decent progress.