Re: A question of small MTUs

William Ivancic <[email protected]> Wed, 13 Nov 2002 20:48:24 -0500
Newsgroups gmane.ietf.pilc
Message-ID <[email protected]>
I'm not sure about the largest or smallest MTU size, but I thought it may 
be appropriate to note some behaviors and problems we were having with MTU 
discovery over mobile networks using mobile-IPv4 double tunnels and 
encryption.   The mobile-IPv4 mobile networking we are using applies double 
tunnels from the home agent to the foreign agent when foreign agent service 
is used.   Adding encryption on top of that hides MTU discovery.  To add to 
the problem, somewhere the don't fragment bit is being set - perhaps in 
some applications or at some Web servers.  Thus, we manually have to set 
the Max MTU in the hosts on the mobile LAN or set the minimum acceptable 
MTU size at the last visible interface to the mobile LAN.

We haven't had much time to really track this problem down and analyze 
it.  But we have experienced it.

I think this is a problem that needs to be recognized by the NEMO 
groups.  Were is the best place to address it is yet to be determined.   I 
think the problems are noted in various RFCs, but the implementations are 
not always followed.  In our particular case, I suspect the encryption 
units are not following the appropriate advice for IPSec or 
IP-in-IP.  Also, there may be ICMP filtering to some locations.

At 05:09 PM 11/13/02 -0500, Matt Mathis wrote:
>Kevin Lehey, John Heffner and I are working on a replacement for RFC1191 style
>path MTU discovery (See RFC2923 for some of the reasons...).
>
>In our current design there is an open question about what is the smallest 
>MTU
>that is cost effective to discover dynamically. ........
>Asked another way, what is the smallest MTU that is (more than occasionally)
>used as an intermediate link between general purpose systems

You may want to contact some military folks regarding this.  They have some 
very small bandwidths and long delays.  They may be using small MTU's to 
get small messages through the network quicker.  The aeronautics group may 
also have similar problems, but they expected to eventually.


Will

_______________________________________________
pilc mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/