Re: Another proposal

[sytek![e-mail] (Rich Fox)]

I think Craig answered the question that was needed to be answered: The 
packetization protocols that were are trying to solve for really is TCP.
Furthermore, I think Noel has limited the choices by saying :


>	Second, as far as the bit in the IP header goes, there are a
>number of proposals to use it in congestion control (e.g. the DEC
>scheme), and from my perspective (as Area Director) that potential use
>is far more critical (in addition to needing that bit far more often,
>making the occasional use for MTU a better bet for the option), so I'd
>be unlikely to support using that bit for MTU.
>	Sorrreeeeee....... just trying to do what's best....
>
>	Noel


  I beleive that this leaves us with the following choices:
    1. RFC1063
    2. ICMP approach
    3. My approach using the MSS option of TCP.



For the sake of this note, I will assume that option 1 is not a viable
option because of the points raised in Steve D's draft paper. I use this
assumption as a starting point for discussing the next options and imply
nothing else.

  Option 2:  The main problem with this option is that this method can break
		down if there is a host that doesn't understand or act on the
		ICMP message. Thus, the numberof messages sent is greatly
		increased with no functionality gain.

  Option 3: The feedback I got for this approach was fairly good except
	one point. Some people feel that sending an MSS option in non-SYN
	packet is changing the meaning of RFC-793. I would like to persue
	this a little further by discussing the various options that can be
 	followed:



   option 3a: Assume that the Host Requirement Doc is the new bible.

	    If we assume that what is written in the HR doc is gospel (which
	    according to others around here implementing products based on
	    TCP believe) then what is stated in this document is true and
	    can be followed as written even if it may change the meaning
	    of an earlier RFC. (This is what is normally meant as being the
	    NEW bible). With this in mind we get the following 2 lines
	    from the HR doc:

	       TCP MUST implement both sending and receiving the Maximum
	       Segment Size option [TCP:4].

	       TCP SHOULD send an MSS (Maximum Segment Size) option in every
	       SYN segment when its receive MSS differs from the default
	       536, and MAY send it always.

	     This doesn't restrict or imply that the MSS option can not or 
	     should not be sent in a non-SYN segment. If the HR doc wanted
	     to imply or forbid the use of the MSS option in a non-SYN
	     segment, then it should have stated. 

	     So if we beleive the statement above then my suggestion as it
	     stood before works without having to change any gateways, or
	     header information in IP. In fact, the only thing needed to 
	     implement this scheme is the ability for IP to inform the
	     packetization protocol that a change in MTU is needed. A fairly
	     simple thing to add.

	     If you do not beleive the statement above then please read on--


    option 3b: MSS-II a new option.

	     It was stated that the problem with my proposal is that a MSS
	     option would be sent in a non-SYN segment. Steve D suggested
	     that to get around this problem we implement a new TCP option
	     that behaves just like the MSS option except it is sent after
	     the connection has been set up (ie: in a non-SYN segment). This
	     is actually an excellent suggestion and adds absolutely no more
	     complexity to the proposal at hand, and I then think we can
	     safely say that RFC-793 has not been affected, the HR doc has
	     not been violated and the benefits stated above are maintained.

    option 3c: Use ICMP.

	     If we are completely opposed to adding any new options even to
	     TCP, then to solve our problem we can replace the MSS-II option
	     with the use of the ICMP message that Steve D has defined in his
	     draft paper. It solves the problem for TCP but may still suffer
	     from all of the problems discussed before for fragmented packets
	     that arrive for NFS or other applications that use UDP etc.




I hope that I have convinced you that option 3 is still a viable solution
and can possibly fulfil the with the least amount of changes.

thanks rich