Using Trace/callback to trace multiple connection

[Alan Lin]

Hello All,

I've been filling with the tcp-variants-comparison.cc code such that I can have different different flow with different access delays as follow:

(Sources)                                                                      (Sinks)

               15ms                                          15ms

n1--------------------------(           )--------------------------------n3

                                       gw1

n2--------------------------(           )--------------------------------n4

                         25ms                                               25ms

Connections are set up such that n1 is sending to n3 and n2 is sending to n4. I was able to used the tracing function to trace the rtt on n1 with no problem. However, I'm  also trying to do the same with n2.

The code in the program is:

static void
RttTracer (Time oldval, Time newval)
{
  if (firstRtt)
    {
      *rttStream->GetStream () << "0.0 " << oldval.GetSeconds () << std::endl;
      firstRtt = false;
    }
  *rttStream->GetStream () << Simulator::Now ().GetSeconds () << " " << newval.GetSeconds () << std::endl;
  NS_LOG_INFO ("In CallBack Function: RttTracer!");
}
 
static void
TraceRtt (std::string rtt_tr_file_name)
{
  AsciiTraceHelper ascii;
  rttStream = ascii.CreateFileStream (rtt_tr_file_name.c_str ());
  Config::ConnectWithoutContext ("/NodeList/1/$ns3::TcpL4Protocol/SocketList/0/RTT", MakeCallback (&RttTracer));
}

I am aware that in "/NodeList/1/$ns3::TcpL4Protocol/SocketList/0/RTT", the 1 corresponds with n1 and that the node list index is based on the order in which the node is generated. In my case n2 has the NodeList index of 2. However, changing the 1 => 3 does not yield any traces. 

Any input on this matter is appreciated!

 

 

[Tommaso Pecorella]

Hi,

there's a known issue with dynamically generated sockets and trace sources.

Try with "/NodeList/1/$ns3::TcpL4Protocol/SocketList/*/RTT"

Hope this helps,

T.

[Tommaso Pecorella]

I forgot to mention...

make sure to call the function AFTER the socket has been created and connected. You could need to increase the delay to TraceRtt call.

T.

[Alan Lin]

Hello Tommaso,

The trace function is called after the socket is created and connected.

I am able to capture using  "/NodeList/1/$ns3::TcpL4Protocol/SocketList/0/RTT" but when I try to capture on a different source node,  "/NodeList/2/$ns3::TcpL4Protocol/SocketList/0/RTT", I have nothing in the output file.

In the above topology I am able to trace the flow with the 2x15ms delay connection with no problem, but I would also like to be able to trace the flow with the 2x25ms delay as well. So far I have had no luck trying to get a trace with the rtt values of the second flow. I have even tried using the wildcard on the Nodelist entry(  "/NodeList/*/$ns3::TcpL4Protocol/SocketList/*/RTT"). Even so, I will only get the trace for the first flow.

[Tommaso Pecorella]

Attach the source code. We'll see if we can figure it out.

T.

[Alan Lin]

Below are to the code I'm using. I have also edited a few of the existing file in the NS3 suite (also included). I added a few trace sources to grab the sampled rtt and the delta between the sampled an estimated rtt. The existing trace source for rtt is actually tracing the estimated rtt (or smoothed rtt).

[Alan Lin]

Hello,

Just checking to see if there's any luck in checking if there's way to trace multiplier nodes through these methods? I've notice that there are other programs like the wireless bulk send that uses the wildcard to just return estimation from one node?

[Tommaso Pecorella]

Hi,

all seems working as intended.

Node 2 is generating the traces. The other nodes don't.

Node 0 and 1 are not involved in TCP generation (they are just routers).

Node 3 is a sink and it doesn't really need to calculate any RTT, RTO or anything else. It could, but it's not sending data and without ACKs it doesn't update any default value. As a consequence, there's no trace.

Does this makes sense ?

Cheers,

T.

[Alan Lin]

Hello Tomasso,

I understand that would be the case if we are running a simulation with a single flow. However, if we up the flows to 2, there are still only a single trace when there are two sources and two sink with two tcp flows. 

[Tommaso Pecorella]

Citing myself:

I forgot to mention...
make sure to call the function AFTER the socket has been created and connected. You could need to increase the delay to TraceRtt call.

Shall I point out that I assumed that you DID check this and I lost 1 hour trying to figure out what was wrong before double checking what you had to check ?

My bad. I must never underestimate people's un-ability to follow directions.

The flows are started at different times. By default at start_time*i, where start_time is 0.1 seconds.

The traces are hooked (they try to be hooked) at 0.00001 second or so.

The only sockets ready at that time are the ones of the first flow.

You owe me 1 hour of my life. As a punishment, you'll go out and get drunk. Then you'll have to do something very stupid (but funny and not harming you or anyone else) and post the pics on Facebook. Add "I forgot to follow the experts direction and this was my punishment" caption. Post the link here.

Have fun,

T.

[Alan Lin]

My apologies... My initial take on the delay was delay in terms of when the call is made in the code rather than in the context of simulation time. 

Unfortunately, I shall not get drunk, but rather spend the next few evenings gathering simulation traces with the help of your corrections.... However I will quote note that "I cannot follow expert instructions and wasted an hour of a fellow expert" during the remainder of my meetings regarding this simulation.

Hopefully this thread is helpful to others looking to similar tracing and will require you to dig any further in this subject. 

Thank you for your time and patience !!!