Path: utzoo!attcan!uunet!wuarchive!julius.cs.uiuc.edu!apple!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: <142319@sun.Eng.Sun.COM>
Date: 12 Sep 90 21:51:19 GMT
References: <1990Sep5.194621.11656@athena.mit.edu> <1990Sep7.153710@apollo.HP.COM> <142133@sun.Eng.Sun.COM> <1990Sep11.131429@apollo.HP.COM>
Sender: news@sun.Eng.Sun.COM
Lines: 72

mishkin@apollo.HP.COM (Nathaniel Mishkin) writes:


>Once the client has the locations, it picks out the ones that it can
>use.  (Like sockaddrs, the stored locations hold information about the
>network protocols you need to use to talk to the server at that location.)
>This "picking out" step happens transparently to the client.  (More
			         ^^^^^^^^^^^^^
>transparently in 2.0 than in 1.5.)

Yes, this is precisely what I am interested in knowing.  Does transparently
mean "random" here because any of the available protocols
give the same functionality or is there some implicit ordering? 

>(BTW, NCS currently has no way to pick among an apparently equivalent
>set of locations.  This is an area for future work.  E.g., you might
>want to favor TCP over X.25, if both are available; you might favor servers
>on the same network as you, if they exist.  Some of these schemes are
>hard to formalize and/or implement given existing underlying technology.)

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.

>> - Using UDP for hundreds of connections is a good idea, but I wonder whether
>>   to support streaming on top of that is  a good idea because it can lead
>>   to all sorts of rate-flow problems.  TCP is great at backing off in
>>   stormy and overloaded networks, while UDP just exacerbates the problem.

>I guess I'm not sure what your point is.  NCS uses a flow control protocol
>on top of UDP.  I.e., NCS uses UDP in much the way that TCP uses IP.
>Thus, virtually all the tricks that TCP uses are candidates for being
>used (and many are used) by NCS.

O.K., so you did build the entire TCP layer on top of UDP and
you added all the code for that in the NCS library.  Has that step really
solved all the problems or perhaps has just moved the problems from one
place to another.

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.  Multiplexing the file descriptors may
solve this problem to some extent, but not completely, because one would
still need to keep all those buffers hanging around for any decent
congestion control and rate-flow problems.

Also, retransmissions would be of the entire UDP packet size and not just
of the size of the MTU of the network.  Or have you worked around this
problem by reducing the UDP packet size to the MTU size?  I hope not.
This retransmission problem will happen only during stormy weather, but
whenever that happens, it sure will let hell break loose.
TCP backs off very graciously in such circumstances. How does your protocol
behave in these cases?

Are all the TCP tricks on top of UDP in the kernel or in the user land?
If it is in user land, I am not sure how gratifying performance you are going
to get out of it.  Atleast for +8K data, the performance will be abysmal.  Most
of the TCP magic is normally in the kernel (which provides for higher
thru'put).  Would you like to share some performance numbers for NCS/UDP
and NCS/TCP? or perhaps just their ratio [if perf numbers are confidential].

Another problem with NCS approach is that the user cannot take advantages
out of any of the new performance improvements of any of the transports.
They will have to wait for the NCS team to hack those same fixes into their
software.  In ONC, they need not do anything.

Any comments ?
vipin
Disclaimer: I speak for no one but myself.
vipin@Eng.sun.com || sun!Eng!vipin