## 4 Performance Evaluations
### Traffic Analysis  
We have conducted a statistical traffic analysis based on the survey results. We used 20 iperf UDP multicast sessions at 15 Mbps (_i.e._, a reasonable bandwidth for HDTV) over Linux implemented DiffServ EF (Expedited Forwarding) service [14]. Experiments have been conducted for two bottleneck link bandwidths; 100 Mbps and 200 Mbps (_i.e._, the bandwidth of the EF service over a link in the edge network shown in Figure 1). Each multicast session was active for 600 s at the server. However, if no user has joined with a channel there was no traffic from that multicast session over the bottleneck link. Usually popularity distribution of video content is considered as a long-tail distribution and more precisely assumes a zipf distribution [15, 16]. This indicates that popularity is high for few top channels and decays fast for non-popular ones. For simplicity, such a distribution abides by the 20-80 rule--that means 20% of the contents are watched by 80% of the users. Therefore we have selected 4 channels as very popular (80% users watching) and remaining 16 as less popular (20% watching). Within each category a user selected a channel with equal probability (_i.e._, creating a discrete step-wise distribution). UDP and TCP short-lived unicast flows applied as background traffic (simulating VoD) also using the EF service. UDP (10 flows at 2 Mbps) and TCP (10 flows with window size of 85 KBytes) unicast flows were applied with random durations (0...600 s) at random start times (0...600 s). Packet size of all the flows was 1470 Bytes and a RED queue of size 400 Kbytes (RED parameters: min-thresh 100 Kbytes, max-thresh 300 Kbytes, dropping probability 0.1) was used for the EF class. Under the _ProxyTV_ traffic analysis, we have chosen (according to the survey) that more than 80% of the users wait for another user to join (_i.e._, if IPTV provider decides the rates to 2.1 Euros for non-premium content and 8.7 Euros for premium content). Each experiment was repeated for 10 seed-values. We have only considered joining behaviour of the users to demonstrate persuasiveness. The leaving behaviour has not been considered and therefore a user who joined at the beginning was active in the session throughput 600 s duration. In the both TV scenarios (marked as _StdTV_ and _ProxyTV_ in the graphs), all users joined a channel during a limited time at the beginning. Figure 5a and b shows respectively the average values of receiving rate and packet loss rate of the multicast sessions at each user through a link bandwidth of 100 Mbps with and without the _ProxyTV_ concept in place for different number of users. Figure 5c shows the number of multicast sessions (corresponding to IPTV channels) consumed the DiffServ EF bottleneck in this scenario with 90% confidence intervals. Under _StdTV_ with 5 users, an average of approximately 4.0 sessions is used and it receives at around 13 Mbps rate. When the numbers of users are increased, the receiving rate degraded due to sharing of the bottleneck by many multicast sessions (reaching almost all 20 channels with more than 300 users). With _ProxyTV_, the number of multicast sessions at a time is significantly less than that of _StdTV_ from 5 to 800 users. The decline of the receiving rates is not as drastic as with _StdTV_. _ProxyTV_ approach only reaches the saturation point of 20 channels with more than 800 users. According to the graphs, an ISP can statistically achieve considerably lesser packet loss rate in the service as a QoE parameter even at one third of the maximum link bandwidth required for all the channels (_i.e._, 20 \(\times\) 15 Mbps) with _ProxyTV_ in compared to _StdTV_. Figure 5: Statistical performances with and without \(ProxyTV\) (100 Mbps link bandwidth). a. (top) Receiving rate; b. (middle) Packet loss rate; c. (bottom) Multicast sessions. Figure 6: Statistical performances with and without _ProxyTV_ (200 Mbps link bandwidth). a. (top) Receiving rate; b. (middle) Packet loss rate; c. (bottom) Multicast sessions.