SMTP, etc. with high RTT

I am looking at doing SMTP and HTTP over a two-way satellite link. Is
it possible to tune/tweak the 2.4 or 2.6 kernel on a machine that
could be acting as either server or client for these, such that TCP/IP
performance will not be too bad?

-- Mark

"Mark Carroll" <(E-Mail Removed)> wrote in message
news:r5s*(E-Mail Removed)

> I am looking at doing SMTP and HTTP over a two-way satellite link. Is
> it possible to tune/tweak the 2.4 or 2.6 kernel on a machine that
> could be acting as either server or client for these, such that TCP/IP
> performance will not be too bad?

Why do you think that the kernel is going to be the bottleneck?

--
use hotmail for any email replies


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

In article <(E-Mail Removed)>, ynotssor <"ynotssor"> wrote:
>"Mark Carroll" <(E-Mail Removed)> wrote in message
>news:r5s*(E-Mail Removed)
>
>> I am looking at doing SMTP and HTTP over a two-way satellite link. Is
>> it possible to tune/tweak the 2.4 or 2.6 kernel on a machine that
>> could be acting as either server or client for these, such that TCP/IP
>> performance will not be too bad?
>
>Why do you think that the kernel is going to be the bottleneck?

It's the kernel that manages the grungy details of TCP and IP, and
it's by fiddling with the details of the TCP implementation that
throughput can be improved. It's clear that if you do things like
increasing the sender's SO_SNDBUF and the receiver's SO_RCVBUF then
that helps, or fiddling with how TCP reacts to packet loss or doing
path MTU discovery or whatever - there are various kernel-level
parameters that can be tuned. But, if you can only tweak just the
sender or just the receiver, I'm less sure that useful stuff can be
done to overcome how satellite comms' high RTT, and the differences in
how packets tend to be lost, interact poorly with how TCP usually
works (which was works much better on ethernet and suchlike, after
all).

It's not so much that the kernel will be the bottleneck, so much as
that the kernel is one of the few things I can think of that is deeply
into the TCP stuff that I can tweak. And, there's a lot of literature
suggesting that TCP throughput over satellite can be much improved,
even just by fiddling with files in /proc/sys/net/ipv4/ and
/proc/sys/net/core/ based on what's described in ip-sysctl.txt in the
kernel documentation.

But, if I can only tweak one end of the connection, and fairly
standard stuff lies on the other side, it's less clear to me that I
can do enough to make inbound and outbound SMTP, and inbound HTTP,
work well. With SMTP, even without the pipelining thing, I can live
with the latency due to the RTT, but I'd prefer that the thing deal as
well as possible with packet loss so that connections aren't dropped
entirely.

-- Mark