Chapter 3 The proposed scheme
3.5 IPTV over Peer to Peer network
We can extend our proposed scheme to Peer to Peer IPTV architecture, which is a more popular and non-commercial business model. P2P IPTV, which means that a client not only receives the packet but also uploads the packets to other peers. The source of video chunk may either be server or other peers. Figure 3.12 shows the architecture of P2P IPTV.
Figure3.12 P2P-IPTV architecture
Since the source of the video chunk may either be the server or other peers in the p2p overlay, a tracker server is needed in this system. The tracker server responds client’s registration and informs client the IP address where it can obtain the video chunk.
Figure3.13 shows the modified proposed scheme that applies to the peer to peer architecture.
28
………….
Peer 1 Peer 2 Peer 3 Peer 7 Peer 8 Peer 9 Peer 10
Tracker Server Source Peer
Internet
Figure3.13 The proposed P2P-IPTV scheme
First of all, client send request to tracker server after the program launch or switches a channel. After tracker detect that there are several peers watching same channel from identical IP address, it assigns a source peer uploads the video chunk to the superpeer in the LAN. As we mentioned before, the broadcast flag is set to one and transmit to superpeer of the LAN. It means that the source peer is playing the role of streaming server in the scheme we proposed before. Additionally, the content provider, which may provides the content to the source peer.
In addition, tracker server assigns a single source to a LAN for simplicity. In the scheme we proposed, the increasing numbers of peers in a LAN that watches identical channel do not require more traffic load; it relies on the relaying of superpeer.
In reality, the download bandwidth and upload bandwidth are not symmetric. The upload bandwidth is often much smaller than download bandwidth. In traditional P2P IPTV architecture, upload bandwidth often be the bottleneck of the system. However, in our
29
proposed scheme, source peer transmit one copy of data packet despite the increasing number of peers. Thus, it allows one single source peer offer more peers’ sessions, which also solves the bottleneck issue. Tracker server is responsible for dispatch clients to a designated source peer in this scheme.
………….
Figure3.14 Tracker server assigns source peer to other peers individually
Figure3.14 shows an example of the proposed P2P IPTV scheme. There are two different channels (A and B) and two LANs. Suppose several peers from LAN B logged in the program and are requesting for both channel A and B. Tracker server assigns source peer A for those requesting for channel A, and source peer B for channel B. If a new peer launched program and turn to channel A, tracker server assigns source peer A to the new peer. However, this new session doesn’t increase source peer A’s load, since the new peer receive the superpeer message of source peer A in LAN B.
30 Session Initiate
Session Initiate
Detection
Superpeer Election
Source Peer respond
Packet Relay
Signal Data
Algorithm
Tracker Server AR Client A Client B
Source Peer respond Streaming Request
Streaming Request Video chunk
Source Peer
Superpeer Video chunk
Figure 3.15 Message flow of proposed P2P- IPTV scheme.
Figure 3.15 shows the signal flow of proposed P2P- IPTV scheme. Tracker server respond client with source peer information, which as the streaming server in IPTV architecture.
31
Chapter 4
Implementation and Experiment
We have implemented the proposed scheme on Linux kernel 9.04. The program is written in C. Thus, we justify our point of view. Furthermore, we analyze network bandwidth and performance improvement of IPTV.
4.1 Implementation
The proposed scheme needs two programs for IPTV architecture, server and the client programs. For P2P IPTV, server’s functionality is replaced by another peer that was designated by the tracker server. Thus, the client program plays both peer and streaming server roles.
Generally, the interface receives packets in three different types of MAC address, broadcast, multicast and the MAC address to it. Nevertheless, for the unique MAC we designated, we have to receive all the packets and drop the packets we don’t need. In order to achieve this goal, the interface should set to promiscuous mode in the first place. After that, promiscuous mode should be turned off while the program is closed.
In general socket programming, packet header including MAC layer, IP layer, and UDP header is filled by the network kernel. However, raw socket API allows us to modify the packet header by ourselves.
32 framework, we can ensure the broadcasting quality and reduce network flow bandwidth.
To begin with, link layer, internet protocol layer and user datagram protocol are all predefined in Linux kernel, or we can build header of our own. However, there are small differences of header definition among various versions of Linux due to implementation issue. Therefore, system provided header format file is recommended.
General speaking, the operation system kernel computes the IP checksum automatically in normal socket function. Nevertheless, raw socket API offers us the authority of modifying network header field information, which means we have to compute the IP checksum value ourselves. There is also a checksum field in UDP header, but it can be omitted due to checksum is optional in UDP.
As we mentioned before, endianness is also an implementation issue, which also affect the way that checksum is computed. The increasing numeric significance with increasing memory addresses, known as little-endian, and decreasing numeric significance with increasing memory addresses (or increasing time), known as big-endian. Figure 4.2 shows memory allocation of these two different frameworks.
33
Figure 4.2 Memory allocation of big-endian and little-endian
The method used to compute the checksum is defined within RFC-1071. To compute the checksum, the checksum is set to 0 firstly. After that, all 16-bit words are summed together using one's complement. The sum is then one's complemented and this final value is inserted as the checksum field. Therefore, checksum value differs from these two different frameworks. For simplicity, two different checksum function is needed, one is for little endian and another one is for big endian. Beyond all questions, we have to detect present machine belongs to which endianness before calling the checksum function. To distinguish current machine belongs to which type of endianness, store a 4 bytes data, e.g.:
“ABCD” as figure 4.2 shown, and read the first byte of this 4 byte data. If the data stores in the first byte is “A”, which means the current machine is big-endian machine and “B”
stores in the first byte indicates little-endian machines similarly. After detecting the machine endianness, we can call the corresponding checksum functions for big-endianness and little-endianness. After fill in network header information and video chunk data in the application data the packet can be forwarded to clients.
34
Figure 4.3 Network topology of implemented scheme
Figure 4.3 shows the implemented environment of the proposed IPTV scheme. Packet one sent from server to superpeer, and packet two sent from superpeer to ordinary peers.
Figure 4.4 and 4.5 shows the content of these two packets respectively.
Since the packet sent from server to superpeer travels through internet. It should acts like a normal UDP streaming packet, which means the header fields of packet should be all correct. Otherwise, the packet will be dropped by other network devices (e.g. router).
35
Figure 4.4 Packet sent from server to superpeer
While packet passes through the NAT, it replaces the Destination address from public IP “114.32.219.123” to private IP “192.168.2.2” according to the NAT table. The Destination MAC is address to peer A and TTL should be large enough (default 64 in Linux kernel and 128 in Windows XP) to go through the network path. In addition, sequence Identification : arbitrary Flag : D Fragments offset : 0 Time to Live :
Source Port : 7200 Destination Port : 7300 Length: 8(UDP)+1024 Checksum: Compute Needed
Sequence Number : 77
Broadcast Flag : 1 Data Payload…
…
36
broadcast flag set to one indicates that superpeer have to forward this packet to other peers
after receiving this packet.
Figure 4.5 Packet sent from superpeer to ordinary peers
There are several differences between figure 4.4 and figure 4.5, “Destination MAC”,
“Time to Live” and “broadcast flag”. Destination MAC is set to the unique MAC predefined in our program. “Time to live” is set to 3 in order to prevent failure routing and
Destination MAC Identification : arbitrary Flag : D Fragments offset : 0 Time to Live :
Source Port : 7200 Destination Port : 7300 Length: 8(UDP)+1024 Checksum: Compute Needed
Sequence Number : 77
Broadcast Flag : 0 Data Payload…
…
37
increase network burden. At last “broadcast flag” is set to zero to inform normal that there is no need to relay this packet.
4.2 Experiment setup and Numerical Analysis
4.2.1 Experiment Setup
To implement the scheme, we use a LINKSYS cable/DSL router with 4-port switch. We use a desktop be the streaming server and two laptop as peers connect to it. Figure 4.6 shows the experiment framework
1. Request
5. Relay
3. Request 2. Response
4. Detect
Figure 4.6 Experiment framework
38
Compare to normal IPTV transmission scheme, streaming server has to forward video chunk to each clients. This task consumes a lot of network bandwidth. In this experiment, we compare normal IPTV transmission strategy and the scheme we proposed by measuring their processing capacity.
4.2.2 Bandwidth Analysis
First of all, we let the playing quality be 1000 kbps for streaming video and extra 10 to 15 percent traffic loads for quality of service and we assume that all the peers are under same LAN watching identical IPTV channel. To measure performance of proposed transmission scheme, we can estimate the bandwidth that passes through the NAT from server to LAN.
As our expectation, network bandwidth grows linearly in traditional client-server transmission scheme while as shown in Figure 4.7
Figure 4.7 Tradition IPTV Client-Server transmission schemes
39
For the scheme we proposed, since the streaming data can be forwarded by superpeer.
However, the QoS related packets are individual and time-sensitive that cannot be relayed by superpeer which is established in TCP connection. Thus, we keep every QoS connection alive and from peers to server directly. But for streaming packets, server chooses one of the peers to relay streaming packets. In other words, server sends only one copy of the streaming data, which may save lots of bandwidth.
As figure 4.8 shows, network bandwidth almost remains flat due to QoS data is light weight traffic compare to streaming data.
Figure 4.8 the proposed transmission scheme
40
4.2.3 Startup delay Analysis
One of the measuring quantities in IPTV systems is the reduction of startup delays. While this problem does not exist in traditional television, in IPTV systems it is relevant, due to bandwidth limitation as well as the employment of buffers and overlay structures.
Generally, client buffers about 20 seconds of video frames before playback starts.
In other words, the video of bit rates 512 kbps buffers 10 Mb before it starts to play. In this simulation, bit rate is 1024 kbps, and the total bandwidth of network is confined to 30Mb.
While a peer joins the channel, it downloads and buffers the packets from server up to 20Mb at the highest speed the LAN offers, and then it starts to play. We describe the parameters for number analysis in Table 4.1.
Table 4.1 Parameters for analysis
Parameter Description
Bi Network bandwidth remains while peer i joins Dstreaming Network traffic for Streaming data
DQoS Network traffic for QoS data
Mbuffer Buffer size for streaming data
T(startup,i) Startup delay time for peer i
For peer i request to streaming server, we have to calculate the remaining network bandwidth fist. The remaining bandwidth is expressed as Equation (1).
After obtaining the remaining bandwidth, we assume that peer downloads with bandwidth
41
Bi. Therefore, startup delay time is calculated as Equation (2).
(1) (2)
Figure 4.9 Startup delay of traditional IPTV framework
Figure 4.9 shows the experiment result. While the peer numbers more than 20, we can observe that the startup delay increases dramatically. The reason for this circumstance is that most of the network bandwidth (30 Mb) is occupied by previous sessions. Therefore, it takes more than 10 seconds to buffer for the last joined peer. If there are more peers connect to server in this LAN, it may suffer video LAG due to insufficient bandwidth for playing the video of bit rate 1024kbps.
In our proposed scheme, the startup delay remains flat thanks to the network
42
bandwidth is not occupied by video traffic.
4.2.4 P2P-IPTV scale Analysis
One major difference between P2P-IPTV and IPTV is that IPTV has a strong streaming server that uploads heavy video traffic loads for clients. However, in P2P-IPTV, a peer obtains video chunk from other peers, which often limited by the small amount of upload bandwidth. Thus, a single peer cannot be connected for too many peers due to poor upload bandwidth limitation. In our proposed scheme, it may also improve the performance of P2P-IPTV.
Figure 4.10 User capacity comparisons
43
Chapter 5
Conclusion and Future Work
In this thesis, we proposed a novel IPTV and P2P-IPTV transmission scheme under NAT architecture. In our proposed scheme, single transmission is used for streaming server instead of multiples. Therefore, lots of network bandwidth can saved in our proposed scheme in both IPTV and P2P-IPTV architecture without modifying any physical network devices, since all the works are done in software phase. We implemented the system to justify our proposed scheme. Furthermore, we analyze the network bandwidth we save in different video playing bit rates and startup delay compare with traditional IPTV/P2P-IPTV transmission scheme.
From our analysis, network bandwidth is saved significantly and startup delay, too.
However, there are several questions need to be discussed and improved. Take superpeer election for example, the superpeer is responsible for forward streaming packets to other peers, which requires additional upload bandwidth. Thus, superpeer is considered with fine quality of network traffic. In addition, system may suffer broadcasting interruption due to superpeer offline. This is also an important issue for server to reelect a new superpeer and gives the authority of forwarding packets, which is so called “superpeer handover”. In this point of view, service interruption time minimization is our main focus.
The proposed scheme also faces problems that caused by NAT e.g. both side of source peer and superpeer are behind NAT. It causes connection establishment failure due to
44
restriction of NAT. To solve this problem, NAT traversal is required before the session initiation. However, the connection cannot be established when both sides are behind symmetric NAT. To conclude, there are several issues for how to construct an efficient P2P overlay of highly QoE (quality of user experience) P2P-IPTV but also saves network bandwidth.
45
References
[1] Diot, C. ; Levine, B.N. ; Lyles, B. ; Kassem, H. ; Balensiefen, D. ; Sprint Adv. Technol.
Labs., USA “Deployment issues for the IP Multicast Service and Architecture” IEEE Network 2000 volume 14 p.78-88.
[2] Kim, K.I. ; Ha, J.L. ; Hyun, E.H. ; Kim, S.H. ; “Internet multicast provisioning issues for hierarchical architecture” Networks, 2001. Proceedings. Ninth IEEE International Conference 2001
[3] Castro, M. ; Druschel, P. ; Kermarrec, A.M. ; Rowstron, A.I.T. ; “Scribe: a large-scale and decentralized application-level multicast infrastructure” Selected Areas in
Communications, IEEE Journal Oct 2002
[4] Hei X.J. ; Yong, L. ; Ross, K.W. ; “IPTV over P2P Streaming Networks the Mesh-Pull Approach” IEEE Communication Magazine Volume 2008 46 p. 86-92
[5] Huang, N.F. ; Chu, Y.M. ; Chen, Y.R. ; “Design of a P2P Live Multimedia Streaming System with Hybrid Push and Pull Mechanisms” Communications and Mobile Computing (CMC), 2010 International Conference 2010 p.541-545
[6] Tang, Y. ; Luo, J.G. ; Zhang, M. ; Yang S.Q. ; Zhang, Q. ; “Deploying P2P Networks for Large-Scale Live Video-Streaming Service”. IEEE Communication Magazine 2007 volume 45 p. 100-106
[7] Hei, X. ; Liang, C. ; Liang, J. ; Liu, Y. ; Ross, K.W. ; “A Measurement Study of a Large-Scale P2P IPTV System " IEEE Transaction Multimedia 2007 volume 9 p.
1672-1687
[8] Silverston, T. ; Fourmaux, O. ; “Measuring P2P IPTV Systems” ACM Network &
Operating Systems Support for Digital Audio & Video (ACM NOSSDAV), 2007.
[9] Yang, X. ; Du, X.J. ; Zhang, J.Y. ; Hu, F. ; Guizani, S. ; “Internet Protocol Television (IPTV): The Killer Application for the Next-Generation Internet” Communications Magazine, IEEE 2007