Adaptive Transmission Control Protocol-trunking flow control ...

Journal Code: D A C

Article ID 1 3 1

2

Dispatch: 01.07.11 No. of Pages: 18

CE: Lynette Dorio ME:

INTERNATIONAL JOURNAL OF COMMUNICATION SYSTEMS Int. J. Commun. Syst. (2011) Published online in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/dac.1312

Yuan-Tse Yu 1, * ,† and Sheau-Ru Tong 2 1 Software

SUMMARY

OO

Engineering Department, National Kaohsiung Normal University, Taiwan Information System Department, National Pingtung University of Science and Technology, Taiwan

PR

2 Management

F

Adaptive Transmission Control Protocol-trunking flow control mechanism for supporting proxy-assisted video on demand system

EC

TE

D

Video streaming has been challenged by the best-effort service inherently provided by the Internet. Transmission Control Protocol (TCP) is sensitive to traffic congestion, and current TCP is insufficient to offer stable and high throughput bandwidth for video transmissions. Although many investigations have been proposed to deal with the inefficient problem of TCP protocol, such as Stream Control Transmission Protocol, these mechanisms and protocols are still not well employed by current Internet and used by Hypertext Transfer Protocol (HTTP). Adaptive TCP-trunking flow control (ATCP+), which is a segment-based flow control scheme built upon TCP protocol, is proposed in the paper. ATCP+ dynamically adjusts the transmitted segment size and makes multiple TCP connections be trunked together based on network condition, in order to optimize all TCP connection throughputs efficiently. The proposed scheme is implemented through HTTP 1.1. Experiments show that the proposed method can achieve stable throughput for smooth multimedia presentation on numerous network states, and the scheme can be handily applied on general web servers. Lastly, ATCP+ presents a cost-effective video streaming solution in real deployment. Copyright © 2011 John Wiley & Sons, Ltd. Received 11 September 2010; Revised 27 April 2011; Accepted 26 May 2011

Internet video streaming; video flow control; multithread download

CO RR

KEY WORDS:

1. INTRODUCTION

Along with the development of the Internet, the web services are now widely adopted. Therefore, Hypertext Transfer Protocol (HTTP) is becoming one of the most popular protocols. The HTTP [1] is based on Transmission Control Protocol (TCP), which is an end-to-end, reliable, and connectionoriented communication protocol. TCP has retransmission capability, thus assuring that packets are not lost during transmission. However, TCP produces serious effect on video streaming. For example, when network congestion occurs, the TCP congestion-control mechanism ref15,ref34 is activated. This mechanism works based on Additive Increase Multiplicative Decrease (AIMD) [4,5] algorithm and automatically reduces the transmitting throughput to half resulting in the delay of video playback. The works result in traffic sawtooth distribution on transmitting throughput. Thus, the TCP cannot provide steady traffic control. Many existing protocols are designed for dealing with the streaming service over Internet. Because video streaming [6–8] applications require real-time and steady transmitting throughput support, the efficiencies of flow control and rate control mechanisms become important for streaming service. For the User Datagram Protocol (UDP)-based flow control mechanism, the current streaming protocol [9–11] mainly adopts Real Time Streaming Protocol (RTSP), Real-time Transport Protocol (RTP), and Real-Time Transport Control Protocol (RTCP) [12] as the basic streaming

UN

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

*Correspondence to: Yuan-Tse Yu, No.62, Shenzhong Rd., Yanchao Township, Kaohsiung County 824, Taiwan. † E-mail: [email protected] Copyright © 2011 John Wiley & Sons, Ltd.

Q1

2

CO RR

EC

TE

D

PR

OO

F

protocols. In this kind of approach, RTSP uses TCP to respond for constructing and controlling time synchronization during streaming transmission at client and server sides. RTP adopts sequence number and timestamp in each UDP packet for achieving flow control according to playback rate. RTCP responds for flow control and congestion control. Thus, this kind of approach provides quality of service guarantee and retransmission mechanism and is supported by many popular presentation tools at client side, for example, QuickTime and Windows Media Player. However, many companies adopt firewalls to block UDP packages for safety consideration. Thus, it becomes hard to deploy this kind of approach for streaming service over Internet. Furthermore, many studies have presented video streaming mechanisms based on TCP-friendly approaches when network is congested. The current TCP-friendly [13–15] protocols include TCPFriendly Rate Control Protocol [16], Rate Adaptation Protocol [17], and Receiver-Driven Layered Congestion Control Protocol [18–20]. However, TCP-friendly is still not specifically designed for streaming transmission and therefore is not guaranteed to reach the required streaming throughput during streaming service. To satisfy real-time streaming requirement, the Internet Engineering Task Force proposed the Datagram Congestion Control Protocol (DCCP) [21]. The DCCP has two basic functions: one is to establish, maintain, and tear down unreliable connections and the other is to utilize the congestioncontrol mechanism for unreliable transmission. The DCCP allows applications to select suitable congestion-control mechanism according to the transmitting requirements via negotiation between server and client. Czekierda et al. [22] proposed an application programming interface framework for unreliable streaming using DCCP over best-effort networks. The framework allows application developers to easily construct their own queuing policies for handling specific streaming requirements. Another famous streaming protocol is Stream Control Transmission Protocol (SCTP). It belongs to a transport layer protocol. Lee et al. [23] proposed an SCTP efficient flow control mechanism to minimize a variation of transmitting rates during network congestions, especially when handover occurs on a mobile user. Although the aforementioned developed protocols are more suitable for streaming transmission, these protocols are still not well employed by current Internet and used by HTTP protocol. Recently, the Adaptive HTTP Streaming (AHS) has been integrated into 3rd Generation Partnership Project (3GPP) Technical Specification [24]. It also has been adopted by Open Internet Protocol television Forum as the core component of their HTTP Adaptive Streaming solution [25]. Besides, the Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP (DASH) solution [26] is heavily developed based on 3GPP AHS. Specifically, 3GPP’s ongoing work of Release-10 now also referred to DASH. These investigations show that the HTTP-based progressive download does have significant market adoption. The working concepts of AHS and DASH are that the clients adapt their requests based on some estimates of their available download rate at the time instants during the streaming service. To overcome the network congestion, in DASH, the HTTP server stores a video with various versions in advance. The number of video version is typically 4 to 10 with different presentation qualities. Each terminal can choose suitable version to download depending on its device capabilities and the network congestion level. The DASH client can also switch from one version to another frequently during the streaming service. Then the H.264 Scalable Video Coding technique may be the best choice of the delivered media for DASH [27]. Based on the aforementioned working concepts, the proposed ATCP+ can become the lower layer of DASH for providing static transmitting throughput; especially at this moment, the rate control and congestion-control algorithms of DASH client are not standardized. Besides, there are several implements and simulations that have been proposed based on the aforementioned behaviors of DASH congestion-control mechanism [27–30]. About the TCP/HTTP-based approaches, there are several famous approaches and systems that have been constructed over current Internet. The HTTP-based progressive download approaches, that is, YouTube and iTunes Movie Trailers, allow users start playback while the media contents are still in downloading progress [31].To achieve smoothing playback at client sides, this kind of approaches download media with full speed after user requests an on demand service immediately, resulting in bursting traffic over Internet and occupying required buffer space at client side. Funasaka [32] proposed a parallel downloading method using proposed HTTP/IUDP approach.

