Tracing tcp RTT with nsc

[ofri...@annapurnalabs.com]

Hi,

I'm using nsc, and I want to trace RTT.

with tcp-socket-base I traced m_lastRtt, but it seems that with nsc there's no easy way.

Can someone shed some light on how to do it? if at all possible?

I read this old discussion - 

https://groups.google.com/d/msg/ns-3-users/ie43N5cnvkQ/zgkwk9iFU_wJ

Alberto Blanc suggested to use the SoftInterrupt for cong-control purposes, is it relevant to RTT as well?

Thanks,

Ofri

[Tommaso Pecorella]

Hi,

no, because NSC is just a wrapper around real TCP implementations in the kernel.

Basically what you should try to do is to find a way to track the TCP inner variables of any [real] socket: it should work on NSC too.

T.

[Matt Anonyme]

Look for tcpprobe. Other than that this blog has many good tips for linux instrumentation http://www.brendangregg.com/blog/2015-07-08/choosing-a-linux-tracer.html .
You can also look at DCE which may be more maintained than NSC.

[ofri...@annapurnalabs.com]

Hi,

Sorry for my late response, and thank you for your prompt reply.

Before I dive into NSC, I thought maybe to add some data of my own to the packet, and in the receive callback, parse it. This should be good enough.

I'm adding SeqTsHeader to the packet, but on receiving, it seems the data is corrupted.

This is how i'm using it:

tx:

Ptr<Packet> packet = Create<Packet> (packetSize);

SeqTsHeader tsHdr = SeqTsHeader();

packet->AddHeader(tsHdr);

rx:

SeqTsHeader tsHdr;

packet->PeekHeader(tsHdr);

Time timestamp = tsHdr.GetTs();

sometimes I get 0 in timestamp, and generally not the expected values.

It is supposed to work? any idea why it is not working?

Thanks

[ofri...@annapurnalabs.com]

Hi,

I replied earlier, to myself by mistake, but this reply was meant for this message.

I also want to add to my reply some insight - I looked at nsc-tcp-socket-impl.cc, and added these line:

1) at SendPendingData, after 

   

Ptr<Packet> &p = m_txBuffer.front ();

size = p->GetSize ();

NS_ASSERT (size > 0);

   I added:

SeqTsHeader tsHdr;

uint32_t hdrSize = p->PeekHeader(tsHdr);

if (hdrSize) {

  Time time = tsHdr.GetTs();

  if (time == Seconds(0))

     NS_LOG_UNCOND("pop: wrong ts");

}

2) at Send, the same lines.

What I see is that the packets that go into the queue have the right SeqTsHdr, while the packets the come out of the queue have corrupted SeqTsHdr.

I haven't found the reason for that, I could really use your help with that.

Thanks, 

Ofri Rips

On Saturday, 22 October 2016 17:19:00 UTC+3, Tommaso Pecorella wrote:

[ofri...@annapurnalabs.com]

OK, I figured out what was my problem...

I thought tcp fragment and then defragment the packets, and keeps each packet as is, and I expected to find the header at each packet and in the same offset, and that is not the case.