traffic models NS3/LENA

[Natalia Molinero]

Hi,

Does anyone know which traffic models are available in NS3 or LENA, please?

Thank you. Best regards,

Natalia.

[Tommaso Pecorella]

Hi,

The traffic models are exactly the same as the ones available for other ns-3 models

T.

[Natalia Molinero]

Hi Tommaso,

I'm afraid that I don't find the documentation where this is explained. Could you please indicate me where you found it?

Thank you very much. Best regards,

Natalia.

[Tommaso Pecorella]

Hi,

perhaps it's not explained because it's too obvious. LTE is a network module, and traffic generators are applications. Applications are independent on network technologies...

T. 

[Natalia Molinero]

so there is no full buffer? 

El miércoles, 29 de julio de 2015, 12:25:53 (UTC+1), Natalia Molinero escribió:

[Natalia Molinero]

If it's do evident, why you don't reply to my answer and give me a list of the traffic models that LENA can use, please? :)

El miércoles, 29 de julio de 2015, 12:25:53 (UTC+1), Natalia Molinero escribió:

[Tommaso Pecorella]

The applications are in the application module. Some documentation is here:

https://www.nsnam.org/docs/doxygen/group__applications.html

About the full buffer, it depends on what buffer you're talking about.

About why I didn't gave the link before... mostly because I am not here to provide links to people that is too lazy to find stuff by themselves. Or better: I love to know in advance who really has an issue and who's just too lazy.

A suggestion: study the tutorial. From your questions it is evident that you did just read it without understanding it.

T.

[Natalia Molinero]

1. Thank you

2. I don't know you and I don't know what you do here apart from being a bit impolite with people that you don't know

3. that link that you gave me has the same things as in the application module...

4. full buffer=infinite buffer... if you don't know what I'm talking about... I'd suggest you not to use the word "lazy" so many times :-P

5. did you see the application on/off? so in colloquial terms, full buffer would emulate the performance as "always on". I guess this is not implemented? 

Thanks again and sorry for pointing out the things like that but you started! :(

El miércoles, 29 de julio de 2015, 12:25:53 (UTC+1), Natalia Molinero escribió:

[Tommaso Pecorella]

On Thursday, July 30, 2015 at 5:18:44 PM UTC+2, Natalia Molinero wrote:

1. Thank you

You're welcome

 

2. I don't know you and I don't know what you do here apart from being a bit impolite with people that you don't know

I usually try to help people here. Being a bit impolite is one of my traits (someone claims that I'm sarcastic). Someone also has the doubt that I'm being paid to be harsh.

 

3. that link that you gave me has the same things as in the application module...

True, because any application can work with the LTE module. I already told you...

 

4. full buffer=infinite buffer... if you don't know what I'm talking about... I'd suggest you not to use the word "lazy" so many times :-P

Ok, let me rephrase. You're imprecise (at best). A "full buffer" is usually the effect of a finite buffer that is filled at a higher rate than the output rate. This usually leads to a saturation condition on the node. If the buffer is full because the output rate is clogged by the network being congested, then you have a network saturation condition, but the buffer being full is a consequence of the saturation rather than its source.

On the opposite, an infinite buffer can never be full (by definition). It can be arbitrarily filled, so to always have a packet to transmit as soon as the previous one is sent. I.e., it's one of the possibilities for triggering a network saturation. This is due to the fact that a finite buffer is, by design, self-limiting, unless you have a back-propagation mechanism and the application (or a higher layer) can fill the buffer as soon as some of its space is freed.

Summarizing, full buffer isn't synonym of infinite buffer. Given the fact that you can use buffers in countless ways to measure and trigger different network behaviours, and you can have countless points where to place a buffer (MAC, IP, TCP, Application, etc.), your question was... lacking details. Thus, I stand my point. you had to spend more time explaining your problem.

 

5. did you see the application on/off? so in colloquial terms, full buffer would emulate the performance as "always on". I guess this is not implemented? 

No, "always on" is not emulated by OnOff. You could do it with BulkTransfer, but the back pressure mechanism isn't (yet) implemented in ns-3. The best thing you can do is to use OnO with a zero Off period and a rate high enough to saturate the channel. This will do the trick, but it could also dramatically slow your simulation.

 

Thanks again and sorry for pointing out the things like that but you started! :(

You don't know me.

I'm an Engineer. Discussing with an Engineer is like fighting in the mud with a pig. After 2 hours you'll find yourself exhausted and you'll realize that the pig is actually enjoying it.

Have fun,

T.

[Natalia Molinero]

hahaha ok, there I go:

1. thanks again!! :)

2. oh, I see! So you do that on purpose or at least you are aware of it... hahaha that's fun! 

3. we can skip this one, it's boring haha

4. WOW! :-D many thanks for that explanation.  Yes, I didn't know much about that and I was confusing stuff... I started working on this not too long ago, sorry...

5. this solves my question :) :)

and I enjoyed it, yes!!  Grazie mille!!! :-D

El miércoles, 29 de julio de 2015, 12:25:53 (UTC+1), Natalia Molinero escribió: