🚀 go-pugleaf

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 <beepy@sun.com> <sun!beepy>
			Sun Microsystems, NFS Development