🚀 go-pugleaf

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