Path: 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> Sender: news@sun.Eng.Sun.COM Lines: 57 In article , 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