re: some further musings

[sytek![e-mail] (Keith Mc Cloghrie)]

> > First:  is it really necessary to reprobe for MTU changes, once the
> > initial negotiation is complete?  Route changes are comparatively
> > infrequent, and many -- most? -- routing changes will not affect the
> > MTU.
> 
> Steve:
> 
> I think you are making two separate points here:
> 
>     (1) Do we need to probe very often?  Your answer (and mine)
>     is no.  Once you know the MTU, you shouldn't have to check
>     it very often because the path shouldn't change.
> 
>     (2) Are the ... 
> 
> Craig

I think there are actually two parts to the first point:

  (1a) Do we need to probe very often **for MTU increases** ?

       I agree that in this case, we do NOT need to probe very 
       often; however, we DO need to probe occasionally.  Example 
       scenario: hosts on LANs at sites joined by two serial lines, 
       a T1 with MTU of 1500, and a 19200 back-up line with MTU of 
       256.  On an outage of the T1 line, the path MTU goes down 
       to 256.  Without an occasional probe, every existing and 
       new connection/application would continue to use an MTU of 
       256 after the T1 line comes back (until the next reboot ?).
       I would say it's worth a one IP-option every 30 minute probe.  

  (1b) Do we need to probe very often **for MTU decreases** ?

       I suggest we need to probe more often in this case, since
       if we probe once every N minutes, then an MTU decrease
       will on average cause N/2 minutes of fragmentation.
       Is once every 2 minutes often enough ?

In fact, to take this further, maybe we should consider these
two cases separately.  

  For (1a), I suggest 1063 has advantages over report-fragmentation
  because it doesn't have to send a bigger datagram just to see if 
  it gets fragmented (c.f. banging your head against a brick wall 
  just to check if the wall is still there).  

  For (1b), however, both our current IP option schemes have the
  bad characteristic that frgamentation starts when the MTU decreases
  but we don't find out until the next time we send a datagram with 
  the IP option.  As an alternative, how about the following:

    define a new IP-option called "report-N-fragmentations" which 
    requests N fragmentation-reports, (NOT one iff the containing 
    message is fragmented, but rather) one ICMP message on the occurrence 
    of each of the next N fragmented datagrams.  This would allow the 
    destination to react immediately after an MTU decrease by sending 
    a limited number of ICMP messages to tell the source that 
    fragmentation has started occurring.  The setting of the value of N 
    would be to balance the number of redundant ICMP report messages 
    against the loss of some of them.  I suggest the value of N be 
    sent in the IP Option, and be considered "N more" so that if the 
    receiver already were primed to send an ICMP message for the next 2, 
    then another such request for 2, would raise the total to the next 4.  
    (there should probably be a maximum for the total).  By this means, 
    the sender could send several of these, thereby protecting against 
    loss of the datagram containing the option.

What would folks think about combining these two schemes.  That is
defining both IP options: 1063's for infrequent but periodic usage
for determining MTU increases; and the report-N-fragmentations for
setting-up triggers for the immedaite discovery of MTU decreases.

Keith.