Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!apollo!mishkin From: mishkin@apollo.COM (Nathaniel Mishkin) Newsgroups: comp.protocols.misc Subject: Re: A comparison of Commercial RPC Systems Keywords: RPC comparison apollo sun netwise Message-ID: <449d9c67.12879@apollo.COM> Date: 24 Jul 89 18:22:00 GMT References: <6569@joshua.athertn.Atherton.COM> Reply-To: mishkin@apollo.com (Nathaniel Mishkin) Organization: Apollo Computer, Chelmsford, MA Lines: 88 In article <6569@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes: >I've finished work on a paper entitled "A Comparison of Commercial RPC >Protocols" which I gave at NCF: The Network Computing Forum, and also >as a work in progress at USENIX. 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. 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. In section 3.3 Levy uses the example of (putative) machines with 9 bit bytes and how this would present a problem for Apollo's data representation scheme (NDR, not RMR as in Levy's posting that announced his paper). In fact, in case it wasn't clear, Sun scheme (XDR) and (presumably) ASN.1 have the same problem -- none of the scheme has any special support for 9 bit bytes. They would presumably represent them all in some larger standard type. Thus, the fact that NDR doesn't have a tag that says "I use 9 bit bytes" produces no problems unique to NDR. I want to take this opportunity to clear up one misconception about NDR (which I know Levy doesn't have but which I know many people do): NDR's representation suite is not open-ended. NDR is best thought of as a "multi-canonical" scheme. I.e. the sender of data can choose from a variety (but fixed) set of representations. We believe the set is usefully large, but not so large as to be onerous for receivers. If a sender's native representation happens to not exist in the set, it is the sender's responsibility to convert to a one of the NDR set before sending the data. Note however, that all the most common representation schemes currently in existence are covered in NDR's suite. Thus, for systems with those representations, no conversion is required on sending. Further, for such systems, the number of conversion routines required for any single system is small: 1 for integers (from big to little endian, or from little to big endian), 1 for characters (from ascii to ebcdic, or from ebcdic to ascii), and 3 for floating point (from 3 of the 4 possible floating representation to the native representation). A total of 5 routines. Not a big deal. (Yes, the total number of conversion routines across all systems is larger, but that's just a matter of coding them up once, and you're done.) In section 4.1 Levy discusses the "silent errors" possible with Sun RPC over UDP as a result of duplicated UDP datagrams. Two other problem cases arise in this mode: (1) If the input or output parameters are larger than 8K, the UDP solution can not be used at all -- you must use Sun RPC over TCP. (2) The caller must be able to approximate the time it will take for the call to execute at the server end. In general, this is a hard number to know (it may be a function of the speed and load of the server and on the complexity of the input data presented on each call). Guessing the wrong value will lead to spurious call failures. -- -- Nat Mishkin Apollo Computer Inc., Chelmsford, MA mishkin@apollo.com