Tuning TCP/IP For Satellite Links (Fedora Core 2 or Red Hat 9)

Anyone know how to tune a TCP/IP network for satellite latency?
We will, shortly, install an EMS Technologies 2000/3000 series
box attached to a satellite receiver. I believe the output into
our Fedora Core 2 system is an Ethernet type interface.

Given the long, know, delays in satellite paths, I was wondering
if anyone knew how to set up networking to allow for larger buffers,
longer TTLs etc?

Any help greatly appreciated. Must be Linux, though ...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.networking Philip N. Daly <(E-Mail Removed)> suggested:
> Anyone know how to tune a TCP/IP network for satellite latency?
> We will, shortly, install an EMS Technologies 2000/3000 series
> box attached to a satellite receiver. I believe the output into
> our Fedora Core 2 system is an Ethernet type interface.

I'd check if the receiver don't already care about it.

> Given the long, know, delays in satellite paths, I was wondering
> if anyone knew how to set up networking to allow for larger buffers,
> longer TTLs etc?

Try:

sysctl -a | grep tcp

And you should find what you are looking for, 'man sysctl' for
complete info.

Good luck

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBXePvAkPEju3Se5QRAl6BAKDCDssCB9t5GiB1u37fT8 JUolSPsACfUXFg
MPaBfoPeMrBaOGskuZOJoYQ=
=uptW
-----END PGP SIGNATURE-----

On Fri, 01 Oct 2004 23:10:40 +0000, Michael Heiming wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
>
> In comp.os.linux.networking Philip N. Daly <(E-Mail Removed)> suggested:
>> Anyone know how to tune a TCP/IP network for satellite latency?
>> We will, shortly, install an EMS Technologies 2000/3000 series
>> box attached to a satellite receiver. I believe the output into
>> our Fedora Core 2 system is an Ethernet type interface.
>
> I'd check if the receiver don't already care about it.

You mean the satellite receiver? I don't think it can. The problem is with
the end-to-end protocol and acknowledgements. I remember reading about
this a long time ago. With satellite links and standard TCP/IP parameters
what tends to happen is that the sender sends a bunch of packets (7? 15?
some small number) and then waits for the acknowledgements (which IIRC are
not just an ack, but also include the highest number of the consecutive
received packets, or some such). So, it is the sender backing off too soon
that is the problem. You have to reset the parameters to open wider the
sender's "window" of packets in transit. The satellite receiver shouldn't
interfere, as I think that would only make things more complicated.

Having said all that, I don't know what parameters to set to what.

>> Given the long, know, delays in satellite paths, I was wondering
>> if anyone knew how to set up networking to allow for larger buffers,
>> longer TTLs etc?
>
> Try:
>
> sysctl -a | grep tcp
>
> And you should find what you are looking for, 'man sysctl' for
> complete info.

Yeah, that is a bewildering array of parameters, and I find it
intimidating to try to figure out what to try to change.

Hmm, you would think that the sattelite service provider and/or receiver
vendor should know how to do this? or at least how to find good numbers?
....but then they want to sell more channel capacity?

--
Juhan Leemet
Logicognosis, Inc.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.networking Juhan Leemet <(E-Mail Removed)> suggested:
> On Fri, 01 Oct 2004 23:10:40 +0000, Michael Heiming wrote:
>> In comp.os.linux.networking Philip N. Daly <(E-Mail Removed)> suggested:
>>> Anyone know how to tune a TCP/IP network for satellite latency?
[..]

>> I'd check if the receiver don't already care about it.

> You mean the satellite receiver? I don't think it can. The problem is with
> the end-to-end protocol and acknowledgements. I remember reading about
> this a long time ago. With satellite links and standard TCP/IP parameters
> what tends to happen is that the sender sends a bunch of packets (7? 15?
> some small number) and then waits for the acknowledgements (which IIRC are
> not just an ack, but also include the highest number of the consecutive
> received packets, or some such). So, it is the sender backing off too soon
> that is the problem. You have to reset the parameters to open wider the
> sender's "window" of packets in transit. The satellite receiver shouldn't
> interfere, as I think that would only make things more complicated.

> Having said all that, I don't know what parameters to set to what.

Yup, dunno a shit about it, that would be how I'd start about the
problem.

>>> Given the long, know, delays in satellite paths, I was wondering
>>> if anyone knew how to set up networking to allow for larger buffers,
>>> longer TTLs etc?
>>
>> Try:
>>
>> sysctl -a | grep tcp
>>
>> And you should find what you are looking for, 'man sysctl' for
>> complete info.

> Yeah, that is a bewildering array of parameters, and I find it
> intimidating to try to figure out what to try to change.

There are a few with keepalive/retries in their name, worth
looking deeper. /usr/src/linux/Documentation/filesystems/proc.txt
might have some more info.

> Hmm, you would think that the sattelite service provider and/or receiver
> vendor should know how to do this? or at least how to find good numbers?

Another good idea.

> ...but then they want to sell more channel capacity?



--
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBXlOaAkPEju3Se5QRAn8AAJwMZwpYd5QGtL5kpjC9/kC9P+TOiQCbB2Ve
+zYZzutQGVMqqwpuHstts0o=
=FVEi
-----END PGP SIGNATURE-----