Previous

Content

Next

4.0.- Two UDP flows  

Warning: this page has a bundle of png and gif pictures; it will last a little if you have an slow Internet connection.
Continuing with our study we will see now how two UDP flows compete for network resources. The topology will be the same we used before for One UDP flow; this time we have two CBR sources in the host A.

In both hosts we have UDP. Host A has a two CBR sources (Constant Bandwidth Rate) that sends packets at a fixed rate of 0.95 Mbps each. 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-2flow.tcl.
At time 0.1 seconds both CBR sources in A start to send packets, and at time 10.0 seconds they stop of sending 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. Both flows behave exactly the same. The green curve corresponding to the flow #2 is printed after the red curve correspnding to the flow #1; then, only the green curve is showed. Observe that response is like we had before when trying with one UDP flow. We have reduced the individual throughput of each flow to just 0.95 Mbps to permit the connection link to accomodate both of them. Flows are flat, no oscillations, really a very nice behavior.
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.

As expected, the system throughput increase slowly until reaching an steady state of a little more than 900 Kbps. Here it is possible to distinguish the two different flows.
Let's see how latency goes with two UDP flows, here we have the graph:

Very, very stable at 14 ms for flow #1 and 18ms for flow #2. Really a very, very stable and low latency. Don't forget that TCP latency was almost 80 ms for the same environment.
With this very stable latency we will expect a jitter of being almost zero; let's see this:

Almost no jittering. Again UDP is the right choice when latency and jittering could be a problem for the transported traffic.
Next let's check the total bytes transferred in these 10 seconds; for flow #1 we have:

KB sent: 1148.437500
For flow # 2 we have:

KB sent: 1148.437500
Total bytes transferred are then:

KB sent: 2296.875000
Two observations. First the total bytes transferred are exactly the same than before when just one UDP flow was used. Second, the bandwidth share is the same, i.e., no flow has problems because it is competing with the other. It is true because each flow is 0.95Mbps and both combined are below the link capacity. Again, as soon as we have some way to define in advance the throughput of each UDP flow, and as soon as all of them when being added do not surpass the link capacity, UDP behavior is close to what we want. No losses and a flat rate transmission.
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, for flow # 1 losses are as follows:

   Packets sent:  1176
Packets dropped:     0
   Total losses:     0.000000%
and for flow # 2 they are:

   Packets sent:  1176
Packets dropped:     0
   Total losses:     0.000000%
Great!!  No losses in each flow and the same number of packets transmitted. UDP couldn't have done its job better.
Okay, to continue with our study let's start changing some parameters of the test. We will select now small packets of 100-byte size instead of big packets of 1000-byte size. The instant throughput graph for this new scenario is as follows:

Again, it is almost impossible to catch any difference. Even with 2-flows, UDP hasn't any problem with the packet size. This graph is almost a carbon copy of the previous graph using 1000-byte packets.Let's see how system throughput goes here with 2 UDP flows:

Again, the same. The packet size seems not being a matter for this case.
Let's check the latency. Being the packets smaller the latency should be less now. Here we have the graph:

Latency is now 10.4-10.8 ms, this means, practically the link propagation delay. The variation is negligible. This latency is exactly as expected. As we said before, 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 for the packet of the first flow (red one); the packet from the second flow (green one) goes back to back with the first one and takes 0.4ms more to reach the end. Its latency is then 10.8ms. Using 1000-byte packets,  the packet from the first flow takes 4ms to be transmiited using a transmission rate of 1900000 bits/sec. Then its latency is 10+4ms=14ms; the next packet from the second flow, back to back with the first, takes 4ms more, being its latency 10+4+4ms=18ms.
Our latency is almost perfect having into account the link propagation delay; let's have a look to the jitter:

As before when having one flow, it's 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; as before, because our system throughput didn't suffer with the new packet size, we have to expect the same quantity of bytes transferred; for flow #1 we have:

KB sent: 1148.144531
For flow # 2 we have:

KB sent: 1148.144531
Total bytes transferred are then:

