I think this makes for great reading. Rgds,
Samuel Gitta Network / Systems Administrator AfricaOnline Uganda -----Original Message----- From: Patrick Gannon [mailto:[EMAIL PROTECTED] Sent: Friday, November 28, 2003 10:43 PM To: [EMAIL PROTECTED] Subject: [isp-satellites] flash networks nettgain BST When I saw the question from Mark, my first reaction was - why would you want to double up the TCP Acceleration technology, as I assumed that surely the Shiron product must already have TCP Acceleration built into it. I spent some time on the Shiron site, and in fact, they seem to brag on their VPN white paper, about having a pure TCP/IP transport that does not use TCP Accelerators or spoofing. This struck me as interesting since I know (enough to be dangerous) about the nature of TCP over satellite. On one of their network operator's web pages that provides far more detail about the product than they provide on their own site, it says that the download speed per TCP session is either 1.1 Mbps (NT) or 1.6 Mbps (95/98/2000) depending on the operating system. The default window size for TCP is 8 KB and without TCP Acceleration the fastest a TCP session will operate over a typical satellite link with that window size, regardless of the speed of the link is about 90 Kbps, and 70 Kbps is probably more typical. A 32 Kbps window will support just over 400 Kbps of throughput, so the way I'm interpreting this is that servers using very large non-standard TCP windows that will theoretically deliver up to 1.x Mbps of TCP throughput, but I wonder how realistic that is in the real world? As I understand it, supporting non-standard window sizes requires hand tuning of client and server. What all has to be tweaked in order to support huge TCP window sizes in order to get maximum throughput? Normally TCP reduces it's window size when packets are dropped, as it interprets all dropped packets as network congestion - so in the event of errors, which are common during rain for example, one would expect throughput to drop significantly, not just due to retransmissions, but because the window size gets reduced, thus limiting throughput. I also wonder what the affects would be on small packets like VoIP when a large TCP window has been established, as the smaller VoIP packets would get queued up behind the larger TCP packets, thus adding jitter. On the upload, no specifications regarding per session TCP throughputs are provided on Shiron's site or the network operator's site I reviewed, which would lead me to believe that there is no TCP acceleration on the uplink, and an unwillingness to tell users what kind of per session throughput they will see. Can anyone provide real-life examples of uplink and downlink throughput for TCP sessions? I am curious if anyone has done any performance tests on TCP applications to see what the per-session throughput is on the InterSky platform, in either PAMA (SCPC return) or BOD (shared bandwidth) mode. I would expect that the maximum uplink throughput for any given TCP session without the use of Netgain or some other TCP Acceleration device such as Mentat SkyX would max out at about 70 Kbps regardless of how fast the actual link speed is. TCP is a guaranteed delivery protocol. It begins transmission with a 'slow start' process that sends a 'segment' of data and then waits for an ACKnowledgement before sending more. With each successful ACKnowledgement that the packets were received by the other side, it sends larger 'segments' containing more data. What happens in satellite networks is that the latency of over 1/2 second round trip makes the TCP sending device (PC or server) think it is on a very slow or congested line because it takes so long for the ACKs to come back from the remote site. This means it takes a longer time to ramp up it's full speed, and due to the latency delaying the acknowledgements, it will eventually top out at some speed based on the window size, regardless of how much bandwidth is available on the link. I understand that about 70 Kbps (per session) is pretty typical. Examples of TCP application layer protocols that can be accelerated are HTTP, FTP, SMTP, Telnet, IRC. Examples of UDP application protocols that can't be accelerated are SNMP, RTP, BOOTP, NTP, TFTP. Of course it is possible to saturate a link with multiple TCP sessions, each getting up to 70 Kbps or so, but without TCP Acceleration I don't see how any individual session could exceed that number by much, regardless of whether there is any other traffic on the network. During times that bandwidth is available due to reduced network traffic, it seems a waste of bandwidth that sessions would be limited to 70 Kbps or so, when in fact there maly be more bandwidth available that might be taken advantage of. Imagine buying an uplink speed of 256 Kbps and being the only PC active on your LAN, but still being limited to 70 Kbps - ouch! This actually happens in many SCPC networks because most have no TCP Acceleration! If in fact, there is no TCP Acceleration in the InterSky product, then the NetGain, Mentat or other TCP Acceleration techniques would definitely increase the speed of a TCP session on that or any other platform that does not have a built-in TCP acceleration technology. The way TCP Accelerators work, is to intercept the acknowledgement requests (SYN) and respond locally with (ACK) rather than waiting for the packet to actually make it all the way to the other side of the satellite link. The TCP Acceleration solution should know what the actual satellite link speed is, so it can ACKnowledge packets locally in such a way as to optimize the actual link bandwidth available. In this way, each individual TCP session has the capability to burst up to the full satellite link speed (based on availability due to other trafic). The difference between Spoofing and TCP Acceleration is that the Spoofer does not maintain an end-to-end accounting and buffering of the actual packets sent and whether they were in fact actually ACK'd by the remote side. In the event a packet is dropped, the Spoofer has no way to resend just the dropped packet and the transmission must begin from scratch, resulting in resending packets that were already successfully sent and received. A TCP Accelerator will buffer packets for a short time and if the remote site indicates that a packet was not actually received error-free, then the dropped packet can be resent. As occasional acknowledgements are received that the packets actually made it to their destination successfully, the buffers are flushed. Another interesting acceleration technique is HTTP Acceleration, which speeds up the 3-way handshake that all TCP sessions employ. When you go to a web page that has multiple pieces of content coming from different places, each of those requires a 3-way handshake before the transfer begins. HTTP Acceleration can dramatically speed up web page downloads by intercepting the handshake requests and responding to them locally - just like TCP Acceleration. Here's how it works - the PC requests a web page, the server comes back and says - do you really want this - the PC responds, yes send it, and the transfer starts..... then it needs to send a picture or another piece of content as part of the web page download, so the PC says, send it, and the server says, are you sure, and the PC says, yes - send it and the content is sent. Now think about the satellite delay for each one of those small conversations between the PC and the server and add up all the satellite latency for each individual piece of content on a web page.... on some pages this can add 10's of seconds of download time for a web page. I'm pretty sure Netgain offers this HTTP Acceleration capability as well as TCP Acceleration. An interesting subject for a future post is VPNs and how they fit into this whole TCP Acceleration issue. I got a chuckle out of Shiron's VPN white paper because what they are basically saying is that on their solution, VPNs don't have a performance hit compared with normal TCP traffic, because all their TCP traffic is slow. Ah, the magic of marketing to turn a limitation into a feature! From their white paper: "One of the advantages of the InterSKY bi-directional IP over satellite system is that it is designed to pass pure TCP/IP. As incredible as it may sound, many other systems are not designed to pass TCP/IP. These systems often utilize inherent protocol accelerators or “spoofers” to improve throughput. What our competitors will not tell you is that their “spoofer” is incompatible with encryption equipment." Note first of all that they make no mention of what they do to "improve throughput" so all I can take from that is that they do not improve throughput compared with their competitors... and secondly it isn't an issue of being "incompatible with encryption equipment." That is highly simplistic and misleading does begin to tell the whole story, but we'll leave that for another post another day... Pat P.S. Learn more about TCP Acceleration at these sites: http://www.mentat.com/skyx/skyx-whitepaper.html http://www.bsatellite.com/Why_iDirect.html#3 I also have an excellent NetGain white paper in pdf format that I can't find on their website any longer, in order to provide a link. They list these references at the end of their white paper: [1] Enhancing TCP Over satellite Channels using Standard Mechanisms, Request For comments, RFC 2488 M. Allman, D. Glover and L. Sanchez, Internet Engineering Task Force (IETF), 1999 http://www.ietf.org/rfc/rfc2488.txt [2] HTTP Page Transfer Rates Over Geo-Stationary Satellite Links. Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. Proceedings of the Sixth International Conference on Telecommunication Systems, March 1998. http://roland.grc.nasa.gov/~mallman/papers/nash98.ps [3] HTTP Experiments in Satellite-Based Networks. M. Allman, Presented at the Telecommunications Industry Association Meeting. March 1999. http://roland.grc.nasa.gov/~mallman/papers/tia-3.99.ps [4] TCP Performance Over Satellite Links.Mark Allman, Chris Hayes, Hans Kruse, Shawn Ostermann. Proceedings of the Fifth International Conference on Telecommunications Systems, Nashville, TN, March, 1997. http://roland.grc.nasa.gov/~mallman/papers/nash97.ps. [5] The effects of asymmetry on TCP performance Hari Balakrishnan, Venkata N.Padmanabhan, and Randy H.Katz. Proceedings of the third annual ACM/IEEE international conference on Mobile computing and networking , 1997, Pages 77 – 89 http://www.acm.org/pubs/citations/proceedings/comm/262116/p77-balakrishn an/ [6] The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm. M. Mathis, J. Semke, J. Mahdavi, T. Ott, Computer Communication Review, volume 27, number 3, pp. 67- 82, July 1997. http://www.psc.edu/networking/papers/model_ccr97.ps [7] Modeling TCP throughput: a simple model and its empirical validation. Jitendra Padhye, Victor Firoiu, Don Towsley, and Jim Kurose. Proceedings of the ACM SIGCOMM '98 conference on Applications, technologies, architectures, and protocols for computer communication , 1998, Pages 303 – 314 http://www.acm.org/pubs/citations/proceedings/comm/285237/p303-padhye/ [8] TCP Behavior with Many Flows, Morris, R. IEEE International Conf erence on Network Protocols, October 1997, Atlanta, Georgia. http://www.eecs.harvard.edu/networking/papers/icnp97-web.ps Patrick Gannon Business Satellite Solutions, LLC Phone: (804) 556-3069 Email: [EMAIL PROTECTED] [EMAIL PROTECTED] Web: www.bsatellite.com > ---------------------------------------------------------------------- > > Subject: flash networks nettgain BST > From: "Mark Anthony C. Delfin" <[EMAIL PROTECTED]> > Date: Thu, 27 Nov 2003 08:45:40 +0800 > X-Message-Number: 4 > > hello, > > has anyone use nettgain technology from flash networks over shiron intersky > or any other VSAT system. > > does it really increase and/or improved tcp connections over > satellite. > > thanks in advance. > > mark > ---------------------------------------------------------------------- ======================================================== __________ The ISP-SATELLITES Discussion List __________ To Join: mailto:[EMAIL PROTECTED] To Remove: mailto:[EMAIL PROTECTED] Archives: http://isp-lists.isp-planet.com/isp-satellites/archives/ --------------------------------------------- This service is hosted on the Infocom network http://www.infocom.co.ug
