How should one proceed with measuring raw throughput of the CSMA link?

[Alexander Samuseu]

Hi.

I'm trying to complete my lab and it involves proving the one particular link is a bottleneck for the rest of the network. So what I'm need to do is somehow measure raw low-level througput of all CSMA physical links in my network model. Here are 2 problems I couldn't tackle: 

1) All connections used to overload the network must be TCP streams, per requirments. But I failed to understand what should be done to specify exact bitrate the applications would use for sending packets with TCP. So I can't be sure they are producing as much traffic load as they are able and hence that my network is really overloaded. In UDP applications there is a bit rate settings, but AFAIK there is no such thing for TCP ones.

2) I failed to understand what should be done to access some mean values of raw througput for all the links. I'm talking about throughput at the lowest possible level, i.e. exact number of bits per second send over abstraction of physical layer (OSI level 1)/ Some counters of flow monitor allow you to get number of bytes send for individual TCP streams, but it's hard to unambiguously bind this info to individual link's throughput, it would need some conversion coefficient applied to them, at best. So I would really appreciate some way to exctract more general throuphut number, like mean number of bytes sent through datalink level or network level (OSI-2 and 3, respectively), per second.

Thank for any advice on the subject in advance.

[Alexander Samuseu]

So, basically, I need to know how much (in %) of total available bandwidth of each CSMA link are consumed by traffic passing through it, is 100%, or still there is some room left?

[Alexander Samuseu]

Just to make sure I've expressed myself clear enough: problem with Flow Monitor is that, if I've got it right, it's monitoring end to end throughput for TCP streams. So there is no way to directrly measure how much bytes are passing through each individual link with it, as many streams could overlap here (so you would need to summarize them all, and then apply some coefficient to make up for overhead imposed by now stripped headers of lower OSI levels, to get something similar to actual bandwidth usage on OSI level 1 or 2), and streams could even be splitted up between several devices due to some kind of balancer algorithm's intervention. So what I need is a rock solid approach to measure the particular link's load at OSI level 1 or 2 (at least 3) at this very moment.

[Konstantinos]

Please study the ns-3 documentation, particularly the statistical framework and the tracing.

You can use trace sources (or create if there aren't any) fro Rx/Tx packets at any level.

[Alexander Samuseu]

Konstantinos, thank you for your answer. I hoped there is a easier way, statistical framework frightens me with its complex syntax and lack of any helpers. But what about my first question? How can I make sure that all my applicatins instaled on network nodes are really produce enough tcp packets to stress it out? How can I set some enormous bit rate for TCP application?

четверг, 16 апреля 2015 г., 15:37:34 UTC+3 пользователь Konstantinos написал:

[Konstantinos]

1) There are a lot of examples to study the statistical framework. 

2) The same way you do it for UDP, you can do it for TCP. Note that TCP has also congestion control mechanisms that will internally adjust the data rate when loses due to congestion happen. 

[Tommaso Pecorella]

Hi all,

a short remark. Due to TCP's congestion control mechanisms, it's highly unlikely that you can fill a link just by using TCP. You'll need multiple TCP flows and, even then, your link will never be really in saturation.

Cheers,

T.

[Alexander Samuseu]

I've removed the "Completed" mark because it seems I just can't find a way how to do this, no matter how hard I'm trying. This enormous pile of mind-wrapping callbacks and multisegmented trace sources' paths left me in total disarray. I simply can't get how I can realise this plain and simple algorithm using all this monstrosity:

1) Aquire and store pair of values {"total_number_of_bytes_send_via_CSMA_adapter_from_the_very_beginning","time_at_which_previous_value_was_recorded"} for each of my nodes each 100-1000ms

2) Upon aquiring the fresh pair of these values calculate throughput using a couple of most recent previous values (simply by (bytes1-bytes2)/(time1-time2))

I failed to find a way how to exctract throughput values directly, also, so I hope at least something similar to mentioned above is possible.

четверг, 16 апреля 2015 г., 17:54:02 UTC+3 пользователь Konstantinos написал:

[Alexander Samuseu]

>1) Aquire and store pair of values {"total_number_of_bytes_send_via_CSMA_adapter_from_the_very_beginning","time_at_which_previous_value_was_recorded"} for each of my nodes each 100-1000ms

Here I made a mistake: not only send, but received and dropped too. All that was put on the wire, or came in from the wire should be included in throughput calculation.