Previous

Content

Next 

2.0.- One UDP flow  

Google
Warning: this page has a bundle of png and gif pictures; it will last a little if you have an slow Internet connection.
To continue with our study we are going to repeat the tests we did before with TCP protocol in section 1.0.- One TCP flow, this time using UDP protocol. The topology is the same in this case, i.e., a simple link connecting two hosts, but the end applications have to be changed to be used with UDP:

 
In both hosts we have UDP. Host A has a CBR source (Constant Bandwidth Rate) that sends packets at a fixed rate of 1.9 Mbps. The packets are 1000-byte size. Host B is in charge only to destroy the packets it receives. The link is a 2 Mbps link having a propagation delay of 10 milliseconds. The buffer size is 20 packets, then our queue can have a maximum of 20 packets. The queue is DropTail (just a FIFO queue). Most of the actual routers and hosts in the Internet use this kind of queue.
 
The tcl code to feed the ns-2 simulator is in upd-1flow.tcl.
 
At time 0.1 seconds the CBR source in A starts to send packets, and at time 10.0 seconds it stops to send packets.
 
To get information from the simulation we use, besides the ns-2 simulator, the awk program to parse the ns-2 output, and the gnuplot utility to plot the results.
 
For each test we are going to get the following information:
 
  1. Instant throughput in kbps
  2. System throughput in kbps
  3. Latency in ms
  4. Jitter in ms
  5. Bytes trasferred
  6. Losses
To filter noises we use EWMA (Exponential Weighted Moving Average) to smooth the outputs using α = 0.9, before ploting.
 
The first graph obtained from the test is instant throughput in kbps:
 
   

 

Okay. After the initial and very fast rate increase the steady state throughput is reached and maintained very stable, just an horizontal line, at a little less of our setting of 1.9 Mbps. The small difference is due because ns-2 estimate 1.9 Mbps as being 1900000 bits/sec using an interval for 1000-byte packets of 4.210526 ms. But the udp1flow.tcl source file calculates throughput as being 1900000 / 1024 kbps = 1855 kbps, just the value you see in the graph above. Nevertheless, the important thing to observe is the very stable rate offered by the UDP protocol.
Let's see now the system throughput. Exactly the same as it was for TCP, the instant throughput is calculated dividing the bytes of each packet (1000 bytes) by the time required to send the packet. The system throughput is calculated dividing the total bytes sent up to a given time by the total time transcurred in seconds. In fact, the system throughput is what really have importance because it says what is the power of your transmission, this means, how many bytes you are transfering by unit of time.

Okay, as expected, the system throughput increase a little more slowly until reaching an steady state of almost 1.855 Mbps.
Let's see how latency goes with UDP, here we have the graph:

Fine!! Very, very stable at 14 ms. Don't be foolish for this graph. Observe that the variation is negligible, from 13.999 ms to 14.001 ms. Really a very, very stable and low latency. Don't forget that TCP latency was almost 73 ms for the same environment. This is one of the reason why real-time traffic is normally transported on top of UDP instead of TCP. A little more about real-time traffic is here where we talk about VoIP.
With this beautiful latency we will expect a jitter of being almost zero; let's see this:

Almost no jittering. UDP is the right choice when latency and jittering could be a problem for the transported traffic.
What about the total bytes transferred in these 10 seconds? ; here we have:

KB sent: 2296.875000
Calculating the system throughput (st) from this data we have:

st = 2296.875 KB * 8 bits/byte / 9.9 seconds = 1856 Kbps
Almost the same we calculated above.
Finally let's see the losses. As we did for TCP, we calculate losses dividing the number of packets that are dropped by the total number of packets that are sent; then, we have:

   Packets sent:  2352
Packets dropped:     0
   Total losses:     0.000000%
Great!! no losses at all. We adjusted our transmission rate a little less that the link bandwidth and all things go right. This is a big difference with TCP. When using TCP we were not worried about any rate of transmission. The FTP source was always ready to send a packet when TCP was ready to receive and transmit it. Using UDP we have to set the transmission rate of our CBR source to be sure that the transmission capacity of the link will not be exceeded. Keep on reading to see what happen when we obviate this important consideration.
Okay, following the same procedure we used before with TCP let's see what happen when we set the packet size to 100-byte size. Let's start having a look to the instant throughput for this new scenario:

