What can I do about slow IP traffic over a satellite link?

[rjohnson1]

Overview:

Our main location is in Seattle (Exodus 1Meg burstable Internet (Pix and 2600 router)). We also have another location in St. Maartin N.A. (internet 128k ppp to local ISP (2600 router)). LAN in St. Maartin consists of 4 Win98 boxes and 2 HP Jetdirect print servers. St Maartin's devices connect to Seattle for email, telnet sessions and print requests. We also use PCAnywhere for remote access and administration.

The problem:

Telnet sessions tend to lock and not return even while in a PCAnywhere connection. The PCA connection doesn't loose connectivity. Print jobs sent directly to HP devices will print small jobs but not large ones. Large ones tend to restart every so often. Email is similar to print jobs. The small ones get through but the large ones do not download at all.

The question:

Is there an IP compression utility that will work on cisco 2600s. Or is there some other idea out there.

Other notes:

This is a note from our providers ISP in St. Maartin that provides the satellite connection.

"THE DELAY OF TRAFFIC TRAVELING VIA SATELLITE IS ARROUND 500 MS. AS FAR AS THE LOAD OF

THIS CUSTOMER'S INTERFACE IN THE LAU-BB3 ROUTER, CURRENTLY IS AT ARROIND 171/255, HIGH

LOAD, AND THE REPORTER GRAPH HAS CONFIRMED THESE HIGH LEVELS OF TRANSMISSION THAT

CAN ATTRIBUTE TO CONGESTION AND DELAYS, IN ADDITION TO THE ALREADY SATELLITE DELAYS."

[svermill]

A couple of things to think about:

TCP window sizes can be a problem when the WAN connectivity is via satellite. This is due to the “bandwidth * delay product.” The number of bits “in flight” increases proportionally with both bandwidth and delay. So a larger number of segments need to go unacknowledged or TCP will leave the line idle while awaiting an ack. RFC 2488 addresses the issue. In particular, your telnet problem is addressed with the following passage:

…Due to the propagation delay of some satellite channels (e.g., approximately 250 ms over a geosynchronous satellite) it may take a long time for a TCP sender to determine whether or not a packet has been successfully received at the final destination. This delay hurts interactive applications such as telnet, as well as some of the TCP congestion control algorithms

That last part about congestion control algorithms is also important. TCP does some pretty detrimental things to effective throughput when a segment gets lost or, as perhaps in your case, times out. It automatically reduces the window size back to one segment (slow start). Big problem that leads to yet more problems. The link to the RFC is below because this discussion could go on for pages and pages. Bottom line – tuning TCP can be a real challenge but may be your only hope for realizing the full benefit of your satellite bandwidth!

One final thought. MTU discovery can be one relatively easy way to alleviate the problem if, in deed, MTU is a contributing factor (if you can’t easily increase the number of segments outstanding by tuning TCP, maybe you can increase the size of the segments in flight and, thus, increase throughput by virtue of more rapidly incrementing the congestion window, in terms of bytes, at the transmitter).

Best of luck,

Scott

http://community.roxen.com/developers/idocs/rfc/rfc2488.html

[elkou141061]

Hi

Guess those 2 document help to understand the

effect of SAT on TCP and the way to tune TCP

for SAT .

http://www.cisco.com/warp/public/759/ipj_3-2/ipj_3-2_tcp.html

http://www.cisco.com/warp/public/759/ipj_3-3/ipj_3-3_futureTCP.html.

Brgds