[Ns-developers] release update [feedback needed]

Wed Jun 10 09:21:59 PDT 2009

That's ok, thanks for the clarification.

I think this should be highlighted in the documentation, as from the  
user point of view the packets have their tags simply lost. From the  
application-level point of view, there is no knowledge (nor it should  
be) that in some point in the network a device did some form of  
aggregation/deaggregation, thus it could be seen as an unexpected and  
unreliable behaviour.

 From an architectural point of view, I perfectly agree with you. The  
aggregate packet should not have any of the subpackets' packet tags.  
I'd say that even the tags of the first one should not be propagated  
to the aggregate packet.

On the other hand, the de-aggregated packets are (should be) exact  
copies of the original packets, thus with all the packet tags back in  
place.

If you ask me, I'd say that the PacketTags should be saved as  
belonging to a specific aggregated packet and re-added during the  
deaggregation. This would be more consistent, and it would allow to:

1) free the aggregated packet from the hassle of the PacketTags of it  
subpackets. They're private and not even accessible. IF the  
aggregation function needs/wants to tag the aggregated packet in some  
way, it should be its responsibility to mark the aggregated packet in  
some way. The PacketTag would be lost anyway during the deaggregation,  
as the aggregated packet is no more.

2) maintain the subpacket's PacketTags when the packets are  
deaggregated back to their original form.

Note that it is totally unneeded to be able to peek a subpacket  
PacketTag from an aggregate packet. As you noted, the aggregated  
packet and its subpackets are different entities and should not share  
tags.

Anyway, this is an architectural/design point. As I sai it's not  
affecting the ns-3 code right now so the only real thing is to point  
out the PacketTags behaviour during an aggregation/deaggregation in  
the documentation.

Cheers,

Tommaso Pecorella

PS: Use case - measure the packet delay in a network.

Simulation scenario: Mixed CSMA - WiFi networks

Test to carry out: check the packet delay / jitter at the receiver and  
in various points of the network.

Solution 1 [best one]: implement the RTP protocol.
Solution 2 [fastest one]: add a TimeTag corresponding to the packet  
creation time.

TimeTags are PacketTags or ByteTags ?

If they're PacketTags, they could be lost in the WiFi network part. So  
this option is a no-go.

If they're ByteTags they're not lost. However the packet creation time  
is not a "byte" related information for real, and I could be  
interested to read it in various network points regardless of the  
protocol stack implemented.

In both cases if the packets are aggregated they'll be obfuscated to  
the nodes, so there is no real need to check out the original  
TimeTags. At best I'd be interested to check out an aggregate's  
TimeTag, but that would be the time when the aggregate has been  
created. Not the time when the aggregated packets have been created.

A network node could implement just the IP stack (not the UDP) and  
still should be able to read the tag for pure simulation purposes. If  
it's a ByteTag it's not so easy to do that. BTW, in a real system I  
would had added an RTP header, so intermediate nodes needing the infos  
SHOULD had the UDP/RTP stack. But that's another point.

Best regards again,

Tommaso

On 10/giu/09, at 17:19, Mathieu Lacage wrote:

> On Wed, 2009-06-10 at 17:04 +0200, Tommaso Pecorella wrote:
>
>> New "bug" (or it's a feature, depending on the fact that it's a
>> documented behaviour).
>>
>> With the new Tags, i.e., he ByteTags and PacketTags, an odd behaviour
>> can be seen. BTW, I really like the differentiation between the two
>> tag types.
>>
>> ByteTags: all works as expected. Better, I haven't found any odd
>> behaviour.
>>
>> PacketTags: when you aggregate/deaggregate a bunch of packets, the
>> respective PacketTags are lost. On the opposite ByteTags are  
>> preserved.
>> The aggregation/deaggregation happens for example using 802.11 AMSDU.
>> I'm not totally keen about considering this the intended behaviour,
>> but again it's a matter of knowledge.
>
> It's the intended behavior. If you think about it, there is simply no
> other possible behavior. These are _packet_ tags and there can be only
> one tag of a given type within a packet so, if you have two packets  
> and
> you aggregate them with AddAtEnd, you cannot merge their packet tags
> because, bad things would happen if both had the same types of packet
> tags with different values in them: which one do you pick ? Right now,
> we keep only the tags from the first packet on the basis that the  
> other
> behaviors are very marginally 'better' so, we pick the easiest  
> solution
> to implement.
>
>> Seriously, I'd consider this as a bug. I couldn't yet verify if the
>> tags are lost during the aggregation or the deaggregation, but it's a
>> matter of finding some time to hack a simulation code I have.
>>
>> Anyway, this is the actual behaviour. Right now it's not affecting
>> anything but the seldom used PacketTags. On the other hand it  
>> severely
>> limits the usefulness of the PacketTag itself.
>
> Packet tags should not be used when packets are expected to be
> assembled/reassembled (fragmentation works fine).
>
>> I'll send a full bug report as soon as I'll have some time to track
>> down the exact point where the tags are wiped out, even tho it might
>> be needed to fix both the Packet::AddAtEnd (used in the aggregation
>> process) and the MsduAggregator::Deaggregate.
>
> I can save you time: AddAtEnd is where the tags are "dropped" but it's
> unlikely that the algorithm implemented in there to "merge" tags from
> two packets will change unless you have a clear usecase with an
> implementable solution which provides a major improvement in terms of
> user-visible behavior.
>
> Mathieu
>

--------------------------------------------------------------

The nice thing about standards is that there are so many to choose from.
And if you really don't like all the standards you just have to wait  
another year until the one arises you are looking for.
-- A. Tanenbaum, "Introduction to Computer Networks"

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Elettronica e Telecomunicazioni
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: tommaso.pecorella at unifi.it
        tommaso.pecorella at cnit.it

phone : +39-055-4796412
mobile: +39-320-4379803
fax   : +39-055-494569