Latency evaluation

[Nicola Stocco]

Hi everyone!
I'm new to ns3 and working on a project to evaluate the behavior of TCP in specific circumstances.
I need to track the average latency of the communication. With latency I mean the time between the generation of a packet to its successful reception (retransmission must be accounted for).

In my simulation I have a point-to-point link between a sender node (Tx) and a receiver node (Rx), I'm simulating a non-symmetric error-prone channel, so packets are subject to various levels of error rate while ACKs are always received successfully. I have not implemented any layer 2 models (if that makes sense). The application is a onoff-application always set to on.

My idea is to store in each packet its generation time, and upon successfully being received, I can easily evaluate their latency.
The first question is how to actually do it. Do I need to create a custom header? Or there is a simpler way to do so?

As I'm new to ns3, I want to ask you if you have a smarter idea to solve my issue or if my proposed solution is correct.

Thanks :)

[Charles Pandian]

There is no need to implement anything in this regard (I mean inside the packet header). Because it is possible to find delay, jitter, and other metrics using FlowMonitor of  ns-3. You just need to learn to use it. Thats all. Even there are more than one way to do this kind of trace analysis on ns-3.

If you need to measure something in a specific way, then learn to use the trace/callback mechanism of ns-3

FlowMonitor may show wrong Routing Layer statistics in some MANET scenarios. But (in your p2p scenario), there will not be any issue in using FlowMonitor for measuring the output parameters of a TCP flows; because basically, it is designed for that.

I have discussed several possibilities of trace analysis in this group at this link (Until now, I received no response for that post 🤔)

Charles Pandian,

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/2d3497c5-be81-4428-92a6-119eef4a0544n%40googlegroups.com.

[Nicola Stocco]

Hi,

thanks for your answer, however, I do not understand how FlowMonitor could help me. I use it to trace Delay and Throughput of the connection, but to my understanding, it isn't helpful to trace the latency as I need.
I'm opting to use CallbackFunctions to get the generation time of a packet and the reception in the packetSink, however, the problem of tracing individual packets persists. I'm going to try with either Uid of the Packet class or by inspecting the header for the SN.
If I misunderstood your previous answer or if I'm doing something wrong, please correct me.

Thank you :)

[Charles Pandian]

Packet delay is the time it takes for any single packet to arrive at the destination.

Latency is the time it takes for the first packet to arrive.
(Correct?)

So

latency  =  timeFirstRxPacket - timeFirstTxPacket;

Where 
timeFirstTxPacket: time when the first packet in the flow was transmitted;
timeFirstRxPacket: time when the first packet in the flow was received by an end node;

Refer : https://www.nsnam.org/docs/models/html/flow-monitor.html

Charles Pandian,

To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/26642522-def3-442a-8647-6fb2893c9388n%40googlegroups.com.

[Nicola Stocco]

Hello,

with latency, I'm referring to the time elapsed between the generation of a packet and its reception.

So

latency  = t_received - t_generated

And I need to evaluate the average latency of the communication.

I need this evaluation because I want to take into account the time lost due to buffering and retransmissions, and I'm not sure FlowMonitor can do that.

As of right now, I have created a CallbackFunction hooked to the "Tx" of the application and another to the "Rx" of the PacketSink, to retrieve the time of both events and consequently evaluate my metric. The problem I'm experiencing now is that the number of packets consumed by the PacketSink differs slightly (0.4%) from the number of packets generated by the application, but this solution seems promising.

[igs...@gmail.com]

 If you explore the FlowMonitor code,  On receiving a packet, it is doing the following while recording delayHistogram (check flow-monitor.cc)

    Time now = Simulator::Now();
    Time delay = (now - tracked->second.firstSeenTime);
    probe->AddPacketStats(flowId, packetSize, delay);

    FlowStats& stats = GetStatsForFlow(flowId);
    stats.delaySum += delay;
    stats.delayHistogram.AddValue(delay.GetSeconds());


so, according to this,   

delay = (now - tracked->second.firstSeenTime);

is EQUAL to your

latency  = t_received - t_generated

because 'racked->second.firstSeenTime'  will be the time of transmission of that packet for the first time.


There are different definitions given to delay and latency in different contexts.

I think, in this case, the 'delay histogram' itself is recording the latency that you are defining.

Correct me if I am wrong.

Of course, you can calculate this by your own custom method.  But I hope that the same may be possible with the Data that FlowMonitor is recording.

Anyway, anyone who knows the internals of FlowMonitor may give the correct difference between delay and latency from the perspective of data that FlowMonitor is recording.

[Nicola Stocco]

Hi,

I'm exploring more in-depth the FlowMonitor class and all the relative classes called by it.
The FlowMonitor uses probes to trace events, so the "position" of such probe in the stack alters the results of the FlowMonitor. As of right now, I'm using ipv4-flow-probe, that is connected to the "Ipv4L3Protocol interface of the node"(ref. ipv4-flow-probe.h), so to this probe, the .firstSeenTime does not correspond to the actual generation of the packet as this probe is logically after the critical buffer that I'm interested in monitoring (i.e. TCP buffer). The firstSeenTime should correspond to the first time the packet is passed from Layer 3 to Layer 2, so the delay evaluated by the FlowMonitor should be an e2e delay seen from Layer 3, while I need an e2e delay seen from the Application Layer.

Maybe I could create my own probe and connect it to the Application Layer, however, I'm not comfortable doing so as I'm working to a deadline and I don't think it is going to be an easy endeavor.

If there is a premade probe that does what I need please refer it to me as it would save me quite some time ahah :)

Anyway, this excursus has been an interesting opportunity to better understand Flowmonitor and ns3 as a whole.

Thank you.

[igs...@gmail.com]

Hello Nicola Stocco,

"The firstSeenTime should correspond to the first time the packet is passed from Layer 3 to Layer 2, so the delay evaluated by the FlowMonitor should be an e2e delay seen from Layer 3,"

It is an interesting finding. I am appreciating it. 👍

So, for the exact calculation of latency at the application layer, you should use your own trace/callback mechanism.

Charles Pandian,