How could make realistic congestion for the network in simulators typically?
Do i have to make congestion in network by playing with background traffic? for example by making an script; sending specific CBR background traffic from 10 seconds of simulation to 20 seconds then, FTP from 20 seconds to 30 seconds and so on? Or is there any tool that follow Internet traffic model?
Beside the above question, Is there any model in NS3 that i can use for making network congestion? In another words, how could we have a realistic network congestion in NS3?
Thanks in advance
There are appliances to address this from a test and measurement perspective. Some of them are sophisticated enough to model entire networks of impairment characteristics.
Related
I would have a question regarding physical problem detection in a link with ping.
If we have a fiber or cable which has a problem and generate some CRC errors on the frame (visible with switch or router interface statistics), it's possible all ping pass because of the default small icmp packet size and statistically fewer possibilities of error. First, can you confirm this ?
Also, my second question, if I ping with a large size like 65000 bytes, one ping will generate approximately 65000 / 1500(mtu) = 43 frames, as ip framgents, then the statistics to get packet loss (because normally if one ip fragment is lost the entire ip packet is lost) with large ping is clearly higher ? Is this assumption is true ?
The global question is, with large ping, could we easier detect a physical problem on a link ?
A link problem is a layer 1 or 2 problem. ping is a layer 3 tool, if you use it for diagnosis you might get completely unexpected results. Port counters are much more precise in diagnosing link problems.
That said, it's quite possible that packet loss for small ping packets is low while real traffic is impacted more severely.
In addition to cable problems - that you'll need to repair - and a statistically random loss of packets there are also some configuration problems that can lead to CRC errors.
Most common in 10/100 Mbit networks is a duplex mismatch where one side uses half-duplex (HDX) transmission with CSMA/CD while the other one uses full-duplex (FDX) - once real data is transmitted, the HDX side will detect collisions, late collisions and possibly jabber while the FDX side will detect FCS errors. Throughput is very low, put ping with its low bandwidth usually works.
Duplex mismatches happen most often when one side is forced to full duplex, thus deactivating auto-negotiation and the other side defaults to half duplex.
I'm a newbie software developer who develops SIP/RTP Voip software.
For sure, I am using UDP protocol and Video Codec for this video is H264.
Since I am new to this Voip area, I am so confused and suffering painful network issues a lot.
I would like to ask experts something related to Network specifically dealing with RTP/RTCP issues on Jitter / Packet loss.
After SIP successfully creates media session, I get some issue for QoS.
Problems I am facing up is just like this below.
Wifi network(latency : 11.1m/s download speed : 14.9mbps upload speed : 3.27mbps) :
http://www.youtube.com/watch?v=epm01c6IT5Q&feature=youtu.be
3G network(latency : 26.4M/s Download speed : 1.94Mbps upload speed : 2.42Mbps) :
http://www.youtube.com/watch?v=-iG156_wdQE&feature=youtu.be
as you see, through 3G that has low upload and download and unstable latency, video quality including video issue coloured green and video's delay is better than Wifi.
using 3G network slower than Wifi , I can always take better user experience than Wifi.
I didn't analyse RTP/RTCP packets deeply but the thing I can tell is ...
At the problem situation, when Wi-fi was used for the application, Jitter was strangely high enough and packet loss was obviously high as well.
To sum up,
As you can see, video quality is better when I use 3G network slower than Wifi.
When Wifi works there, Jitter and packet loss are obviously high as I can analyse packet using wire-shark on the receiver side.
at that morning time, video problem(green pixel of video, video delay) was much more serious but as time went, at the afternoon and night, problem had been recovered a bit.
As far as I know, it would be related to network bandwidth and network congestion.
I am not sure that it is proper diagnosis and also need to solution to this.
I'm sorry that I have not enough background information yet.
Thanks.
You area going to have to look at the RTCP or RTCP-XR messages to see what is going wrong. If that fails then like the other posts have said you will need to use wireshark to determine what the issue is.
There is most likely a network layer issue that is causing this so do what you can to test your connection to the other side. A traceroute might be a good place to start to see what the difference is between how the 3G routes vs the wifi.
Wifi can have many issues related to jitter and packet loss that your cell network might not depending on your signal strength (and other things). If you can test with a hard wire connection then you can rule out wifi as an issue and if you still have issues it has to be network/ISP related. If a hardwired connection resolves your issues then you know it was the wifi and you can troubleshoot accordingly.
The green is most likely an artifact of the jitter/packetloss. Normally in the US, for voice, a ptime of 20ms is used. Which means that audio packets (and video if used) are send every .02 seconds. If your jitter is higher than 20ms or you have high packetloss or burst packetloss then you will likely see and hear distortions because the packets either arrive out of order and are dropped or are lost. The green screen is just one of many you could see depending on the app you are using. I work mostly with audio so I am sorry I can't be more helpful with the exact meaning of that artifact.
Working on my thesis I need to create a simulation for video transmission in a normal WLAN to detect how much the quality is reduced depending on the number of devices or quality of originating transmission.
I was using NS-3 for this when someone proposed to me to use my home devices (I have a number of computers, tablets, E-readers, video game consoles etc).
It seemed to me like a good idea since I have a fast enough WiFi I can just use my Mac as the hotspot and connect all devices through it then sniff the packets with wireshark and limit the speed of the transfer using "Network Link Conditioner" my question is, would limiting the speed of transfer with the network link conditioner affect the devices using my computer as a hotspot? or does it only affect my personal computer and I need to figure another way of limiting the speed to successfully simulate what I need?
I am not 100% sure what you are after, but seeing you mentioned limiting bandwidth on your Mac, this may be in use:
Basically, you'll need a PC that can run FreeBSD and two network interfaces (e.g. a built in NIC plus one other card). You then setup the box to bridge those two cards.
Check out this tutorial to see how Network Bandwidth Latency and Delay Simulation Tutorial
Once setup you can then control the parameters of that bridge using the ipfw command in FreeBSD, allowing you to change bit rates, latency and simulate packet loss.
With this box in between your video sources (the internet?) and with a wifi router on the other side to connect your devices to, you'd be able to simulate a variety of conditions.
[Note: credit for digging this out this link needs to go to a colleague of mine, but I used this on a project once he'd set it up and it was very powerful]
I'd like to garner fellow SO'ers experience with regards to the issue of UDP packet loss (or drop-out).
Initially my understanding is that given direct point to point connections where the NICs are connected via a crossover cable and ample buffer on the NICs and timely processing of said buffers, that there 'should' be no packet loss or packet ordering issues. I believe this is also the case given one good/high-end switch in between the points.
Excluding the above scenario, what is the expected average UDP packet loss over a LAN
What scenarios cause UDP packet ordering issues?
No idea on the UDP packetloss on average LANs. I assume reasonably low on modern switched networks, otherwise your LAN or endpoints are too highly loaded. :)
The re-ordering is probably easiest to achieve when routes are brought up and down; say, one of the switches in your organization is under enough load that re-organizing the tree makes sense and traffic is sent through different switches. More likely is your ISP's peers coming and going, or reaching traffic limits, and the priority of packets through them changes -- old packets were in flight on the heavy-loaded network, new packets are in flight on the lighter-loaded network, and they arrive out of order.
I too am looking for an expected average. I found that from a direct link (PC to PC) packet loss occurs very rarely, although it definitely occurs. Availability was something like 99.9% at 1 kB packets # 50 Hz.
I have seen reordering just by sending and receiving on the same network interface.
I concluded that this occurs because each packet is handled asynchronously so that there is a chance of a newly arrived packet being processed before packets received prior to the newly received one.
On my basic gigabit switched LAN I get zero packet loss at even 50,000 packets per second, with FreeBSD, Solaris or Linux.
However Windows is something quite special, I easily see packet loss on exactly the same hardware at low speeds such as 10,000 per second. This is mainly due to buffer overflow between WinSock and the NIC, if you drive the packets faster you lose more, if you space out the packets you drop less.
There is no magical number, my situation is probably worse due to Broadcom having terrible Windows drivers.
You can easily see packet ordering issues, however it is almost always only the last two packets switched. This is an artifact of how switches function.
Interestingly what you haven't mentioned in Wi-Fi, radio signals are highly subject to interference and environmental conditions.
I have created a bandwidth meter application to measure total Internet traffic. I need to test the application with relatively high data transfer rates, such as 4 Mbps. I have a slow Internet connection, so I need a simulator to test my application to see the behavior with high throughput rates.
As an option, you can run some HTTP server in one virtual machine with NAT'ed network adapter and test your bandwidth meter against it from the host system or a similar VM.
There are commercial packet generators that do this, and also a few freely available ones like PackETH and Bit-Twist.
There are also other creative solutions. For example, do the packets need to be IP packets for your purpose? If not, you could always get a "dumb" switch or hub (no spanning-tree or other loop protection) and plug a crossover cable into it. (or a straight-through Ethernet cable would work if the switch supports Auto-MDIX) The idea would be that with a loop in your network, the hub/switch will flood the network to 100% for you since it will continually re-forward the same packets.
If you try this, be sure yours is the only computer on the network, since this technique will effectively render it useless. ;-)
You could always send some IP broadcast packets to "seed" the loop. Otherwise, the first thing I think you'd likely see is broadcast ARP packets, which won't help if you're measuring layer 3 traffic only.
Lastly, (and especially if this sounds like too much trouble) I recommend you read up on dependency injection and refactor your code so you can test it without the need for a high-speed interface. Of course, you'll still need to test your code in a real high-speed environment, but doing this will give you much more confidence in your code.