Packet Annotation

Asked by Falk on 2009-12-15

Hi,

I would like to know, if there is a concept like Packet Annotation used in Click (http://read.cs.ucla.edu/click/).

The problem is, I need a lot of information about a packet that is transmitted (Start of Contention for the Packet, Transmit Power, Time of Arrival, SNR at receiver, TCP ACK or TCP DATA etc.).
The easiest solution would be to add extra information to a packet, whenever it passes a processing unit, which has access to the information or can calculate it. An then to evaluate these information at receiver side.

An other approach would be to use a virtual node (like Virtual Path Selection), which has global knowledge. But that would make it difficult to map certain information to a specific packet.

What do you think?

Regards,
Falk

Question information

Language:
English Edit question
Status:
Solved
For:
openWNS WiFiMAC Edit question
Assignee:
No assignee Edit question
Solved by:
Sebastian Max
Solved:
2009-12-16
Last query:
2009-12-16
Last reply:
2009-12-16

Hi,

if you need a concept to identify a packet on all layers (here you give
802.11 and TCP as an example) openWNS does unfortunately not have it.
According to the ISO/OSI model higher layer information is not
accessible at all to the lower layers. Only exception is the
UpperConvergence class. For Layer2 this is in framework/dllbase, for the
other layer it is in the according module directories.

If you want to probe only results for certain packets the
"CompoundContext" is what you want. It is for example used to filter
results by source MAC address. It could also be used to filter out
special packets. Unfortunately again the "mark" is only visible at the
layer where it was put in.

Greats,

Mac

Falk wrote:
> New question #94158 on openWNS WiFiMAC:
> https://answers.launchpad.net/openwns-wifimac/+question/94158
>
> Hi,
>
> I would like to know, if there is a concept like Packet Annotation used in Click (http://read.cs.ucla.edu/click/).
>
> The problem is, I need a lot of information about a packet that is transmitted (Start of Contention for the Packet, Transmit Power, Time of Arrival, SNR at receiver, TCP ACK or TCP DATA etc.).
> The easiest solution would be to add extra information to a packet, whenever it passes a processing unit, which has access to the information or can calculate it. An then to evaluate these information at receiver side.
>
> An other approach would be to use a virtual node (like Virtual Path Selection), which has global knowledge. But that would make it difficult to map certain information to a specific packet.
>
> What do you think?
>
> Regards,
> Falk
>
>
>

Falk (kingsnoopy) said : #2

You are certainly right.
Nevertheless for my evaluation I need specific information about a packet from different layers. Am I right, that a Service like the Virtual Path Selection is accessable from every node within the network?

I tried to create a Service like the VirtualPathSelectionService, but although I could compile OpenWNS I get the following error when running ./openwns-dbg in an scenario directory:

StaticFactory<wns::ldk::MSRConfigCreator wns::ldk::ManagementServiceInterface, wns::ldk::ManagementServiceInterface>> says: You tried to create a 'wifimac.efficiency.EfficiencyCalculationOverVEC' instance.
Valid choices are:

  * dll.services.management.InterferenceCache
  * wifimac.management.PERInformationBase
  * wifimac.management.ProtocolCalculator
  * wifimac.management.SINRInformationBase
  * wifimac.pathselection.PathSelectionOverVPS

Is there a codeline I missed, where such a service has be registered with the ManagementServiceInterface?
I am sure to have duplicated the VirtualPathSelectionService exactly at least in ../modules/dll/wifimac

The other possiblily would be to generate an output at different layers and modules and then use a third party tool to evaluate the different output files...
Do you have some advice where to start looking for some explanation about the probes and how to write an own?

BR,
Falk

Sebastian Max (smx-comnets) said : #3

Dear Falk,

> Nevertheless for my evaluation I need specific information about a
> packet from different layers.
One question: Do you need this specific information during the runtime
of the simulation (e.g. for dynamic optimization), or do you need it
afterwards (to analyze the behavior of the system)?

If you need the second case, the best option is certainly to use the
probing system.

In the first case, I have another question: This information - do you
need it at only at the node where it is created, or do you need it also
at other nodes?

In the first case, we have a typical "management information base
(MIB)", with the speciality that it must be accessible in different
layers. The second case is more general in the way that the MIB
additionally transmits its content (partly) to other nodes, either
virtually (in the simulator) or by control frames.

> Am I right, that a Service like the
> Virtual Path Selection is accessable from every node within the
> network?

The VPS-Service is accessible from every Layer2 from every node within
the network. In the classification above, it is the first option (access
information during runtime) and the second option (MIB with transmission
to other nodes, virtually).

There is the possibility to have services that are not only accessible
from Layer2, but from all Layers. Maciej will write something about this
later today!

> I tried to create a Service like the VirtualPathSelectionService, but
> although I could compile OpenWNS I get the following error when running
> ./openwns-dbg in an scenario directory:
[...]
> Is there a codeline I missed, where such a service has be registered with the ManagementServiceInterface?
> I am sure to have duplicated the VirtualPathSelectionService exactly at least in ../modules/dll/wifimac

I suspect that you have created all neccessary C++ code, but not the
related Python configuration. See
wifimac/PyConfig/wifimac/pathselection/PathSelection.py: VirtualPS,
VirtualPSServer
wifimac/PyConfig/wifimac/support/NodeCreator.py: function createVPS
wifimac/PyConfig/wifimac/Layer2.py: function setPahtSelectionService

I hope that's it... a second very good example (with less functionality
and thus less complexity) is the Virtual Capability Information Base of
the WiFiMAC.

> The other possiblily would be to generate an output at different
> layers and modules and then use a third party tool to evaluate the
> different output files...
Yes, but this would not be case two in the first question - no dynamic
optimization, but probing after runtime.

> Do you have some advice where to start looking for some explanation
> about the probes and how to write an own?

Maciej, your turn, please :-)

