Chapter 2 Background
2.5 Network Address translation
NAT maps IP address from one domain to another, usually from private-use range to public IP. It is usually as a solution to save IPv4 address. The NAT serves N internal hosts and maintains a public IP pool which contains M IP addresses. The N hosts seldom get online concurrently so the number of M is usually less than N. When an internal node starts a
10
public IP address is allowed, mapping several private IP addresses into a single one might cause L4 port conflict and makes the upper layer connection broken. Port Address Translation (PAT) is introduced which will also translate L4 port number to avoid this problem. PAT is a kind of extension of NAT and the translation table is larger than NAT and operation is more complex. In the following sections, we use the term “NAT” to stand for PAT.
11
Chapter 3
The Proposed Scheme
In this chapter, we proposed a novel IPTV video chunk transmission scheme which can be applied to current network architecture without modifying any physical devices in Internet infrastructure. While multiple peers behind same NAT are connecting to the streaming server as in Figure 3.1, the streaming server should be aware of this kind of event.
Internet
Streaming Server
Figure 3.1 Traditional P2P network behind NAT
However, server considers all the sessions as independent connections in traditional
12
session transmission strategy. Since every clients are connecting to server through the NAT device. NAT maps these connections into one public IP address with different ports as in figure 3.2 shown.
Figure 3.2 NAT Mapping Table
After server receives these requesting messages from one identical IP address but different ports, server should treat these session independently. Therefore, server loads additional overhead to send video chunk to a LAN with many duplicated packets as Figure 3.3 shown.
Since the data payload of these packets are identical if those peers are watching the same IPTV channel. We suggested that server should build up a mechanism to detect this inconsequent case, and transmit only one copy of video data payload. In order to achieve this goal, server has to choose one of the peers behind same NAT to become superpeer and deliver the packet to it. The chosen peer should be responsible for deliver the packet to other peers in its LAN.
P riva te Int erf ace
Internal IP port External IP port
Public Int erf ace
192.168.2.1 6970 140.113.215.235 6970 192.168.2.2 6970 140.113.215.235 6971 192.168.2.3 7055 140.113.215.235 7055 192.168.2.4 8023 140.113.215.235 8023 192.168.2.5 7235 140.113.215.235 7235
13
Internet
Streaming server
192.168.2.1
192.168.2.2
192.168.2.3 192.168.2.4
192.168.2.5 140.113.215.235
Fi Figure 3.3 Streaming server receives request from same LAN
3.1 Peer joins
From the very beginning, clients send request to the streaming server as the program launches. For the signaling traffic, the reliability of connection is vital. Thus, TCP (Transmission Control Protocol) is suggested because of its retransmission and error detection mechanism. On the other hand, UDP (User Datagram Protocol) is mostly used for real-time applications when data loss can be compromised and compensated via using algorithms to compensate the data loss, which is adopted in this scheme. UDP sends the media stream as a series of small packets. This is simple and efficient; however, there is no mechanism within the user datagram protocol to guarantee delivery quality. It is up to the
14
receiving application to detect packet loss or packet corruption and to recover data via using error correction techniques. The streaming video may suffer a dropout while serials of data packets are lost due to network congestion. Therefore, we need to build up a mechanism that reports the QoS (Quality of Service) related data.
3.1.1 Single peer
First of all, a client launches the program and send session initiate message to the streaming server. After the server receives the request, it examines the entire online peer first; find out if there is a session already existed with same IP address but different ports, which means there are two or more clients behind same NAT. If the IP address of the request is not redundant, server will treat this session in traditional client-server method.
Step1. Client sends session initiate request to server.
Step2. Server respond client with video chunk in UDP packet, and set broadcast flag equaled to 0 in the Pseudo Header.
Step3. Client buffers the payload (not including pseudo header) to be adequate for quantity of video streaming.
15
1
Session Initiation Streaming Data
Signal Data
Streaming Server NAT Client
2
Figure 3.4 Single Client message flow
Since there are no other client requesting same channel in it's local area network, we have no alternative way to reduce neither inside nor outside traffic load. This situation cannot advantage the improvement of our proposed scheme.
3.1.2 Multiple peers
While there are two or more clients requesting same IPTV channel. In traditional opinion, IPTV server would treat these connections as independent sessions. In other words, network traffic loads would be doubled while the number of user grows twice much as before. However, if some of the source IP address of these connections are identical, which means they are behind the same NAT and same LAN. We propose a scheme to reduce the
16
redundant data flow on the P2P under NAT network. Thus not only the network traffic load was reduced, but also both IPTV startup delay and switching delay were shortened.
Session Initiation
Streaming Server NAT Client A Client B
4 2 1
5
Figure 3.5 Multiple Clients message flow
Step1. Client sends session initiate request to server.
Step2. Server examines all the current connections and detect that there are sessions that have identical IP address same as the request.
Step3. Server chooses one of the peers that have identical IP address to become superpeer.
Step4. Server responds each video chunk in UDP packet, and sets broadcast flag to 1 in the pseudo header to the superpeer.
Step5. Superpeer receives the packet and resets the Broadcast Flag to 0, and then relays the packet to other peers behind the same NAT.
17
3.2 System Process
Peer Request
Neighbor Check Superpeer selection
Server Respond Set Broadcast flag to 1
Figure 3.6 illustrates the flow chart of the whole system. The blue part represents the Client side, and the red part stands for the Server side. First of all, Client starts the program and sends the request to the server, then waits for reply. After the server received the request and before it answered the client with streaming data, the server has to check whether if there are neighbors of this new coming client also watching the same channel.
18
After detecting, server setups a broadcast flag in pseudo header at the start of the application layer data, which actually is the streaming data payload. Flag 0 indicates that there are no other clients with same IP address connecting to server beforehand. Figure 3.7 shows the difference of these two types of pseudo header.
Pseudo_Header other hand, flag is set to 1 to represent that the superpeer must receive this packet and then be responsible for relaying this packet to other ordinary peers in its local area network and behind the same NAT.
Therefore, after server has detected that there are two or more clients connecting with identical IP address. The server should have to pick one of these clients to become superpeer, who has the responsibility of relaying the packets. Figure 3.8 shows the state that more than two peers are connecting to the server and the receiving packets. The red connection indicates the direct connection between server and superpeer. The blues are the data flows among peers.
19
Figure 3.8 Data flows of proposed scheme
Furthermore, while clients were receiving the packets, they don’t know who the superpeer is until they check the broadcast flag in the packet they received. In other words, clients have to receive all the packets that flow on the LAN and inspect the broadcast flag inside the packet to decide relay the packet to other peers or not. In order to achieve this frames through, thus allowing the computer to read frames intended for other machines or network devices. To remind, many operating systems require superuser privileges to enable promiscuous mode.
20
In this case, peers receive all the packets, even those that don’t belong to the console.
Therefore, program has to check the MAC address in the packets it receives prior to processing the packets. However, peers don’t know who the superpeer is. For this reason, peer has to receive the MAC address that either addressed to its NIC or a unique one we assumed. The reason for we receive the MAC that addressed to NIC is the superpeer case.
Since the connection between server and the superpeer is normal client-server architecture, superpeer should receive the packets that addressed to its MAC address. But for non-superpeer cases, peers receive packets that were forwarded from the superpeer.
Consequently, non-superpeer receives those packets that are addressed to a unique MAC addressed that was configured in the program. Figure 3.9 shows the peer sniffing all the
Figure 3.9 peer sniffing packets in the LAN
21
To those non-superpeers, they only need buffer the streaming data payload in the packets they receive. On the other hand, superpeer should set the broadcast flag from 1 to 0, and modified the MAC address to the unique MAC address that we assumed before. After superpeer had done these modifications to the packets it receives, it sends the packets through the network sockets to the LAN it belongs to.
Furthermore, we might need a quality of service (QoS) monitoring mechanism in this system. We suggested that this control session may use TCP for QoS related messages.
These messages include current download/upload speed, buffered packets size, packet loss rate, etc. With this QoS control mechanism, we can easily obtain session quality. For
example, if a peer reports that its packets loss rate is high, streaming server may reelects the superpeer. Thus, with these little control message, we can ensure the video broadcasting quality.
3.3 Peers Leaving
While the peers were trying to shut down the IPTV program or switch to another channel, it sends the message to inform server of this event. With this circumstance, it matters while the leaving peer is the superpeer. Since the superpeer is out of duty, the server should pick one peer of the rest peers in its LAN that are still watching this channel to become superpeer. The newly elected superpeer doesn’t know about the predecessor superpeer’s leaving until it receives the video chunk packet that was addressed the broadcast flag as 1. Additionally, the peer send leaving message to streaming server via control socket. Server decides to elect a new superpeer or remain the previous one.
22
Another situation is that there are only two peers in its LAN watching same channel.
Certainly one of them is the superpeer, and the other one is the ordinary peer. After the superpeer leaving, only one peer stays in this LAN to watch this IPTV channel. Therefore, there is no need for the remaining peer to become superpeer.
3.4 Message Format
IPTV is a time-sensitive application and has the ability of tolerating slightly packets loss. Thus, the User Datagram Protocol is adopted in the proposed scheme. However, UDP uses a simple transmission model without implicit handshaking dialogues for providing reliability, ordering, or data integrity. UDP provides an unreliable service and datagram may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level.
However, slight packet loss is tolerable in streaming applications. Therefore, there is no necessary to build up retransmission mechanism in this proposed scheme. Thanks to the network congestion and traffic delay characteristic of network, the packets that peer receives may be out of order. Thus, sequence number is needed in this system. Firstly, server split the video into chunks, and forwards the packets to clients. The sequence number and the broadcast flag are set in the pseudo header.
Figure 3.10 shows the proposed message packet format. To begin with, we may fill the Ethernet Destination MAC either with unique MAC address or the peer’s network interface MAC address depends on whether the receiving peer is superpeer or ordinary peer in the
23
link layer header. Server transmits the video chunk to the superpeer with superpeer’s interface MAC address so that the packets can deliver to the superpeer successfully. For the relaying packets, superpeer modify MAC address field to the unique MAC and relay it.
In the IP header, since UDP is adopted in this system, the protocol field should be 17, which represented the User Datagram Protocol. Furthermore, while in the implantation phase, endianness issue was encountered. Endianness is the same as byte order. The usual contrast is whether the most-significant or least-significant byte is ordered first. A big-endian machine stores the most-significant byte first (at the lowest address), and a little-endian machine stores the least-significant byte first. Endianness not only determines the way we store and read the data, but also influences on the checksum calculation result.
24
Link Layer Header
0 5 6 11 12 14
Eth Destination MAC Eth Source MAC Eth Packet type
……
Internet Protocol Header
0 3 4 7 8 15 16 31
Version IHL Type of service Total Length
Identification Flags Fragment offset
Time to Live Protocol Header checksum Source Address
Figure 3.10 the proposed scheme message format
25
Since the checksum was originally computed and filled by the network kernel.
However, in the raw socket function, this field is authorized to the program itself, which means the kernel won’t compute it for us. Therefore, we need to rewrite the checksum function for both little endian and big endian cases and fill the checksum field.
IPv4, time to live (TTL) is an 8-bit field. In the Internet Protocol (IP) header, TTL is the 9th octet of 20. The time to live value can be thought of as an upper bound on the time that an IP datagram can exist in an Internet system. The TTL field is set by the sender of the datagram, and reduced by every host on the route to its destination. If the TTL field reaches zero before the datagram arrives at its destination, then the datagram is discarded and an ICMP error datagram (11 - Time Exceeded) is sent back to the sender. The purpose of the TTL field is to avoid a situation in which an undeliverable datagram keeps circulating on an Internet system.
However, under current network environment, personal computer may under several layers of routing devices to make the most use of IP address. Therefore, TTL should set to a small value in order to decrease the effect of network flooding as figure 3.11 shown.
26 IP Header
TTL = 2
IP Header TTL = 1 IP Header TTL = 0
Internet
Figure 3.11 TTL subtracts while passing the network device
The sequence number is to ensure the packet ordering. While the server splits the video into video chunk packets, it assigns the Sequence Number to it with increasing order.
Client buffers the video payload of packets by the ordering of Sequence Number to make sure that there are no video packets disordering for the playback.
At last, the broadcast flag in the Pseudo Header only has two different possible values.
The flag is either 0 or 1 depending on the receiving peer target identity. The memory size of sequence number, we allocate as same as in TCP standard protocol – 32bits. However, in order to save the network bandwidth, packet size minimization is needed. Thus, the broadcast is set as a Boolean value, which occupies only one byte.
27
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
The proposed scheme needs two programs for IPTV architecture, server and the client