Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!CMCL1.NYU.EDU!TIHOR
From: TIHOR@CMCL1.NYU.EDU (Stephen Tihor)
Newsgroups: comp.protocols.misc
Subject: RE: A comparison of Commercial RPC Systems
Message-ID: <212779944.00003F7A.1989@CMCL1.CMCL1.NYU.EDU.ARPA>
Date: 1 Aug 89 01:46:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 24

If ywe are talking real world you bet your business sorts of issues then
protocols must not fail in WORST practical case.    From observations of events
in the Internet I assert that to the extent taht the SUN internal network
convinces you that 8K UCP barrages are reasonable it is not a good model for
much of the Internet.


It would  have been straightforwards to design simple feedback loops with a
hysterisis parameter to avoid the known network problems or too direct a
feedback loop into such protocols as the NFS packet size/multi packet code or
RWHO.

Networking protocols should BE DESIGNED NOT TO FAIL IN THE GENERAL CASE.
Protocol designs have to be PESIMISTIC because you can not insure that the
world is a simple catenet of ethernets with moderately compatible machines on
them. Degrade performance if you can't figure out how to autotune down but
don't just fail anmd require an end user to solve an internetwork level problem.

The more widely used a protocol is intended to be the better it should be at
handling bad enviornments.  [I did not find the original explaination for using
UDP o instead of TCP for NFS RPC to be very convincing once SUN started pushing
NFS as a standard for remote files systems.

-------