[clue-tech] Downside of increasing TCP window size?

[Jim Ockers]

Hi Nate,

So far the only feedback I've gotten about what effect increasing the
window size would have is that it could make the web server take longer
to recognize a TCP socket problem with a terrestrial client that some-
how lost its connection and is no longer able to ACK anything.

That doesn't seem too serious but I wonder if there are any other
possible gremlins associated with making our web server have huge
TCP send-windows and small TCP receive-windows.

> > The Layer 2 is a 4800 baud MSAT satellite dialup to the PSTN and our
> > own terminal server (with an analog modem) using Linux pppd on both
> > ends.  The TCP connection is an SSL request to an apache web server, 
> > using the Perl Net::SSL libraries via LWP::UserAgent and possibly 
> > HTTP::Request.
> 
> Is it possible to dump the MSAT/PPP mess with all those layers and 
> switch to something designed for fixed satellite data.  (And I don't 
> mean nasty ol' Starband.)

Unfortunately for this project we have to get the MSAT to work properly.
MSAT is basically POTS phone but they do have a 4800 bps modem in the
satellite terminal unit with an RS232 port on the side of the housing.
You can issue AT commands like ATDTnnn-nnn-nnnn and it will make a data
call at 2400 or 4800 bps.  Each MSAT terminal has two phone numbers 
provisioned - one for voice, one for data, and they can be enabled/
disabled independently by the satellite operator.

We use Mitsubishi ST200 MTs (mobile terminals) designed for vehicle
or marine mounting.  They are truly outstanding pieces of hardware,
even if the data rate is a bit slow.  :)  Very reliable, and the dish/
radome is very small (8 inch diameter, or so).

> Just going by your description, it sounds like this is a fixed satellite 
> service, and doing the whole MSAT/dial-up/PPP thing sounds like it's 
> adding all sorts of lovely things.  Is PPP already optimized for the 
> path's MTU size, for example?

We set the MTU on both ends to 576.  A single retransmitted frame
with MTU1500 saturates the link for a "long" time, causing even more
retransmits, creating a death spiral for the connection.

> Now you're going to ask: What do I recommend they switch to?  That's 
> hard... see, I know there ARE lowerish-latency satellite links out 
> there, 'cause a friend of mine used to do some work at McMurdo Station 
> in Antartica and well, it's hard to tell he's not on a terrestrial link 
> -- we did some VoIP stuff between here and there and got some special 
> allowances to do some link tests, etc... ICMP is normally blocked at the 
> terrestrial side of the link at a firewall, but we had a couple of IP's 
> to experiment with for a few days.

We are in the process of switching to iDirect (www.idirect.net) and
their software is really, really smart.  So far I've been pretty
impressed with it.  The TCP acceleration they do is very good.  Essen-
tially what I've been trying to do is get my PPP link to work for
TCP like the iDirect link, without the spoofed TCP ACKs though.

> the world you're trying to reach.  I'm not sure what MSAT is, but why 
> does it need chatty whiny PPP riding over it to make it work?

For this particular application we need PPP to work.  For most of our
data transfer over MSATs we use zmodem, which has a very good window
scaling mechanism and is very efficient even over high latency links.

-- 
Jim Ockers, P.Eng. (ockers at ockers.net)
Contact info: please see http://www.ockers.net/