UN

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Y.-T. YU AND S.-R. TONG

Copyright © 2011 John Wiley & Sons, Ltd.

Int. J. Commun. Syst. (2011) DOI: 10.1002/dac

3

ADAPTIVE TCP-TRUNKING FLOW CONTROL MECHANISM

F1

TE

D

PR

OO

F

The proposed approach is evaluated through simple theoretical estimation and simulation experiments. The results show that the proposed parallel downloading method is an attractive protocol to distribute large files on dynamic networks composed of wireless links. Baldini et al. [6] present PATTHEL, a session-layer solution designed for parallelizing stream transfers. Parallelization is achieved by striping the flow among multiple TCP channels. This method is flexible enough to adapt to several scenarios. Base on the aforementioned discussion, we know that the TCP/HTTP-based streaming approaches segment whole video files [33, 34] into several coarse-grained segments according to the playback rate. Figure 1(a) displays the concept of adopting each segment as the transmission unit. The total transmission time is divided into T time periods. Therefore, transmission of each segment, that is, Tsegment , has to be finished in time period T normally. However, if the network is congested and the segment cannot be completely transmitted in the time period T , then the total transmitting time of Tsegment is longer than time period T , as shown in Figure 1(b). The situation causes the delays of video playback. To solve the problem, we proposed a TCP/HTTP-based streaming control mechanism and utilized the byte ranges method of the HTTP protocol to transmit the segments in this paper. The proposed Adaptive TCP-Trunking Flow Control (ATCP+) algorithm is developed based on segment streaming transmission [35–37] and multithread downloading approaches for overcoming the drawbacks of TCP/HTTP protocol. The suitable segment sizes for achieving maximum transmitting throughput when network congestion happened is also investigated in this paper. The proposed ATCP+ dynamically adjusts the number of HTTP sessions to reach the required transmission throughput for dealing with the delay problem. Finally, experimental results indicate that the ATCP+ algorithm can not only achieve the steady transmitting rate but also reduce the delay of video playback and reach the expected transmission throughput for video streaming.

EC

2. PROBLEM STATEMENT

CO RR

The TCP’s congestion control consists of the four main mechanisms, namely, slow-start, congestion avoidance, fast retransmit, and fast recovery [38]. Each mechanism utilizes two important variables, that is, congestion window (cwnd) and slow-start threshold size (ssthresh), to control the transmission. The slow-start mechanism avoids bursting traffic when new TCP connection injects

UN

Color Online, B&W in Print

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Figure 1. Downloading status (a) without network congestion and (b) with network congestion. HTTP, Hypertext Transfer Protocol. Copyright © 2011 John Wiley & Sons, Ltd.


4

CO RR

EC

TE

D

PR

OO

F

