Subject: RE: Setting the appropriate MTU

From: "Johnson, Gregory LCDR" <[email-masked]>
Date: Wed, 16 Feb 2000 09:26:04 -0500

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-masked]]
Sent: Tuesday, February 15, 2000 3:18 PM
To: [email-masked]'
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 *****

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 16 Feb 2000 11:41:21 -0800 (PST)

> 200 ms MTU would be only 100 bytes (with at least 40 bytes of this being

Just a point of interests on the above.  TCP has a delayed acknowledgement
mechanism.  An ack is sent for every two segments or when the delayed ack
timer fires.  The delayed ack timeout value (DATO) is usually 200ms.  If it
takes more than DATO for TCP to receive a segment, there are two consequences.
First, TCP will ack every segments.  Second, every such acks will be a delayed
ack.  If TCP is going to ack every segment, it may be better to just turn
off delayed ack mechanism completely.  And depending on the reverse channel,
more acks may or may not affect performance.  Something to think about when
doing TCP throughput performance experiments with slow links...

							K. Poon.
							[email-masked]