Well, the graph is almost the same, or exactly the same? We need to have hawk eye to catch any difference. It seems that UDP hasn't any problem with the packet size. On the contrary, TCP was severly affected when the packet size was reduced. For 100-byte size packets TCP system throughput was reduced almost one-half. Let's see how system throughput goes here with UDP:

Again, the same. We found an advantage when using UDP instead of TCP. The packet size is not a matter in this case, or at least, for the two tests we did.
Let's check the latency. Being the packets smaller the latency should be less now. Here we have the graph:

Yes... Latency is now 10.4 ms, this means, practically the link propagation delay. Also the variation is negligible. This latency is exactly as expected. A 100-byte packet takes 0.421053 ms to be transmiited using a transmission rate of 1900000 bits/sec. Adding this value to the 10 ms link propagation delay we have a total latency of 10.4 ms.
Latency is very stable, then the jitter should be very close to zero, let's see this:

No more than ± 0.002 ms. Couldn't be better for real-time traffic transportation.
Now let's have a look to the number of bytes transferred; because our system throughput didn't suffer with the new packet size, we have to expect the same quantity of bytes transferred; here we have:

KB sent: 2296.191406
Almost no de-rating. Very nice and efficient the job UDP protocol has done using these tiny packets. It's time to check losses:

   Packets sent: 23513
Packets dropped:     0
   Total losses:     0.000000%
Fine!! Number of packets are now almost ten times more but we have no losses at all.
Well, UDP olimpically ignored the packet size reduction and maintained its high score; then, a curious question would be: what about if the packet is so big as 4000-byte packet size?. The first graph using this bigger packet size is the instant throughput:

What we have here? Incredible..., the same movie. UDP is not very concerned about the packet size; it simply makes its job. Again is almost impossible to find any difference with the tests using 1000-byte and 100-byte packet sizes.
The system throughput should be the same thing, just a copy of the previous one; let's see this:

Exactly. Packet size is not a matter in this case. Latency should be higher because of the bigger packet size; here we have:

Latency climbs up to 26 ms. Well, the time required to transmit a 4000-byte size packet on the 1.9 Mbps bandwidth link is 16.84 ms + the link bandwidth propagation of 10 ms and we are close to our 26 ms latency. But this result is infinitely better than the TCP answer of more than 300 ms for this test.  Again UDP shows us that it is the right choice when dealing with traffic requiring very low latency and jittering.
Let's see if jitter is worst when using these bulk packets:

In spite of the higher latency the new value is almost constant and jittering continue being very close to zero.
The number of bytes transferred should not suffer when using bigger packets; let's check this asseveration:

KB sent: 2296.875000
The answer is exactly the same we got before when using 1000-byte size packets.
Now is time to see if losses are present when using bigger packets; here we have the ns-2 output:

   Packets sent:   588
Packets dropped:     0
   Total losses:     0.000000%
Less packets but no losses at all.
Well, UDP surpasses all tests until now with very high score, enough higher than TCP. But the competition is not over yet. It's time to check how UDP will react when the link bandwidth is reduced. Let's adjust the link bandwidth to 1 Mbps instead of the original value of 2 Mbps. The propagation delay will be kept in 10ms. Here we have the instant throughput for this case:

Well, as was expected the instant throughput reduced itself to one-half with this change. Nevertheless, the graph is very similar, having a high steady state behavior.
The system throughput should also adapt to this new link bandwidth capacity; let's see this:

Nothing unexpected. Let's check the latency; it should be the same having the same 1000-byte size packets and 10ms link propagation delay. Here we have the graph:

Something terrible has happened here. Why the latency climb to these higher values? Immediately we suspect of the queue behavior. Let's have a look first to the queue graph when using a 2 Mbps link. With this bandwidth the latency was 14ms. The graph is here:
 

 
 
The maximum number of packets in the queue is just one, being most of its time empty. Then, queue length doesn't contribute to increase latency in this case. Let's see now the queue when link bandwidth is reduced to 1 Mbps:
 
   

 

