MFAN node
7.5.4 Flow routing policies over the optical queue
This experiment aims to study the behaviour of the three policies defined in Section 7.4:
Newest-flow, Most-Active-flow and Oldest-flow. As previously stated, the difference among
0 0.2 0.4 0.6 0.8 1
20 40 60 80 100 Time (s)
Fair Rate ThFR
0 0.2 0.4 0.6 0.8 1
20 40 60 80 100 Time (s)
Priority Load ThPL
Figure 7.14: Fair Rate and Priority Load evolution in a TCP-dominated scenario (Newest-flow policy and OQth = 80%).
0 0.2 0.4 0.6 0.8 1
20 40 60 80 100 Time (s)
Fair Rate ThFR
0 0.2 0.4 0.6 0.8 1
20 40 60 80 100 Time (s)
Priority Load ThPL
Figure 7.15: Fair Rate and Priority Load evolution in a UDP-dominated scenario (Newest-flow policy and OQth = 80%).
them is the choice of which flow is to be transmitted over the optical queue upon conges-tion of the IP layer. Therefore, the following focuses on the performance of the optical queue. Firstly, the results are shown when the system is TCP-dominated and, secondly, the performance of MFAN under a UDP-loaded scenario is studied.
MFAN Performance in an TCP-dominated scenario
Figure 7.16 shows the total number of UDP and TCP flows switched in the optical layer during the 100 seconds that the simulation lasts for the three policies, with OQth in the range 10% to 90% of the total queue length.
23000
Figure 7.16: Total number of UDP and TCP flows switched in the optical layer (over 100 seconds). TCP-dominated scenario.
First of all, it is important to notice that only a few UDP flows are routed over the optical layer in the cases of Oldest- and Most-Active-flow policies. This is because, with these two policies, only some UDP flows are detected as elastic flows (false positives). On the other hand, it can be seen that the Newest-flow policy sends a greater number of UDP flows through the optical queue. This has a tremendous impact on the performance of the optical queue since the UDP flows, which do not suffer congestion control, increase the overall delay in the optical queue (see Figure 7.17).
5.3 5.4 5.5 5.6 5.7 5.8 5.9 6
10 20 30 40 50 60 70 80 90
Delay (ms)
OQth (%) Newest-flow Policy Most-Active-flow Policy Oldest-flow Policy
Figure 7.17: Mean delay of the UDP packets in the optical queue (Confidence inter-vals=95%). TCP-dominated scenario.
Finally, Figure 7.18 shows the average goodput of the TCP flows in the optical queue, for different queueing threshold OQth values. Again, the Newest-flow policy shows the worst results (that is, low goodput values). Concerning the other two, the Oldest-flow policy presents the best results among the three policies, given that the number of TCP flows accepted is smaller than those accepted by the Most-Active-flow policy (see Figure 7.16 bottom). The reason for this is that the Oldest-flow policy is more accurate at detecting the heaviest flows, since the Most-Active-flow only considers the “backlog”, which is a short-term measure of the heaviness of the flows.
MFAN Performance in an UDP-dominated scenario
This section shows the results when the greatest amount of traffic is UDP. Figure 7.19 represents the number of TCP and UDP flows sent to the optical layer in the simulation.
The amount of UDP flows is almost the same for all policies, but the Newest-flow policy sends more TCP flows to the optical layer.
According to the amount of UDP and TCP flows in the optical domain (Figure 7.19), the greatest delay is achieved when using the Newest-flow policy (see Figure 7.20). However, the difference among the policies is below 0.1 ms. If we compare this results with the ones in the TCP-dominated scenario (Figure 7.17), we realize that the number of UDP flows is
800
Figure 7.18: TCP flows goodput in the optical queue (Confidence intervals=95%). TCP-dominated scenario.
Figure 7.19: Total number of UDP and TCP flows switched in the optical layer (over 100 seconds). UDP-dominated scenario.
decisive for the queuing delay. The number of TCP flows does not greatly influence the UDP queueing delay, because of the congestion avoidance mechanism.
5.08 5.09 5.1 5.11 5.12 5.13 5.14 5.15 5.16
10 20 30 40 50 60 70 80 90
Delay (ms)
OQth (%)
Newest-flow Policy Most-Active-flow Policy Oldest-flow Policy
Figure 7.20: Mean delay of the UDP packets in the optical queue (Confidence inter-vals=95%). UDP-dominated scenario.
The goodput achieved by the TCP flows is represented in Figure 7.21. In this scenario the performance of the Active-flow policy is better than Oldest-flow policy. The Most-Active-flow policy sends to the optical layer the flows which are transmitting a greatest amount of traffic. Moreover, as P L > T hP L, this sends only the flows classified as streaming ones. This pattern matches with the TCP flows that are in the slow start phase and do not reach the congestion avoidance phase. When these flows are sent to the optical queue, they can increase their TCP transmission window, thus increasing their goodput. However,
“old” TCP flows sent to the optical layer are flows in the congestion avoidance phase, so they do not achieve higher bit rates.
Performance study with different traffic profiles
According to the results of the previous sections, we discover that the performance of the policies depends on the traffic profile observed in the network. The best goodput is achieved when the Oldest-flow policy is used over a TCP-dominated scenario, whereas the Most-Active-flow policy outperforms when the system is mostly loaded by UDP flows.
This evolution is shown in Figure 7.22. When the proportion of UDP flows is greater than
1500 2000 2500 3000 3500 4000 4500
10 20 30 40 50 60 70 80 90
Goodput (Kbps)
OQth (%)
Newest-flow Policy Most-Active-flow Policy Oldest-flow Policy
Figure 7.21: TCP flows goodput in the optical queue (Confidence intervals=95%). UDP-dominated scenario.
TCP flows, a better goodput is achieved by the Most-Active-flow policy. The UDP delay is almost the same as with the Oldest- and Most-Active-flow policies. In light of this, a new “Hybrid policy” could be defined on attempts to exploit the benefits of both policies.
Such a “Hybrid policy” would use the Most-Active-flow policy when the system is loaded by UDP traffic and it would follow the Oldest-flow one when TCP traffic dominates.