QoS Evaluation of HTTP over Satellites

Transcription

1 2011 Internatonal Conference on Cyber-Enabled Dstrbuted Computng and Knowledge Dscovery QoS Evaluaton of HTTP over Satelltes Lukman Audah Faculty of Electrcal and Electronc Engneerng Unverst Tun Hussen Onn Malaysa Part Raja, Batu Pahat, Johor, Malaysa Zhl Sun and Hatham Cruckshank Centre for Communcaton Systems Research (CCSR) Unversty of Surrey Guldford, Surrey GU2 7XH, Unted Kngdom {l.audah, z.sun, Abstract Ths paper presents the studes for the end-to-end QoS of IP over ntegrated terrestral and Next Generaton Satellte Network (NGSN) usng HTTP web applcaton. We compare between Bg-LEO and EuroSkyWay lke satelltes constellatons for the QoS parameters (e.g. delay, loss rato, throughput and connecton duraton) of request-response HTTP connectons from a remote server n London and a remote clent n Boston. We model the HTTP request-response wth multple connectons and response fles szes varatons. We create the network scenaro wth error model to smulate the transmsson loss envronment usng NS-2 smulaton software. A Dfferentated Servces (Dffserv) queue nterface s placed n the terrestral network on the server sde to regulate and dfferentate the traffc flows across the narrow bandwdth of the satellte lnks. The results showed a good performance evaluaton comparson of the QoS parameters nvolved n the HTTP web communcatons across LEO and GEO satellte systems. Keywords-component; Qualty of Servce (QoS); IP over Satellte; Dffserv; HTTP Applcaton; Integrated Network I. INTRODUCTION The Next Generaton Satellte Network (NGSN) plays a very mportant role n provdng ubqutous communcatons across the globe. It has unque characterstcs lke large coverage area, fast network deployment and natve broadcastng/multcastng servces that extend the Internet connectvty anywhere-anytme. The latest standard development from European Telecommuncatons Standards Insttute (ETSI) [1] on dgtal vdeo broadcastng lke DVB- S/S2 [2, 3] for the forward channel and DVB-RCS [4] on the return channel has made the satellte technology able to provde hgh speed Internet broadband at compettve and economcal prcng rate (e.g. Tooway [5]). The NGSN conssts of ntegraton of both terrestral and satellte networks. Synchronze connectons between the two networks are vtal n order to provde optmum end-to-end QoS. The terrestral networks have the advantage n term of technology, bandwdth and speed (e.g. hgh speed and low bterror-rate of optcal fbre) compared to the satellte networks that have narrow bandwdth and more prone to the transmsson loss. Due to that advantage, the terrestral network may leverage the data transfer over the satellte by adoptng a control mechansm such as Dffserv [6] to regulate and dfferentate the traffc flows rght before beng transmtted over the satellte. Contrary to the prevous study on end-to-end QoS optmzaton of IP over satelltes as n [7], we propose a Dffserv queue nterface n the terrestral network to regulate and dfferentate the multple connectons between server and clent. It provdes scalablty by smplfyng the complexty functons such as traffc classfcaton and traffc condtonng wthn the edge satellte network [8, 9]. Prevous related studes on end-to-end QoS of IP-Dffserv [10, 11, 12] only analyzed wred or wreless terrestral networks wthout ntegratng wth the satellte networks. None has done a top-down comparson on QoS parameters for the Hypertext Transfer Protocol (HTTP) web communcatons between LEO and GEO satelltes systems. The HTTP s desgned as an Applcaton Layer protocol wthn the framework of the Internet Protocol Sute (TCP/IP). It functons as request and response protocols n the clent-server computng system. It uses TCP relable connecton for the hostto-host data transfer. A clent that often referred as a user agent (UA) s actually a web browser or web crawler. Meanwhle, the server s the applcatons system runnng on a computer that hosts the web ste. In order to establsh a HTTP connecton, a clent submts a request message to the server. The server s dentfed usng Unform Resource Locator (URL) whch nterlnked the hypertext resource on the Internet. Upon recevng a request from clent, the server wll respond by sendng a response message back to the clent that contan the desred resource nformaton content such as HTML fles and also the completon status nformaton. There are two standard versons of HTTP protocols whch are HTTP/1.0 and HTTP/1.1. The HTTP/1.0 uses a separate connecton to the same server for every request and response functon just lke the Fle Transfer Protocol (FTP) sute whle the HTTP/1.1 uses a sngle connecton for the clent and server data transfer across the Internet [13]. Ths paper ams to evaluate and compare the QoS parameters (.e. delay, loss rato, throughput and connecton duraton) for the HTTP web communcatons between ntegrated terrestral-leo and terrestral-geo networks. The comparson s done based on average new connectons and server response fles szes varatons. The NS-2 smulator software s used to smulate the nternetworkng scenaros for approxmately one hour of smulaton tme. The rest of ths paper s organzed as follows. Secton II descrbes the smulaton confguraton. Secton III dscusses the smulaton results and analyss. Fnally, secton IV presents the concluson and future works of the research /11 $ IEEE DOI /CyberC

2 Remote HTTP Server 5 ms 5Mb/s Dffserv Queue Interface 1 ms 2Mb/s GSL 1 London LEO/GEO Satelltes Constellaton GSL 2 Boston Fgure 1. NS-2 smulaton scenaro. Remote HTTP Clent 1 ms 2Mb/s II. SIMULATION CONFIGURATION The NS-2 smulaton scenaro s shown n Fg.1 whch conssts of a remote server, a remote clent, a Dffserv queue nterface, two ground statons to satellte lnks termnals (GSL) and the LEO/GEO satelltes constellaton. There are two dfferent NS-2 smulaton scenaros used whch are the terrestral-leo and terrestral-geo. The man dfference between the two scenaros s only the satellte network parameters whle the rest are exactly the same. Further detals are descrbed as follows. A. The LEO/GEO Satelltes Network The NS-2 smulatons confguratons only dffer n the satelltes network parameters whle the rest are the same for the whole smulatons. We use Bg-LEO constellaton (.e. 66 satelltes) [14] and EuroSkyWay constellaton (.e. 5 satelltes) [15] as an example of LEO and GEO satelltes respectvely. A remote server located n London, UK ( N, 0 0 ) transmts multple TCP-New Reno connectons usng HTTP web applcaton to a remote clent located n Boston, USA ( N, W). TABLE I shows the LEO and GEO parameters used throughout the smulatons. Snce n real world the satelltes network has hgh transmsson errors [16], therefore a random error model s ntroduced to smulate the characterstc. The error model produced three dfferent bt-error-rates (BER) whch are 10-7, 10-6 and 10-5 for three dfferent error scenaros. TABLE I. LEO AND GEO SATELLITES PARAMETERS Parameter LEO Satelltes GEO Satelltes Alttude 780 Km Km Planes 6 1 Satelltes per plane 11 5 Inclnaton (degree) Interplane separaton (degree) Seam separaton (degree) 22 - Elevaton mask (degree) Intraplane phasng YES YES Interplane phasng YES NO ISL per satellte 4 2 ISL bandwdth 25 Mb/s 25 Mb/s Uplnk/Downlnk bandwdth 2 Mb/s 2 Mb/s Cross-seam ISL NO NO ISL lattude threshold (degree) 60 - B. Traffc Modelng for HTTP Web Applcaton The applcaton traffc used n the NS-2 smulatons s based on Packmme-HTTP web object whch generates the realstc synthetc web traffc [17]. We modfed the average server response fles szes to be based on Pareto dstrbuton wth average dscrete values of 20 Kbytes and 30 Kbytes. Meanwhle, the average nter-arrval tme for both request and response connectons follow margnal dstrbuton (e.g. a combnaton of modfed fractonal-arima and Webull dstrbuton functons) wth average new connecton rates vares between 1 and 5 connecton/second. We smplfed the complex equatons of fle sze and nter-arrval dstrbutons taken from the NS-2 source codes as follows. The current server response fle sze s randomly generated usng Pareto dstrbuton based on 3 average (e.g. avg_(x)) values whch are 20 Kbytes and 30 Kbytes respectvely. Equaton (1) shows the random varable of fle sze where x corresponds to the average szes. The RNG corresponds to the random number generator functon that generates numbers unformly dstrbuted between 0 and 1. The S(x) and P are the Pareto scale and shape parameters respectvely. The S(x) n (2) s a varable based on the average fles szes n (1) whle the P s a constant (.e. 1.27). S( x) F( x) (1) (1 P) lm RNG( n) n1 avg _( x) ( P 1) S( x) (2) P The current nter-arrval tme of new HTTP connecton s generated as n (3) where p corresponds to the fractonal autoregressve ntegrated movng average (f-arima) random dstrbuton functons as shown n (4) and (5). The shape and scale parameters n (6) and (7) are the Webull shape and scale varables respectvely whch correspond to the dscrete average new connecton rate (R) values between 1 and 5. The A and C are the sgma-epslon and sgma-nose coeffcents respectvely whle B s the f-arima nternal state coeffcent. The D, E and F are the Webull coeffcents whle G and H are the Gamma coeffcents parameters. Further detals of the parameters nvolved n the followng equatons could be read n [17]. (1 shape) Ih( log( 1 p) scale (3) 0.5 f y( 0 y( 1 erf 2 p f ( y( ) f y( 0 (4) 2 y( erfc 2 f y( 0 2 y( A f _ ARIMA( B C (5) 178

3 D R F logr E log 2 shape (6) D E 1 2 F scale 1 logg 1shape H R e 1 The TCP-New Reno segment sze s set to 576 bytes (.e. 536 bytes of payload and 40 bytes of header) wth maxmum congeston wndow sze of 30 packets. The man reasons for choosng small segment sze and maxmum congeston wndow are to accommodate many HTTP web connectons wthn the 2 Mbps of lnk bandwdth and also to reduce buffer overflow when the number or new connectons ncreased. TABLE II shows the HTTP web parameters used n the smulatons. Parameter HTTP server response fle sze New connecton nter-arrval tme TCP type TCP packet sze TABLE II. HTTP WEB PARAMETERS Value Model : Pareto Dstrbuton Average (avg_) : 10, 20, 30 Kbytes Shape (shape) : 1.27 Model : Margnal Dstrbuton Average connecton/second (R): 1, 2, 3, 4, 5 New Reno 576 bytes (536 bytes payload + 40 bytes header) C. Dfferentated Servces (Dffserv) Dfferentated Servces (Dffserv) s an Internet QoS archtecture whch s developed to resolve scalablty problems and to provde preferental treatment to traffc flows based on class of servce (CoS). The Dffserv queung mechansm n the smulatons used Random Early Detecton (RED) queue and Tme Sldng Wndow 3 Color Marker (TSW3CM) polcer type whch dfferentate traffc flows based on 3 drop precedence (.e. Green, Yellow and Red). Traffc flows classfcaton wll be based on the Commtted Informaton Rate (CIR) and Peak Informaton Rate (PIR) whch are set to 1.85 Mbps and 1.9 Mbps for the total TCP connectons. Ths settng s to allow the maxmum lnk utlzaton to be between 90% - 95% (.e. lnk bandwdth of 2 Mbps). Packets wll be marked as Green f the flow rate less than CIR, Yellow f the flow rate between CIR and PIR, and Red f the flow rate more than PIR. Red marked packets wll be randomly dropped frst followed by Yellow and Green packets respectvely only f the buffer space exceeds mnmum threshold. All packets wll be dropped f the buffer space exceeds maxmum threshold. TABLE III shows the Dffserv queue confguraton. The total buffer sze of physcal queue s 350 wth average packet sze of 576 bytes. The 3 vrtual queues are vrtually some fractons of the physcal queue sze whch correspond to the mnmum threshold (mnth) and maxmum threshold (maxth). Assumng that 95% of the total physcal (7) queue buffer sze s used for user traffc, therefore the maxth could be set to 335 packets. The mnth s set less than maxth. TABLE III. DIFFSERV QUEUE CONFIGURATION Parameter Value Commtted Informaton Rate (CIR) 1.85 Mbps Peak Informaton Rate (PIR) 1.90 Mbps Mnmum Threshold (mnth) 300 packet Maxmum Threshold (maxth) 335 packet Packet Drop Probablty 1 (Green) 0.01 Packet Drop Probablty 2 (Yellow) 0.05 Packet Drop Probablty 3 (Red) 0.10 III. RESULTS AND ANALYSIS Each NS-2 smulaton s carred out for approxmately one hour of smulaton tme. The smulatons are done 5 tmes (.e. based on connecton rate (R) values whch are between 1 and 5) for each HTTP server response fle sze (e.g. avg_ values whch are 10, 20 and 30 Kbytes) n 3 dfferent BER values. Therefore, the total numbers of repeated smulatons are 90 tmes for both terrestral-leo and terrestral-geo smulaton scenaros. The smulaton results and analyss wll be dvded nto 4 QoS categores whch are delay, loss rato, throughput and HTTP web connecton duraton. Each category refers to the IP over satellte performance metrc and measured as average values per hour. The QoS parameters are calculated from NS-2 output trace usng AWK programmng scrpt and then plotted on graphs usng Mcrosoft Excel. In order to get better understandng of the followng fgures, we use the same reference symbols and annotatons. There are 9 colored lnes on each graph whch represent the QoS categores on 3 dfferent HTTP server response fles szes and 3 dfferent BER values whch are 10-7 (.e. symbol), 10-6 (.e. x symbol) and 10-5 (.e. symbol). A. Average End-to-End Packet Delay The packet delay s measured by subtractng the packet receved tme at the clent (t r ) to the packet sendng tme from server (t s ). The average delay (D) s measured by summng up all packets delays and then dvded by the total number of successfully receved packet (P t ) at the clent sde as shown n the followng equaton. n 1 D s) t Pt r ts ( (8) Fg. 2 shows that the average packet delay s proportonal to the ncrement of average new connecton per second. The more new connecton establshed per second, the hgher would be the delay. In addton, the delay also ncreased when the BER values ncreased from 10-7 to 10-5 due retransmsson. However, the delay values n Fg. 2 are much hgher than n because of dstnct dfference n alttude between GEO and 179

4 Average Packet Delay Over LEO Satelltes Max =0.2421s, Kbytes, Mn =0.1199s, Delay (s) Loss Rato Average Packet Loss Rato over LEO Satelltes Max = , Kbytes, Mn = , BER Delay (s) Average Packet Delay Over GEO Satelltes Max =0.3846s, Kbytes, Mn =0.2866s, Fgure 2. Average end-to-end packet delay. Loss Rato Average Packet Loss Rato Over GEO Satelltes Max = , Kbytes, Mn = , BER 10-6 Fgure 3. Average end-to-end packet loss rato. 6 LEO satelltes. Moreover, the propagaton delay over GEO satellte system s more than 250 ms [18] as opposed to the LEO satelltes system whch s more than 12 ms [6] dependng on the hop count wthn the satelltes network. The delays steadly ncreased between 1 and 3 average new connecton per second. However, after 3 average new connectons per second, sgnfcant dvergence could be seen between each flow of packet sze wth maxmum average packet delay of second and second (.e. flows wth 30K bytes and ) n LEO and GEO systems respectvely. In addton, the mnmum average packet delays are second and second for flows wth 10 Kbytes and n LEO and GEO systems respectvely. There are two man reasons that cause the delays varaton whch are the ncrement of queung delay and the ncrement of packet retransmsson. The queung delay wll ncrease when the number of ncomng packets ncreased whch wll fll up the buffer space. The ncomng packets of new flows keep on ncreasng regardless of the completon of prevous flows. When the nflux rate become more than the queue servng tme, packets wll be dropped and longer delay s needed to retransmt that packets from server to clent. Besdes that, the packet retransmsson manly happened because of early drop by Dffserv RED queue for the Red marked packets and also due to the packets drop n the satellte lnks. B. Average End-to-End Packet Loss Rato Loss rato (L) refers to the rato of total packet loss ( P l ) over total transmtted packet from server to clent (P s ). Equaton (9) shows the loss rato calculaton. n L Pl 1 (9) n P 1 s Fg. 3 shows that the average end-to-end packet loss rato s proportonal to the ncrement of average server response fles szes, average new connecton per second and BER values. The loss rato values for all HTTP web flows over GEO satelltes are slghtly more than the one n LEO system. Ths manly due to the hgher round-trp-tme (RTT) that cause the buffer space n most queues to fll up more quckly by the nflux of new connectons. In addton, the Dffserv queue regulates the flows by probablstcally drop packets when buffer sze exceeds mnmum threshold (.e. when packet nflux rate more than queue servng tme). 180

5 Average Packet Throughput Over LEO Satelltes Max = Kbps, Kbytes, 30 Kbytes Kbytes 650 Mn = Kbps, Kbytes Throughput (Kbps) Throughput (Kbps) Average Packet Throughput over GEO Satelltes Max = Kbps, 30 Kbytes, Mn = Kbps, Fgure 4. Average end-to-end packet throughput. 30 Kbytes 20 Kbytes 10 Kbytes Besdes that, the BER n satellte network also produce sgnfcant ncrement n packet loss especally for BER values above Based on the Fg. 3, the mnmum average end-to-end packet loss rato could be seen at 1 average new connecton/second, 10 Kbytes average server response fle sze -7 and BER of 10 whch correspond to average loss rato values of n terrestral-leo system and n terrestral GEO system. The maxmum average packet loss rato values are at 5 average new connecton/second, 30 Kbytes average server response fle sze and whch correspond to average loss rato of n terrestral-leo system and n terrestral-geo system. The average loss rate s below 5% n worst condton due to the Dffserv QoS control and TCP relable connecton n both systems. C. Average End-to-End Packet Throughput The average end-to-end packet throughput (T) s calculated by dvdng the total receved packet (P t ) at the clent sde over the total duraton of HTTP web flows. The value s then multpled by 8 and dvded by 1000 n order to get the value n Kbps. The HTTP web total duraton s calculated by subtractng the recevng tme of last packet at the clent sde (t l ) to the sendng tme of frst packet from the server sde (t f ). Connecton Duraton (s) Average HTTP Web Connecton Duraton Over LEO Satelltes Max = s, 30 Kbytes, BER Mn = s, Connecton Duraton (s) 10 Kbytes - BER 10 ^-5 20 Kbytes - BER 10^-5 30 Kbytes - BER 10^-5 Average HTTP Web Connecton Duraton Over GEO Satelltes Fgure 5. Average HTTP web connecton duraton. Max = s, 30 Kbytes, BER 10-5 Mn = s, The total duraton s slghtly less than the 1 hour of smulaton tme because the HTTP web connectons start a few seconds after the network scenaro setup n NS-2 s completed. n Pt ( ) 8 ( Kbps) 1 tl t f 1000 T (10) The average end-to-end packet throughput concludes the prevous QoS parameters because they are closely related as shown n (10). It s proportonal to the total receved bt varaton and nverse proportonal to the packet delay varaton. Based on Fg. 4, the average end-to-end packet throughput s proportonal to the ncrement of average server response fle szes and average new connecton/second. The hgher the average server response szes and average new connecton rate, the hgher would be the P t. However, the average packet throughput decreases as the BER ncreased. The P t receved at hgher BER (.e ) s less than the one at lower BER (.e ) wthn total flow duraton due to many packets losses

6 D. Average HTTP Web Connecton Duraton In real world, the average HTTP web connecton duraton could be regarded as the tme conceved by the clent upon sendng a HTTP URL usng web browser untl all web contents loaded on the computer screen. The HTTP web connecton duraton s calculated for every completed flow wthn 1 hour of smulaton tme by subtractng the recevng tme of last packet at the clent sde (T l ) to the sendng tme of frst packet of a connecton at the server sde (T f ). The average value (C d ) s calculated by summng up all completed connecton duratons and then dvded by the total number of completed connectons (f t ) as shown n (11). f t T l T f C d s) 1 ft ( (11) Based on Fg. 5, the average HTTP web connecton duraton s proportonal to the ncrement of average HTTP server response fles szes, average new connecton rates and BE R values. The hgher the average server response fles szes and BER, the longer would be the tme needed for the connecton to complete. The reason s related to the packet loss rato whch ncreased rapdly n hgher average server response fles szes especally for hgher BER values due to the retransmsson of many packets loss. IV. CONCLUSION AND FUTURE WORKS Ths paper presented smulaton studes to show top-down comparson between terrestral-leo and terrestral-geo networks for the end-to-end QoS performance evaluatons of HTTP web applcaton. The end-to-end QoS parameters (.e. average packet delay, average packet loss rato, average packet throughput and average HTTP web connecton duraton) are measured aganst the varaton of average HTTP response fles szes (.e. 20 Kbytes, and 30 Kbytes), average new connecton/second (.e. between 1 and 5) and BER (.e. 10-7, 10-6 and 10-5 ) for 1 hour of NS-2 smulaton tme. The average packet delay, average packet loss rato, average packet throughput and average HTTP web connecton duraton are proportonal to the ncrement of average new connecton rates, average server response fles szes and BER values. Other parameters that contrbute o the ncrement of QoS parameters are the queung delay, buffer sze and the lmted lnk bandwdth that lmt the burst of new HTTP web connectons. The future works wll nvolve a cross-layer technque for end-to-end QoS performance enhancement. Ths may nclude the transport and network layers modfcatons. On the transport layer, a TCP Performance Enhancng Proxy for satellte lnks satpep could be ntegrated n the system to mprove TCP performance by usng splt connectons and dynamc wndow reszng based on avalable bandwdth. Ths wll greatly reduce the TCP packet round-trp-tme (RTT) especally n terrestral-geo system. The satpep also may have a better packet loss recovery mechansm by usng Negatve Acknowledgement (NAck). Moreover, the network layer enhancement ams to optmze the bandwdth utlzaton on satellte lnks by usng load balancng technque wth multple GSL on both server and clent sde. Ths wll nvolve multple paths lnks from server to clent. An admsson control wth Dffserv queue nterface wll be placed on the terrestral network to regulate and dfferentate the flow paths over the satelltes based on current delay and throughput. REFERENCES [1] The European Telecommuncatons Standards Insttute, [2] ETSI, Dgtal Vdeo Broadcastng (DVB) framng structure, channel codng and modulaton for 11/12 GHz satellte servces, EN , August [3] ETSI, Dgtal Vdeo Broadcastng (DVB): user gudelnes for the second generaton system for broadcastng, nteractve servces, news gatherng and other broadband satellte applcatons (DVB-S2), TR , February [4] ETSI, Dgtal Vdeo Broadcastng (DVB): nteracton channel for satellte dstrbuton systems, EN , [5] Tooway, [6] L. Audah, Z. Sun and H. Cruckshank, End-to-end QoS of IP-Dffserv network over LEO satellte constellaton, n Proceedngs of 2 nd Internatonal ICST Conference on Personal Satellte Servces, PSATS 2010, Rome, Italy, February 2010, pp [7] S. Kttperachol, Z. Sun and H. Cruckshank, Performance evaluaton of on-board QoS support for multservce applcatons on the ntegrated next generaton satellte-terrestral network, n Proceedngs of 4 th Internatonal Conference on Advanced Satellte Moble Systems, ASMS 2008, pp [8] K. Nchols, S. Blake, F. Baker and D. Black, Defnton of the Dfferentated Servces Feld (DS feld) n the IPv4 and IPv6 headers, IETF Network Workng Group, RFC 2474, [9] S. Blake, D. Black, M. Carlson, E. Daves, Z. Wang and W. Wess, An archtecture for Dfferentated Servces, IETF Network Workng Group, RFC 2475, [10] J. Yang, J. Ye, S. Papavasslou and N. Ansar, Decouplng end-to-end QoS provsonng from servce provsonng at routers n the Dffserv network model, n Proceedngs of Internatonal Conference on Global Telecommuncatons, GLOBECOM 2004, vol.3, no.1, pp [11] J. Yang, J. Ye, S. Papavasslou, Enhancng end-to-end QoS granularty n Dffserv network va servce vector and explct endpont admsson control, IEEE Journal of Communcatons, vol.151, no. 1, pp.77-81, [12] L. Myounghwan, J.A. Copeland, An adaptve end-to-end delay assurance algorthm wth dffserv archtecture n IEEE e/IEEE hybrd mesh/relay networks, n Proceedngs of 18 th Internatonal Conference on Computer Communcatons and Networks, ICCN 2009, pp [13] R. Feldng, J. Gettys, J. Mogul, H. Frystyk, L. Masnter, P. Leach and T. Berners-Lee, Hypertext Transfer Protocol HTTP/1.1, IETF Network Workng Group, RFC 2616, [14] Bg LEO Tables, constellatons/tables/tables.html. [15] H. Cruckshank, Z. Sun, F. Carducc and A. Sanchez, Analyss of IP voce conferencng over EuroSkyWay system, IEEE Journal of Communcatons, vol. 148, no. 4, pp , [16] M. Allman, D. Glover and L. Sanchez, Enhancng TCP over satellte channels usng standard mechansms, RFC 2488, [17] J. Cao, W.S. Cleveland, Y. Gao, K. Jeffay, E.D. Smth and M. Wegle, Stochastc models for generatng synthetc HTTP source traffc, n rd Proceedngs of 23 Conference of the IEEE Communcatons Socety, INFOCOM 2004, Hong Kong, March 2004, vol. 3, pp [18] Z.Sun, Satellte Networkng: Prncples and Protocols, 1 st ed., John Wley & Sons Ltd, 2005, pp