Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ulowell!apollo!mishkin
From: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Newsgroups: comp.protocols.misc
Subject: Re: A comparison of Commercial RPC Systems
Keywords: RPC comparison apollo sun netwise
Message-ID: <44c030ef.1d6d5@apollo.HP.COM>
Date: 31 Jul 89 15:24:00 GMT
References: <6569@joshua.athertn.Atherton.COM> <449d9c67.12879@apollo.COM> <118445@sun.Eng.Sun.COM>
Reply-To: mishkin@apollo.com (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 27

In article <118445@sun.Eng.Sun.COM> brent%terra@Sun.COM (Brent Callaghan) writes:
>In article <449d9c67.12879@apollo.COM>, mishkin@apollo.COM (Nathaniel Mishkin) writes:
>> of 8K UDP datagrams is a losing proposition.  ...
>
>I can`t follow this argument at all.  You seem to be saying that 8K UDP
>datagrams are no good because you *might* have problems.  I agree
>with all your observations on the problems that might happen - but in
>practice the problems that you described are rare.

I guess I have to disagree with the "rare".  I have seen some systems
systematically fail to handle 5 back-to-back packets.

>Where packet drops are a problem (NFS across slow gateways and unreliable
>links) the answer is obvious - just reduce the packet size so that you
>take less of a hit from drops.  NFS users can control this with "rsize"
>and "wsize" mount options.

The idea of reducing the packet size (i.e. the number of packets sent
in a burst) is fine.  What's not fine is expecting users or applications
to do the reducing.  It's the business of the underlying RPC system to
handle this.  How would people react to a TCP implementation that had
the property that you'd have to notice that your "send"s were failing
and then make some call to reduce (say) the TCP window size?
-- 
                    -- Nat Mishkin
                       Apollo Computer Inc., Chelmsford, MA
                       mishkin@apollo.com