TCP Over Satellite communications

First I would like to say it has been a very long time since my last article, but now I am in the mode for writing so I would like to share my expireance with TCP and Satellite Communication challanges. I am working at Expand Networks and one of our advantages is in optimizing TCP communication in challanging enviorments such as Satellite, so what is so challanging you ask??

• The Satellites we use for communication are up in the sky ~35000 kilometer away from ground also called GEO Sat
• Communication between ground station to the Satellite easly impacted from enviorment (clouds, rain, snow, solar events...)
• Satellite is a shared resource

All the Satellite set a big challange in TCP communication, one of the main is RTT (round trip time), the other is packet loss due to channel error's the satellite may encounter.

To overcome this challanges we use some of the avilable TCP enhancments avilable such as: proxying the TCP session and in the session over the satelite increasing Window Size using the window scale options. additional to that selecting the congestion control that is most suitable for the enviorment we are in. the congestion control as his name indicate is an algorithem that tells the TCP when to back off because a congestion was detected or when to continue and at what level to send the tcp traffic.

Here are Some of the Congestion Control Algorithems:

Reno - the most common used today by default (linux implement NewReno), basicly during the slow start increasing 1/cwnd for each ACK recived and decrease by 0.5 if a loss was detected

BIC - binary increase congestion as the name imply it uses some binary search algorithem to esitimate the correct cwnd

CUBIC - another algorithem considered some kind of enhancment to the BIC algorithem

Hybla - some kind of a hot topic in congestion control algorithem over satellite communication

Vegas, illinois,Veno, Westwood....

basicly you can see that there are many algorithms out there and all are created due to diffrent challanges sattelite , wireless or even wired communication had brought over the years.

There is no ultimate algorithem that can handle all sitiuations (as of today), each have his advantages and disadvantages, Reno is ok when delay is going +-20ms + RTT but more then that if you had +-100ms + RTT with Reno you would be in a problem as it would often back off the window by half.

TCP Window Scale

One of the overlooked subjects especially when it come to the CCIE RS is the real deep knowledge and understanding of TCP, the one subject from the scope of TCP that I would like to pass to you readers is the concept of Window Scaling. Why do we need window scaling or what the hell is it?! First may be lets start with the why, I do not know about you guys but when I am buying something I expect to utilize it fully and not half way, and the same goes to my Internet line if I buy 10Mbps pipe I do not want to utilize only 5Mbps. So What is Window Scaling and how can he help us better utilize our pipe?! Window Scaling is an optional enhancement that allows us to extend our window size so you say wait why do I need to extend my window size? Well normally the window size is 16 bit with a max size of 64K byte and when you are talking about a in your LAN delay (1ms avg) that is more then enough for just above 500Mbps but when we are over the WAN we start experiencing some delays the amount of throughput we can provide is decreasing fast, already with 10ms delay you can have only just above 5oMbps with 100ms we already in 5Mpbs and you see where is that going. so what and how we can take the 16bit we have in the TCP header and make them bigger well the simple answer is we cant as we have only 16bit not one bit more in the header for window. but what we can do is use the options 3 byte filed to where we indicate what is our scale factor, the defined scale factor can be between 0 to 14 where the max window can be 1GB 65536 * (2^14) = 1073741824 well now we are talking this is a window. but with grate window come grate responsibility, now we need to watch out for overflowing the network causing congestion (the congestion will be for another talk). So basically what we learned is that the higher the Delay we need a bigger window to free the belt on our traffic. The Max Throughput calc is actually very simple: [ WIN(in bits)/delay(in second) ] / 1000000 = Throughput in Mbps Scale Window calc is: (2^scale factore) * window(bytes) Notice that as the WS is optional it must be offered by both sides to and the lowest WS factor win.