🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.protocols.misc
Article #70

Re: A comparison of Commercial RPC Systems

#70
From: Brent Callaghan
Date: Mon, 31 Jul 1989 07:58
57 lines
3341 bytes
In article <WESOMMER.89Jul29153901@anubis.athena.mit.edu>, wesommer@athena.mit.edu (William Sommerfeld) writes:
> Are you claiming that it's acceptable for a protocol to have to be
> tuned by the user in order to avoid congesting gateways or even to
> work *at all*?

No, I'm not claiming that it's a desireable property of an NFS implementation
that a sysadmin has to fudge around with read and write sizes and timeouts.
Such tuning would be unneccessary if provided by the transport layer (where
it properly belongs) - unfortunately, UDP doesn't offer anything useful here.
There's nothing to prevent an NFS implementation from varying timeouts and UDP
packet sizes automatically based on server response statistics.  I agree,
congestion control should be automatic.

> Are you also claiming that it's acceptable for someone writing an
> application using a remote procedure call package to make packet sizes
> user-visible?

No, I'm not claiming that. It depends on the transport you use.  If you run
the RPC on UDP then you must acknowledge an upper limit on the message size.
If you use TCP instead then you don't really have to worry. 

If I'm using an unreliable datagram protocol like UDP then I have to acknowledge
a tenet of datacomm theory that short messages have a better chance of getting
through OK than long ones.  If you have problems sending long messages then it's
worth trying shorter ones.

> There's no excuse for explicitly using UDP fragmentation.  It will get
> you into trouble.

Yes, it will get you into trouble if you have a lot of drops between client
and server. If drops are negligible then you're a fool not to exploit big
packets.

I can only argue from experience - it seems that NFS runs quite happily in
most networks with fragmentation.  Users complain about poor performance
when you don't fragment.  What would you rather have ?

> By the way, Brent, please check your facts.  SUN RPC does NOT
> encapsulate multiple request or response packets into a single UDP
> packet. NFS merely makes larger single requests if told to do so.

I'm sorry if I was unclear.  I was trying to say that a single
fragmented UDP packet can encapsulate the "effect" of multiple smaller
packets that are not fragmented.  If you have to move lots of data
between client and server with RPC's it's much more efficient to do it
in a few big requests than in lots of little ones. Even if the big
requests get fragmented - the fragments don't have to be acknowledged
individually by the destination.  This presupposes an acceptably small
number of drops which appears to be true for most users of our NFS
implementation.

Are there any NFS implementations that constrain their users from using
fragmented UDP packets ?

Made in New Zealand -->  Brent Callaghan  @ Sun Microsystems
			 uucp: sun!bcallaghan
			 phone: (415) 336 1051
Technical Details
Message-ID: <118584@sun.Eng.Sun.COM>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!sun-barr!newstop!sun!terra!brent
References: <6569@joshua.athertn.Atherton.COM> <449d9c67.12879@apollo.COM> <WESOMMER.89Jul29153901@anubis.athena.mit.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!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
Message-ID: <118584@sun.Eng.Sun.COM>
Date: 31 Jul 89 07:58:20 GMT
References: <6569@joshua.athertn.Atherton.COM> <449d9c67.12879@apollo.COM> <WESOMMER.89Jul29153901@anubis.athena.mit.edu>
Sender: news@sun.Eng.Sun.COM
Lines: 57