Re: MTUs on different paths
Steve Deering <deering@pescadero.stanford.edu> Tue, 12 December 1989 04:40 UTC
Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA07497; Mon, 11 Dec 89 20:40:28 PST
Received: by decwrl.dec.com; id AA11390; Mon, 11 Dec 89 20:40:25 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA12530; Mon, 11 Dec 89 20:40:12 PDT
Date: Mon, 11 Dec 1989 20:33:00 -0000
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Re: MTUs on different paths
To: Craig Partridge <craig@NNSC.NSF.NET>
Cc: mtudwg
Message-Id: <89/12/11
In-Reply-To: Craig Partridge's message of Mon, 11 Dec 89 084901 -0500
me: There is, however, a problem with the RFC-1063 approach of allowing the Reply MTU to be piggybacked on any returning datagram -- the association between the MTU and its corresponding TOS or other route-influencing options may be lost. Craig: Well, this is one of the two approaches. The other approach has TCP initiating the options and TCP, could conceivably, retrieve the option and direct IP as to the TOS being used. Yes, that's the second of my "three reasonable ways to return MTU information". Steve
- MTUs on different paths art
- Re: MTUs on different paths Steve Deering
- re: MTUs on different paths Craig Partridge
- Re: MTUs on different paths Steve Deering
- Re: MTUs on different paths Philippe Prindeville