unique packet identifier in ns3

[Abdul Jabbar]

Hi,

Is there a unique packet identifier in ns3? If so, how do we trace it?
I want to calculate instantaneous delay and throughput for udp based
simulations. I understand that in certain cases, there might a
combination of attributes that can be used to identify packets. For
example, if I use UDP with wifi, the MAC SeqNumber along with source
and destination IP address can identify a packet uniquely. But what
about the case where UDP is being used with point-to-point links?

Thanks,
Abdul.

[Mathieu Lacage]

You can:
1) hook in your traffic-generator's Tx event
2) add a 'tag' which contains a unique id to each packet from the Tx
event
3) hook in your receiver's Rx trace event (or in any other trace
event)
4) lookup the relevant tag and print its uniqueid.

Here is a rough outline of how the above could be done:

static UniquePacketIdManager g_manager;

static void TxHook (std::string path, Ptr<const Packet> p)
{
g_manager.Set (p);
}

static void RxHook (std::string path, Ptr<const Packet> p)
{
NS_ASSERT (g_manager.Has (p));
UniqueId uid = g_manager.Get (p);
std::cout << uid.packetId << std::endl;
// or, p->PrintTags (std::cout);
}

int main (int argc, char *argv[])
{

g_manager = UniquePacketIdManager (1);

Config::Connect ("/NodeList/x1/ApplicationList/y1/Tx", MakeCallback (&TxHook));

Config::Connect ("/NodeList/x2/ApplicationList/y2/Rx", MakeCallback (&RxHook));

}

I hope that the above helps,
Mathieu

[Gustavo Carneiro]

2008/10/15 Mathieu Lacage <mathieu...@sophia.inria.fr>

On Tue, 2008-10-14 at 17:37 -0500, Abdul Jabbar wrote:
> Hi,
>
> Is there a unique packet identifier in ns3? If so, how do we trace it?
> I want to calculate instantaneous delay and throughput for udp based
> simulations. I understand that in certain cases, there might a
> combination of attributes that can be used to identify packets. For
> example, if I use UDP with wifi, the MAC SeqNumber along with source
> and destination IP address can identify a packet uniquely. But what
> about the case where UDP is being used with point-to-point links?

You can:
 1) hook in your traffic-generator's Tx event
 2) add a 'tag' which contains a unique id to each packet from the Tx
event
 3) hook in your receiver's Rx trace event (or in any other trace
event)
 4) lookup the relevant tag and print its uniqueid.

I am surprised by this answer.  I would have guessed packet->GetUid () is all what Abdul would need...
 

--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

[Mathieu Lacage]

On Wed, 2008-10-15 at 11:20 +0100, Gustavo Carneiro wrote:

>
> I am surprised by this answer. I would have guessed packet->GetUid ()
> is all what Abdul would need...

I think you caught me over-engineering this: you are right.

Mathieu
>

[Abdul Jabbar]

So, it appears that the consensus is that ns3 already uses a unique
packet id, Uid. I guess this implies that all traffic sources use it
and any future user defined applications based on packet class will
use it. Please correct me if I am wrong.

Secondly, I would still need to trace this Uid every time a packet is
transmitted, received, forwarded or dropped. Would you suggest an
optimal way to achieve this? Hook in to the respective trace events?

Thanks,
Abdul.

[Gustavo Carneiro]

2008/10/15 Abdul Jabbar <jab...@gmail.com>

So, it appears that the consensus is that ns3 already uses a unique
packet id, Uid. I guess this implies that all traffic sources use it
and any future user defined applications based on packet class will
use it. Please correct me if I am wrong.

A new Uid generated for each packet that is created in the system, so applications don't even need to know anything about UIDs, it just works.

One thing that may muddy or invalidate these matters is when packets are aggregated or fragmented somewhere in the stack, such as:

  1- IPv4 fragmentation when transmitting packets larger than the device MTU;

  2- Multiple small packets sent by an application to a TCP socket, which the TCP socket then may potentially aggregate in a smaller number of outgoing packets;

However, if you get the UIDs at the netdevice layer (Tx or TxQueue/Dequeue trace events), you should not be affected by those problems.
 

Secondly, I would still need to trace this Uid every time a packet is
transmitted, received, forwarded or dropped. Would you suggest an
optimal way to achieve this? Hook in to the respective trace events?

Exactly.
 

Thanks,
Abdul.

On Oct 15, 2008, at 6:04 AM, Mathieu Lacage wrote:

>
> On Wed, 2008-10-15 at 11:20 +0100, Gustavo Carneiro wrote:
>
>>
>> I am surprised by this answer.  I would have guessed packet->GetUid
>> ()
>> is all what Abdul would need...
>
> I think you caught me over-engineering this: you are right.
>
> Mathieu
>>
>
>
> >

[Abdul]

