Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!samsun!vipin
From: vipin@samsun.Sun.COM (Vipin Samar)
Newsgroups: comp.protocols.misc
Subject: Re: RPC Technologies
Keywords: Transports UDP TCP Performance
Message-ID: <142630@sun.Eng.Sun.COM>
Date: 18 Sep 90 01:53:19 GMT
References: <1990Sep5.194621.11656@athena.mit.edu> <1990Sep7.153710@apollo.HP.COM> <1990Sep14.093420@apollo.HP.COM>
Sender: news@sun.Eng.Sun.COM
Lines: 98


> Vipin Samar writes:
>>Yes, I agree this is a tough problem on formalizing these
>>heuristics - perhaps after all it is not such a bad idea to give control to
>>users in such cases.  One can never really have all the bases covered.
>
>I definitely agree that there should be at least one mode that lets
>user policy choices come into play.

So, we have agreed on one thing that it is a good idea to have an
escape hatch for programmers/users to be able to choose a
particular transport.  Any ideas as to how will you extend NCS to do it?
ONC (tirpc) allows it today by using NETPATH environment variable.
One can either set it or use one of the default transports of the required
type available on the system.

>>If one cannot support huge (say 100) TCP connections because of resource
>>problem, then you have said that NCS/UDP will be able to
>>overcome the resource problem.  I wonder if that is true, because
>>building up of entire TCP functionality on top of UDP is going to require
>>system resources as well.

>Of course.  However it is also of course true that NCS RPC's buffers
>(unlike those of the kernel implementation of TCP) aren't consuming wired
>physical memory, thus giving NCS some more room to play.  And then there's
>the wired space in the kernel for TCP connection blocks and any other
>miscellaneous TCP overhead.  Further, the nature of the NCS RPC protocol
>lets the server simply blow off its pseudo-connections to clients at
>any point that a call is not in progress; the pseudo-connection
>reestablishment happens automatically and transparently to the application
>(and the stubs).

I am assuming that you blow away the connection state only when you have the
guarantee that the data has reached the other side.  TCP also frees
up all the associated buffer space in such cases.  The only difference
would be in the number of mbuf's (2?)reqd to keep the state/sequencing.
Streaming/UDP becomes a win, only if one knows beforehand that there will be
hundreds of connections for that particular RPC service.
	Even when one is using TCP, the server can blow away the
connection (if the call is not in progress) and the client will simply
have to rebind (at some extra cost).  The client RPC library should
provide the required transparency.  The question is which is better -
pay huge cost at each call (discussed in earlier messages) OR pay
rebinding cost only when it is required?  In my opinion, second approach
is better.

I am sure that there are many TCP/IP experts on this newsgroup.  Does any
one want to share his/her opinion on building the TCP functionality
on top of UDP?

>It is also true that even an RPC running on top of a COTP has buffer
>management problems and that they're arguably HARDER than RPC's over
>CLTP's.  Note that when I say RPC/COTP I mean one that has somewhat more
>complicated problems than say, SunRPC/TCP.  The problematic scenario
>is the case where for some reason, the stub is not consuming its input
>data stream for some period of time.  In our model, we have a thread
>(or set of threads), distinct from the thread running the stub, that's
>responsible for actually reading from the connection.  One reason for
>this is so that client-generated "cancels" (i.e., requests to abort calls)
>can be processed even if the stub/server thread isn't currently in the
>RPC runtime.  Thus, there is a layer of buffering between the connection
>and the stub.  There is finite space for this buffering. 

If I assume that both the threads are share the buffer space, then what do
you mean by "finite space for this buffering"?  Also, the problem
described above seems more like a problem created by your implementation.
Also, this problem should exist for CLTP too.  How did you handle that case?

>We endeavor to send MTU-sized UDP packets and I don't know why you "hope
>not".

Because I want good performance and that can happen only by minimizing
transitions between kernel and user land.  Choosing a large number is
bad for stormy cases & retransmissions and leads to overrun for machines
with fewer mbuf's or less memory.  Choosing a small number for UDP packet
size is bad for performance.  Sun decided to go with a compromise - 8K
UDP packet size.  In NCS, is there a mechanism for size negotiation
for faster/bigger machines (lots of memory) which can easily handle
bigger size UDP packets?  Just curious - what do you guys do for NFS?
Do you use 1K packets only?

Actually, you can easily rest all of my fears by posting some performance
ratios for UDP/TCP (not numbers - I know they are confidential)


> In any case I take seriously
>my responsibility to produce a real evaluation of the wisdom of this
>approach once I'm in a position to do the evaluation.

I hope that performance will be one of the criterian.

>--
>                    -- Nat Mishkin

vipin
Disclaimer: I speak for no one but myself.

vipin@Eng.sun.com || sun!Eng!vipin