Touche!!  Here we have the reason of our increased latency. The queue length is now oscillating around the 19 packets. We have 19000 bytes waiting to be served creating an additional delay of 152 ms to the already fixed portion of 10 ms due to the link propagation delay. Total calculated latency is then 162 ms.
What's the reason of this bottleneck? Why the queue fill practically up to its maximum capacity? The reason should be that we have a constant rate bandwidth (CBR) source generating 1.9 Mbps, but our link is only capable to transmitting 1 Mbps. If this was the case we must have losses when packets leave the source and try to enter the link. We will check this asseveration when having a look to losses, just below.
This latency of 170ms destroys any possibility to transport real-time traffic over UDP in these conditions. This is a very important consideration when transmitting traffic using UDP. The link bandwidth capacity has not to be surpassed by the packet source if we want to have ideal conditions for real-time traffic transporting. The real-time application has to be enough intelligent to self control its rate of source packets when it observes losses to adapt itself to the network capacity. This is an advantage that TCP protocol gives us for free; just because TCP was designed to test, constantly, network conditions trying to utilize as much as is possible of the link bandwidth capacity, controlling at the same time any incipient presence of congestion.
With this high latency we should have problems too with jittering; let's see the jitter graph for this environment:

Yes, we have almost a constant jitter of about 3.789ms. This represents the oscillation we see above in the latency graph and in the queue length graph. This problem avoids the possibility of using this environment to transport real-time traffic.
Let's see now the number of bytes transferred; they should be limited by the new link bandwidth capacity. Here we have:

KB sent: 1227.539062
The number of bytes transferred are now a little bit more than a half of the previously sent. Problem here is that because we are using a constant bandwidth rate source, we must have high losses close to the source, just before the flow enters the link. Let's check the losses to verify this asseveration:

   Packets sent:  2352
Packets dropped:  1095
   Total losses:    46.556122%
Just as was thought. Observe that packets sent are exactly the same (2352 packets), but now only 1257 of them survive the bottleneck and can travel through the network to the other end of the link.
Of course, we could think that this problem would be the same if we use TCP, but instead of having an FTP source that send a packet just when the network is ready to receive it, we set a constant bandwidth rate (CBR) source that simply sends packets to a fixed rate without having to be worried about network condition.  Let's check what happen in this case; using the same environment we used before for UDP let's just change the transporting protocol to TCP. We need to replace the receiving application with a TCP sink that can acknowledge the packets it receives.
The tcl code to feed the ns-2 simulator is in tcp-1flow-cbr.tcl.
The instant throughput in kbps is:

Okay, this graph is very similar that we got before using an FTP source instead. Have a look here.
Let's see now the system throughput:

Again, the patter is almost the same; have a look to the same graph but using an FTP source here:
And now, let's check what we think will be the "ultimate test" for TCP protocol performance using CBR sources; here we have losses:

   Packets sent:  1264
Packets dropped:     0
   Total losses:     0.000000%
Great!! TCP controls fairly well the CBR source. Only 1264 packets are generated and none of them is lost. Observe that if we want or need to use UDP for whatever reason we have, then we must be very worried about the rate of transmission of our sources. This, because UDP can't exercise any control and then, when rate of source is higher that network capability we are going to have, surely, a lot of losses.
This is a great advantage of TCP over UDP. To be sure and avoid network congestion using UDP, we should use some sort of admission control before accepting a new UDP flow in our network. TCP has not this restriction. We can use admission control with TCP but if we don't use it, we know that TCP will do the best to avoid congestion and losses in the network, when the amount of incoming flows surpass the network capacity.
Continuing with our UDP protocol study, now we are going to see the system response when we change the buffer size in the link. Our buffer is actually 20 packets. What about if we take this value to 50 packets?
Here we have the UDP instant throughput:

Really it is difficult to catch any difference with the 20 packets buffer we saw above. Let's see the system throughput:

Again, any difference, in case of having, it is imperceptible. UDP is responding very similar to TCP when trying with an overbuffering network. Let's see now latency:

Exactly the same respect to the case of having a 20 packets buffering. We can suspect that despite of the bigger buffer, it is not being used at all. To confirm our mind let's check the queue length; here we have:

Confirmed!! The queue behavior is the same as before when dealing with a 20 packets buffering; have a look above and you can see that both graphs are almost identical (if not identical at all). The maximum number of packets in the queue is just one, being most of its time empty. Then, queue length doesn't contribute to increase latency in this case neither.
We would expect the same behavior for jittering; here we have:

