Discussion

As we can see from the results, some times the needed BR is less than that suggested by TFRC. In this case, where the encoder gives less BR than TCPF suggestion, the additional unused BR can be used to add some enhancement layers, in the case of multilayer encoding. Another option is to prefetch a part of the stream data, if possible for the streaming applications, so that it can be used when there are loss or congestion. Another possibility is to use FEC to increase the quality by protecting against loss. As shown in Figure 8.1, we place the NN module in the receiver. This choice is to avoid the need to use other protocols to give feedback on the network statistics (e.g. loss, etc.) to the sender. Obviously, in two-way sessions, it must be implemented in both sides. In other words, each of the sender and the receiver must has its own module of all the previously mentioned ones. All the feedback information (from the sender to the receiver or vice-versa) should be sent using the TFRC. This is because, unlike RTCP which sends the information back every 5 sec., TFRC sends the acknowledgment one time every RTT estimated period of time. In this case, the sender can change its sending rate rapidly based on this information. However, as suggested in the literature [108,124,126], changing the sending rate too fast can lead to an unstability problem. In addition, changing the sending rate with high frequency will influence the human perception considerably, as it degrades the overall quality. It should be also mentioned that one of the drawbacks of using the equation-based TFRC is the large amount of feedback information needed, but this is a common problem of all the rate control protocols aimed to react rapidly to the changes in the network state.