How to track out of order number of bytes in TCP Rx Buffer ?

[Matt Anonyme]

Hi,

i went through the documentation and found how to track TraceSources (http://www.nsnam.org/doxygen/_trace_source_list.html) but what if there is no TraceSource ? For instance I would like to plot the number of out of order packets in TCP. I've added a member function in TcpRxBuffer which does that I believe:

uint32_t
TcpRxBuffer::OutOfOrder() const
{
  return m_size - m_availBytes;
}

but how can I track its return value ? Do I need to create an intermediate variable ? timescales should be low (in case we monitor bulk transfer out of order packets) so I am not sure a callback periodically called would be precise enough ? Any advice ?

Regards
Matt

[Konstantinos]

Hi Matt,

NS-3 is open-source project and you have the right to change any part of the code you like.

If there is no trace-source available, it is just because it was not foreseen at that time as a general requirement.

So I would recommend to create a new trace source for the value you want.

Regards,

K.

[Matt Anonyme]

It is easy enough so I will do that. Thanks

[Matt Anonyme]

In my code (based on ns3.19) I do sthg like:

===
Ptr<OutputStreamWrapper> streamRxNext = asciiTraceHelper.CreateFileStream (prefix+"_RxNext.csv");
NS_ASSERT(sock->m_rxBuffer.TraceConnect ("NextRxSequence", "NextRxSequence", MakeBoundCallback(&dumpNextTxSequence, streamRxNext)));
===
and when I launch the script:
====
1 ObjectBase:TraceConnect(): Could not find accessor for NextRxSequence
assert failed. cond="sock->m_rxBuffer.TraceConnect ("NextRxSequence", "NextRxSequence", MakeBoundCallback(&dumpNextTxSequence, streamRxAvailable))", file=../src/internet/model/mp-tcp-subflow.cc, line=1605
terminate called without an active exception
===
Any idea as to why it does not find the accessor even though it should exist see:
===
TcpRxBuffer::GetTypeId (void)
{
  static TypeId tid = TypeId ("ns3::TcpRxBuffer")
    .SetParent<Object> ()
    .AddConstructor<TcpRxBuffer> ()
    .AddTraceSource ("NextRxSequence",
                     "Next sequence number expected (RCV.NXT)",
                     MakeTraceSourceAccessor (&TcpRxBuffer::m_nextRxSeq))
===

Regards

[Nat P]

Il giorno giovedì 22 gennaio 2015 11:45:10 UTC+1, Matt Anonyme ha scritto:

In my code (based on ns3.19) I do sthg like:

===
Ptr<OutputStreamWrapper> streamRxNext = asciiTraceHelper.CreateFileStream (prefix+"_RxNext.csv");
NS_ASSERT(sock->m_rxBuffer.TraceConnect ("NextRxSequence", "NextRxSequence", MakeBoundCallback(&dumpNextTxSequence, streamRxNext)));
===
and when I launch the script:
====
1 ObjectBase:TraceConnect(): Could not find accessor for NextRxSequence
assert failed. cond="sock->m_rxBuffer.TraceConnect ("NextRxSequence", "NextRxSequence", MakeBoundCallback(&dumpNextTxSequence, streamRxAvailable))", file=../src/internet/model/mp-tcp-subflow.cc, line=1605
terminate called without an active exception
===
Any idea as to why it does not find the accessor even though it should exist see:
===
TcpRxBuffer::GetTypeId (void)
{
  static TypeId tid = TypeId ("ns3::TcpRxBuffer")
    .SetParent<Object> ()
    .AddConstructor<TcpRxBuffer> ()
    .AddTraceSource ("NextRxSequence",
                     "Next sequence number expected (RCV.NXT)",
                     MakeTraceSourceAccessor (&TcpRxBuffer::m_nextRxSeq))
===

Regards

What is the type of m_nextRxSeq ?

[Matt Anonyme]

I believe this is something available in upstream ns3:
== From TcpRxBuffer.h ==
TracedValue<SequenceNumber32> m_nextRxSeq; //!< Seqnum of the first missing byte in data (RCV.NXT)
===
I am able to Connect to other sources, but not this one :(

[Konstantinos]

Hi Matt,

When you say you are able to trace other sources, are they TCP sources, or from other classes?

Generally, for TCP you have to make sure that the TCP socket is created before you connect the trace source.

Try to schedule this connect after the socket is created.

[Matt Anonyme]

Apparently, part of the problem is that content was buffered and not flushed on program closing (would like to know why :/). If I replace my hardcoded End of Line
  *stream->GetStream() << Simulator::Now() << "," << oldSeq << "," << newSeq << "\n";
by :
  *stream->GetStream() << Simulator::Now() << "," << oldSeq << "," << newSeq << std::endl;
then it works.

I am on a linux platform

[Konstantinos]

This is a C++ thing http://stackoverflow.com/a/213977

• std::endl sends a newline character '\n' and flushes the output buffer. 
  
• '\n' sends the newline character, but does not flush the output buffer.

[Matt]

But I would expect that when closing the file, everything would be
flushed right ? I don't close the stream explicitly but ns3 should,
shouldn' it ?

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ns-3-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/ns-3-users/XJwQmd7aTzc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> ns-3-users+...@googlegroups.com.
> To post to this group, send email to ns-3-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ns-3-users.
> For more options, visit https://groups.google.com/d/optout.

[Matt Anonyme]

I still can't figure why I am not able to trace "UnackSequence":

NS_ASSERT(sock->m_txBuffer.TraceConnect ("UnackSequence", "UnackSequence", MakeBoundCallback(&dumpNextTxSequence, streamTx)));

So I ran ns3 with NS_LOG += ":TypeId" # to look for AddTraceSource
to notice that the TraceSource was never registered !!

TypeId
TcpTxBuffer::GetTypeId (void)
{
  static TypeId tid = TypeId ("ns3::TcpTxBuffer")
    .SetParent<Object> ()
    .AddConstructor<TcpTxBuffer> ()
    .AddTraceSource ("UnackSequence",
                     "First unacknowledged sequence number (SND.UNA)",
                     MakeTraceSourceAccessor (&TcpTxBuffer::m_firstByteSeq))

  ;
  return tid;
}

You've got to insert at the beginning of tcp-tx-buffer.h this line:
NS_OBJECT_ENSURE_REGISTERED (TcpTxBuffer);

but even when doing so, even though it's registered:

TypeId:TypeId(0x7fffde935b80, 202)
TypeId:TypeId(0x7fffde935ae0, ns3::TcpTxBuffer)
TypeId:AllocateUid(0x7fa223c81580, ns3::TcpTxBuffer)
TypeId:SetParent(0x7fffde935ae0, TypeId:GetName(0x7fffde9358c0)
TypeId:GetName(0x7fa223c81580, 2)
TypeId:LookupInformation(0x7fa223c81580, 2)
ns3::Object)
TypeId:SetParent(0x7fa223c81580, 274, 2)
TypeId:LookupInformation(0x7fa223c81580, 274)
TypeId:DoAddConstructor(0x7fffde935af0, 0x7fffde935a90)
TypeId:AddConstructor(0x7fa223c81580, 274, 0x7fffde935900)
TypeId:LookupInformation(0x7fa223c81580, 274)
TypeId:AddTraceSource(0x7fffde935b00, UnackSequence, First unacknowledged sequence number (SND.UNA), 0x23d0ef0)
TypeId:AddTraceSource(0x7fa223c81580, 274, UnackSequence, First unacknowledged sequence number (SND.UNA), 0x23d0ef0)
TypeId:LookupInformation(0x7fa223c81580, 274)
TypeId:HasTraceSource(0x7fa223c81580, 274, UnackSequence)
TypeId:LookupInformation(0x7fa223c81580, 274)
TypeId:LookupInformation(0x7fa223c81580, 2)
TypeId:LookupInformation(0x7fa223c81580, 3)
TypeId:LookupInformation(0x7fa223c81580, 3)
TypeId:GetParent(0x7fffde935b70)
TypeId:GetParent(0x7fa223c81580, 274)
TypeId:LookupInformation(0x7fa223c81580, 274)

when trying to connect to the tracesource:

Starting research !!
0s -1 TypeId:LookupTraceSourceByName(0x7fffde934760, UnackSequence)
0s -1 TypeId:GetTraceSourceN(0x7fffde934760)
0s -1 TypeId:GetTraceSourceN(0x7fa223c81580, 2)
0s -1 TypeId:LookupInformation(0x7fa223c81580, 2)
GetTraceSourceN ()0
0s -1 TypeId:GetTraceSourceN(0x7fffde934580)
0s -1 TypeId:GetTraceSourceN(0x7fa223c81580, 2)
0s -1 TypeId:LookupInformation(0x7fa223c81580, 2)
0s -1 TypeId:GetParent(0x7fffde934580)
0s -1 TypeId:GetParent(0x7fa223c81580, 2)
0s -1 TypeId:LookupInformation(0x7fa223c81580, 2)
0s -1 TypeId:TypeId(0x7fffde9345c0, 3)
0s -1 TypeId:GetTraceSourceN(0x7fffde934760)
0s -1 TypeId:GetTraceSourceN(0x7fa223c81580, 2)
0s -1 TypeId:LookupInformation(0x7fa223c81580, 2)
GetTraceSourceN ()0
0s -1 TypeId:GetTraceSourceN(0x7fffde934580)
0s -1 TypeId:GetTraceSourceN(0x7fa223c81580, 3)
0s -1 TypeId:LookupInformation(0x7fa223c81580, 3)
0s -1 TypeId:GetParent(0x7fffde934580)
0s -1 TypeId:GetParent(0x7fa223c81580, 3)
0s -1 TypeId:LookupInformation(0x7fa223c81580, 3)
0s -1 TypeId:TypeId(0x7fffde9345c0, 3)
-1 ObjectBase:TraceConnect(): Could not find accessor for UnackSequence
assert failed. cond="sock->m_txBuffer.TraceConnect ("UnackSequence", "UnackSequence", MakeBoundCallback(&dumpNextTxSequence, streamTx))"

if anyone has an idea ?

Cheers

> ns-3-users+unsubscribe@googlegroups.com.

[Nat P]

Il giorno venerdì 23 gennaio 2015 18:51:42 UTC+1, Matt Anonyme ha scritto:

I still can't figure why I am not able to trace "UnackSequence":

NS_ASSERT(sock->m_txBuffer.TraceConnect ("UnackSequence", "UnackSequence", MakeBoundCallback(&dumpNextTxSequence, streamTx)));

So I ran ns3 with NS_LOG += ":TypeId" # to look for AddTraceSource
to notice that the TraceSource was never registered !!

TypeId
TcpTxBuffer::GetTypeId (void)
{
  static TypeId tid = TypeId ("ns3::TcpTxBuffer")
    .SetParent<Object> ()
    .AddConstructor<TcpTxBuffer> ()
    .AddTraceSource ("UnackSequence",
                     "First unacknowledged sequence number (SND.UNA)",
                     MakeTraceSourceAccessor (&TcpTxBuffer::m_firstByteSeq))

  ;
  return tid;
}

You've got to insert at the beginning of tcp-tx-buffer.h this line:
NS_OBJECT_ENSURE_REGISTERED (TcpTxBuffer);

Filed a bug for this:
https://www.nsnam.org/bugzilla/show_bug.cgi?id=2045

 

[Tommaso Pecorella]

Fixed in ns-3-dev

Thanks,

T.

[Matt Anonyme]

Apparently, my problem stems frm tracesources being registered with the same UID, here uid 274 is used several times. Any memory of this in ns3.19 ? found nothingin bug tracker. Is it because of the way I use traceConnect ?

NS_ASSERT(sock->m_txBuffer.TraceConnect ("UnackSequence", "UnackSequence", MakeBoundCallback(&dumpNextTxSequence, streamTx)));

I will investigate :)

TypeId:SetParent(0x7fb2e5df7580, 274, 2)
TypeId:LookupInformation(0x7fb2e5df7580, 274)
TypeId:DoAddConstructor(0x7fff0549a430, 0x7fff0549a3d0)
TypeId:AddConstructor(0x7fb2e5df7580, 274, 0x7fff0549a240)
TypeId:LookupInformation(0x7fb2e5df7580, 274)
TypeId:AddTraceSource(0x7fff0549a440, NextRxSequence, Next sequence number expected (RCV.NXT), 0x6c0ed0)
TypeId:AddTraceSource(0x7fb2e5df7580, 274, NextRxSequence, Next sequence number expected (RCV.NXT), 0x6c0ed0)
TypeId:LookupInformation(0x7fb2e5df7580, 274)
TypeId:HasTraceSource(0x7fb2e5df7580, 274, NextRxSequence)
TypeId:LookupInformation(0x7fb2e5df7580, 274)
TypeId:LookupInformation(0x7fb2e5df7580, 2)
TypeId:LookupInformation(0x7fb2e5df7580, 3)
TypeId:LookupInformation(0x7fb2e5df7580, 3)
Registering NextRxSequence" with uid="274"
TypeId:AddTraceSource(0x7fff0549a450, RxTotal, Size of all packets in receive buffer , 0x6c0e60)
TypeId:AddTraceSource(0x7fb2e5df7580, 274, RxTotal, Size of all packets in receive buffer , 0x6c0e60)
TypeId:LookupInformation(0x7fb2e5df7580, 274)
TypeId:HasTraceSource(0x7fb2e5df7580, 274, RxTotal)
TypeId:LookupInformation(0x7fb2e5df7580, 274)
TypeId:LookupInformation(0x7fb2e5df7580, 2)
TypeId:LookupInformation(0x7fb2e5df7580, 3)
TypeId:LookupInformation(0x7fb2e5df7580, 3)
Registering RxTotal" with uid="274"
TypeId:AddTraceSource(0x7fff0549a460, RxAvailable, Size of all packets in receive buffer , 0x6b4ef0)
TypeId:AddTraceSource(0x7fb2e5df7580, 274, RxAvailable, Size of all packets in receive buffer , 0x6b4ef0)
TypeId:LookupInformation(0x7fb2e5df7580, 274)
TypeId:HasTraceSource(0x7fb2e5df7580, 274, RxAvailable)
TypeId:LookupInformation(0x7fb2e5df7580, 274)
TypeId:LookupInformation(0x7fb2e5df7580, 2)
TypeId:LookupInformation(0x7fb2e5df7580, 3)
TypeId:LookupInformation(0x7fb2e5df7580, 3)
Registering RxAvailable" with uid="274"
TypeId:GetParent(0x7fff0549a530)
TypeId:GetParent(0x7fb2e5df7580, 274)
TypeId:LookupInformation(0x7fb2e5df7580, 274)
TypeId:TypeId(0x7fff0549a540, 2)
TypeId:TypeId(0x7fff0549a4a0, ns3::TcpTxBuffer)
TypeId:AllocateUid(0x7fb2e5df7580, ns3::TcpTxBuffer)
TypeId:SetParent(0x7fff0549a4a0, TypeId:GetName(0x7fff0549a280)
TypeId:GetName(0x7fb2e5df7580, 2)
TypeId:LookupInformation(0x7fb2e5df7580, 2)
ns3::Object)
TypeId:SetParent(0x7fb2e5df7580, 275, 2)

[Matt Anonyme]

Nevermind, the uid is thetype identifier so it's normal it's shared.

[Matt Anonyme]

Ok I nailed it, you have to add GetInstanceTypeId member to TcpXxBuffer otherwise ns3 looks only in traceSources of Object and ofc does not find the registered trace sources.

So this fix is not enough:
http://code.nsnam.org/ns-3-dev/rev/5c9ec4cf871f

cheers.

[Tommaso Pecorella]

Hi Matt,

thanks for the heads up, but... it shouldn't be necessary !

As a matter of fact, many classes have no GetInstanceTypeId and they have working TraceSources.

Can you send us an example ?

Thanks,

T.

[Matt Anonyme]

When calling TraceConnect, you retrieve the GetInstanceTypeId () and lookup for tracing sources of the returned TypeId:

bool
ObjectBase::TraceConnect (std::string name, std::string context, const CallbackBase &cb)
{
  NS_LOG_FUNCTION (this << name << context << &cb);
  TypeId tid = GetInstanceTypeId ();
  NS_LOG_UNCOND( "GetInstanceTypeId=" << tid);
  Ptr<const TraceSourceAccessor> accessor = tid.LookupTraceSourceByName (name);
  if (accessor == 0)
    {
      NS_LOG_WARN("Could not find accessor for " << name);
      return false;
    }

  bool ok = accessor->Connect (this, context, cb);
  return ok;
}

Thus if I don't override GetInstanceTypeId in TcpRxBuffer, it looks for the TraceSources in its parent class "Object" but not the tracesources exclusive to TcpRxBuffer. I've not executed the code step by step but when overriding GetInstanceTypeId, TraceConnect finds my source, else it doesn't .

[Matt]

also I believe it would make sense to add NS_LOG_WARN when the source
is not found/ TraceConnect fails ?

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ns-3-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/ns-3-users/XJwQmd7aTzc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> ns-3-users+...@googlegroups.com.

[Tommaso Pecorella]

Hi Matt,

the NSLOG_WARN makes sense.

What still puzzles me is the need tor GetInstanceTypeId. Sorry but I'm all but convinced about it. I didn't check the code, but logic tells me to look after something else.

Reason for the GetInstanceTypeId need / not need topic:

1) CsmaNetDevice has a number of traces, and they are working as intended.

2) CsmaNetDevice doesn't have any GetInstanceTypeId.

-> consequence: GetInstanceTypeId is not needed for working TraceSources.

-> sub-clause: it should be something else.

Cheers,

T.

[Matt]

indeed this is puzzling. I am sorry I don't have really the time to
investigate this right now plus I am not sure it is worth: I use an
old ns3.19 ( It would be interesting to see if it TcpRxBuffer tracing
works on ns3.21/22) with some modifications I've not done myself (very
little should have been done but I can't say for sure core was
untouched).
If some notify the same problem, I could help investigate when I get time.