sytek!rfox@Sun.COM (Rich Fox) Wed, 29 November 1989 22:45 UTC
Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA01741; Wed, 29 Nov 89 14:45:32 PST
Received: by decwrl.dec.com; id AA16952; Wed, 29 Nov 89 14:45:22 -0800
Received: from sun.Sun.COM (sun-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA03814; Wed, 29 Nov 89 14:43:42 PST
Received: from sytek.UUCP by sun.Sun.COM (4.1/SMI-4.1) id AA09426; Wed, 29 Nov 89 14:43:09 PST
Received: by sytek.hls.hac.com (5.51/5.17) id AA06408; Wed, 29 Nov 89 10:43:32 PST
Date: Wed, 29 Nov 1989 10:43:32 -0800
From: sytek!rfox@Sun.COM
Message-Id: <8911291843.AA06408@sytek.hls.hac.com>
To: mtudwg
Subject: Re: Another proposal to think about >> Your proposal to handle MTU discovery at the TCP level sounds >> reasonable, except that it only works for TCP. That means we would >> have to make similar changes to any other "packetization" protocols, >> such as TP4 or VMTP or NFS, in order for them also to take advantage >> of MTU discovery. > >Excuse me, but something is obviously wrong in someone's thinking >here (possibly mine): Why would one *want* to change the packet >size of an VMTP or UDP packet? They are record-oriented protocols >and must preserve such boundaries. > >-Philip I think its a philosophical reason. If you use the SMDS approach, each record or NFS 8K packet will be sent out as a number of mtu packets + last packet, with a common id of some sort and the layer above IP incurs the cost of fragmentation as opposed to having IP incur the cost. You do bring up a good point: Which packetization protocols are we really trying to help/solve with the mtu discovery? rich