KB sent: 2296.289062
Both flows transfer the same number of bytes and the total bytes transferred are almost the same as before when working with 1000-byte size packets. Also, the total bytes transferred are almost the same as before when working with just one UDP flow.
Let's finish these tests checking losses. Here we have them for flow #1:

   Packets sent: 11757
Packets dropped:     0
   Total losses:     0.000000%
And for flow #2:

   Packets sent: 11757
Packets dropped:     0
   Total losses:     0.000000%
Very well. No losses at all and both flows behave exactly the same.
Well, again as occurred before when testing one flow, UDP ignored the packet size reduction and maintained its high score; Let's check now what happen if we try with packet of 4000-byte size. The first graph using this bigger packet size is the instant throughput:

Again, UDP is not very concerned about the packet size; it simply makes its job. Graph is almost the same compared with tests using 1000-byte and 100-byte packet sizes.
Let's check the system throughput; here we have:

Observe that due to the packet size we have some initial noise but after stabilization the graph for each flow is very flat and steady state at 900 Kbps as expected. UDP does not generate peaks and valleys as TCP does trying to adapt itself to the network conditions. UDP flow is flat as soon as we have a constant bit source (CBR) and the link has enough capacity to support the bandwidth required.
Let's have a look to the latency for this scenario:

This graph indicates back to back packets. A red flow packet enters before and just behind it a green flow packet. Red flow packets latency is 26ms (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). Green flow packets latency is 16ms more because packets are traveling back to back. Then we have 26+16 = 42ms. Anyway, these values are far below TCP values where latency reached values very close to 400ms.
Jitter should be almost zero; latency is very stable for each flow; let's see:

Practically zero. Let's check now the number of bytes transferred using these bigger packets; for flow #1 we have:

KB sent: 1148.437500
And for flow #2 we have:

KB sent: 1148.437500
Total bytes transferred are then:

KB sent: 2296.875000
Very well!!  Same bytes transferred in each flow and total bytes transferred being the same as before when using 1000-byte size packets. Despite the unperceptible noise we observed in the instant bandwidth and system throughput graphs and the higher unavoidable latency, the UDP behavior is almost the same for the two different size of packets.
Finally, let's check losses in each flow; here we have losses for flow #1:

   Packets sent:   294
Packets dropped:     0
   Total losses:     0.000000%
and for flow # 2 they are:

   Packets sent:   294
Packets dropped:     0
   Total losses:     0.000000%
Less packets but no losses at all.
Again, with two flows, UDP surpasses all tests until now with very high score, enough higher than TCP. Next 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:
 
 
Problems begin for UDP. It is unable to understand that it has less available capacity and each flow tries to maintain its constant rate of 0.95Mbps. But in this case the link capacity is unable to support this load. Something has to occur and we see in the graph that the green flow was starved just when both flows reached 500Kbps filling up the link availability. From here the red flow survives and reaches its rate of 0.95Mbps but with some noise. The green flow didn't have such a good luck and it is seriously starved. It's natural because as we saw above a red flow packet leaves the source before, followed back to back for a green flow packet. The second packet encounters an adverse environment and it is probably dropped. Let's have a look to the buffer queue for this scenario. The fight there should be until being destroyed.
 
   

 

Very nice graph. Red flow almost fill the queue (18 packets) leaving space for just 2 packets for the green flow. All green flow packets above two (2) trying to enter the queue will be dropped. We will check losses below to confirm this scenario.
As you see UDP can work very nice but you have to be sure that available link bandwidth is not surpassed. It's here where having some kind of admission control is a must when trying with this kind of protocol.
The system throughput should reflect this behavior; here we have:

Just an image of what we have above.
Let's check the latency; now we have a 20 packets queue in the buffer; latency is as follows:

Yes, latency is very high. The queue length is now oscillating around the 20 packets. We have 20000 bytes waiting to be served creating an additional delay of 160 ms to the already fixed portion of 10 ms due to the link propagation delay. Total calculated latency is 170 ms.
This behavior is very similar what we had before when studying one UDP flow. We have a bottleneck again. Have a look to the comments we did before here.
Jitter should presemt some problems too; here we have the graph:

Green flow is supporting the worst part. Jittering is almost 8ms in this case. Really if we want to work with UDP it is very important to know in advance how much the traffic will be and have enough link capacity to support this.
Let's see now the number of bytes transferred; they should be limited by the new link bandwidth capacity. For flow #1 we have:

KB sent: 1148.437500
And for flow #2:

KB sent: 78.125000
Total bytes transferred are then:

KB sent: 1226.562500
For flow #1, number of bytes transferred are the same that before when having a 2 Mbps link, but you see that flow #2 was seriously starved.
Finally let's check losses, for flow #1 we have:

   Packets sent:  1176
Packets dropped:     0
   Total losses:     0.000000%
Conditions don't change for this flow; same number of packets sent with no losses at all.
For flow #2 we have:

   Packets sent:  1176
Packets dropped:  1096
   Total losses:    93.197279%
Highly damage this flow. Less than 7% of packets survive and reach the end side.
Continuing with our tests we are going to see the system response when we change the buffer size in the link. Our buffer is actually 20 packets. Let's try now with 50 packets. Instant throughput is as follow:

We have here the same story. No difference with the 20 packets buffering option. Let's compare the queue length for both cases. Using 20 packets buffering we have:

And using 50 packets buffering we have:

Exactly the same; excess of buffering doesn't matter because buffer space is never filled up. I'm not going to show you the rest of the graphs for this scenario; they are exactly the same to the 20 packets buffering option. Hope you trust me.
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, nothing different. Something really natural because if we see above we can observe that queue length never reach more than one packet, then it doesn't matter if our queue is 5 packets instead of 20 packets. Let's check the queue length for this new buffering condition:

Again, exactly the same graph. And again I'm not going to show you the rest of the graphs for this scenario because they are exactly the same to the 20 and 50 packets buffering options. You have to trust me for a second time.
Well, UDP has practically the same response with 20, 50, or 5 packets buffering. It doesn't queue in buffers and its behavior is steady in all these cases.
Our last test 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:

Again, in this environment the time required to reach the final throughput is a little bit longer. This can be see it even better having a look to the system throughput, let's check this graph:

Compare this graph with the same but having a 10ms link and you will see that now the time to reach the steady state is a little bit longer. The curve slope is less steep. The longer link propagation delay requires that it will take a little more time to reach the steady state condition. Exactly the same as we saw before when dealing with just one UDP flow.
Of course, latency should be higher; here we have:

Again, we have red and green flow packets traveling back to back. Time to transmit a 1000-byte size packet in this emvironment is 4ms. First flow (red one) packet has a latency of 100ms (propagation delay) + 4ms (transmission time) = 104ms. Next packet, from the green flow, reach the end side just 4ms later, having a latency of 108ms.  Observe that these latencies are unavoidabled and the minimum being possible on this environment. UDP behavior doesn't add any ms more to the natural latency.

Being latency so stable jitter should be almost zero, here we have the graph:

Nice, very nice. Despite the longer link propagation delay, UDP behaves as better as is possible giving actual conditions.
 
Let's check not if bytes transferred have some variation in this new environment; for flow #1 we have:
 

KB sent: 1148.437500
 
In this case the flow is exactly the same; no de-rating. For flow #2 we have:
 

KB sent: 1148.437500
 
Total bytes transferred are then:
 

KB sent: 2296.875000
 
We can say that the new higher link propagation delay has no effect on the UDP throughput.
 
Finally let's check losses; for flow #1 these are:
 

   Packets sent:  1176
Packets dropped:     0
   Total losses:     0.000000%
Same number of packets sent with no losses; For flow #2 probably we will have the same ideal situation:
 

   Packets sent:  1176
Packets dropped:     0
   Total losses:     0.000000%
Excelent!! Same number of packets sent with no losses. The longer link propagation delay doesn't affect 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.
 
I'm going to repeat here what we said when we were studying behavior of one UDP flow. Conclusions are the same, i.e.: "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. "
 
   

 
Both, TCP and UDP are actually used to transport traffic in Internet; our next step will be to study how One TCP Flow and One UDP Flow share the same network competing for resources. This will be the theme of our next section.
 

 
Previous

Content

Next