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
  •   Rich Fox