draft RFC comments

[[e-mail] (Fred Bohle acc_gnsc)]

Folks,

	What I was trying to accomplish in my suggestion was a way
to tie together discovery of the MTU with the three-way handshake
in TCP.  Having reviewed the working group log and the draft RFC,
I have some comments and proposals:

1.  Add a PMTU query option, as in the original RFC1063.  The receiving
TCP can retrieve the PMTU query option and respond with a PMTU reply
option and a new PMTU query of its own.  The point to doing this is the
retransmission and sequence number processing of TCP will guarantee the
delivery of this information.

2.  TCP would have to do this only if the call to GET_MAXSIZES call
indicated the real size was unknown.  If it is known, the MTU size
would be used in calculating the MSS size in the MSS option.  If it
is unknown, the PMTU query option would be specified by TCP.

3.  Allowing TCP to generate the reply guarantees retransmission of the
reply.  Tying it to the SYN, SYN-ACK, ACK-of-SYN sequence gets the
MSS decided in a predictable sequence.  There is no way to do this with
an ICMP response.  

4.  UDP and other protocols at that layer could use the information
since the IP layer still maintains a cache of MTU sizes.  

5.  I agree with Pradeep that the next-hop field seems redundant, since
non-cooperating gateways will ignore this option.  The result is that
the minMTU is not updated.  Subsequent fragmentation will correct this.
The objection raised to his point was if the destination host did not
support Unexpected Fragment messages, the fragmentation would go
unnoticed (unpunished?).  Suppose we have the fragmenting gateway
return an Unexpected Fragment message?  This will requre more state in
the gateway, but would protect against non-cooperating hosts.
(Maybe this requires too much state in the gateway. What say you all?)

Overall, I am impressed with the development of the MTU discovery working
group, and only wish I had been involved from the beginning.  Since I am
currently working on the TCP/IP implementation in ACC's ACCES/MVS product,
this is great timing for working on IP options and any TCP changes
necessary.  When it comes time to experiment, I am anxious to participate.

Light up your flaming arrows, warm up your blowtorches, and let me know
what you think.

Fred