into network. To avoid the traffic burst situation, the TCP’s cwnd is initialized to one segment, and ssthresh is initialized to 65535 bytes. One segment size is typically set as 512 bytes. The slow-start mechanism increments the number of cwnd with exponential growth each time the sender successful receives acknowledgement (ACK) from receiver. Typically, the growth of cwnd size would not exactly exponential because the receiver may delay its ACKs. After some time periods, the immediate routers start discarding packets because the Internet researches the capacity limitation. The second mechanism of TCP’s congestion control is congestion avoidance. The mechanism mainly deals with the problem of packet loss when network congestion happens. Although slow-start and congestion avoidance are independent mechanisms, both slow-start and congestion avoidance mechanisms utilize cwnd and ssthresh to maintain the connection situation. For example, if cwnd is less than or equal to ssthresh, TCP is in slow start; otherwise, TCP is performing congestion avoidance. Besides, when a timeout or reception of duplicate ACKs happens, which means that congestion occurs, one-half of current cwnd size is saved in ssthresh. Additionally, if the congestion is indicated by a timeout, cwnd is set to one segment. Finally, the mechanisms of fast retransmit and fast recovery deal with the problem of packet loss according to receiving situation of duplicated ACKs in a row. The situation indicates that a segment has been lost. TCP then performs a retransmission without waiting for a retransmission timer to expire. According to the aforementioned discussion, the TCP congestion control makes the distribution of transmitting throughput become a sawtooth distribution, which seriously affecting streaming video. Although TCP is connection oriented and reliable through the retransmitting mechanism, it is not designed for streaming originally and cannot provide steady throughput. Network congestion causes TCP congestion control to be activated to reduce the transmitting throughput, causing the delay in playback. Conversely, the TCP congestion control does not limit transmitting throughput when the network traffic is less. Based on these considerations, this study presents a flow control mechanism based on TCP. The proposed algorithm downloads each segment via HTTP. A segment is considered as a control unit of evaluated transmitting throughput. Each segment is further downloaded via scheduled subsegments through the byte range capacity of HTTP. Therefore, the size of subsegment needs to be take into consideration in the proposed approach. Additionally, this study presents a different transmitting model within the proposed segment downloading mechanism, which does not require modifying the base layer of the TCP communication protocol. Furthermore, The investigated algorithm solves the problem of HTTP streaming delay by proposed multithread downloading approach, especially when the delay is effected by TCP’s flow control and congestion-control mechanisms. Figure ?? shows the basic executing procedures of the proposed algorithm, in which the byte range capacity of HTTP with multithreading is adopted to download a segment of 1.24 MB length. Firstly, the client sends HTTP requests for three different segment ranges in the selected video file, namely, from 0 to 393,000 bytes; from 393,001 to 786,000 bytes, and from 786,001 to 1,310,000 bytes. The web server then responds ‘206 Partial Content’ message with the indicated segments simultaneously via three TCP sessions. Then the required transmitting throughput can be achieved at client side. However, the main consideration is the optimal subsegment size under different network condition. Therefore, the Adaptive TCP-Trunking Flow Control (ATCP+) algorithm is proposed to dynamically adjust subsegment size according to network situation in this paper. To obtain the effectiveness of HTTP transmitting throughput with different subsegment length, we design several experimentations at first. The HTTP client is set in National Pingtung University of Science and Technology (NPUST) campus, and the HTTP server allocated at foreign country (http://ia300124.us.archive.org/2/items/ThePhantomoftheOpera/Phantom_of_the_Opera.mpg). We use the byte ranges capacity of HTTP/1.1 protocol. Figure 3 shows the request message sent from the client. We run the test at five different time in a day: 6:00 AM, 10:00 AM, 12:00 PM, 14:00 PM, and 22:00 PM. The byte ranges are set from 8 KB to 10 MB, and we test 10 times with each length. According to the results, we obtain that when the subsegment size increases, the average throughput increases generally. Figure 4 shows the average throughput of all experimentations. In Figure 4, it shows that the transmission is affected by TCP slow-start mechanism when the value of subsegment length is between 8 and 100 KB. Then it cannot reach the maximum throughput, which means it

UN

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 F2 33 34 35 36 37 38 39 40 41 42 43 44 45 46 F3 47 48 49 50 51 F4 52 53 54




5

OO PR D TE EC CO RR

UN

Figure 2. Hypertext Transfer Protocol (HTTP)-based multithread downloading execution procedures. TCP, Transmission Control protocol; IP, Internet Protocol.

Figure 3. The format of byte ranges downloading.

cannot utilize the network resource as well. This is because the subsegment size is too small and the TCP is still in slow-start stage. When the size of byte ranges is larger than 100 KB, the TCP enables the congestion avoidance mechanism, then the throughput is variations between 54 and 71 KB/s. This is because the network reaches the maximal throughput in this experimentations. Copyright © 2011 John Wiley & Sons, Ltd.



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

F


6

F OO

Figure 4. Average throughput.

EC

TE

D

PR

Based on the experimental results, we know that the maximal throughput can be achieved when the byte ranges is set between 500 KB and 1 MB. When the subsegment size is larger than 1 MB, the network congested frequently. This is because the congestions trigger the TCP to enable the AIMD mechanism for decreasing the transmitting throughput. By the aforementioned experimental results, to obtain the maximal throughput, the suitable byte ranges size is between 100 KB and 1 MB. If the size is too small, it cannot satisfy the consumption of the TCP slow-start mechanism, and it cannot reach the maximal transmitting throughput. Contrarily, if the size is too large, then the TCP triggers the AIMD mechanism. Therefore, the size of byte ranges should be dynamically adjusted according to the network situations. As a result, in this study, we set the maximal subsegment size as 65,500 bytes, and the maximal segment length is 1.24 MB, which equals to summation size of 20 subsegments, for achieving the coarse-grain streaming transmissions. 3. ADAPTIVE TRANSMISSION CONTROL PROTOCOL-TRUNKING FLOW CONTROL

CO RR

This study combines the segment video streaming and multithread downloading, as shown in Figure 5, to form the ATCP+ algorithm that is based on TCP and utilizes HTTP to download the byte ranges for coarse-grain segment video streaming. The aforementioned experimental results indicate that the network can achieve the highest transmitting throughput when the segment length is 1.24 MB. The condition also decreases the frequency of network congested. Therefore, the proposed ATCP+ performs segment transmission with segment length of 1.24 MB. The transmitting throughput at client side is computed as Eqn (1) where D denotes a segment length, Tstream denotes the video playing time, and Throughput indicates the expected target streaming throughput at the client.

UN



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 F5 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54


Throughput D

D Tstream

(1)

Figure 5. Algorithm of Transmission Control Protocol-Trunking Flow Control Mechanism. HTTP, Hypertext Transfer Protocol. Copyright © 2011 John Wiley & Sons, Ltd.


7


CO RR

EC

TE

D

PR

OO

F

In Figure 6, Tsegment represents the computational time requirement for downloading a segment from a web server, and Tstream denotes the required time period for a client to plays the segment. The time of Tstream is derived from the Eqn (1). For example, if the playback rate at client side is 1024 Kbits/s and the length of D is 1.24 MB, then Tstream is 10 s. Therefore, the ATCP+ downloads a segment with size of 1.24 MB every 10 s. If the segment cannot be downloaded within 10 s, then the user experiences the transmission delay. Consequently, the required time to download a Tsegment from web server must less than the necessary time to play the segment Tstream at client side to prevent starvation situation during playback. The basic principle of ATCP+ algorithm is that the ATCP+ divides each segment into k subsegments (subsegment, L) such that the downloading time of each subsegment is shorter than scheduled time period Tstream . For example, Figure 7 indicates that if the network is congested before ATCP+ starts to download the first segment, then ATCP+ divides the segment into three subsegments to perform streaming transmission. The network is still in congesting situation before second segment downloading procedure. Therefore, the ATCP+ algorithm continues to transmit in three subsegments. However, the network condition improves while transmitting the third segment. Therefore, ATCP+ performs streaming transmission with two subsegments in this time period. Because the Internet becomes better before the fifth segment transmitting procedure, then there is only one segment to be transmitted for reaching the target transmitting throughput in this time period. The policy of adjusting k value is based on two thresholds, upper bound (H1) and lower bound (H 2), as shown in Figure 8. The H1 threshold is assigned to 80% of the Tstream , and the H 2 threshold

Figure 6. Delay situation caused in segment transmission. HTTP, Hypertext Transfer Protocol.

F7

F8

UN


Figure 7. ATCP+ algorithm of throughput control (k value adjustment). HTTP, Hypertext Transfer Protocol. Copyright © 2011 John Wiley & Sons, Ltd.

F6


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54



8

F

Figure 8. Upper bound(H1), lower bound(H2), and subsegments (L).

EC

TE

D

PR

OO

is assigned to 90% of the Tstream in the implemented ATCP+ system in advanced. If the actual download time Tsegment is less than the upper bound (H1), that means the network throughput is larger than the required playback rate at client side. In this case, the transmitting throughput achieved by current amount of subsegment, and the throughput of transmitting subsegments has exceeded the target throughput, and the system should decrease the value of k. Therefore, the scheduled length of each subsegment increases. If the actual downloading time Tsegment exceeds the lower bound (H 2), then the system should increase the value of k. In order to avoid unlimitedly increasing k value, the maximum of subsegment length is assigned to lower bound, which is approximately 100 KB in this case. The parameters of the ATCP+ algorithm have been indicated in Table I. Figure 9 shows the flow chart of the ATCP+ algorithm. This study assumes that the network is congested at the beginning of streaming service, and then the initial value of k is set as 10. If Tsegment =Tstream is smaller than the upper bound (H1), it means that the status of network congestion is improved. Under this situation, the ATCP+ calculates the new value of D=k. If the value of D=k is less than the segment length of upper bound, then the ATCP+ decreases the value of k by 1. If the value of Tsegment =Tstream is larger than H 2, it means that either the network is congested or the network transmitting throughput cannot satisfy the target throughput. Oppositely, if the D=k value is larger than the segment length of lower bound, then the ATCP+ increases the value of k by 1 to speed up the transmitting rate. However, to avoid unlimited incense of k value, this work sets the maximal value of k to 10.

CO RR

4. SYSTEM IMPLEMENTATION

In this study, we implement the ATCP+ based on Java platform. Figure 10 shows the user interface of the implemented ATCP+ system that includes nine parts: ATCP+ parameter setting, ATCP+ mechanism setting, ATCP+ multimedia source setting, ATCP+ log, ATCP+ network flow distribution, ATCP+ control button, ATCP+ Display, HTTP streaming network flow distribution, and HTTP streaming control button. In Figure 10, in the area of ‘ATCP+ parameter setting’, ‘d ’ denotes the maximum packet size, which is set as 65,500 bytes, and ‘D’ indicates the segment length. There are at most 20 packets

UN

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 T1 19 F9 20 21 22 23 24 25 26 27 28 29 30 31 32 F10 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54


Table I. Indication of ATCP+ algorithm parameters.

Parameter d D k L Tsegment Tstream H1 H2

Indication

Maximum packet size One segment length Number of HTTP parallel downloading session Subsegment length in each HTTP parallel downloading session

The required time (from start to the end) for downloading a segment from a web service The required time for playing a segment at client side. Tstream 80% Tstream 90%

Default value 65,500 bytes 1.24 MB (d 20) L D D=k Lower bound D 100 KB Upper bound D 1.24 MB Calculated from Eqn 1

HTTP, Hypertext Transfer Protocol. Copyright © 2011 John Wiley & Sons, Ltd.


9

OO PR


EC

TE

D

Figure 9. Flow chart of ATCP+ algorithm.

UN

CO RR


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

F


Figure 10. User interface of the implemented ATCP+ system.

within one segment, and the maximum segment length equals to 1.24 MB. The field of ‘Window’ provides the operator to indicate the monitoring duration for obtaining average transmitting throughput. The information of ‘Throughput’ field is the target transmitting rate that is equal to the playback rate at client side. The value of ‘Tstream ’ is calculated by Eqn (1). The area of the ‘ATCP+ mechanism setting’ provides operator to indicate the parameters during the streaming procedures. The selection of ‘ATCP+’ means using ATCP+ algorithm to operate the downloading stream automatically. The area of ‘ATCP+ multimedia source setting’ shows the information of media source, the location of receivers, and the related network configurations. For example, in this case, the media source is allocated on overseas website, and the receivers are Copyright © 2011 John Wiley & Sons, Ltd.


10

D

PR

OO

F

allocated in NPUST, Taiwan. There are four fields in the area of ATCP+ display, namely, Tstream , k, D, and L, to show the scheduled values of at ATCP+ run-time. The area of the ‘ATCP+ log’ shows the segment value at run-time. For example, in Figure 10, the current video file can be divided into 387 segments, and the current transmitting states of each segment are listed. The area of ‘ATCP+ network flow distribution’ shows the current network status. The yellow line shows the transmitting status of each segment. For example, in this case, there are eight peaking curves formed by yellow line. The time period of each peak means one Tsegment . The interval between two green vertical lines means one Tstream . The blue line represents the k value. In this case, the k value is set as 10 initially. The red line represents the mean transmitting rate. The area of HTTP network flow distribution shows the network transmitting status of HTTP streaming. The yellow line shows the download status from HTTP web server, and the red line represents the average transmitting throughput of HTTP streaming. Figure 11 presents the algorithm of calculating the subsegment length in each session. Because one segment includes 20 packets and the value of 20 cannot be divided by k with no remainder, the remaining packets are deployed equally in each session. For example, if k D 7, then L D d 3, d 3, d 3, d 3, d 3, d 3, d 2. Based on this calculation, it can obtain the download byte range for each session from start_byte to end_byte. Then the maximum segment size for each session is 1.24 MB, and the smallest segment size is 100 Kb.

TE

5. EXPERIMENTS 5.1. Experimental environments

CO RR

EC

An experiment is performed involving ATCP+ and HTTP streaming. Table II lists the experimental data for the three network environments and video lengths. There are three experimental servers with different network conditions. The first one is an overseas web server, which is far away from the client’s location; the second one is allocated in Gungsheng Cable Company, which is in Pingtung city, and the bandwidth capacity cannot satisfy the experimental requirement of streaming; the third one is allocated at National Pingtung Institute of Commerce (NPIC), which is in Pingtung city too,

UN

01 02 03 04 05 06 07 08 09 10 11 12 13 F11 14 15 16 17 18 19 20 21 22 23 24 T2 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54


Figure 11. Subsegment (L) downloading computing algorithm. HTTP, Hypertext Transfer Protocol. Table II. Parameters of transmitted video. Video ID

Video title

Video length (MB)

Resource provider

Video 1 Video 2 Video 3

test1.mpg test.mpg Phantom_of_the_Opera.mpg

76 400 485

Gungsheng Cable Company NPIC Overseas web server

NPIC, National Pingtung Institute of Commerce. Copyright © 2011 John Wiley & Sons, Ltd.


11


and the bandwidth capacity is large enough to support the streaming requirement. The testing client is allocated at NPUST. Table III presents the parameter settings of ATCP+.

T3

5.2. Experimental Results 5.2.1. Overseas web server F12

F13 T4

PR

OO

F

Experiment 1: Target transmission capacity is 1 Mbps. Figure 12 depicts the experimental results when the server is allocated on overseas web server. The bandwidth capacity is about 600–800 Kbps when adopting pure HTTP streaming. The capacity is less than the expected target transmitting throughput. However, the expected target transmitting throughput is achieved when using ATCP+ with the segment lengths of 0.6, 1.2, and 2.4 MB. Both Figure 13 and Table IV reveal that when the segment length is 0.6 MB, the suitable value of k is 10 for achieving the target throughput. In this case, the subsegment length is only 63 KB. The case of 2.4 MB segment length only needs six sessions to reach the target transmitting throughput, whereas the segment length of 1.2 MB needs only two sessions. Thus, the case of 2.4 MB needs longer Table III. Experiment parameters settings. Parameter

Value

TE

D

0.6, 1.2, 2.4 1, 1.5 10 Tstream 80% Tstream 90%

EC

D (MB) Throughput (Mbps) k H1 H2

CO RR


UN

Figure 12. The comparison of three different segments and Hypertext Transfer Protocol (HTTP) streaming. (Experiment 1 of overseas web server).


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Figure 13. k value comparison of segment transmission. (Experiment 1 of overseas web server). Copyright © 2011 John Wiley & Sons, Ltd.


12

Table IV. Parameter values after testing (Experiment 1 of overseas web server). Segment length (MB)

K value

Subsegment L (KB)

Tstream (ms)

10 2 6

63 639 426

5000 10,000 20,000

0.6 1.2 2.4

OO

F

transmitting time than the case of 1.2 MB, and the required time period is not positive relative to segment length. That is, in the case of 2.4 MB, the required transmitting time is more than two times of 1.2 MB case. This is mainly because the larger segment requires longer transmitting time, raising the effect of network congestion. Thus, the best network transmitting throughput is achieved with the segment length of 1.2 MB. Additionally, a suitable k value in the case of 1.2 MB utilizes the network bandwidth efficiently.

CO RR

EC

TE

D

PR

Experiment 2: Target transmission capacity is 1.5 Mbps. In this experiment, the target transmitting throughput is set as 1.5 Mbps. In this case, HTTP streaming still does not reach the expected target transmitting throughput, as shown in Figures 14 and 15. When the segment length is set as 0.6 MB, the network throughput is about 1200–1400 Kbps, which is below the maximum transmitting throughput because of the slow-start mechanism of TCP. When the segment length is set as 2.4 MB, the length is too long for network transmission. Therefore, TCP congestion control is activated to decrease the transmitting throughput. The resulting transmitting

Figure 14. The comparison of three different segment lengths and Hypertext Transfer Protocol (HTTP) streaming. (Experiment 2 of overseas web server).

UN



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 F14 F15 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54


Figure 15. k value comparison of segment transmission. (Experiment 2 of overseas web server). Copyright © 2011 John Wiley & Sons, Ltd.


13


throughput is only 1.4 Mbps, which is less than the target transmitting throughput of 1.5 Mbps. The transmitting throughput just reaches the expected target transmitting throughput when segment length is set as 1.2 MB. As shown in Table V, it needs 10 sessions in all cases of segments length, indicating that the network bandwidth capacity either has reached its limit under all cases or is affected by network congestion.

T5

OO

F

5.2.2. GungSheng television station in Taiwan. In this experiment, the web server is allocated in the GungSheng television station, which is a local television station in Taiwan. The network capacity is only 420 Kbps, which is not enough to provide target transmitting throughput, that is, 1 Mbps. The HTTP streaming with segment lengths of 0.6, 1.2, and 2.4 MB is employed to test ATCP+ under the condition of insufficient network bandwidth.

F16 F17 T6

TE

D

PR

Experiment 1: Target transmission capacity as 1 Mbps. Both the HTTP streaming and the proposed ATCP+ algorithm cannot achieve the target transmitting throughput because of the limit network bandwidth, that is, 420 Kbps, as shown in Figures 16 and 17. In this situation, the network bandwidth is not enough, even when ATCP+ tries to utilize network bandwidth by increasing the number of sessions. The ATCP+ takes 10 sessions to download with all segment lengths, as shown in Table VI, and then the network has reach maximal bandwidth capacity. Additionally, the transmitting time of HTTP streaming is too long, because the TCP congestion control causes unsteady throughput. Both segment lengths of 0.6 and 1.2 MB achieve steady transmitting throughput. However, the segment length of 2.4 MB is too long, and it enables the TCP congestion-control mechanism, which results in decreases of network transmitting throughput. Small segment length achieves steady transmitting throughput under the limited bandwidth capacity. However, longer segments length results in unsteady throughput affected by TCP congestion-control mechanism.

EC

5.2.3. National Pingtung Institute of Commerce. The National Pingtung Institute of Commerce is allocated on Taiwan academic network, which has high bandwidth capacity. The ATCP+ is

CO RR

Table V. Parameter values after testing (Experiment 2 of overseas web server). Segment length (MB)

Subsegment L (KB)

Tstream (ms)

10 10 10

63 127 255

3300 6700 13,300

UN

0.6 1.2 2.4

K value


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Figure 16. The comparison of three different segment lengths of 0.6, 1.2, and 2.4 MB for Hypertext Transfer Protocol streaming. (Experiment 1 of GungSheng television station in Taiwan). HTTP, Hypertext Transfer Protocol. Copyright © 2011 John Wiley & Sons, Ltd.


14

F

OO

Figure 17. k value comparison of segment transmission. (Experiment 1 of GungSheng television station in Taiwan).

Segment length (MB)

K value

Subsegment L (KB)

Tstream (ms)

10 10 10

63 127 255

5000 10,000 20,000

D

0.6 1.2 2.4

PR

Table VI. Parameter values after testing (Experiment 1 of GungSheng television station in Taiwan).

TE

examined by HTTP streaming and segment lengths of 0.6, 1.2, and 2.4 MB to determine whether it achieved the target transmitting throughput.

CO RR

EC

Experiment 1: Target transmitting capacity is 1 Mbps. The resulting network throughput of HTTP streaming is between 10 and 12 Mbps, which exceeds 12 times of the expected target transmitting throughput, as shown in Figures 18 and 19 and Table VII. The resulting high throughput is mainly because the TCP and HTTP protocols are not designed for the streaming applications. The ATCP+ algorithm maintains the target transmitting throughput of 1 Mbps with three different segment lengths, that is, 0.6, 1.2, and 2.4 MB. Additionally, the ATCP+ uses only one session for three different segment lengths to achieve the expected throughput. Consequently, if the bandwidth capacity of the network is high, the segment transmitting throughput is not affected by the network congestion. Besides, the experimental results show that the transmitting throughput is not affected obviously by segment length within ATCP+ algorithm when the network has high bandwidth capacity.

UN



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 F18 F19 T7 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54


Figure 18. The comparison of three different segments and Hypertext Transfer Protocol (HTTP) streaming. (Experiment 1 of National Pingtung Institute of Commerce in Taiwan). Copyright © 2011 John Wiley & Sons, Ltd.


15

OO


Figure 19. k value comparison of segment transmission. (Experiment 1 of National Pingtung Institute of Commerce in Taiwan).

Segment length (MB)

K value

Subsegment L (KB)

Tstream (ms)

1 1 1

0.6 1.2 2.4

5000 10,000 20,000

TE

D

0.6 1.2 2.4

PR

Table VII. Parameter values after testing (Experiment 1 of National Pingtung Institute of Commerce in Taiwan).

CO RR

EC


Figure 20. The comparison of three different segments and Hypertext Transfer Protocol (HTTP) streaming. (Experiment 2 of National Pingtung Institute of Commerce in Taiwan).

UN

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

F


Experiment 2: Target transmission capacity as 1.5 Mbps. The target transmitting throughput is set as 1.5 Mbps. In this case, the transmitting throughput still appears burst situation when adopting HTTP streaming method, as shown in Figures 20 and 21 and Table VIII. Oppositely, the ATCP+ algorithm with segment lengths of 0.6, 1.2, and 2.4 MB all maintains the transmitting throughput of 1.5 Mbps. Only one session is required with three different segment lengths. Besides, comparing with three different cases, the case of using 1.2 MB as the segment length can achieve the highest transmitting throughput efficiently in shortest time period. 6. CONCLUSIONS In this study, the proposed ATCP+ algorithm includes two main concepts, that is, segmentation and multithread downloading, for achieving better streaming performance based on general HTTP protocol. The ATCP+ dynamically adjusts the segment length according to the condition of network Copyright © 2011 John Wiley & Sons, Ltd.


F20 F21 T8

16

OO

F


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 Q2 44 45 46 47 Q3 48 49 50 51 52 53 54


PR

Figure 21. k value comparison of segment transmission. (Experiment 2 of National Pingtung Institute of Commerce in Taiwan). Table VIII. Parameter values after testing (Experiment 2 of National Pingtung Institute of Commerce in Taiwan). Subsegment L (KB)

Tstream (ms)

1 1 1

0.6 1.2 2.4

3300 6700 13,300

TE

0.6 1.2 2.4

K value

D

Segment length (MB)

UN

CO RR

EC

congestion. To provide steady video streaming throughput in shortest time period, the ATCP+ utilizes numbers of session to transmit video segment simultaneously. The experimental results demonstrate that the HTTP streaming cannot achieve the expected transmitting throughput regardless of network bandwidth capacity. When the network has limited bandwidth capacity, it results in unsteady transmitting throughput affected by TCP congestioncontrol mechanism. Additionally, the HTTP protocol leads to the bursting traffic under sufficient bandwidth networks. The proposed ATCP+ algorithm achieves and maintains the target transmitting throughput. Thus, ATCP+ achieves a steady and suitable transmitting throughput. Although the ATCP+ algorithm adopts multithread downloading method to increase transmitting throughput, there are two drawbacks in our experience. Firstly, the multithread downloading method does not perform well when the network has insufficient bandwidth, especially when the available bandwidth capacity is less than the required playback rate at client side. However, ATCP+ algorithm still maintains steady transmitting throughput under insufficient bandwidth network environments. Secondly, to avoid the deny of service, web servers provides the mechanism to limit the number of session in simultaneous time period with one dedicated Internet Protocol address. This situations also limit the multithread downloading capacity of ACTP+. Utilizing the multihoming technique is an alternative solution for dealing with the problem of session limitation. ACKNOWLEDGEMENTS

This research is supported by the National Science Council (NSC 99-2220-E-017-002-). REFERENCES 1. Gettys J, Fielding R, Mogul J, Frystyk H, Masinter L, Leach P, Berners-Lee T. RFC 2616 – Hypertext Transfer Protocol – HTTP/1.1, Internet Engineering Task Force, February 1999. URL http://www.faqs.org/rfcs/rfc2616.html. 2. Martin J, Nilsson A, Rhee I. Delay-based congestion avoidance for TCP. IEEE/ACM Transactions on Networking 2003; 11(3):356–369. DOI: 10.1109/TNET.2003.813038. 3. Kuschnig R, Kofler I, Hellwagner H. Improving internet video streaming performance by parallel TCP-based requestresponse streams. In Proceedings of the 7th Annual IEEE Consumer Communications and Networking Conference (IEEE CCNC 10). IEEE Press: Piscataway, NJ, 2010, DOI: 10.1109/CCNC.2010.5421815. 4. Wu G, Chong EK, Givan R. Streaming stored video over AIMD transport protocols. In Proceedings of the 4th International Symposium on Multimedia Software Engineering. IEEE Computer Society: Washington, DC, 2002. Copyright © 2011 John Wiley & Sons, Ltd.


17


CO RR

EC

TE

D

PR

OO

F

5. Zhao L, Jing Y, Dimirovski G. Improvement of AIMD algorithm considering multimedia transfer over internet. In Proceedings of the 6th International Conference on Telecommunications in Modern Satellite, Cable and Broadcasting Service (TELSIKS). IEEE: New York, NY, 2003, DOI: 10.1109/TELSKS.2003.1246251. 6. Baldini A, Carli LD, Risso F. Increasing performances of TCP data transfers through multiple parallel connections. In IEEE Symposium on Computers and Communications. IEEE Computer Society: Washington, DC, 2009; 630–636, DOI: 10.1109/ISCC.2009.5202274. 7. Chakareski J, Frossard P. Rate-distortion optimized distributed packet scheduling of multiple video streams over shared communication resources. IEEE Transactions on Multimedia 2006; 8(2):207–218. DOI: 10.1109/TMM.2005.864284. 8. Nikolaus B, Ott J, Bormann C, Bormann U. Reducing bandwidth consumption at startup of media transmissions. IEEE Transactions on Broadcasting 2006; 52(3):368–373. DOI: 10.1109/TBC.2006.879864. 9. Ozcelebi T, Tekalp AM, Civanlar M. Delay-distortion optimization for content-adaptive video streaming. IEEE Transactions on Multimedia 2007; 9(4):826–836. DOI: 10.1109/TMM.2007.895670. 10. Stewart R, Xie Q, Morneault K, Sharp C, Schwarzbauer H, Taylor T, Rytina I, Kalla M, Zhang L, Paxson V. RFC2960–Stream Control Transport Protocol, Internet Engineering Task Force, 2000. URL http://www.faqs.org/ rfcs/rfc2960.html. 11. Steinberg J, Pasquale J. Improving HTTP-based video performance using network flow buffering. In IEEE Symposium on Computers and Communications (ISCC). IEEE Computer Society: Washington, DC, 2010, DOI: 10.1109/ISCC.2010.5546807. 12. Schulzrinne H, Casner S, Frederick R, Jacobson V. RFC1889 – RTP: a transport protocol for real-time applications, Internet Engineering Task Force, 1996. URL http://www.faqs.org/rfcs/rfc1889.html. 13. Padhye J, Kurous D, Towsley R. A model based TCP-friendly rate control protocol. The International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), 1999. 14. Tsao SC, Lai YC, Lin YD. Taxonomy and evaluation of TCP-friendly congestion-control schemes on fairness, aggressiveness, and responsiveness. IEEE Network November 2007; 21(6):6–15. 15. Widmer J, Denda R, Mauve M. A survey on TCP-friendly congestion control. IEEE Network 2001; 15(3):28–37. 16. Jourjon G, Lochin E, Dairaine L. Optimization of TFRC loss history initialization. IEEE Communications Letters 2007; 11(3):276–278. DOI: 10.1109/LComm.2007.061707. 17. Rejaie R, Handley M, Estrin D. RAP: an end-to-end rate-based congestion control mechanism for realtime streams in the internet. In Proceedings of the 18th Annual Joint Conference of the IEEE Computer and Communications and Communications Societies. IEEE: New York, NY, 1999. 18. Chou P, Mohr A, Wang A, Mehrotra S. Error control for receiver-driven layered multicast of audio and video. IEEE Transactions on Multimedia 2001; 3(1):108–122. DOI: 10.1109/6046.909598. 19. Zhao L, Yamamoto H. Multisource receiver-driven layered multicast. In Proceedings of the IEEE Region 10 Conference (TENCON). IEEE: New York, NY, 2005, DOI: 10.1109/TENCON.2005.301296. 20. McCanne S, Jacobson V, Vetterli M. Receiver-driven layered multicast. In Conference Proceedings on Applications, Technologies, Architectures, and Protocols for Computer Communications. ACM: New York, NY, 1996. 21. Lai YC. DCCP congestion control with virtual recovery to achieve TCP-fairness. IEEE Communications Letters 2008; 12(1):50–52. DOI: 10.1109/LCOMM.2008.071421. 22. Czekierda L, Grobelny T. Framework for application-level adaptation of media streams transmitted using DCCP protocol. In IEEE Symposium on Computers and Communication. IEEE Computer Society: Washington, DC, 2009, DOI: 10.1109/ISCC.2009.5202275. 23. Lee KJ, Nam SS, Mun BI. SCTP efficient flow control during handover. In Wireless Communication and Networking Conference. IEEE: New York, NY, 2006, DOI: 10.1109/WCNC.2006.1683443. 24. 3GPP TS 26.234 v9.3.0 (2010-06). 3rd generation partnership project; technical specification group services and system aspects; transparent end-to-end packet-switched streaming service (PSS); protocols and codecs (Release 9), section 12: adaptive HTTP streaming, 2010. 25. HTTP adaptive streaming, draft v0.06, 7 June 2010. 26. (MPEG) IJSW. Dynamic adaptive streaming over http. w11578, CD 23001-6, w11578, CD 23001-6. ISO/IEC JTC 1/SC 29/WG 11 (MPEG), Guangzhou, China, 2010. 27. de la Fuente YS, Schierl T, Hellge C, Wiegand T, Hong D, Vleeschauwer DD, Leekwijck WV, loudec YL. iDASH: improved dynamic adaptive streaming over HTTP using scalable video coding. In Proceedings of the 2nd Annual ACM Conference on Multimedia Systems. ACM: New York, NY, 2011. 28. Yao J, Hossain I, Kanhere S, Hassan M. Empirical evaluation of HTTP adaptive streaming under vehicular mobility. IFIP Networking 2011 Conference, Valencia, Spain, 2011. 29. Mller C, Timmerer C. A test-bed for the dynamic adaptive streaming over HTTP featuring session mobility. In Proceedings of the 2nd Annual ACM Conference on Multimedia Systems. ACM: New York, NY, 2011. 30. Akhshabi S, Begen AC, Dovrolis C. An experimental evaluation of rate-adaptation algorithms in adaptive streaming over HTTP. In Proceedings of the 2nd Annual ACM Conference on Multimedia Systems. ACM: New York, 2011. 31. Van Deursen D, Van Lancker W, Van de Walle R. On media delivery protocols in the web. In Proceedings of the IEEE International Conference on Multimedia and Expo (ICME). IEEE Computer Society: Washington, DC, 2010, DOI: 10.1109/ICME.2010.5582620. 32. Funasaka J. Evaluation on parallel downloading method using HTTP over UDP. In International Symposium on Autonomous Decentralized Systems. IEEE Computer Society: Washington, DC, 2009, DOI: 10.1109/ISADS.2009.5207382.

UN

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54



Q4

18

OO

F

33. Chen S, Shen B, Wee S, Zhang X. Segment-based streaming media proxy: modeling and optimization. IEEE Transactions on Multimedia 2006; 8(2):243–256. 34. Thyagharajan K, Ramachandran V. Segmentation analysis for effective usage of network resources in video streaming. In International Conference on Computational Intelligence and Multimedia Applications. IEEE Computer Society: Washington, DC, 2007. 35. Ip AT, Jiangchuan L, Lui JCS. COPACC: an architecture of cooperative proxy-client caching system for on-demand media streaming. IEEE Transactions on Parallel and Distributed Systems 2007; 18(1):70–83. 36. Jurca D, Frossard P. Video packet selection and scheduling for multipath streaming. IEEE Transactions on Multimedia 2007; 9(3):629–641. DOI: 10.1109/TMM.2006.888017. 37. Yoshihisa T, Tsukamoto M, Nishio S. A scheduling protocol for continuous media data broadcasting with large-scale data segmentation. IEEE Transactions on Broadcasting 2007; 53(4):780–788. 38. Stevens W. TCP slow start, congestion avoidance, fast retransmit, and fast recovery algorithms. RFC 2001, Internet Engineering Task Force, January 1997.

AUTHORS’ BIOGRAPHIES

TE

D

PR

Yuan-Tse Yu received the BS degree in Applied Mathematics from Kaohsiung Polytechnic Institute in 1996, the MS degree in Information Management from National Pingtung University of Science and Technology, Taiwan in 1998, and the PhD degree in Computer Science and Information Engineering from National Cheng Kung University, Taiwan in 2005. He is currently an assistant professor in the Department of Software Engineering, National Kaohsiung Normal University, Taiwan. His research interests are multimedia networking protocols and distributed multimedia systems.

CO RR

EC

Sheau-Ru Tong (M’90) was born in Taiwan in 1962. He received the BE degree in Computer Engineering from the National Chiaotung University, Taiwan in 1984 and the PhD degree in Computer Science from University of Minnesota, Minneapolis in 1994. In 1994, he worked as a network system engineer at the Computer Communications Research Labs in Industrial Technology Research Institute, Taiwan. He is currently a Professor of the Department of Management Information Systems and a Director of the Compute Center, National Pingtung University of Science and Technology, Taiwan. His research interests include wireless mobile networks, multimedia communications, Internet quality of service and video on demand systems.

UN

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54




Author Query Form Journal: International Journal of Communication Systems Article: dac_1312 Dear Author, During the copyediting of your paper, the following queries arose. Please respond to these by annotating your proofs with the necessary changes/additions. If you intend to annotate your proof electronically, please refer to the E-annotation guidelines. If you intend to annotate your proof by means of hard-copy mark-up, please refer to the proof markup symbols guidelines. If manually writing corrections on your proof and returning it by fax, do not write too close to the edge of the paper. Please remember that illegible mark-ups may delay publication. Whether you opt for hard-copy or electronic annotation of your proofs, we recommend that you provide additional clarification of answers to queries by entering your answers on the query sheet, in addition to the text mark-up.

Query No.

Query

Q1

AUTHOR: Please provide a suitable figure (abstract diagram or illustration selected from the manuscript or an additional ‘eye-catching’ figure) and a short ‘GTOC’ abstract (maximum 80 words or three sentences) summarizing the key findings presented in the paper for Table of Content (TOC) entry.

Q2

AUTHOR: Contract/grant sponsor has been presented in the acknowledgement section (as per style instruction). Please check.

Q3

AUTHOR: Please provide accessed date for Reference 1: date/month/year

Q4

AUTHOR: Please provide accessed date for Reference 10.

Remark

USING E-ANNOTATION TOOLS FOR ELECTRONIC PROOF CORRECTION Required Software Adobe Acrobat Professional or Acrobat Reader (version 7.0 or above) is required to e-annotate PDFs. Acrobat 8 Reader is a free download: http://www.adobe.com/products/acrobat/readstep2.html Once you have Acrobat Reader 8 on your PC and open the proof, you will see the Commenting Toolbar (if it does not appear automatically go to Tools>Commenting>Commenting Toolbar). The Commenting Toolbar looks like this:

If you experience problems annotating files in Adobe Acrobat Reader 9 then you may need to change a preference setting in order to edit. In the “Documents” category under “Edit – Preferences”, please select the category ‘Documents’ and change the setting “PDF/A mode:” to “Never”.

Note Tool — For making notes at specific points in the text Marks a point on the paper where a note or question needs to be addressed. How to use it: 1. Right click into area of either inserted text or relevance to note 2. Select Add Note and a yellow speech bubble symbol and text box will appear 3. Type comment into the text box 4. Click the X in the top right hand corner of the note box to close.

Replacement text tool — For deleting one word/section of text and replacing it Strikes red line through text and opens up a replacement text box. How to use it: 1. Select cursor from toolbar 2. Highlight word or sentence 3. Right click 4. Select Replace Text (Comment) option 5. Type replacement text in blue box 6. Click outside of the blue box to close

Cross out text tool — For deleting text when there is nothing to replace selection Strikes through text in a red line. How to use it: 1. Select cursor from toolbar 2. Highlight word or sentence 3. Right click 4. Select Cross Out Text

Page 1 of 3

Approved tool — For approving a proof and that no corrections at all are required. How to use it: 1. Click on the Stamp Tool in the toolbar 2. Select the Approved rubber stamp from the ‘standard business’ selection 3. Click on the text where you want to rubber stamp to appear (usually first page)

Highlight tool — For highlighting selection that should be changed to bold or italic. Highlights text in yellow and opens up a text box. How to use it: 1. Select Highlighter Tool from the commenting toolbar 2. Highlight the desired text 3. Add a note detailing the required change

Attach File Tool — For inserting large amounts of text or replacement figures as a files. Inserts symbol and speech bubble where a file has been inserted. How to use it: 1. Click on paperclip icon in the commenting toolbar 2. Click where you want to insert the attachment 3. Select the saved file from your PC/network 4. Select appearance of icon (paperclip, graph, attachment or tag) and close

Pencil tool — For circling parts of figures or making freeform marks Creates freeform shapes with a pencil tool. Particularly with graphics within the proof it may be useful to use the Drawing Markups toolbar. These tools allow you to draw circles, lines and comment on these marks.

How to use it: 1. Select Tools > Drawing Markups > Pencil Tool 2. Draw with the cursor 3. Multiple pieces of pencil annotation can be grouped together 4. Once finished, move the cursor over the shape until an arrowhead appears and right click 5. Select Open Pop-Up Note and type in a details of required change 6. Click the X in the top right hand corner of the note box to close.

Page 2 of 3

Help For further information on how to annotate proofs click on the Help button to activate a list of instructions:

Page 3 of 3