I have a revised critique of Fred Templin's proposal: http://tools.ietf.org/html/draft-templin-inetmtu-05
at my IPTM (ITR Probes Tunnel MTU) page: http://www.firstpr.com.au/ip/ivip/pmtud-frag/#sprite_critique The three elements of the critique apply to the use of Sprite-MTU in an ITR-ETR system (at least for IPv4). The third element may be applicable to the many other uses which Sprite-MTU is intended to help with. In brief (please read the full critique before responding), they are: 1 - The ITR has to set up state even when a single short (too short to be a problem for MTU limits) packet is tunneled to an ETR. 2 - The ITR and ETR have to continually engage in Sprite-MTU communications as long as packets are tunneled to the ETR - and this should arguably start with the first packet. Both these place a huge load on the ITR, for just a single packet - which doesn't even need any MTU management. My proposal avoids such overheads, by being triggered only by longer packets. 3 - The initial response of the ITR to a longer packet is to send back a Packet To Big message to the sending host and to tunnel the packet. The sending host will then resend the packet (and probably subsequent packets) in multiple small fragments - but the original packet may arrive at the destination host and be acknowledged. This contradictory response is likely to cause trouble for sending hosts, including those implementing RFC 4821, as well as being a source of extra packets, confusion etc. This tunneling, MTU, fragmentation, PMTUD stuff is really challenging. So far, Fred's proposal and my own IPTM (ITR Probes Tunnel MTU) are the only two which are applicable to the ITR-ETR schemes we are discussing on this list. I would really appreciate some critical assessment of IPTM, and likewise some confirmation or otherwise of my critique of Sprite-MTU. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
