Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!newstop!sun!terra!brent
From: brent%terra@Sun.COM (Brent Callaghan)
Newsgroups: comp.protocols.misc
Subject: Re: A comparison of Commercial RPC Systems
Keywords: RPC comparison apollo sun netwise
Message-ID: <118445@sun.Eng.Sun.COM>
Date: 28 Jul 89 22:01:05 GMT
References: <6569@joshua.athertn.Atherton.COM> <449d9c67.12879@apollo.COM>
Sender: news@sun.Eng.Sun.COM
Lines: 57

In article <449d9c67.12879@apollo.COM>, mishkin@apollo.COM (Nathaniel Mishkin) writes:
> of 8K UDP datagrams is a losing proposition.  This is because systems
> must fragment such datagrams into pieces that will fit into data-link
> (MAC) level packets.  The size of such packets on ethernet is around
> 1500 bytes.  Thus, on ethernet, an 8K UDP datagram is actually sent as
> 5 (or so -- I'm not bothering to figure out the size of headers and such)
> ethernet packets.  The problem with this is that, given the way IP does
> fragmentation (and reassembly), if any of the 5 fragments is lost, they
> might as well all have been lost -- neither UDP nor IP has any support
> for figuring out what got lost and telling the sender what to resend.
> The receiving application sees none of the fragments.
> 
> I have observed systems that are simply unable to handle 5 back-to-back
> packets, as it would have to in order to successfully process a call
> that had 8K of input parameters.  In such a situation, the caller could
> retransmit its 8K UDP datagram until the cows come home and it might
> never be received intact.  In general, fragmentation works only when
> you're using TCP/IP, which has mechanisms for retransmitting lost pieces
> of TCP streams.
> 
> The problem with large UDP datagrams is exacerbated if the path between
> sender and receiver traverses one or more gateways.  There are two reasons
> for this: (1) If many senders of large UDP datagrams are trying to use
> the same gateway simultaneously, the gateway will get lots of fragments
> sprayed to it at a time.  The odds that it will drop one is thus increased.
> (2) As the number of gateways between sender and receiver increases,
> so does the probability that a packet will be lost (the total probability
> being a cumulative function of the probability of each single gateway
> dropping a packet).
> 
> On the basis of the preceding, I would claim that the performance numbers
> for Sun RPC on UDP are, in general, irrelevant, because, in general,
> it can't work.  Sure, it'll work in some restricted cases, but people
> need to understand the serious restrictions.

I can`t follow this argument at all.  You seem to be saying that 8K UDP
datagrams are no good because you *might* have problems.  I agree
with all your observations on the problems that might happen - but in
practice the problems that you described are rare.

For RPC's it's a big performance win if you can encapsulate multiple
request-response packets into a single UDP packet.  Even if this
packet is fragmented, it's still much more efficient if the network
is reliable enough that packet drops are not a problem.  In practice
local area networks ARE reliable enough to support 8K UDP packets
efficiently.  

Where packet drops are a problem (NFS across slow gateways and unreliable
links) the answer is obvious - just reduce the packet size so that you
take less of a hit from drops.  NFS users can control this with "rsize"
and "wsize" mount options.  NFS users will also complain that performance
is noticeably worse when the the packet size limit is reduced from 8K.


Made in New Zealand -->  Brent Callaghan  @ Sun Microsystems
			 uucp: sun!bcallaghan
			 phone: (415) 336 1051