OnOff application - variable OffTime attribute settings

554 views
Skip to first unread message

Jiří Pokorný

unread,
Apr 27, 2017, 10:14:16 AM4/27/17
to ns-3-users
Hi guys,

I am trying to simulate a TCP transfer using the OnOff application, but I am having a problem with the OffTime attribute.
My original goal was to have one stream with constant data rate to be transmitting for a long time while there will be another stream transmitting for shorter time and I want to see how the second stream affects the first one. I found out that if I want to transmit larger amount of data, it stops for no reason, so I did some experimenting with the OffTime attribute.

I ran my simulation with this parameter:

onoff1.SetAttribute("OffTime", StringValue("ns3::ConstantRandomVariable[Constant=10]"));

where I set constant to 0, 5 and 10 and it behaved very differently each time. Results are shown in the three following pictures.


I am transferring 500 kB of data.
1) In the first picture, the transfer stops at time 10 s without any reason.
2) In the second picture the transfer works perfectly, except I would prefer if it started at time 0.
3) In the third picture, after the server sends some data it stops for about 5 s and then it starts again.

Can anybody explain to me this behaviour, how this attribute works or how should I set it correctly to get my goal?

Working source code is attached.

Thank you for any help.

Jiri
onOff.cc.txt

Rediet

unread,
Apr 27, 2017, 12:16:37 PM4/27/17
to ns-3-users
Hello Jiri,

First of all, the OnOffApplication starts with an OFF period (see ScheduleStartEvent called by StartApplication) thus the initialization delay that you see.
Secondly, here is the part I'm less sure about, it seems that there are some slow P2P connections in your topology (200kps). Considering that you are generating 1 packet roughly every 0.2ms (200b@1Mbs), your queues will saturate and start dropping frames before all the packets could be transmitted, especially in the first, always ON, scenario. The 5s/10s OFF times in the other scenarios may leave your system time to transfer all packets (5s to transfer 1s' worth of packet for 3rd scenario presumably). To confirm/infirm, consider simplifying your topology or increasing your P2P data rates.

BR,

Rediet

Tommaso Pecorella

unread,
Apr 27, 2017, 6:05:58 PM4/27/17
to ns-3-users
I totally agree, you're saturating the link.

Moreover, for the CBR generation you need to set the OffTime to zero. You can use the OnOffHelper::SetConstantRate function, it's easier than figuring out the right params by yourself.

T.

Jiří Pokorný

unread,
Apr 28, 2017, 4:35:26 AM4/28/17
to ns-3-users
Hello,

first of all, thank you for your answers. You were both right, lost packets were caused by the queue saturation.

I ran the simmulation two more times with data rate 200 kbps (first picture) and 300 kbps (second picture) and that confirmed your assumptions.


















I checked the PCAP file and I dont see any dropped packets or retransmissions. The connection is just terminated with FIN,ACK as everything was OK, but I am missing some data. It looks like, not all data are being transmitted from point A.

The thing is, I need to send the data with higher data rate, because I would like to use full throughput of the other links.

My scenario is: A--------500kbps---------B--------1Mbps---------C--------200kbps---------D

Let's say my source will be sending data from point A to point D, it will send it with maximum data rate from point A to B, which would be 500 kbps. The source will NOT know the capacity of the link from C to D so it will have no reason to reduce the speed to only 200 kbps.

So my next question is, how can I force the application to send all data with maximum data rate? I would guess by increasing the buffer at point A?

Thank you,

Jiri

Dne pátek 28. dubna 2017 0:05:58 UTC+2 Tommaso Pecorella napsal(a):

Rediet

unread,
Apr 28, 2017, 7:20:55 AM4/28/17
to ns-3-users
Hi Jiri,

If you want to your app to use all the resources, i.e. bandwidth, why not use BulkSendApplication instead of OnOffApplication then?
You can also derive the BulkSendApplication so that it's data rate may be limited by a newly added attribute, if you want to have a hybrid (i.e. CBR if enough bandwidth) app.
By the way, if you want to "see" the dropped packets you'll have to connect to the corresponding trace source. You can then put them inside a pcap if desired or just count them.

BR,

