[Ns-developers] tag rework for next release

Mathieu Lacage mathieu.lacage at sophia.inria.fr
Wed Jun 3 23:47:24 PDT 2009


On Wed, 2009-06-03 at 23:01 -0700, Tom Henderson wrote:

> >> One thing that I noticed is that packet tags are left out of the 
> >> Packet::Serialize() process (while byte tags are included).  This is a 
> >> bit subtle, but it basically means that packets that are sent to another 
> >> node via an ns-3 channel will retain packet tags but if that ns-3 
> >> channel happens to utilize a real IP tunnel (in a distributed simulation 
> >> use case) the packet tags will be stripped.

The ns-3-tags code does not serialize _any_ tag (byte or packet) for now
which is a deficiency but which is not a problem for now because no one
is doing a distributed simulation (for now).

> >>
> >> It seems like we ought to support packet tags in Serialize, but is there 
> >> a reason why not?
> > 
> > Lazyness: I can fix this late next week but feel free to beat me to it.
> 
> What is the status of serializing tags?  I see this in the code:

I did not see the point of trying to address a problem which already
exists in ns-3-dev. Filing a bug about this separate issue to track it
seems like the right thing to do. See bug 582.

>    // write tags
>    //XXX
>    //reserve = m_tags.GetSerializedSize ();
>    //buffer.AddAtStart (reserve);
>    //m_tags.Serialize (buffer.Begin (), reserve);
> 
>    // aggregate byte buffer, metadata, and tags
>    Buffer tmp = m_buffer.CreateFullCopy ();
>    tmp.AddAtEnd (buffer);
> 
> 
> > 
> >> We ought to document somewhere the interaction between application-level 
> >> tags and NSC, while this is not yet fixed for NSC.
> > 
> > I doubt it will ever be really fixed in nsc.
> 
> this would be nice to document somewhere in NSC, tracker, and/or manual. 
>    If a packet enters an nsc stack with tags, should some log message be 
> raised?  Do you have a suggestion on how to document this?

It sounds like a bad idea to generate a log message but the nsc
documentation/manual should mention this.

> >> Also, in udp-echo-server.cc:
> >>
> >>             NS_LOG_INFO ("Received " << packet->GetSize() << " bytes 
> >> from " <<
> >>               address.GetIpv4());
> >>
> >> -          packet->RemoveAllTags ();
> >> +          packet->RemoveAllPacketTags ();
> >>
> >>             NS_LOG_LOGIC ("Echoing packet");
> >>             socket->SendTo (packet, 0, from);
> >>
> >>
> >> Why not remove all byte tags also?  Conceptually, this is a new packet 
> >> that is being echoed; i.e., it should behave the same as if the packet 
> >> were freed and a new one generated.
> > 
> > Yes, this makes sense.
> 
> the above still needs fixed.

done.

> also:
> 
> \packetperf Doxygen is stale; it would be nice also to include some 
> brief comment about the performance implication of enabling metadata, 
> and the two different types of tags
> 
> There is a distinction between packet and byte tags in terms of removal 
> that could be more explicit in the doxygen.  Namely, packet tags can be 
> removed one-by-one, while byte tags must all be removed.  So, maybe 
> document that byte tags are assumed to have a lifetime of a packet and 
> not removed until the packet is conceptually freed, while packet tags 
> added somewhere should be removed by the consumer of the tag (such as a 
> cross-layer tag internal to a node that should be stripped before 
> sending on an ns-3 channel).

done.

thanks for the review,

Mathieu



More information about the Ns-developers mailing list