I agree that mobile channels introduce other problems, but in this case it's
the low data rate that's the issue not the mobility. Inmarsat Mini-M is a
digital system, with FEC and interleaving and actually provides a channel
that has a fairly good BER as long as the SNR is high enough. If the SNR
drops too much then you are likely to drop the connection - it's a sharp
cutoff, not a smooth degradation of service. And anyway, my testing has been
from a fixed location...
The slow channel speed is the biggest factor, since at 4 kbps it will take 3
secs to transmit 1500 bytes (if the channel is 8 bits, synchronous). If it
is 10 bit asynchronous (8 bits data, 1 stop and 1 start bit) then it would
take 3.75 sec. Many sources recommend an MTU size equivalent to what can be
transmitted in 100-200 ms but I think that is not really appropriate for
slow channel speeds 'cause the efficiency would be very poor. At 4kbps, a
200 ms MTU would be only 100 bytes (with at least 40 bytes of this being
TCP/IP overhead!).
-Greg
LCDR Gregory W. Johnson
Ass't Prof. Electrical Engineering
USCG Academy
New London CT
860-444-8683
-----Original Message-----
From: Davenport, David M (CRD) [mailto:[email protected]]
Sent: Tuesday, February 15, 2000 3:18 PM
To: '[email protected]'
Subject: RE: Setting the appropriate MTU
Now you've added mobility to the equation...
With Inmarsat-M/Mini-M and other low data-rate, mobile satellite services
an appropriate MTU selection is driven primarily by the Rician/Rayleigh
fading channel and the trade-off:
Large data frames to increase throughput efficiency
- vs. -
Small data frames to reduce required retransmission due to fading/shadowing
For fixed site satellite with BER < 10^(-5), I'd suggest IP fragmentation
along the
entire route dominates MTU selection...and the bigger the better.
David M. Davenport
GE Corporate Research and Development
One Research Circle, M/S KWC421
Niskayuna, NY 12309
Phone/Fax: (518) 387-5041/4042
***** Opinions contained herein are my own
and not necessarily those of my employer *****
This archive was generated by hypermail 2b29 : Wed Feb 16 2000 - 10:17:12 EST