[Ns-developers] release update [feedback needed]

[Mathieu Lacage]

On Wed, 2009-06-10 at 18:21 +0200, Tommaso Pecorella wrote:

> 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.

Patches to the documentation are most welcome.

>  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.

Unfortunately, there are many more use-cases where what should happen is
not as clear.

> 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.

And what happens if you re-fragment your new aggregated packet on
boundaries which do not match the original subpackets ? And then, you
re-aggregate them with other fragments, and, then, re-fragment ?

[snip]

> 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.

You can do this with 'byte' tags: you can read them all with the byte
tag iterator.

> 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.

Mathieu