Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!sun-barr!newstop!sun!commuter!beepy From: beepy%commuter@Sun.COM (Brian Pawlowski) Newsgroups: comp.protocols.misc Subject: Re: A comparison of Commercial RPC Systems Summary: RPC comparison apollo sun netwise fragmentation Keywords: RPC comparison apollo sun netwise Message-ID: <118603@sun.Eng.Sun.COM> Date: 31 Jul 89 15:45:41 GMT References: <6569@joshua.athertn.Atherton.COM> <449d9c67.12879@apollo.COM> Sender: news@sun.Eng.Sun.COM Lines: 69 In article <449d9c67.12879@apollo.COM>, mishkin@apollo.COM (Nathaniel Mishkin) writes: > Below are some comments on Joshua Levy's "A Comparison of Commercial > RPC Systems" recently posted on comp.misc. > In section 3.1 Levy discusses the implications on performance of the > size of UDP/IP datagrams. It is important to note that, in general, use > of 8K UDP datagrams is a losing proposition. I have to object to the term "in general". I would respond that "in general, the use of 8K UDP datagrams is a win for transferring large amounts of data, and has shown to be a win in applications such as NFS." Performance for smaller transfer sizes (blocks sizes) entails greater processing overhead in the application layer, and traverses through the networking layers to accomplish the same overall data transfer. This would imply to me that the total time to transfer the same amount of data using smaller packets is greater. > 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. For "noisy" or "loaded" networks with lots of packet loss, smaller packets could make more sense. However, it is pessimistic to put this forward as the "general" case. > 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. Hmmmm... again, the in general. In general, systems incapable of handling back to back packets (sometimes only two - I've seen) have problems. Again, smaller packets would make sense so as not to thrash the poor performing system. In general, over an extensive network at Sun, 8K UDP packets provide greater throughput, less overhead. (You know: Tastes better - less filling.) I would argue against proposing "least common denominators" as the general case; this is a pessimistic strategy. I think this points to "the general" need for flexibility in a distributed application, using a datagram protocol, to allow static or dynamic (preffered) configuration of parameters such as UDP packet size (and retransmissions, with backoff strategies). > 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 like your argument, EXCEPT FOR THE FACT THAT IT FLIES IN THE FACE OF WHAT WE SEE IN LARGE nfs NETWORK INSTALLATIONS. I think you are approaching this from a pessimistic, worst case scenario which is a bad way to deal with network throughput. In general, I have to assure you - it works. > -- > -- Nat Mishkin > Apollo Computer Inc., Chelmsford, MA > mishkin@apollo.com Brian Pawlowski Sun Microsystems, NFS Development