dcrocker@TWG.COM (Dave Crocker) (08/09/88)
To answer Van's query about my previous note: We do not expect Berkeley code to port directly over to our Streams implementation. While it would be delightful if it did, the Streams architecture lends itself to a substantially different implementation style, although many of the routines can translate quite easily. In the good cases, this means that the left window on your screen shows BSD and the right show the streams code, and you do fairly straightforward translations. The other piece of my comment was simply management-speak for saying that we don't have any in-house experience with this software revolution wrought by Van, et cie, so that we ought to gain some familiarity with its dynamics before shipping it to customers (who have a fairly strong expectation that we will support the code we ship.) Given the history of Van's changes to TCP code, I suspect that my m-speak was mostly a formality. Dave
dcrocker@TWG.COM (Dave Crocker) (08/23/88)
Another religious issue... Network friendliness vs. throughput? Clearly, any host participating in an internet needs to be a good neighbor. Van, et cie's, combined efforts seem to provide enough mechanism to settle the questions of "how?" The question of whether it is more or less important that performance is, mostly, deciding on the number of checksums that can fit on the head of a PIN. Nonetheless, I am curious to see the dominant point of view assuming that internet friendliness must be the answer. It presupposes a certain kind of market. If 90% of the marketplace is on small lans, then performance is likely to be foremost in the customers' minds. They do little or no internetting and therefore do not care about congestion control. No, the current number probably is not 90%, but there is a threshold, somewhere, that says performance needs to dominate. Dave
KASTEN@MITVMA.MIT.EDU (Frank KAstenholz) (08/23/88)
Speaking as a commercial developer who is trying to make extensive use of TCP/IP in a product that will eventually be required to move large images through a network very quickly and highly reliably I would say that the more important of the two choices (friendliness vs speed) is that one be a good neighbor. Our products perform newspaper composition - editing articles, pictures, ads, graphics, etc, designing pages, and sending full page images to a photo typesetter. All of this requires a fairly large bandwidth (worst case - a newspaper page could be over 20 Megabytes and the requirement is to ship one of these pages to the phototypesetter every minute). However, while the speed requirement is high, that can allways be alleviated by throwing more money at the system (buying more/bigger CPU's, etc, etc). What is important to us (and maybe many other commercial developers/users of TCP) is that the network be reliable. If the newspaper does not get printed then the publisher looses his/her ad revenue for the day, etc, etc and that is millions. So, a reliable network is more important than a fast one - even on a single local lan. This is only one data point but I guess that it represents a large portion of the people who wish to integrate TCP into their products. Frank Kastenholz Atex/EPPS/Eastman Kodak All opinions are mine and mine alone (etc etc etc).