On Oct 15, 11:25 am, "Gustavo Carneiro" <gjcarne...@gmail.com> wrote:
> 2008/10/15 Abdul Jabbar <jab...@gmail.com>
>
>
>
> > So, it appears that the consensus is that ns3 already uses a unique
> > packet id, Uid. I guess this implies that all traffic sources use it
> > and any future user defined applications based on packet class will
> > use it. Please correct me if I am wrong.
>
> A new Uid generated for each packet that is created in the system, so
> applications don't even need to know anything about UIDs, it just works.

Sounds good.

>
> One thing that may muddy or invalidate these matters is when packets are
> aggregated or fragmented somewhere in the stack, such as:
>
>   1- IPv4 fragmentation when transmitting packets larger than the device
> MTU;
>
>   2- Multiple small packets sent by an application to a TCP socket, which
> the TCP socket then may potentially aggregate in a smaller number of
> outgoing packets;
>
> However, if you get the UIDs at the netdevice layer (Tx or TxQueue/Dequeue
> trace events), you should not be affected by those problems.
>

Could you clarify on when the UID is generated in the system really?
Based on what you are saying regarding
problems with ip fragmentation and tcp aggregation, it implies that
the UID is generated
when an application sends data to tcp/udp socket? Or is it generated
at the netdevice layer?

>
>
> > Secondly, I would still need to trace this Uid every time a packet is
> > transmitted, received, forwarded or dropped. Would you suggest an
> > optimal way to achieve this? Hook in to the respective trace events?
>
> Exactly.

Could this (tracing UID) be considered significant enough to be
included
in future release of ns3 by default.

[Justin P. Rohrer]

I'm working with Abdul on migrating our simulation models from ns2 to
ns3 and wanted to branch off from the unique pid discussion to a
higher level question: What is the correct way to instrument
instantaneous and average per-packet delay?

With ns2 we did this by keeping track the unique pid in the trace file
using post-processing scripts and hence the interest in getting access
to the uid again to trace it, but perhaps this is not the best
approach with ns3? We were wondering if there has been thought given
already to instrumenting delay in the network simulations, or if there
is a vision of how this would be accomplished in the future. Besides
tracing the uid we have also thought of options such as a special
application which sends timestamps in the payload or doing and icmp
implementation, but neither of these options seem ideal. We are
looking forward to others feedback on this question.

Thanks!

Justin P. Rohrer

http://www.ittc.ku.edu/~rohrej
Graduate Research Assistant
Information and Telecommunications Technology Center
The University of Kansas

[Mathieu Lacage]

On Wed, 2008-10-15 at 13:26 -0700, Abdul wrote:

> Could you clarify on when the UID is generated in the system really?
> Based on what you are saying regarding
> problems with ip fragmentation and tcp aggregation, it implies that
> the UID is generated
> when an application sends data to tcp/udp socket? Or is it generated
> at the netdevice layer?

It is generated whenever someone calls one of the non-default
constructors of the Packet class. You can trivially see in packet.cc
where m_globalUid is incremented.

Mathieu

[Mathieu Lacage]

hi,

On Wed, 2008-10-15 at 18:41 -0500, Justin P. Rohrer wrote:
> I'm working with Abdul on migrating our simulation models from ns2 to
> ns3 and wanted to branch off from the unique pid discussion to a
> higher level question: What is the correct way to instrument
> instantaneous and average per-packet delay?
>
> With ns2 we did this by keeping track the unique pid in the trace file
> using post-processing scripts and hence the interest in getting access
> to the uid again to trace it, but perhaps this is not the best
> approach with ns3? We were wondering if there has been thought given

I would hope that we can leverage the packet tag stuff I mentioned in my
first email to perform online calculations of all these metrics and
avoid post-processing.

> already to instrumenting delay in the network simulations, or if there
> is a vision of how this would be accomplished in the future. Besides
> tracing the uid we have also thought of options such as a special
> application which sends timestamps in the payload or doing and icmp

There is already some code which can be used to attach timestamps to
packets and calculate delay and jitter. See
src/contrib/delay-jitter-estimation.h

> implementation, but neither of these options seem ideal. We are

There is already an icmp implementation in a branch and I plan to submit
it for inclusion soon. It was reviewed on ns-developers a couple of
weeks ago.

Mathieu

[Yi Ling]

Hello Mathieu Lacage,

Thank you for sharing this timestamps method to calculate delay and jitter. I looked into the code and have a question. 

If the retransmission happen, does this method still work?

If it works, my understanding is the retransmission mechanism would copy all packet including the time tag. So no matter how many times re-transmit the packet, the time tag contains the original time. Am I right? 

Yi

[Tommaso Pecorella]

Post edited due to possible misunderstandings.

--------

Hi Yi,

Perhaps you didn't notice the thread date. Let me go by an example, an 11 years old kid, that at the time of Mathieu's post was probably more busy with school and games, now would be 18 and could have a family, kids, a job, and join the army. All legally.

About your question, please refer to the latest ns-3 tutorial (we're at 3.24 by the way) and check the examples/udp/udp-echo.cc example. The answer is in the code.

T.