Newsgroups: bit.listserv.ibmtcp-l
Date:         Wed, 23 Dec 1992 16:08:00 PST
From:         "Denis DeLaRoca 825-4580 (310)" <CSP1DWD@UCLAMVS.BITNET>
Subject:      Re: IBM TCP/IP inadequacies (was Usage of vector facility for
              TCP/IP?)

Frank Vance <fvance@WG.WAII.COM> writes:

>  I used to think that, but Bill R. convinced me they really do care, y
>  just don't have the resources.  So they try to focus on things they
>  think are most in demand from the customers.

What resources? It is a fact that the TCPIP product is a proven money-
maker, resources can be created easily to support such products. What
triggered this and other messages is the fact that severe and well
known problems in fundamental areas of the product (ie, IUCV/VMCF)
persist and that IBM has publicly (thru this list and thru support)
expressed their priority to fix these problems, well over a year
later all these stated intentions and promises have vanished into
thin air.

You might ask why is IUCV/VMCF so important?  As it turns out IUCV/VMCF
(and the VM platform) make up the essential bridge between user
processes and the TCPIP kernel, every single TCPIP transaction goes
thru that bridge, but this bridge is neither solid nor ample, you can
fall from it very easily. For example you can't reliable run one tcp/ip
application in one split of my ISPF session and then start another
tcp/ip app (whether it be from IBM or not) in a second split... I can't
have that same tcp/ip app multitask and use tcp/ip services without the
risk of losing access to IUCV from within my address space.  Can't even
run IBM's own telnet and FTP clients together... can't deploy Gopher,
Wais, Web, NewsReader clients, or any other tcp/ip applications that
multitasks and/or shells out to other tcp/ip applications without
running into some TCPIP problem, usually an IUCV/VMCF problem.  We have
observed complex crashes in IUCV cleanup, we have observed user address
spaces being left non-swappable by IUCV, the list goes on...

The starting point for TCPIP was the VM work done at Wisconsin, but
what was a virtuous, simple and glorified hack, in those days, has
become totally obsolete and regressive. The current TCPIP architecture,
unchanged from those simple days, bears absolutely no resemblance
to modern day reality of fast computers and high-speed networking,
the fact that TCPIP for MVS is hosted by means of a badly engineered
(and buggy) VM emulator platform is absolutely mind boggling... the
basic engineering principles to do high performance tcp/ip implemen-
tations are by now well known, the sound engineering principles to
host such implementations efficiently in modern day operating systems
are also well known. MVS itself is in many respects as good an operating
system as you can get and I am told by the MVS gurus that no significant
obstacle exists to host a high-performance implementation of tcp/ip.

It is clear that market pressures pushed IBM for an early release of
TCPIP in what I'd consider a fundamentally flawed implementation, an
implementation with inherent functional, performance and reliability
limits. Rather than following that up with a better engineered imple-
mentation we've seen more and more construction on a building that is
for all intensive purposes sitting on a sandpit... and the crux of the
matter is dealing with Operating System issues. To customer complains
of poor performance we've seen the emergence of "offloading" whereby
the basic tcp/ip protocol processing is offloaded to a peripheral
processor... but this hardly changes the picture as we are still left
saddled with complex interfaces to talk to an offload tcpip box, and
we are still saddled with all the overhead and problems of the VM
emulation platform. I don't see any future on this, on paper it
looks as, if not more, expensive that the current solution.

>  My personal opinion is that the "typical" customer wants some crazy ngs,
>  like CICS sockets, the NDB system, and the like, none of which I hav
>  use for.  Of course, that "typical" customer probably thinks my
>  requirement list (higher throughput, lower CPU consumption, better
>  Network Systems support) is strange too.

I think these last requirements: performance, low resource utilization
and rational network systems support are essential, nothing strange
about them, and I would contend should be the areas that IBM should
be putting all their resources and expertise to provide. I don't much
care if they give me NFS and X-Windows support, I want the absolutely
best tcp/ip engine that MVS is capable of hosting, with that building
block in place the rest can be build around.

But if today, right this minute you want a mainframe tcp/ip that can
go 700-800Mb/s easily without overwhelming your CPU you go to the Cray
folks not IBM. This at a time when gigabit networking and applications
are just over the horizon doesn't augur too well for the future of
tcp/ip on IBM mainframes. Remember, part of this discussion was tri-
gerred by the guy trying to do some real networking and trying to
diminish the ensuing 90% overhead on his computer!

Something radical has to happen, what will it be?

-- Denis
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU