create new tag
, view all tags
To limit the scope of the Lotka-Volterra Congestion Control test, a smaller one clusterhead and up to three source ecosystem was utilised (Figure 21). This allowed for a small scale source/sink (child/parent) test of the algorithm without the complexities of a relay node or larger network. In this case, the clusterhead was programmed as a WiSeNeT sink, and the assumption was that the clusterhead communicated with the network sink (its parent) under a different frequency band, so that no interference is caused. Note that it is the queue length at the clusterhead that is used to drive the congestion control scheme.


Figure 21: Network for LVCC test

A key component of LVCC algorithm involves the receiver (in this case, the clusterhead) broadcasting a backpressure signal (BS) back to the senders (the sources) with the number of packets or bytes received at each period T, depending on the metric used. The sources then use BS to calculate their new individual transmission rates (population size of a species) based on their own rates and the contribution of the other sources competing for the same buffer space (limited resource). This recalculation is done at each period T, and is ideally synchronised with the receipt of BS.

Figure 22: LVCC source performance of the “true” algorithm under WiSeNeT

Implementation of “true” LVCC resulted in the performance as shown in Figure 22. Note that “true send” was chosen over “moving send” in this instance. It was found that the network was able to maintain stable performance with one operational source, and that convergence time to stable speed was relatively quick. However, as soon as a second source was switched on, the algorithm immediately became unstable and ultimately did not reach any stable solution. As soon as the second source was switched off, the network returned to a stable solution quite quickly. Analysis of the network revealed that under “true” LVCC, although a nice and clean concept, network synchronisation ultimately leads to packet collisions as demand exceeded capacity at common periods/intervals. If BS is not received by the source, then the LVCC algorithm does not perform as expected. Note that BS is a priority packet, and therefore is not ACKed or resent. Furthermore, timed and synchronised BS potentially leads to increased network overhead as packet collisions with the BS packet are resent, adding extra pressure on the capacity of the network. As well, “true send” seemed to be unable to cope with the rate changes and retries – “moving send” may produce a different result to the above test; however no results are available for “moving send” on the above setup.

It was noted that on the original testbed, a highly modified implementation of LVCC had been programmed into the link layer. The key differences between this “modified” version and “true” LVCC are that:

  • It embeds the BS inside each ACK sent back to the sender.
  • The calculation of the new individual transmission rates at the source were triggered on receipt of the ACK (and therefore BS).
  • It used a variant of “moving send”, where after each ACK/BS, the next send time was determined immediately before sending out another packet.
  • No synchronisation was achieved as this LVCC process was event-driven rather than time driven.
Despite these differences, the following scenario was implemented on the original testbed using a Python script under the constraints presented in Table 6:

  • 1. T = 0 seconds: Start sink
  • 2. T = 1 second: Start source 1
  • 3. T = 61 seconds: Start source 2
  • 4. T = 121 seconds: Start source 3
  • 5. T = 301 seconds: Terminate source 3
  • 6. T = 331 seconds: Terminate source 2
  • 7. T = 361 seconds: Terminate source 1
  • 8. T = 366 seconds: Terminate sink
This achieved results as expected for LVCC (Figure 23). Its performance converged quickly to the new relevant stable solution for all changes in the number of nodes. This is due to the fact that BS packets are now always received by the source, by having them embedded in the ACK packet.

Flows Stable Solution
1 3.333333333
2 1.739130435
3 1.176470588
4 0.888888889
5 0.714285714
6 0.597014925
7 0.512820513
8 0.449438202

Key Variables
alpha 1.1
beta 1.2
r 0.75
K 4
Table 6: Constraints for “modified” LVCC test

Figure 23 : LVCC performance of the “modified” algorithm under the original testbed

WiSeNeT was subsequently re-configured with the same “modified” version of LVCC, and achieved comparable results, as per Figure 24. Minor changes were made in the link layer to incorporate the BS inside the ACK packets and to use “moving send”, as well as modifying the LVCC thread at the network layer to block until a BS (ACK) packet is received instead of recalculating at each period T.

Figure 24: LVCC performance of the “modified” algorithm under WiSeNeT

At the sink, LVCC attempts to maintain an average stream throughput of the stable solution for one source, regardless of the number of sources sending (in this case, 3.33 packets/second). An observation of the stream throughput at the sink during the WiSeNeT run presents results that support this (Figure 25).

Figure 25: LVCC sink throughput of the “modified” algorithm under WiSeNeT

Note that as the LVCC source transmission rate calculation is event driven, the x axis on the rate calculation graphs are calculation number, not time. However, the stream throughput (or instantaneous receive rate) at the sink is obtained on a timed basis (per second), and is plotted accordingly.

-- XiaohongWu - 2012-01-22

Topic revision: r2 - 2012-01-23 - XiaohongWu
This site is powered by the TWiki collaboration platformCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback