Thursday, February 25, 2010

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.

2 comments:

Nicolas said...

Not sure if you took a look at the RFC 5783 they recently released. I've been trying to make the time to read it, it sounds like a nice consolidation of this interesting topic.

Nicolas
http://ccie-en-espanol.blogspot.com/

cciep3 said...

Hi Nicolas

RFC's are published every day almost, that specific RFC is created to make some kind of summary document for what was done until today, not bringing any news to the table.

With that said it can be a nice refeerance document.