strange results in flowmonitor

[Boris]

hi again, 

i've faced with such strange thing. Look at this output:

[code]

Flow 1 (10.0.0.3 -> 10.0.0.1)

  Tx Bytes:   2054712  Tx packets:   3570

  Rx Bytes:   2002296  Rx packets:   3479

  Packets lost:   36

  Data Transfer rate: 0.285022 Mbps

  Troughtput: 0.283444 Mbps

Flow 2 (10.0.0.1 -> 10.0.0.3)

  Tx Bytes:   77240  Tx packets:   1931

  Rx Bytes:   77200  Rx packets:   1930

  Packets lost:   0

  Data Transfer rate: 0.0107144 Mbps

  Troughtput: 0.0107122 Mbps

[/code]

according this output, 10.0.0.1 received 3479 packets from 10.0.03 as the same time as 10.0.0.3 sent only 1931 packets. How it possible?

script attached.

[Konstantinos]

What is strange? You have TCP traffic which also sends ACKs on the return link.

[Boris]

I see, but in TCP every packet must be confirmed, isn't it? so, number of packets and number of acknowledgements should be equal.

btw for UDP stream result is very similar, however there is no ACK's in general..

[Konstantinos]

Yes, every packet should be acknowledged, but that does not mean that you will have individual ACKs packets for eack data. 

Multiple ACKs might be combined in a single packet. So, that's why the number of Rx Data packets is not the same with that of Tx ACKs.

[Boris]

Yea, but in my case it seems something different or I understand Rx and Tx incorrectly.

Look, flow 1. I interpreting this output like that:
10.0.0.3 sent 3570 packets to 10.0.0.1
10.0.0.3 received 3479 packets from 10.0.0.1

So, on 3570 packets 10.0.0.3 received 3479 packets with acknowledgements, right?

Then look at flow 2. Why numbers differs from other ones in flow 1? My application sends data only from 10.0.0.3, so 10.0.0.1 should send only acknowledgements, what numbers 1931 and 1930 means? I don't understand that...

[Konstantinos]

Yes 10.0.0.3 received 3479 packets so it should have send 3479 ACKs.

Multiple ACKs however can be "combined" into a single reply so when one ACK-packet is sent to 10.0.0.3 it may acknowledge more than one data packets.

[Boris]

Okay, I understood about flow 1. So, explain me please, what is flow 2 and how interprete its statistics?

[Konstantinos]

What? I do not think you understood.

Flow_1 is the data packets and Flow_2 is the ACK-packets.

[Boris]

hmm, okay, and what is Tx and Rx in that case?

[Konstantinos]

Tx are the transmitted packets and Rx are the received packets of that flow.

[Boris]

aha..so

10.0.0.3 sent 3570 data packets and 10.0.01 recieved only 3479, right? so 3570-3479=91 packets were lost.

10.0.0.1 sent 1931 packets with ACK's, which acknowledge 3479 received packets and 10.0.0.3 received 1930 packets, so 1 packet was lost. Is it right?

среда, 25 июня 2014 г., 18:08:41 UTC+4 пользователь Konstantinos написал:

[Konstantinos]

The packets might not be lost (yet). 

As you can see FlowMonitor reports only 36pkt for the first flow and 0 for the second as lost. 

They could be still in transit. You have to give the simulator some time from the time the last packet is send until you stop to so every packet is accounted for.

[Boris]

thanks a lot!

but what about UDP? i've changed the script like in attach..there is flow 2 too..what is this in this case?

Flow 1 (10.0.0.1 -> 10.0.0.2)
  Tx Bytes:   514800  Tx packets:   100
  Rx Bytes:   185328  Rx packets:   36
  Packets lost:   195
  Data Transfer rate: 0.0913398 Mbps
  Troughtput: 0.0913235 Mbps
Flow 2 (10.0.0.2 -> 10.0.0.1)
  Tx Bytes:   185328  Tx packets:   36
  Rx Bytes:   154440  Rx packets:   30
  Packets lost:   6
  Data Transfer rate: 0.0328823 Mbps
  Troughtput: 0.0328802 Mbps

[Tommaso Pecorella]

Hi,

This is an example of non polite message:

no offense, but do you think the devs are a bunch of crazy sadists, aiming at driving users mad in every possible way ?

Yes, of course they are. They did name the applications "UdpEchoServer" and "UdpEchoClient" because they have twisted minds.

It's like going to the Echo Valley, climb on top of the Echo Viewpoint and be surprised that there is an actual Echo !

This is the correct way to handle such a question:

maybe you did not notice the "Echo" part of the Application you are using, or maybe your English knowledge, although good, is not perfect.

You may indeed be unaware of the Echo term. Let me introduce it. In English "Echo" is referred to the natural phenomenon of a sound bouncing back to whoever emitted it, usually with a sensible delay. It is mostly experienced in valleys, and the dumbest people even try to see if there's an Echo phenomenon in snow valleys, possibly causing avalanches.

By extension, an "Echo" thing is one bouncing back whatever it is sent to it back to the sender without changing its content. The applications you used do exactly that.

The morale is: never assume that who ask a question knows the meaning of every english term, even if it's a very common one.

T.

[Boris]

oookay, exuse me for my carelessness..but anyway strange results are there
flow 1.
how number of lost packets may be greater than number of packets sent?

[Tommaso Pecorella]

THAT is a good question. And a call for a documentation improvement.

The number if "lost" packets is the number of lost... IP packets.

On the contrary, the number of send and received packets are the number of packets passed to the IP layer or delivered from the IP layer.

The difference ? Fragmentation.

Unfortunately there's no simple way to be sure that a segment loss is equivalent to a packet loss, so there's this "glitch". Simply avoid to send packets larger than the MTU, or subtract the received and sent packets.

Cheers,

T.

[Boris]

i see, thanks

btw why packets are losing during modeling? is it planned and may it be managed?

четверг, 26 июня 2014 г., 21:44:24 UTC+4 пользователь Tommaso Pecorella написал:

[Tommaso Pecorella]

Hi,

there should be no drop in CSMA at physical level (unless you explicitly set a ReceiveErrorModel). However, drops due to excessive queue length may still happen.

Check the csma drop traces, probably you'll find the reason.

Cheers,

T.