Rediet

Jiří Pokorný

unread,
May 3, 2017, 12:32:16 PM5/3/17
to ns-3-users
Hello,

Regarding the first line:
I am still struggling with this issue. I tried using using BulkSendApplication and OnOff application, but it seems like it works equally. My assumption is, that both applications check my slowest link speed and then send it to the target with that exact speed. Example, I have links 500kbps, 1Mbps and 200kbps, both apps seem to generate data with speed of 200kbps. I need it to start sending the data with speed of 500kbps.

Regarding the second line: 
What is that newly added atrribute you mention? Where can I find it? Can you provide some code with use of this?

Regarding the third line: 
I am using the p2p.EnablePcapAll("socket-bound-static-routing", true); command, it generates several files, but they are all the same. It looks like a bug in NS3, but I haven't found anything about it. Or did you mean a different type of tracing?

Sorry for the million questions and thanks for the answer.

Jiri

Dne pátek 28. dubna 2017 13:20:55 UTC+2 Rediet napsal(a):

Tommaso Pecorella

unread,
May 3, 2017, 7:49:08 PM5/3/17
to ns-3-users
Hi,

no idea for n°2 (ask Rediet), however...
1) TCP will always adapt to the slowest link, it's TCP 101. If you need a CBR flow at full speed you need UDP. Also this is UDP 101.
3) It's not an ns-3 bug, and the PCAP files are slightly different. Check what a promiscuous mode is and think about it.

T.

Rediet

unread,
May 4, 2017, 6:58:14 AM5/4/17
to ns-3-users
Hi Jiri,

I can see that my suggestions were not so clear. Btw, thanks Tommaso for the clarification.

Concerning the attribute, it was a suggestion to modify the code (through inheritance) in order to tell the BulkSendApplication to use the available resources up to a certain point, thus "throttling" the application source, because currently it'll use up the whole available bandwidth. It is just an idea though. I have nothing to show (just a vague notion that you'll probably need you'll have to do a max between the offered data rate and the throttling data rate) and it may even be a bad idea, but it could have corresponded to your needs...
The advantage of BulkSendApplication over OnOffApplication is that the former adapts itself to the underlying TCP (if used for OnOffApplication). So you'll have less chances of dropping packets in the intra-node underlying TCP queue (@Tommaso, is this correct?), even before anything is even transmitted between nodes.

The tracing I was talking about was the more elaborate TraceSource possibility that is offered by ns-3. See the tutorial/manual on how to configure a TraceSink to catch the dropped packets.
I just realized that I was wrong when counselling you to dump them in a pcap; they are just rough packets, with no headers, considering that they are dropped by the TCP queue, so you'll not be able to decode them properly with Wireshark (at least I don't think so). However you can simply count them and/or account for their payload in your TraceSink.

BR,

Rediet

Tommaso Pecorella

unread,
May 4, 2017, 7:53:56 PM5/4/17
to ns-3-users
Just replying to the question...

yes and no.

BulkSend will stop feeding packets to TCP when the TCP queues are full (actually the queues in the TC layer below IP, and the TCP queues as a consequence).  
OnOffApplication will not stop feeding the TCP layer, and the "extra" packets will be dropped.

However, the problem is that these two apps are meant to do different things.

BulkSend is meant to send a given amount of data at the fastest rate possible. The data must be sent, not lost in the process - think to it as the download of a file from an web server.
OnOffApplication is a data generation application. it generates data blindly at a given rate (when in On). Hopefully the L4 will be able to send them, but it it isn't... who cares.

This is also stressed by one (small but important) fact.
OnOffApplication can use TCP or UDP sockets.
BulkSend can use ONLY TCP !

Cheers,

T.

Luis Alvarez Lopez

unread,
Nov 3, 2018, 3:39:18 PM11/3/18
to ns-3-users
Hi, i have a question related to this issue. Would it be possible to change the Constant value of the Constant Random Variable from the command line? I mean using a variable and that stuff. Everywhere i look i find out that the way to set this attribute is using "StringValue(...)" but this doesn't allow any kind of variations does it? Thanks
Reply all
Reply to author
Forward
0 new messages