[Mip4] Re: Negotiating maximum packet size (draft-vaarala-mip4-fragmtu-00)

[sami.vaarala at iki.fi]

Hi Kent, 
Thanks for the comments, some responses and questions below. 
> 1) Why GRE encap not supported?  Seems like adding a few words would
>     allow that since there's no technical hurdle to cover supported 
>     encapsulation modes.
No particular reason - this draft just documents what we thought would
solve our most immediate problems.  GRE is no different, except that
you may run protocols over GRE that don't support the notion of
fragmentation.  (Of course IP over GRE will work just fine.) 
> 2) Does it make sense for FA to advertise the Frag-MTU-Pref value so
>     the MN can send that info to the HA in a protected manner?
I'm not sure what you mean here, can you elaborate?  The preference
is protected using MN-HA authenticator?  And the MN and HA are
configured with their respective values, so they don't need input
from network. 
> 3) Not clear how the MN's IP stack use this effective MTU?  Is the IP MTU
>     set to this value to tune the TCP MSS negotiation between MN and CN?
>     IMHO, this is the most important objective so Tunnel MTU Discovery is
>     not needed for obtain optimal MTU size.
Well, that's one thing you can do, and should do (if possible).  You can
also do MSS rewriting and other such things. 
> 4) If effective MTU is not related to IP MTU to affect TCP MSS, then
>     we will still have the black hole problem between CN and MN due
>     to ICMP filters.
That's true - but this would also be the case if the MN was at home
and trying to communicate with the MN.  The intent of the mechanism
in the draft is to solve the case where the MN is away, and the route
between the MN and the HA is poor - although a connection from the MN
home network would work just fine.  (Tweaking the TCP MSS for initiated
connections so that it will work when initiated from the home network is
outside the MIP4 scope - there isn't necessarily even a registration
involved if the MN boots up at home.) 
> 5) If effective MTU is used for TCP MSS, then does it make sense to
>     re-negotiate on each registration?  Should this be accomplished
>     only in the initial registration?  How would active TCP session
>     deal with changing IP MTU?
If DF was set, the MIP code could simply manufacture an ICMP back to the
stack with packet too big (i.e. a local ICMP).  There are other
possibilities, though. 
> 6) Let's say that MN has 2 interfaces, one that use IP-in-IP and the
>     other use UDP.  Initially, MN roams to a network that uses IP-in-IP.
>     TCP sessions are started with CNs.  Then MN roams to network
>     that requires UDP.  We would be back at not having optimum
>     MSS.
Yes, that's true.  But if you do MSS tweaks (which are local matters
anyway), you may take the maximum packet size and subtract the maximum
overhead (UDP) when determining your offered MSS? 
> 7) Seems like the lowest common denominator is the effective MTU
>    of the lowest MTU among UDP, IPinIP, GRE?  And if one enables
>    IPSec too, the optimal MTU shrinks more.  Just wondering at the
>    end of the day, it may be just easier to say regardless which
>    tunneling method is used, go with MTU size 1400 for one size fits
>    all?
That's what we've done in our previous product version, but actually
1400 is too large, at least for some specific networks (it's precisely
the value we ran into problems with :-).  Choosing a value that will
work for sure is black magic as the routers where this is a problem
are clearly broken in any event. 
> 8) Is it expected that the HA which receives the effective MTU will
>     set the tunnel mtu soft state accordingly for tunnel mtu discovery?
>     So if tunnel mtu discovery is enabled on the tunnel between HA
>    and CoA, then soft state is set.  If tunnel mtu discovery is disabled,
>     the effective mtu is not used for forwarding MN traffic toward CoA?
>     General question is how is the effective MTU linked to tunnel MTU
>     Discovery?
The HA and the MN should do whatever they do with plain RFC 2003 /
RFC 3519.  There is no difference, except that the tunnel MTU may
occasionally change.  To overcome the IP-IP vs. IP-over-UDP
difference, the tunnel MTU can be taken to be the worst case, but
that's an implementation decision IMO.  Other than that, the tunnel
MTU should change extremely rarely (e.g. HA is reconfigured). 
> 9) Though this draft seems to say that the HA processes the effective MTU
>     by ensuring that all encapsulated traffic (original packet is 
> fragmented if
>  too big) are within the size of effective MTU, when the DF bit is unset.
>     In this case, when DF bit is set, HA will send ICMP unreachable to
>     source.  This message may be filtered.
Yes, if we have a filter between HA and CN we're in trouble, unless
we stop honoring the DF bit (which is tempting after dealing with a
number of black hole problems..:).  I don't think there is a way around
this problem.  However, we don't have to rely on ICMP between the MN and
the HA, which is a larger problem, because the MN moves around in whatever
networks that are out there. 
Best, 
-Sami 
--
Mip4 mailing list: Mip4@ietf.org
   Web interface: https://www.ietf.org/mailman/listinfo/mip4
    Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/