home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / bit / listserv / ibmtcpl / 3053 < prev    next >
Encoding:
Text File  |  1992-12-23  |  5.3 KB  |  97 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!gatech!paladin.american.edu!auvm!UCLAMVS.BITNET!CSP1DWD
  3. Message-ID: <IBMTCP-L%92122319104540@PUCC.PRINCETON.EDU>
  4. Newsgroups: bit.listserv.ibmtcp-l
  5. Date:         Wed, 23 Dec 1992 16:08:00 PST
  6. Sender:       IBM TCP/IP List <IBMTCP-L@PUCC.BITNET>
  7. From:         "Denis DeLaRoca 825-4580 (310)" <CSP1DWD@UCLAMVS.BITNET>
  8. Subject:      Re: IBM TCP/IP inadequacies (was Usage of vector facility for
  9.               TCP/IP?)
  10. Lines: 85
  11.  
  12. Frank Vance <fvance@WG.WAII.COM> writes:
  13.  
  14. >  I used to think that, but Bill R. convinced me they really do care, y
  15. >  just don't have the resources.  So they try to focus on things they
  16. >  think are most in demand from the customers.
  17.  
  18. What resources? It is a fact that the TCPIP product is a proven money-
  19. maker, resources can be created easily to support such products. What
  20. triggered this and other messages is the fact that severe and well
  21. known problems in fundamental areas of the product (ie, IUCV/VMCF)
  22. persist and that IBM has publicly (thru this list and thru support)
  23. expressed their priority to fix these problems, well over a year
  24. later all these stated intentions and promises have vanished into
  25. thin air.
  26.  
  27. You might ask why is IUCV/VMCF so important?  As it turns out IUCV/VMCF
  28. (and the VM platform) make up the essential bridge between user
  29. processes and the TCPIP kernel, every single TCPIP transaction goes
  30. thru that bridge, but this bridge is neither solid nor ample, you can
  31. fall from it very easily. For example you can't reliable run one tcp/ip
  32. application in one split of my ISPF session and then start another
  33. tcp/ip app (whether it be from IBM or not) in a second split... I can't
  34. have that same tcp/ip app multitask and use tcp/ip services without the
  35. risk of losing access to IUCV from within my address space.  Can't even
  36. run IBM's own telnet and FTP clients together... can't deploy Gopher,
  37. Wais, Web, NewsReader clients, or any other tcp/ip applications that
  38. multitasks and/or shells out to other tcp/ip applications without
  39. running into some TCPIP problem, usually an IUCV/VMCF problem.  We have
  40. observed complex crashes in IUCV cleanup, we have observed user address
  41. spaces being left non-swappable by IUCV, the list goes on...
  42.  
  43. The starting point for TCPIP was the VM work done at Wisconsin, but
  44. what was a virtuous, simple and glorified hack, in those days, has
  45. become totally obsolete and regressive. The current TCPIP architecture,
  46. unchanged from those simple days, bears absolutely no resemblance
  47. to modern day reality of fast computers and high-speed networking,
  48. the fact that TCPIP for MVS is hosted by means of a badly engineered
  49. (and buggy) VM emulator platform is absolutely mind boggling... the
  50. basic engineering principles to do high performance tcp/ip implemen-
  51. tations are by now well known, the sound engineering principles to
  52. host such implementations efficiently in modern day operating systems
  53. are also well known. MVS itself is in many respects as good an operating
  54. system as you can get and I am told by the MVS gurus that no significant
  55. obstacle exists to host a high-performance implementation of tcp/ip.
  56.  
  57. It is clear that market pressures pushed IBM for an early release of
  58. TCPIP in what I'd consider a fundamentally flawed implementation, an
  59. implementation with inherent functional, performance and reliability
  60. limits. Rather than following that up with a better engineered imple-
  61. mentation we've seen more and more construction on a building that is
  62. for all intensive purposes sitting on a sandpit... and the crux of the
  63. matter is dealing with Operating System issues. To customer complains
  64. of poor performance we've seen the emergence of "offloading" whereby
  65. the basic tcp/ip protocol processing is offloaded to a peripheral
  66. processor... but this hardly changes the picture as we are still left
  67. saddled with complex interfaces to talk to an offload tcpip box, and
  68. we are still saddled with all the overhead and problems of the VM
  69. emulation platform. I don't see any future on this, on paper it
  70. looks as, if not more, expensive that the current solution.
  71.  
  72. >  My personal opinion is that the "typical" customer wants some crazy ngs,
  73. >  like CICS sockets, the NDB system, and the like, none of which I hav
  74. >  use for.  Of course, that "typical" customer probably thinks my
  75. >  requirement list (higher throughput, lower CPU consumption, better
  76. >  Network Systems support) is strange too.
  77.  
  78. I think these last requirements: performance, low resource utilization
  79. and rational network systems support are essential, nothing strange
  80. about them, and I would contend should be the areas that IBM should
  81. be putting all their resources and expertise to provide. I don't much
  82. care if they give me NFS and X-Windows support, I want the absolutely
  83. best tcp/ip engine that MVS is capable of hosting, with that building
  84. block in place the rest can be build around.
  85.  
  86. But if today, right this minute you want a mainframe tcp/ip that can
  87. go 700-800Mb/s easily without overwhelming your CPU you go to the Cray
  88. folks not IBM. This at a time when gigabit networking and applications
  89. are just over the horizon doesn't augur too well for the future of
  90. tcp/ip on IBM mainframes. Remember, part of this discussion was tri-
  91. gerred by the guy trying to do some real networking and trying to
  92. diminish the ensuing 90% overhead on his computer!
  93.  
  94. Something radical has to happen, what will it be?
  95.  
  96. -- Denis
  97.