BR,
Sebastian

Sebastian Max (smx-comnets) said : #4

Dear Falk,

I just re-read your initial question :-)

> I would like to know, if there is a concept like Packet Annotation
> used in Click (http://read.cs.ucla.edu/click/).
No.

> The problem is, I need a lot of information about a packet that is
> transmitted (Start of Contention for the Packet, Transmit Power, Time
> of Arrival, SNR at receiver, TCP ACK or TCP DATA etc.). The easiest
> solution would be to add extra information to a packet, whenever it
> passes a processing unit, which has access to the information or can
> calculate it. An then to evaluate these information at receiver side.

This is definitely the way to go! The only problem is if you require
information that is not available in the layer you are working in. In
your case, this would be Layer2, where TCP ACK/DATA cannot be accessed
(there is no such thing as deep packet inspection). All other mentioned
values are available either at the transmitter or the receiver in Layer2.

For TCP ACK/DATA, Maciej might be able to help :-)

BR,
Sebastian

Falk (kingsnoopy) said : #5

Hi,

thank you!
I need those information for the calculation of the "link efficiency" only after runtime (of course an online monitoring would be nice). So I could use the Probing System to generate outputs. But like I said, the text file analysis is going to be difficult.

A central element which gathers information and generates output afterwards would be easier.

Lets assume I do not need the upper Layer Type of the Packet. How can I add information like the beginning of the Contention time to a packet at Layer2 without increasing its size?

Falk

Best Sebastian Max (smx-comnets) said : #6

Dear Falk,

> Lets assume I do not need the upper Layer Type of the Packet. How can I
> add information like the beginning of the Contention time to a packet at
> Layer2 without increasing its size?

1. Select the appropriate FU that shall include the information (DCF?).

2. Add the information field to the Command. All commands should have
three structs to order the information: local (information that is only
used by FUs in the same node), peer (information that is also used by
FUs in the peer FUN) and magic (information that is only available in
the simulator). Your information should go into magic, I suppose.

The DCF has no command (i.e. only the empty command), hence you need to
add it (currently DCF is derived from wns::ldk::fu::Plain<DCF,
wns::ldk::EmptyCommand>) and activate it when needed. See e.g the Beacon
FU in wifimac/src/management/, function periodically.

3. The size is computed by a visitor pattern that calls the function
"calculateSizes" in every FU if the FU has activated its command in the
command-pool. See e.g. the RTS/CTS or again the Beacon. If you do not
implement this function, the size will not be changed.

BR,
Sebastian

Falk (kingsnoopy) said : #7

Thanks Sebastian Max, that solved my question.

Hi,

if you still need some cross layer stuff:

There is a global registry you can use:

#include<WNS/simulator/ISimulator.hpp>

#Insert the global PacketMarkerObject (For exmaple done in
modules/dll/wimac/src/WiMAC.cpp)
wns::simulator::getRegistry()->insert("MyPacketMarker", packetMarkerObject);

#This can be done everywhere
pMO = wns::simulator::getRegistry()->find("MyPacketMarker");

Every packet has a unique birthmark (compoundPtr->getBirthmark()) that
can be used to identify it. When entering the next lower layer the
surrounding packet gets a new Birthmark. As said before the
UpperConvergence classes are the point where you can access both, the
packet received from the layer above and the new packet surrounding it
having the other packet as payload. You could think of something like:

pMO->belongsToTheSame(oldPacket->getBirthmark(), newPacket->getBirthmark());
pMO->mark(anyPacketInAnyLayer->getBirthmark());

and then for evaluation:
pMO->isMarked(anyPacketInAnyLayer->getBirthmark());

pMO must have data structures knowing which Birthmarks belong to the
same packet. Then if any Birthmark was marked, all Birthmarks of the
packet return true for isMarked.

Greats,

Mac

Falk wrote:
> Question #94158 on openWNS WiFiMAC changed:
> https://answers.launchpad.net/openwns-wifimac/+question/94158
>
> Status: Answered => Solved
>
> Falk confirmed that the question is solved:
> Thanks Sebastian Max, that solved my question.
>
>

Falk (kingsnoopy) said : #9

Hi,

thank you, that sounds interessing. I will give it a try (combination of magic information and the global registry).

There is one problem I see, namely that packets not sucessfully transmitted never reach the UpperConvergence classes.

Most probably I will come back to you...

Best Regards,
Falk

Hi,

UpperConvergence is the place to mark compounds in outgoing direction.
In incoming direction you have to look at the LowerConvergence classes
(called PhyUser in wireless layer 2). Here you see all incoming
compounds because error calculation is done later.

Greats,

Mac

Falk wrote:
> Question #94158 on openWNS WiFiMAC changed:
> https://answers.launchpad.net/openwns-wifimac/+question/94158
>
> Falk posted a new comment:
> Hi,
>
> thank you, that sounds interessing. I will give it a try (combination of
> magic information and the global registry).
>
> There is one problem I see, namely that packets not sucessfully
> transmitted never reach the UpperConvergence classes.
>
> Most probably I will come back to you...
>
> Best Regards,
> Falk
>
>