Credit where credit is due

[mogul (Jeffrey Mogul)]

In the process of editing Steve's draft proposal, I went through
the material I used 2 years ago when writing "Fragmentation Considered
Harmful", and found this message:
    
    Return-Path: <[e-mail]>
    Received: from SRI-NIC.ARPA by navajo.stanford.edu with TCP; Sun, 24 May 87 02:42:34 PDT
    Received: from decwrl.dec.com by SRI-NIC.ARPA with TCP; Sun 24 May 87 00:15:43-PDT
    Received: by decwrl.dec.com (5.54.3/4.7.34)
	    id AA16654; Sun, 24 May 87 00:15:45 PDT
    Received: by imagen.uucp (5.51/Imagen-1.1)
	    id AA04028; Sat, 23 May 87 22:20:55 PDT
    Return-Path: <geof>
    Received: by apolling.imagen.uucp (4.12/Imagen-1.1)
	    id AA01407; Sat, 23 May 87 22:17:05 pdt
    Date: Sat, 23 May 87 22:17:05 pdt
    From: imagen!apolling![e-mail] (Geof Cooper)
    Message-Id: <[e-mail]>
    To: [e-mail]
    Reply-To: imagen![e-mail]
    Phone: [phone] (work)
    Postal-Address: IMAGEN, 2650 San Thomas Expressway, Santa Clara, CA 95052
    Subject: Re: IP Datagram sizes
    
    I like the idea of an IP-level solution to the fragmentation problem
    since it has application to UDP protocols (I know that none that exist
    today could use it, but that's no excuse for ignoring UDP).
    
    Isn't there a destination unreachable message with the reason being
    "can't fragment and had to" (sorry my ICMP spec is at the office)?  If
    not, we could certainly add one.
    
    In that case, the idea is to always send TCP packets with the "don't
    fragment" bit set.  Use the scheme suggested that keeps track of MTU's
    in the routing cache.  Update the cache based on DU's received
    (decrease the MTU a bit and try again) -- time out the entry on a long
    timer to be able to detect new routes.
    
    The obvious improvement is to have the ICMP message also include the
    MTU restriction that is appropriate -- that requires changing ICMP, of
    course, but it would probably be a good idea.