Explanation on Extending Simulation Time and Draining the Queue in Congested ns-3 UAN Scenarios

[Ehab Hegazy]

Dear ns-3 Experts and Colleagues,

 
I am working on performance evaluation of routing protocols in heavily congested Underwater Acoustic Network (UAN) using ns-3.42. I'm seeing end-to-end delays that are far above my configured simulation time, and I want to confirm what the simulator is doing under the hood when it comes to event scheduling and draining queues.
Simulation Set up
Scenario : 60 nodes, 15 CBR/UDP sources at the same time Channel capacity 10 kbps.
Mobility: Random Waypoint with 0 seconds pause time (continuous high mobility)
Traffic Duration: Applications stop at simTime - 1.0.
Simulator Stop: Set by Simulator::Stop(Seconds(simTime)).
The Observation:
I am seeing average end-to-end delays (e.g. 600-700 seconds) bigger than my configured simTime (e.g. 500 seconds) at zero pause time and heavy congestion.
My questions are:
1-How an event loop works: If Simulator:When Stop(Seconds(500)) is called, does ns-3 strictly halt all event processing at t=500, dropping any packets remaining in MAC/IP queues? Or does the simulator implicitly advance the clock to drain pending events if the event list is not empty?
2- FlowMonitor Interaction: Is the FlowMonitor module automatically scheduling events beyond the Simulator::Stop() time to make sure all transmitted packets are included in the statistics?
3- Zero Pause Time Impact:  In high mobility scenarios (0s pause), large route rediscovery (RREQ floods) is caused by frequent route breaks. 

Is it normal for the queueing delay to make packet delivery times extend far beyond the window for generating traffic? What happens to these "late" packets in ns-3 if the simulation clock has already stopped?

My goal is to make sure that my methodology for calculating and reporting these “super-simulation” delays is scientifically sound .
Thanks for your time and insights.

--

Yours sincerely,

Ehab