Again, the response coincides with the previous one. Let's check now the number of bytes transferred and losses. We have in these cases:

KB sent: 2296.875000
Exactly the same quantity of bytes transferred, and:

   Packets sent:  2352
Packets dropped:     0
   Total losses:     0.000000%
Again, same quantity of packets sent with no losses. Then, UDP has reacted the same as TCP when the link is overbuffered but not congested.
Next step is to verify how a buffer reduction to a size of 5 packets, instead of 20 packets can affect UDP behavior.  The instant throughput graph is as follows:

Well, this graph can't be more similar to the previous test having a 20 packets buffering. It seems that UDP is not very concerned about buffer size. On the contrary TCP felt the hit; check the TCP behavior for this case just here. UDP has a better response in front of the underbuffering network. Let's check now the system throughput:

No perceptible difference as you can verify. Latency shouldn't suffer in front of this scenario; let's see:

Just 14 ms as before. UDP is not very worried about the new reduced buffereing capacity. Let's see the jitter response:

Practically no jitter at all. We should expect this behavior. When we checked above, with 20 and 50 packets buffering, the forming queue under UDP, we saw that it never was above one packet. However, to be sure in this case, let's check this graph for this environment:

Exactly the same response. Then, it doesn't matter how large the link buffer is, it is maintained by UDP almost empty most of the time. To finish this test let's check bytes transferred and loss response:

KB sent: 2296.875000
This answer is exactly the same. And losses:

   Packets sent:  2352
Packets dropped:     0
   Total losses:     0.000000%
Same great response. No losses and all packets sent were received at the receiver end.
Well, UDP had a better response that TCP when the network is underbuffered. Practically the response was the same with 20, 50, or 5 packets buffering. The main problem with UDP protocol is that we have to know in advance how much bandwidth the traffic it is carrying will require. If we can resolve this problem, perhaps using some sort of admission control, then UDP is really a great contender against TCP. If we can't have some way to be sure that the incoming flows are going to be supported by the network, it is better to go with TCP; it is safer.
Our last test for one UDP flow will be to see what happen when the link is longer, i.e., the propagation delay is higher. Next tests will be done using a propagation delay of 100ms instead of 10ms, almost a ten times longer link. The instant throughput is:

Okay, in this environment the time required to reach the final throughput is a little bit longer as you see. This increased delay should affect the time necessary to reach an stable system throughput, let's check this graph:

Yes, the curve slope is a little bit less steep in this case. The longer link propagation delay requires that it will take a little more time to reach the steady state condition.
With this longer link propagation delay the latency should be higher; let's have a look to this graph:

Latency, as expected, is the link propagation delay (100ms) plus the time required to move the packet from end to end (4ms). Nevertheless, jittering should be almost zero because latency is very stable. Jitter is here:

 
 
Nice, no problems here. Of course, the long link propagation delay is not the best for real-time traffic. Let's see now what about the bytes transferred:
 

KB sent: 2296.875000
 
The bytes transferred are exactly the same; no de-rating here. Next let's check losses:
 

   Packets sent:  2352
Packets dropped:     0
   Total losses:     0.000000%
 
   

 
Excelent!! Same number of packets sent with no losses. The longer link propagation delay doesn't affect to much UDP traffic except for the initial delay in reaching the steady state condition and, of course, the longer latency, something that is impossible to avoid in this case.
Compare to TCP in this test, UDP surpasses TCP response. TCP was deeply affected when the link propagation delay was increased from 10ms to 100ms as you can see here. Problem to select UDP instead of TCP as a viable transport protocol is how to control losses when the network get congested. If we have a controlled network where admission control can be implemented, and if we can shape UDP traffic to be sure it respects the initial solicited bandwidth, then UDP would be a very nice solution for traffic transport. But, because this ideal conditions can't be implemented yet in Internet, and being the main goal to protect the health of the network against congestion disease, the only solution is to run it with the safer TCP.
But UDP is actually being used to transport real-time traffic in Internet, competing with TCP for the network available resources. It is, then, very interesting to verify how both protocols share the same network, and how, the behavior of each of them affects the other. But, previously, we are going to investigate a little how two flows of the same protocol compete between them for network resources. Our next step will be to study how Two TCP Flows share the same network; but this is a theme for our next section.
   

Previous

Content

Next