Re: Another proposal
sytek!rfox@Sun.COM (Rich Fox) Fri, 01 December 1989 02:39 UTC
Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA02484; Thu, 30 Nov 89 18:39:12 PST
Received: by decwrl.dec.com; id AA18256; Thu, 30 Nov 89 18:39:08 -0800
Received: from sun.Sun.COM (sun-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA19712; Thu, 30 Nov 89 18:38:59 PST
Received: from sytek.UUCP by sun.Sun.COM (4.1/SMI-4.1) id AA02403; Thu, 30 Nov 89 12:54:44 PST
Received: by sytek.hls.hac.com (5.51/5.17) id AA13109; Thu, 30 Nov 89 12:06:00 PST
Date: Thu, 30 Nov 1989 12:06:00 -0800
From: sytek!rfox@Sun.COM
Message-Id: <8911302006.AA13109@sytek.hls.hac.com>
To: mtudwg
Subject: Re: Another proposal
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
- Re: Another proposal Rich Fox
- Re: Another proposal smb
- re: Another proposal Craig Partridge
- Re: Another proposal Jeffrey Mogul
- Re: Another proposal Rich Fox
- Re: Another proposal smb
- Re: Another proposal Keith Mc Cloghrie
- Re: Another proposal Keith Mc Cloghrie
- Re: Another proposal Philippe Prindeville