Jason Thorpe writes:

>It doens't really matter if I did or didn't.  In your ether+radio
>example, even the "traditional" code would have been bounded by the
>MTU of the outgoing interface!

Err, yes, that was the whole point.

here's a diagram (for clarity, no tcondescension!)
       (1kbyte mtu)
   .....                   .....           
    |                        |                         non-PMTU host C
 wireless host            Wireless gateway                  |
    A                        B                              |
    |                        |                              |
  ethernet                 ethernet  ------------------------
(isolated net,
 or unattached)

C doesn't do PMTU and has the old MSS behivour.

It doesn't matter whether A does PMTU or not: if it's doing in_maxmtu
advertisements, then it advertises an inappropriately-large MTU over
the wireless network.

If C doesn't do PMTU, and it sees the (ether-sized) MSS advertisement
from A, then C will clip its MSS to the Ethernet MSS.  There's no
fragmenttation on the C-B hop.

But B still has to fragement the EtherMTU sized packets over the radio
link.

Where bandwidth is scarce, packet loss is high, absolute packet rate
is limited, and doing IP fragementation of TCP packets is simply not
acceptable.  Inevitable drop rates over the wireless link, and
subsequent loss of fragements, renders the system thoroughly unusable.
Fragmentation over slow, lossy wireless isn't just harmful, its deadly.

At least that's what I found. Just anecdotally. No hard numbers to
back it up this time.  Just widespread obsevation that Metricom is
barely acceptable, even without fragmentation.

You can try this yourself with a Metricom radio and STRIP, if you have
a radio, and see what I'm talking about.

In the old world, A always advertised a 1K mtu, and when B saw that in
the initial-connection setup, the MTU in both directions was no
greater than A's wireless MTU.  So there was no fragmentation over the
wireless link.

As it is, with in_maxmtu, even if A does do PMTU, traffic from
non-PMTU hosts with allsubnetsarelocal is still FUBARed when it hits
the radio gateway B.

There's a similar MTU-limit issue that comes up with mobile-IP
enapsulation.  I still have a vague memory from an early projec that
the `initial MSS no bigger than interface MTU0 was actually required
by an RFC somewhere, but I could easily be misremembering.