help for TCP throughput evaluation

75 views
Skip to first unread message

TCP

unread,
Jan 17, 2015, 1:53:41 PM1/17/15
to ns-3-...@googlegroups.com
Hi guys maybe someone can help me. I've done a NS3 script for TCP throughput evaluation.

during the running state I can evaluate the throughput using THR=TotalReceivedBytes/TotalUtilTime  (Mbps)

looking to the Mathis formula for the TCP:   THR=(MSS/RTT)*(C/sqrt(Loss)) , there is a way to test if I can obtain the same results with these 2 methods?

My network is simple: 2 nodes and a channel and I give to the program:
-simulation time
-channel delay
-channel speed/rate
-error probability
-TCP segment size

Any kind of solution will be fantastic, thanks in advance

TCP

unread,
Jan 18, 2015, 11:44:35 AM1/18/15
to ns-3-...@googlegroups.com
Noboby can help me?

Tommaso Pecorella

unread,
Jan 18, 2015, 12:01:39 PM1/18/15
to ns-3-...@googlegroups.com
Honesty... I didn't understand the problem. The obvious solution (compare the numbers) seems so obvious that it can't be right.
Please rephrase. Or use your native language, perhaps we can figure it out.

T.

TCP

unread,
Jan 18, 2015, 2:29:15 PM1/18/15
to ns-3-...@googlegroups.com
yes you idea is right, the problem is how I have to implement the Mathis formula THR=(MSS/RTT)*(C/sqrt(Loss))
with these input

-simulation time
-channel delay
-channel speed/rate
-error probability
-TCP segment size
have you any ideas?
thank you

Tommaso Pecorella

unread,
Jan 18, 2015, 3:37:17 PM1/18/15
to ns-3-...@googlegroups.com
MSS: it's a simulation param. Check the "ns3::TcpSocket::SegmentSize" attribute. Default is 536 bytes, but you probably want to enlarge it. See also examples/tcp/tcp-variants-comparison.cc.
RTT: it depends on your simulation. If you don't have huge delays in the routers due to heavy traffic, it can be approximated by knowing the channel delays.
C: it is the channel capacity. You should know it...
Loss: it's the error probability. Again, you should know it.

T.

TCP

unread,
Jan 20, 2015, 4:01:46 AM1/20/15
to ns-3-...@googlegroups.com
ok thank you very much, my doubt was about RTT because it is the time for packet+ack, and i was thinking delay was a one way delay
Reply all
Reply to author
Forward
0 new messages