Reasonable Forward-delay time

Section 4.2 describes how an extra forward delay helps reduce redundancy. The forward-fixed delay is used to prevent forwarders from sending unnecessary packets that can be canceled by ACK messages from the destination node. However, this delay time is purely an overhead for the forwarders far away from the destination node. Similarly, the forward-random delay is also unnecessary for forwarders that have no contenders aside them.

Figure 11 shows a simple topology that depicts all kinds of situations for forwarders. The light-blue nodes marked with “S” or “D” stand for the source and the destination nodes, respectively. Other nodes marked with different numbers represent different types of forwarders. FloodingRD in a forwarding machine analyzes incoming packets and messages during a unit period (currently, the unit period is set to one second) to decide which type of forwarders it is. Note that a FloodingRD may play different types of forwarders for different connections that have different source and destination nodes, individually. As such, a forwarder is able to apply reasonable extra forwarded delays to packets that to be forwarded based on which forwarder type it is for a connection.

Figure 11. A simple topology to show different types of forwarders

Type-1 nodes represent forwarders that are in the direction opposite to the destination node. There is a common feature among these nodes: the rate of the successful packet forwarding is less than other types of nodes. On these nodes, retxQueue would be blocked and therefore reduce the waste of bandwidth. More bandwidth can be further saved by extending FW_FIXED_DELAY to aggravate the blocking of retxQueue. Rather than cancel all transmissions on these forwarders, this method consumes little bandwidth but recovers regular functionality more quickly.

A type-2 node stands for forwarders who should not apply any extra forward delay since the destination node is far away from it, and there is no other forwarder nearby.

Type-3 forwarders can notice the existence of each other by receiving duplicate forwarded packets. If another nearby forwarder exists, these adjacent forwarders begin competing the forwarding of a packet. Firstly, each one selects FW_RANDOM_DELAY in a predefined range. Then, the forwarder with smallest random delay will cancel the forwarding of others and become the winner who takes

Type-4 nodes are the nodes that are next to the destination node. A type-4 node has to apply the fixed delay to wait for the acknowledgements of the forwarding packets. If it detects that the fixed delay is not long enough, the delay time should be extended.

Because determining the forwarder type of a node must collect the required information during a unit period, the reaction time is not as instant as the former one.

Besides, since the measurement of those RTTs require the transmissions of data greedy UDP throughputs, TCP throughputs, and latencies.

Table 6 lists FloodingRD with different configurations used in these experiments.

The RF daemon is provided as a contrast, which enables all functionalities with fixed parameter settings. The AT_RTT daemon modifies RF to determine the waiting period for an ACK (by the parameter RQ_RETX_TIMEOUT) dynamically. AT_FFD determines the value of FW_FIXED_DELAY by the number of ACK packets from the destination node. The AT_FRD daemon extends the value of FW_RANDOM_DELAY by detecting the existence of other forwarders aside it. The AT daemon enables all functionalities described above.

Symbol Describe

RF Enable forward-random delay and retransmission AT_RTT Decide the waiting period for an ACK dynamically AT_FFD Decide the value of FW_FIXED_DELAY automatically AT_FRD Decide the value of FW_RANDOM_DELAY automatically AT Enable all Auto Tuning functions

Table 6. Types of FloodingRD

Because Auto Tuning can change the value of RQ_RETX_TIMEOUT to fit the requirements of different network environments, the value of this parameter is reduced to be 40 instead of the original value 80. However, this value is similar to that used by AT_RTT, and the performances of daemon AT_RTT are therefore similar to those of daemon RF.

Figure 12 presents the average throughput for greedy UDP connections in a chain network with 2 nodes to 5 nodes. In 2-node cases, only the AT_RTT and AT daemons raise the throughput performance. Because the extra forward delay mechanism only takes place on forwarders, it can not provide any improvements when no forwarders exist in 2-node cases. Generally, the reduction of the values for the FW_RANDOM_DELAY parameter can improve the average throughput more than that for the RW_FIXED_DELAY parameter. Besides, the AT daemon can double the average throughput in 3-node cases. These improvements become less and less significant while the number of nodes increases.

Intuitively, these mechanisms only decrease the latencies; how can they improve

Auto Tuning, the RTT time will be decreased by taking off the extra unnecessary forward delay overhead, and the retransmission timeouts can therefore be reduced further and raises the UDP throughputs.

UDP Throughput

Figure 12. Average UDP throughput to compare functions of Auto Tuning

UDP Throughput

Figure 13. Average Latency under one-way greedy UDP

Figure 13 presents the measured latencies in the same experiment settings with Figure 12. These results prove that Auto Tuning functionalities indeed reduce the latencies. On the other hand, the results also provide an evidence of the relationship

between latency and UDP throughput in our scheme. We can observe that the daemon, which can reduce latency, can raise UDP throughput as well.

The average RTT time is measured on the source node. Figure 14 organizes these data in the same experiment settings and provides another evidence of the relationship between latency and UDP throughput.

Figure 14. Average RTT time at the source under one-way greedy UDP

Figure 15 illustrates the average TCP throughputs in the same topology. Unlike UDP, the throughput of TCP is limited by the protocol design rather than our retransmission scheme. Therefore, the reduction of latencies influences TCP performance slightly.

Figure 15. Average TCP throughput in a chain network