|
|
ARCHIVE: TCP-IP Distribution List - Archives (1988)
DOCUMENT: TCP-IP Distribution List for February 1988 (360 messages, 173727 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/02.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 01 Feb 88 13:46:19 EST (Mon) From: dm@bfly-vax.bbn.com To: ddc@xx.lcs.mit.edu Cc: adrion@sh.cs.net, iab@venera.isi.edu, npag@louie.udel.edu, steve@note.nsf.gov, tcp-ip@sri-nic.ARPA, csnet-ec@sh.cs.net, adrion@cs-umass.ARPA, cosepup@postgres.berkeley.edu, dm@bfly-vax.bbn.com Subject: Re: Help...looking for network anecdotes
``The development of COMMON LISP would most probably not have been
possible without the electronic message system provided by the
ARPANET. Design decisions were made on several hundred distinct
points, for the most part by consensus, and by simple majority ote
when necessary. Except for two one-day face-to-face meetings, all
of the language design and discussion was done through the ARPANET
message system, which permitted effortless dissemination of
messages to dozens of people, and several interchanges per day.
The message system also provided automatic archiving of the entire
discussion, which has proved invaluable in preparation of this
reference manual. Over the course of thirty months, approximately
3000 messages were sent (an averabe of three per day), ranging in
length from one line to twenty pages... It would have been
substantially more difficult to have conducted this discussion by
any other means, and would have required much more time.''
Guy Steele, ``COMMON LISP: the language'' (Digital
Press, 1984). pp xi-xii.
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 88 12:57:11 GMT From: backman@interlan.UUCP (Larry Backman) To: comp.protocols.tcp-ip Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
In article <[A.ISI.EDU]26-Jan-88.08:13:44.CERF> CERF@A.ISI.EDU writes: >NOVELL Netware and TCP/IP have been made to interoperate by Novell. > >I do not know any of the details of the software or how one conveys >the desired IP destination to the TCP/IP server. It may behave like >TELNET piggybacking (where you log into a host and TELNET back out >again, specifying where you want to go to the User Telnet). > [] Sorry to bang the drum loudly but... Micom-Interlan implemented the TCP gateway under Netware with OS support from Novell. They know Netware, we know TCP.(or kind of). Client programs on the gateway were ported from Bsd4.3, they look and act exactly the same. A user wishing to use TELNET goes through the following script: ipx /* load Netware driver in workstation*/ net3 /* load Netware redirector */ f:login server\username netbios /* load NETBIOS emulator */ gwattach gatewayname /*make a NETBIOS connection between PC and server */ Telnet vax4 ..... The server and gateway are roughly analogous to a real OS with TCP. You log on to a file server, prepare your environment, and then use TCP as a service. We ifconfig addresses just like UNIX, and have an /etc/hosts file just like UNIX. In our next release we will have domain name resolution... Hope I clarified things. Larry Backman Micom - Interlan
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 88 15:51:36 GMT From: hrp@ishmael.CRAY.COM (Hal Peterson) To: comp.protocols.tcp-ip Subject: TCP-IP Verification Suite
The TCP/IP community does not have a strong tradition of formal
testing from specifications. Historically (see RFC-1025, ``TCP and IP
Bake Off''), testing a TCP/IP implementation has meant structured
plugging it in and trying it, with as many other implementations as
possible.
Over the last few years, there has been a movement toward more formal
testing from within the DCA, and they are currently beta testing
(metatesting?) a suite covering every conceivable aspect of all the
MIL-STD protocols: IP, TCP, FTP, TELNET, and SMTP. The tests are
comprehensive and do find bugs, but require a significant investment
of time and effort to run.
There was a note on the tcp-ip list last year from Bob Jones
(bobj@kauai.mcl.unisys.com) in which he wrote:
For those who are interested, the DCA is setting up an administrative
agreement with the National Bureau of Standards to provide for the
certification of the TCP/IP suite of protocols. NBS is expected to
announce for vendors to participate under the National Voluntary
Laboratory Accreditation Program (NVLAP). This program is expected
to be in place sometime in early 1988. Any questions please call
DCEC, Jim Tontonoz, 703-437-2038.
This certification would probably involve passing the aforementioned
DCA test suite.
--
Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120
hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-5884
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 88 16:51:44 GMT From: ddc@LCS.MIT.EDU To: comp.protocols.tcp-ip Subject: Re: Help...looking for network anecdotes
Rick,
In fact, I think E-mail is a great story. What seems mundane to
us is a great leap forward to the rest of the world. A spoecific
example just a few months ago: I am on a security working group
considering the problem of integrity in data processing systems. This
group has both military and commercial security people. When we
started to plan the followup to a workshop, we found ourselves in two
groups: those that could exchange netmail, and those who could not.
The military folks, by and large, had interconnected mail addresses,
and they started proposing actions and schedules that seemed silly to
those with telephone and postal services. At the end, some of the
commercial security folks asked how they could get netmail, as it
seemed essential if they were to keep up with the others.
Of course, the first netmail story is the building of the network
itself. The builders of the network were its forst users (as is only
fair; they get both the benefit and the pain). It is cldear to me, as
a member of that group, that the group effort necessary to build the
Internet simply could not have succeeded without netmail.
Another local example is the Clinical Decision Making group at
the Laboratory for Computer Science. They are concerned with computer
support for doctors. They work with computer professionals and, more
to the point, with doctors. The doctors are not at MIT, but at various
medical schools in Boston and elsewhere. Those folks make heavy use of
networks, and in fact caused some of the local med schools to get
attached to the MIT net. Theu use the net for mail, but also for
remote execution of programs, for exchange of data, and for
distributed program interaction. They assert (I just asked them) that
network technology is critical to the way theyu do their work, and
that the patterns of working with remote colleagues would not be
nearly as effective without nets.
There is nothing special about these stories; they a similar to
many others. But they are local, and real.
Dave Clark
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 88 18:46:19 GMT From: dm@BFLY-VAX.BBN.COM To: comp.protocols.tcp-ip Subject: Re: Help...looking for network anecdotes
``The development of COMMON LISP would most probably not have been
possible without the electronic message system provided by the
ARPANET. Design decisions were made on several hundred distinct
points, for the most part by consensus, and by simple majority ote
when necessary. Except for two one-day face-to-face meetings, all
of the language design and discussion was done through the ARPANET
message system, which permitted effortless dissemination of
messages to dozens of people, and several interchanges per day.
The message system also provided automatic archiving of the entire
discussion, which has proved invaluable in preparation of this
reference manual. Over the course of thirty months, approximately
3000 messages were sent (an averabe of three per day), ranging in
length from one line to twenty pages... It would have been
substantially more difficult to have conducted this discussion by
any other means, and would have required much more time.''
Guy Steele, ``COMMON LISP: the language'' (Digital
Press, 1984). pp xi-xii.
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 88 19:35:30 GMT From: ddc@LCS.MIT.EDU To: comp.protocols.tcp-ip Subject: Re: Help...looking for network anecdotes
"All we know is the phenomenon: we spend our time sending messages to each other, talking and trying to listen at the same time, exchanging information. This seems to be our most urgent biological function; it is what we do with our lives." Lewis Thomas, "The Lives of a Cell"
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 88 20:09:07 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
Thomas, Please see: "The NSFNET Backbone Network," Proc. 1987 SIGCOMM Symposium and also recent Internet Monthly reports from U Delaware. Dave
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 01:19:26 GMT From: karn@thumper.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: Hop problem
> the "packet radio" referenced was not the DARPA packet radio but the > amateur packet radio. I don't know how those systems handle the TTL > field... The "amateur Internet" is much like the real Internet -- a mixture of IP gateways and "digipeaters". Digipeaters are single frequency store-and-forward repeaters that operate on the source routing fields in the "AX.25" amateur link level protocol. Since digipeaters do not understand IP, they do not modify TTL fields even though they may introduce considerable delay. Most amateur packet radio channels operate at 1200 bps synchronous, with substantial contention and keyup delays, plus high collision rates due to hidden transmitters. In general, the TCP/IP nodes on the amateur Internet are PCs running my TCP/IP implementation (the "KA9Q" package). This includes end-nodes as well as IP gateways. At present, my code decrements the TTL field by 1 for each pass through a gateway module, including the end hosts. One of the interesting observations to come out of our experiments so far is the interaction between the retransmission algorithms in the TCP (transport) and AX.25 (link) layers. It definitely does *not* pay to try "too hard" at the link layer. If it takes several extra retransmissions to get a packet through, chances are that a TCP retransmission will occur in the meantime and you'll just have to do the same all over again with another copy. It may be worthwhile to allow control over the "beta" constant in TCP, perhaps in combination with the "reliability" bit in the IP header (my gateway code uses this bit to override the per-link default setting as to whether to use link level acknowledgements or not). I think we've shown pretty convincingly, though, that you can't use link level ARQ to sweep fundamental inadequacies in the lower layers under the rug. This is especially true with channel access algorithms. Our experiments are now moving toward multi-frequency full duplex gateways that will eliminate contention and improve channel utilization markedly. Phil
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 01:31:41 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Re: Help...looking for network anecdotes
Rick, I have to add in a story about the benefits of e-mail. A few years ago I was talking to a random seatmate on the Washington-to-San Francisco milk run and got around to asking her what she did. She was a geologist. She was on a post doc at Stanford. I asked how the field was progressing from her perspective. She said that the field was making dramatic advances in the past few years because so many geologists were using this new thing called electronic mail all over the world and they were using it to find out what others already knew! They used the mechanisms of e-mail to raise the level of common knowledge on the leading edge of the field. No one wants to spend years doing research in some part that has already been worked over and the usual method of writing/reading journals was too slow. I find that dramatic. And I find that they were mostly using the Arpanet without "full permission" to be a sad commentary on those of us who know how valuable this all is to humanity, because we have not found a way to fund the intellectual interconnection of all researchers in a straight forward manner yet. So, please thke this kind of "evidence" and build te case. Thanks, Dan -------
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 01:53:34 GMT From: karn@thumper.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
> 1) Best effort systems rely totally on hosts for congestion > management. That is, transport protocols are responsible for > congestion control and congestion avoidance. The problem with the existing flow control mechanisms in the ARPANET is that they add considerable overhead even when the network is otherwise lightly loaded. As I understand it, the ARPANET links all run at 56kbps; so in theory they could carry 7 kilobytes/sec. However I've *never* seen a file transfer throughput of more than 2.5-3.0 kilobytes/sec, even over a short East Coast path in the middle of the night. My timings are consistent enough that I can only attribute the difference to the ARPANET's internal packetizing and flow control overhead. (If there are other factors at work I'd like to know about them). Yes, transport protocol behavior is important, but there's no reason why the "best effort" network can't have defense mechanisms that activate only when the network is congested. For example, the network might normally run in a pure datagram mode, with no network bandwidth wasted on edge-to-edge acknowledgements. However when the network becomes congested, the internal equivalent of "source quench" packets are sent to the entry node, telling it to stop injecting so much traffic into the network. The entry node might translate that into an access protocol message telling the host (or gateway) to slow down, but more importantly the entry node could simply delay or discard additional traffic before it enters the network. Discarding packets is certainly one way to get TCP's attention, but the delaying tactic would be more efficient. There have been theoretical assertions that even infinite buffering is insufficient to prevent datagram network congestion. However, this assumes no interaction between the network and the transport protocol, and this is certainly not true with TCP. TCP cannot transfer more than one window's worth of data per round trip time, so to slow it down you either reduce the window size or increase the round trip time. If you can't get it to reduce its window size voluntarily (e.g., with a source quench) then you can certainly increase its round trip time (i.e., with additional buffering). Given a finite number of TCP connections, enough buffer space will eventually reduce the offered datagram load to the capacity of the network, although everyone would be better served if the TCPs could instead cut their window sizes. NFS and ND are not completely uncontrolled, rather they are basically stop-and-wait protocols. They would behave well too if only they did retransmission backoff like TCP. A lot of effort has gone into tuning TCP round trip time estimates. Question: has anyone looked into techniques for tuning TCP window sizes? Intuitively, I expect that increasing the window size for a TCP-based file transfer would increase throughput until the slowest link in the path saturates. Beyond this point, throughput would remain constant but round trip delay would goes up, unnecessarily increasing delay for other users of the same path. It would be nice to find an algorithm that found and operated at this optimal operating point automatically. Any ideas? Phil
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 02:04:48 GMT From: karn@thumper.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: Hop problem
In article <919@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes: > The "amateur Internet" is much like the real Internet -- a mixture of IP > gateways and "digipeaters".... Oops, what I meant to say here was that the amateur network is much like the real Internet in that both consist of a mixture of IP gateways and lower level entities that don't understand IP. The amateur packet radio internet includes its non-IP "digipeaters" in the same way that the "real" Internet includes X.25 packet switches, Ethernet repeaters and bridges. Depending on the specific network configuration, either the IP-level gateways or the subnetwork level components may do the bulk of the work. Phil
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 02:36:43 GMT From: greg@vertical.oz (Greg Bond) To: comp.protocols.tcp-ip,comp.lang.c Subject: Re: C binding interfaces for TCP/IP
In article <610@cresswell.quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes: > In article <7202@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > > [talks about Sun XDR protocol] > > it up in the Sun reference manual and found that it had FAR too much > > overhead for my purposes. I ended up implementing my own scheme that > > runs much faster. > > How can a program run much faster than a PROTOCOL? > The protocol is one thing, the source-code implementation of it that > SUN give away is quite another. Correct. If the PROTOCOL requires significant overhead of bytes on the wire, then the IMPLEMENTATION will be limited in the speed it can achieve, no matter how good the code implementing it is. We may say that "standards" are more important than efficiency. In this case, Doug seems to have made the judgement that the application required an efficiency un-obtainable with XDR spec, and invented his own, and assumed the support responsibility etc. Yes, the protocol is not the implementation. But great implementation may not save a poor or inappropriate protocol. [ I make this as a general point; I have no knowledge of XDR per se ] -- #define WHOAMI Gregory Bond, Vertical Software, Melbourne, Australia #define ADDRESS greg@vertical.oz, uunet!vertical.oz!greg #define JOKE Ain't no-one here but us chickens... #include <standard/disclaimer>
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 05:06:40 GMT From: cscosl!yf@ncsuvx.ncsu.edu (Yen Fu-Shin) To: tcp-ip@sri-nic.arpa Subject: Old articles and RFC
Does anyone know where I can find old articles? where I can find RFC-1008, RFC-1007 and RFC-1006. -------
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 14:27:00 PST From: <art@acc.arpa> To: "thumper!karn" <thumper!karn@faline.bellcore.com> Cc: tcp-ip@sri-nic.arpa Subject: TCP window sizing
>A lot of effort has gone into tuning TCP round trip time estimates. >Question: has anyone looked into techniques for tuning TCP window sizes? >Intuitively, I expect that increasing the window size for a TCP-based >file transfer would increase throughput until the slowest link in the >path saturates. Beyond this point, throughput would remain constant but >round trip delay would goes up, unnecessarily increasing delay for other >users of the same path. It would be nice to find an algorithm that found >and operated at this optimal operating point automatically. Any ideas? Phil, Have you seen any of Van Jacobsen's work on TCP? His algorithms include dynamically adjusting the TCP window based on Acks and Timeouts in an attempt to optimize the widow for current congestion levels. He has done some very good process control analysis to understand the dynamics of the system. Art Berggreen art@acc.arpa ------ -------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Feb 88 12:26:58 est From: Denis Haskin <dhaskin%lucy.wellesley.edu@RELAY.CS.NET> To: info-vax@lucy.wellesley.edu, tcp-ip@SRI-NIC.ARPA, big-lan%suvm.bitnet@cunyvm.cuny.edu, dhaskin@lucy.wellesley.edu Subject: Xyplex MAXserver 5000
Has anyone had any experience with the Xyplex MAXserver 5000 (in any configuration), in any kind of environment? Their glossy and the information available thus far in the trades is not really very detailed, and I am be particularly interested in any hands-on experience. Please respond directly to me (I cannot regularly read the tcp-ip list because of the volume of traffic) and I will summarize back to these lists. Thanks, and apologies if you received duplicates because of the cross-posting. Denis W. Haskin, Network Manager Wellesley College DHaskin@Lucy.Wellesley.Edu -or- Wellesley, MA 02181 Denis@Bambam.Wellesley.Edu 617-235-0320 x3123 -------
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Feb 88 12:50:47 est From: Denis Haskin <dhaskin%lucy.wellesley.edu@RELAY.CS.NET> To: info-vax@lucy.wellesley.edu, tcp-ip@SRI-NIC.ARPA, big-lan%suvm.bitnet@cunyvm.cuny.edu Subject: Let me dispel any myths about my illiteracy
> Has anyone had any experience with the Xyplex MAXserver 5000 (in any > configuration), in any kind of environment? Their glossy and the information > available thus far in the trades is not really very detailed, and I am be > particularly interested in any hands-on experience. ^^^^^^^^ Sigh. I really can speak English, although it may not appear that way. "I am particularly..." That's embarrassing... Denis -------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 12:08:17 GMT From: merlin@hqda-ai.UUCP (David S. Hayes) To: comp.protocols.tcp-ip,comp.unix.questions Subject: FTP Directory listings under TOPS-20
I have been having trouble doing FTP to Arpanet hosts using
the TOPS-20 operating system. They support filenames of the sort
Device:<dir1.dir2...>file.type.version
I want to find out what legal choices exist for "device" and
the directory heirarchy. This is easy to do when FTP-ing to a
Unix host, but I don't know how to do it when the host is running
TOPS-20.
Can anyone enlighten me? This is particularly important,
because I know there are many good things on the archives at
SIMTEL-20, but I don't know how to get a list of what's available.
(send *advance* :insert 'thanks)
--
David S. Hayes, The Merlin of Avalon PhoneNet: (202) 694-6900
UUCP: *!uunet!cos!hqda-ai!merlin ARPA: ai01@hios-pent.arpa
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 13:48:42 GMT From: larry@pdn.UUCP (Larry Swift) To: comp.protocols.tcp-ip Subject: Re: Visa paper draft Finally available
I give up: what is Visa, and why might I want a copy of the draft?
Larry Swift UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207 Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 1988 19:22-EST From: CERF@A.ISI.EDU To: cheriton@PESCADERO.STANFORD.EDU Cc: pogran@CCQ.BBN.COM, robert@SPAM.ISTC.SRI.COM tcp-ip@SRI-NIC.ARPA Subject: Re: PSN 7 End-to-End question.
Dave, good questions! There was an attempt at a truly datagram network in the early 1970's. It was developed by Louis Pouzin and Hubert Zimmermann and, I think, Gerard LeLann. They worked at IRIA which is now known as INRIA (National Research Institute on automation and information processing) in France. The network was called CYCLADES. I am sorry I don't have references at hand (I am on travel using a small laptop for comm), but my recollection is that they experienced packet loss rates up to 48% when the network became congested. The ARPANET E-E protocols are intended to push back towards the source soon enough to avoid sustained loss rates of that magnitude, as I understand them. Lean and mean often applies best when the resources are plentiful, but can become a liability if the network is permitted to enter a congested state. Vint
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 17:06:06 GMT From: robert@pvab.UUCP (Robert Claeson) To: comp.protocols.tcp-ip,comp.protocols.appletalk,comp.protocols.tcp-ip.ibmpc Subject: Advice on TCP-IP/NETBIOS/APPLETALK interconnection sought
Netlanders, Assume a company or institution that has a few UNIX file-servers running NFS or RFS, some workstations running UNIX and a number of PC's and/or Mac's. The network is based on IEEE 802.3 and uses TCP/IP as its primary protocol. I want to be able to use laser printers (PostScript, of course) from a PC or a Mac, log in to a UNIX machine via the network, send electronic mail back and forth between the machines and possibly use the UNIX file servers to store DOS or Mac files. What would be the best solution to integrate these two or three environments? Should I use TCP/IP, NFS, TELNET and SMTP on all computers? (Does it even exist?) Have I better use TCP/IP, NETBIOS and EtherTalk on the same cable and some kind of gateway between them? Does such a thing exist? I would appreciate any comment, suggestion and opinion on this, since these and related questions will probably arise soon, not only for me, but for many other as well. Thanks, Robert -- Robert Claeson, System Administrator, PVAB, Box 4040, S-171 04 Solna, Sweden eunet: robert@pvab uucp: sun!enea!pvab!robert
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 17:50:47 GMT From: dhaskin@lucy.wellesley.EDU (Denis Haskin) To: comp.protocols.tcp-ip Subject: Let me dispel any myths about my illiteracy
> Has anyone had any experience with the Xyplex MAXserver 5000 (in any > configuration), in any kind of environment? Their glossy and the information > available thus far in the trades is not really very detailed, and I am be > particularly interested in any hands-on experience. ^^^^^^^^ Sigh. I really can speak English, although it may not appear that way. "I am particularly..." That's embarrassing... Denis
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 19:03:58 GMT From: Z3000JD@AWITUW01.BITNET To: comp.protocols.tcp-ip Subject: 'ARP-Server for ULTRIX'
We have a TCP-IP gateway from TCP/IP Ethernet to CDCNET. This gateway does not support the ARP-Protocol. On the TCP-Side we have a MicroVAX runnin ULTRIX. Does anyone now how I can configure the UTRIX machine so it can work as a ARP-responder for the Internet-address of the TCP-IP Gatway. Johannes Demel Technical University Vienna Z3000JD@AWITUW01.BITNET
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 19:32:51 GMT From: karn@thumper.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: TCP-IP Verification Suite
> The TCP/IP community does not have a strong tradition of formal > testing from specifications. Historically (see RFC-1025, ``TCP and IP > Bake Off''), testing a TCP/IP implementation has meant structured > plugging it in and trying it, with as many other implementations as > possible. Actually, I think there is a lot to be said for this approach. Formal verification is difficult, slow and expensive, while the informal testing of a new implementation on the real Internet quickly shows whether it's likely to work in actual use. The real world has a way of revealing things that remain stubbornly hidden in the lab. The TCP/IP experience has shown that finding clear-cut protocol violations is not difficult. The *real* issues are a) getting rid of gaps and ambiguities in the specs themselves that can allow different implementations to "conform" yet not be interoperable, and b) figuring out how to armtwist the vendor of a broken implementation to fix it once a problem has been identified. Formal verification suites attack neither of these problems. Phil
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 22:11:17 GMT From: bob@zog.PRC.Unisys.COM To: comp.protocols.tcp-ip Subject: Performance Data Wanted
Does anyone know of published performance data on TCP/IP for various hardware? That is, how many packets per second should a given CPU be able to send, exclusive of the subnetwork protocol or the communications medium? I am particularly interested in data for the VAX 11/785, but will take data for any CPU. Please note that I am not interested in simply answering this question, but in finding public, non-proprietary measurements that can be publicly cited. Thank you.
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 22:27:00 GMT From: art@ACC.ARPA To: comp.protocols.tcp-ip Subject: TCP window sizing
>A lot of effort has gone into tuning TCP round trip time estimates. >Question: has anyone looked into techniques for tuning TCP window sizes? >Intuitively, I expect that increasing the window size for a TCP-based >file transfer would increase throughput until the slowest link in the >path saturates. Beyond this point, throughput would remain constant but >round trip delay would goes up, unnecessarily increasing delay for other >users of the same path. It would be nice to find an algorithm that found >and operated at this optimal operating point automatically. Any ideas? Phil, Have you seen any of Van Jacobsen's work on TCP? His algorithms include dynamically adjusting the TCP window based on Acks and Timeouts in an attempt to optimize the widow for current congestion levels. He has done some very good process control analysis to understand the dynamics of the system. Art Berggreen art@acc.arpa ------
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 88 23:31:12 GMT From: terrell@musky2.EDU (Roger Terrell) To: comp.protocols.tcp-ip Subject: Who sells TCP/IP for AT&T 3B2/300's?
Does anyone know who (if anyone) sells a version of TCP/IP for the AT&T 3B2/300? What hardware does this need if it exists? Thanks, Roger -- Roger Terrell Muskingum College ...cbosgd!musky2!terrell (UUCP) New Concord, OH 43762
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 00:22:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
Dave, good questions! There was an attempt at a truly datagram network in the early 1970's. It was developed by Louis Pouzin and Hubert Zimmermann and, I think, Gerard LeLann. They worked at IRIA which is now known as INRIA (National Research Institute on automation and information processing) in France. The network was called CYCLADES. I am sorry I don't have references at hand (I am on travel using a small laptop for comm), but my recollection is that they experienced packet loss rates up to 48% when the network became congested. The ARPANET E-E protocols are intended to push back towards the source soon enough to avoid sustained loss rates of that magnitude, as I understand them. Lean and mean often applies best when the resources are plentiful, but can become a liability if the network is permitted to enter a congested state. Vint
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 00:45:37 GMT From: robert@SPAM.ISTC.SRI.COM (Robert Allen) To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
>> > 1) Best effort systems rely totally on hosts for congestion
>> > management. That is, transport protocols are responsible for
>> > congestion control and congestion avoidance.
>>
>> Yes, transport protocol behavior is important, but there's no reason why
>> the "best effort" network can't have defense mechanisms that activate
>> only when the network is congested. For example, the network might
>> normally run in a pure datagram mode, with no network bandwidth wasted
>> on edge-to-edge acknowledgements. However when the network becomes
>> congested, the internal equivalent of "source quench" packets are sent
>> to the entry node, telling it to stop injecting so much traffic into the
>> network. The entry node might translate that into an access protocol
>> message telling the host (or gateway) to slow down, but more importantly
>> the entry node could simply delay or discard additional traffic before
>> it enters the network. Discarding packets is certainly one way to get
>> TCP's attention, but the delaying tactic would be more efficient.
This is what was on my mind when I asked if the ETE was used for all
traffic. If everything is fine and dandy then there shouldn't be a
need for ETE. It should only activate when needed, similar to when
traffic directing cops are only sent out when the stoplights breakdown
(hmmm, maybe that's sort of poor metaphor, but...). As originally
stated, the Arpanet was designed as an open network, where the hosts
or gateways were assumed not to overuse the network. Now however that
can no longer be assumed. Perhaps indeed some new protocols need
to be developed that put a chokehold on gateways, instead of trying to
choke the traffic at an IMP (via ETE, and assuming that the network
consists of homogeneous hardware and software) or at a host (which is
obviously a problem currently, since host behavior is very heterogenous).
Current routing protocols seem to be very weak at load sharing and con-
gestion control. Most metrics are are hops, rather than quality metrics.
cisco gateways have the administrative distance metric, but for the most
part this field is in its infancy.
>> Question: has anyone looked into techniques for tuning TCP window sizes?
>> Intuitively, I expect that increasing the window size for a TCP-based
>> file transfer would increase throughput until the slowest link in the
>> path saturates. Beyond this point, throughput would remain constant but
>> round trip delay would goes up, unnecessarily increasing delay for other
>> users of the same path. It would be nice to find an algorithm that found
>> and operated at this optimal operating point automatically. Any ideas?
I wonder about this. If the situation were ideal it might be the case
that throughput would remain the same when saturation occurred, however
in reality wouldn't the increasing load (over and above the sat. level)
on the IMP be likely to cause congestion problems, perhaps enough
to back up the series of links to the transmitting host, or more likely,
to cause enough of a delay to cause TCP to declare the host/network
unreachable?
My understanding of the internal structure of the Arpanet is not what
it should be, so excuse me this question. Are all Arpanet (internal)
links pretty much equal in speed (assumedly their MTU size is constant
since it is all the same hardware)? If that is the case perhaps your
model works, but consider this. With networking becoming the widespread
thing that it is, is it fair to design protocols which are designed for
a relatively homogeneous PSN(etwork)? The Arpanet seems to me to be
rather unique in its construction and administration. Networks of the
future may not rely on a homogeneous core, but may rather be a series
of smaller networks which provide routes of varying expense or quality
of service to each other, on a peer rather than superior basis. In
fact, isn't it possible that the current problems encountered in the
Arpanet with loops and backdoor routes messing up the network could be
considered to be weaknesses of the existing protocols? This by the way
really is a question, and not an assertion.
Comments welcome.
Robert Allen, robert@spam.istc.sri.com
415-859-2143 (work phone, days)
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 02:53:29 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
Phil, At least on paths in the mid-Atlantic region I regularily get 12K-16K bps between ARPANET hosts and at least 9.6 Kbps fetching gobs from SRI-NIC, because that's what my home access line speed is and it runs flat-out. I have seen rates to 23 Kbps on some occasions. Be advised PSN 96, through which all my packets fly, is one of the busiest ARPANET spots. Oh, I bet you're connected via X.25. We use real 1822 here. Dave
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 04:01:35 GMT From: medin@AMES-TITAN.ARPA (Milo S. Medin, NASA ARC Code ED) To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
Phil, I used to see throughput rates 3-4 years ago as high as 38-39 Kb/s moving files with FTP between a DEC-10 system running DEC System-10 (CCC) at Lawrence Livermore National Lab to a 4.2 BSD VAX 11/750 (P mach.) at Los Alamos National Lab via the MILNET when I was working at LLNL. This was after the ARPANET/MILNET split, and as I recall, there were a couple PSN's in the path from LLNL to LANL. This was for a large file (100K or so) in the evening. Of course, the FTP's could have been lying to me (I didn't use a stopwatch), but it 'felt' pretty snappy... True, I don't see that kind of rate these days, but then there is a lot more traffic on MILNET these days as well. So I don't think it's the internal PSN network that is the bottleneck. True, both systems were directly attached to MILNET PSN's via 1822 interfaces, and we were running an older version of PSN software before, but I doubt things have changed for the worse *that* much since then... Let's make sure the bottleneck isn't an extra hop through an EGP neighbor or some X.25 interface before throwing stones at the poor PSN's... Ah yes, back in the good ol' days, before all the users discovered these networks... I remember it well. Milo
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 04:38:29 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip,comp.unix.questions merlin@hqda-ai.UUCP Subject: Re: FTP Directory listings under TOPS-20
It is possible to look around in a TOPS-20 directory hierachy just as you would on Unix. However some of the tools to do so are not going to be available via FTP, and I think some sites may place even more restrictions on anonymous FTP users. I don't know any way to find all the legal structures, but if you know a structure, you can find the directories by doing dir <root-directory> You can find subdirectories under foo by doing dir <foo>*.directory
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Wed, 3 Feb 88 12:56:48 PST From: Greg Satz <satz@clash.cisco.com> To: iso@nrtc.northrop.com, tcp-ip@sri-nic.arpa Subject: X.25 Call User Data for higher level protocols
I am in need of the protocol identifiers used in the CALL USER DATA field of the X.25 CALL REQUEST packet for various higher level protocols. I believe I know the following information but need to be able to fill in the blanks. Can anyone help or provide a reference as to where I might find this data? Who supplies these numbers? ISO? I would like to define an ID for a virtual circuit that includes an extra 16 bit data field that could be used like the ethernet type field. Has something like this already been defined? Should I be using 802.2? Comments? Protocol Call User Data (byte in hex) -------- -------------- PAD 0x01 IP 0xCC ISO IP 0xCD XNS ?? PUP ?? DECNET ?? Chaos ?? -------
-----------[000032][next][prev][last][first]----------------------------------------------------
Date: 3 Feb 88 05:09:59 GMT
From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To: comp.protocols.tcp-ip
Subject: Re: TCP window sizing
Have you seen any of Van Jacobsen's work on TCP? His algorithms include
[ ... ]
Is he going to publish any papers on his findings (either simulations
or in-the-field benchmarks)?
-Philip
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 1988 13:08-EST From: CERF@A.ISI.EDU To: cscosl!yf@NCSUVX.NCSU.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Old articles and RFC
1. RFCs are at SRI-NIC. You can use anonymous login with password guest and FTP from the <NIC> directory. 2. old articles - if you mean published ones, the NCSU computer science library, if you have one, should have journal and proceedings. Vint Cerf -------
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 09:05:47 GMT From: slevy@UC.MSC.UMN.EDU (Stuart Levy) To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
We have 1822 here, too, but I've never seen rates over 3.5 KBytes/sec (i.e. 28 Kbits or half the nominal line speed) on any TCP transfer. Even talking to other nodes on the same IMP as we are. Even talking to our own net-10 address, for that matter. We have an HDH connection to a remote IMP. Until recently we were connected via an ECU (to the same IMP, of course); that did about the same.
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Wed, 3 Feb 88 17:34:05 EST From: Alex McKenzie <mckenzie@LABS-N.BBN.COM> To: tcp-ip@SRI-NIC.ARPA Subject: ARPANET Throughput
In addition to recounting old war stories, some of you might be interested in the "calculated" performance of the ARPANET design. A fairly extensive set of calculations were published in the Proceedings of the 1972 Fall Joint Computer Conference in a paper by McQuillan, Crowther, Cosell, Walden, and Heart (all of BBN) titled "Improvements in the design and performance of the ARPA network" on pages 741-754. Alex McKenzie -------
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 15:19:04 GMT From: mminnich@UDEL.EDU (Mike Minnich) To: comp.protocols.tcp-ip Subject: Re: Performance Data Wanted
There is an article "User-Process Communication Performance in Networks of Computers" in the January '88 issue of IEEE Trans. on Software Engineering, vol 14, number 1. It contains some of the performance data you seek. mike
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 16:31:16 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
Phil and Dave, Just to add to the history of how much data we used to be able to shove through the old Arpanet: In the late 70s I used to FTP (in TCP mode) the huge LISP executable file that was a few megabytes in size. I did it from SRI to/from BBN. Regularly got 40-45 kilobits out of the throretical limit of 56. That was on assumed lightly loaded lines because I did it late at night. In the daytime I would get anywahere from 10-30 kilobits per second. (As Dave pointed out, it was all 1822 interfaces.) Lenny Kleinrock told me a magic number in 1966 -- it was 37%. Anytime you try to get more than 37% of the capacity out of any shared services you will start to get unhappy. When you go over 70% you will be miserable. Dan -------
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 18:08:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Old articles and RFC
1. RFCs are at SRI-NIC. You can use anonymous login with password guest and FTP from the <NIC> directory. 2. old articles - if you mean published ones, the NCSU computer science library, if you have one, should have journal and proceedings. Vint Cerf
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 18:24:56 GMT From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) To: comp.protocols.tcp-ip Subject: Re: Who sells TCP/IP for AT&T 3B2/300's?
terrell@musky2.EDU writes: Does anyone know who (if anyone) sells a version of TCP/IP for the AT&T 3B2/300? What hardware does this need if it exists? We have Enhanced TCP/IP WIN/3B from The Wollongong Group on our 3B2/400s. AT&T sells it directly. It does pretty well. We use it exclusively for rlogin, telnet, and ftp purposes, though; we continue to use only smail for a mailer, although this package came with a SysV version of sendmail. -=- Karl
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 19:18:16 GMT From: dnwcv@dcatla.UUCP (William C. VerSteeg) To: comp.protocols.tcp-ip Subject: Zero windows in SUN Unix
I am testing a new terminal server and have run into a problem with TCP windows closing. I have noticed that SUN Unix 4.2 rel3.2 doesn't open its TCP window without prompting. If the SUN closes its window, and it stays closed long enough for a few "polling" packets to pass by, data flow ceases. The window stays closed until a rather long timer on the terminal server expires and it sends another short exploratory packet. This causes aggravating data stoppages. Is this closed window scenario common? Would it be advisable to reduce the terminal server's timer length from 2 minutes to something like 10 seconds? Thanks in advance Bill VerSteeg
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 19:23:49 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
Once upon a time, about 1982, I measured 70kbits/sec from my host looped through the local IMP and back, using max-sized UDP packets. The IMP was number 1 on the ARPANET (UCLA); the host was an IBM 3033 mainframe; the IMP interface was the ACC IF/370 using an 1822 VDH connection. We commonly saw 45-48 kbits/sec doing FTP's between two different hosts via the UCLA IMP; the source was generally a VAX runnning LOCUS in Computer Science, and the sink was the aforementioned 3033 (Computer Science sure loved the cheap, fast printing available on the mainframe!). Bob Braden
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 20:41:31 GMT From: wbe@bbn.com (Winston B Edmond) To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
Robert Allen @ SPAM.ISTC.SRI.COM writes: > >> Yes, transport protocol behavior is important, but there's no reason why >> the "best effort" network can't have defense mechanisms that activate >> only when the network is congested. For example, the network might >> normally run in a pure datagram mode, with no network bandwidth wasted >> on edge-to-edge acknowledgements. However when the network becomes >> congested, the internal equivalent of "source quench" packets are sent >> to the entry node, telling it to stop injecting so much traffic into the >> network. > > If everything is fine and dandy then there shouldn't be a > need for ETE. It should only activate when needed, ... One must be careful about such things. Maybe for a LAN it makes sense to say "when *the network* becomes congested", but for a widely distributed network, such as the ARPANET, with many independent communication paths, the question should really be rephrased as: Can delay caused by congestion controls be avoided when all the paths and nodes between the message's source and destination, including whatever multiple and alternate paths might be used, are relatively uncongested? That would require enough timely information about the path to decide, and the cost of that decision would have to be weighed against the performance improvement to be gained. Once upon a time, the ARPANET had no preallocation of space in the destination IMP, and still does not use it for short-enough messages. Suffice it to say that its absence was enough of a problem to be worth putting it in. If performance in the uncongested case is currently a problem, perhaps the source IMP could estimate the likelihood of congestion along its selected path and then choose between sending multi-packet messages with or without preallocation, with the destination accepting either. ------------------------------ I would strongly recommend against building a system that activated and deactivated a congestion control system, if by that one means sometimes ceasing to use network processing and communication resources to exchange congestion information. Instead, the congestion control system should always be running, with an option to note that a particular network path is uncongested at the moment. Congestion avoidance requires that information about the state of the network be propagated throughout the network. Perfect knowledge would require that predictions at the source node be accurate for the transit time of the packet. Decreasing the amount or timeliness of the information increases the likelihood of congestion and packet loss. If a disableable congestion control system were used, the network nodes would have to be careful to kick in the congestion controls BEFORE congestion actually occurs, or else there would be a catastrophe point in the network's ability to handle traffic. That point would occur as IMPs switch from sending just user traffic to sending user traffic PLUS congestion control traffic. -WBE Disclaimer: these are personal remarks and should not be taken as official statements of BBN Laboratories Incorporated.
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 20:56:48 GMT From: satz@CLASH.CISCO.COM (Greg Satz) To: comp.protocols.tcp-ip Subject: X.25 Call User Data for higher level protocols
I am in need of the protocol identifiers used in the CALL USER DATA field of the X.25 CALL REQUEST packet for various higher level protocols. I believe I know the following information but need to be able to fill in the blanks. Can anyone help or provide a reference as to where I might find this data? Who supplies these numbers? ISO? I would like to define an ID for a virtual circuit that includes an extra 16 bit data field that could be used like the ethernet type field. Has something like this already been defined? Should I be using 802.2? Comments? Protocol Call User Data (byte in hex) -------- -------------- PAD 0x01 IP 0xCC ISO IP 0xCD XNS ?? PUP ?? DECNET ?? Chaos ??
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 21:33:45 GMT From: thad@cup.portal.com To: comp.protocols.tcp-ip,comp.unix.questions Subject: Re: FTP Directory listings under TOPS-20
The command "INFORMATION STRUCTURES *" (abbreviated I STR *) will
produce a list of the available structures on a given TOPS-20 system.
To see all available (to you!) directories on a given structure:
DIR structure:<*>,
NO FILE
note the comma (putting you into sub-command mode), and note you will
need to enter two RETURNs after the NO FILE.
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 22:11:28 GMT From: karn@THUMPER.BELLCORE.COM (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
We're on a 56Kb/s HDH link to the Columbia IMP, and Stuart's figures are consistent with mine. I spent some time analyzing the HDLC link level on our Sun gateway to make sure it's not the bottleneck. As far as I can tell, it isn't. We're running in message mode (does anybody even bother with packet mode?), with zero acknowledgement delay and a window size of 7. Yes, Dave, the tests were done between Columbia and UDel, but I wouldn't expect such consistent numbers if heavy loading at Delaware was the cause. While we're on the subject of network throughput, I came across an interesting statistic the other day. The French national packet network carries 1,200 billion characters/month, "more than three times the traffic of Tymnet, Telenet and all other American networks combined... In fact, France accounts for more data traffic than all the rest of the world's nations combined..." ["Tout le Monde! C'est Telematique Francaise!", US Black Engineer, Winter 1987, p.5]. While this certainly *sounds* impressive, 1.2 terabytes/month is only 3.7 megabits/sec, roughly 40% of a single Ethernet. We routinely see cables around here running at such levels for sustained periods (NFS/ND traffic between Sun-3's, naturally). Add up all the LANs in the world and even France's awesome network capacity withers into insignificance. Now all we need is a long-haul packet network with a capacity matched to that of tomorrow's LANs so we can have national NFS server banks... Phil
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 22:34:05 GMT From: mckenzie@LABS-N.BBN.COM (Alex McKenzie) To: comp.protocols.tcp-ip Subject: ARPANET Throughput
In addition to recounting old war stories, some of you might be interested in the "calculated" performance of the ARPANET design. A fairly extensive set of calculations were published in the Proceedings of the 1972 Fall Joint Computer Conference in a paper by McQuillan, Crowther, Cosell, Walden, and Heart (all of BBN) titled "Improvements in the design and performance of the ARPA network" on pages 741-754. Alex McKenzie
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 88 23:19:00 GMT From: SRA@XX.LCS.MIT.EDU (Rob Austein) To: comp.protocols.tcp-ip Subject: Apollo NCS paper
Natheniel Mishkin was kind enough to send me machine readable copies of the paper he mentioned a few days ago on NCS (Apollo's Network Computing Achitecture). For those who are interested, I placed them in XX:<ANONYMOUS> as NCS-PAPER.INTERLEAF and NCS-PAPER.PS. They are available (as you might guess) via anonymous FTP on XX.LCS.MIT.EDU. --Rob
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 10:17:00 PST From: <art@acc.arpa> To: "satz" <satz@clash.cisco.com> Cc: iso@nrtc.northrop.com,tcp-ip@sri-nic.arpa Subject: RE: X.25 Call User Data for higher level protocols
>I am in need of the protocol identifiers used in the CALL USER DATA >field of the X.25 CALL REQUEST packet for various higher level >protocols. I believe I know the following information but need to be >able to fill in the blanks. Can anyone help or provide a reference as >to where I might find this data? > >Who supplies these numbers? ISO? I would like to define an ID for a >virtual circuit that includes an extra 16 bit data field that could be >used like the ethernet type field. Has something like this already >been defined? Should I be using 802.2? Comments? > > Protocol Call User Data (byte in hex) > -------- -------------- > > PAD 0x01 > IP 0xCC > ISO IP 0xCD > XNS ?? > PUP ?? > DECNET ?? > Chaos ?? Greg, CCITT defines the high order two bits of the first octet of call user data as follows: 00 - Used for other CCITT recommendations (such as X.29) 01 - Reserved for use by "national" administrative authorities 10 - Reserved for use by international administative authorities 11 - Reserved for arbitrary use between consenting DTEs I believe (they can correct me if I'm wrong) that BBN chose 0xCC and 0xCD for use on the DDN. If you want to establish a standard for use in the Internet I would suggest contacting both DCA and ANSI to see if there is interest. I would appreciate hearing any results you find. Art Berggreen art@acc.arpa ------ -------
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 04:01:57 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
Phil, Tout l'faire! Dave
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Thu, 04 Feb 88 11:26:43 CST From: Shane Davis <X233SD%TAMVM1.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: TCP/IP for Amdahl UTS System V
Greetings...
We are looking for some way to run TCP/IP from our UTS UN*X system. UTS is
being run as a virtual machine on an Amdahl 5860 under VM/SP HPO Rel. 4.2.
The VM system is connected to Internet via Spartacus K200 Ethernet Controller
and running KNET software. UTS version is System V.2/UTS 1.1.3. We would like
to know what options we have with this setup. Is another Ethernet box required?
Is it possible, impossible, difficult, feasible to make KNET route packets
bound for a pseudo-hardware address to the UTS virtual machine, such as has
been done with RSCS here? What vendors can provide TCP/IP software for UTS and
can that software work under the UTS system which runs as a virtual machine?
We're still in the fact-finding stage and I am only helping a little bit with
this project but as I am already on this list I am making the request for info
for the one who will be responsible for implementing any plans we make toward
setting up UTS for TCP/IP.
Please don't give me too many flames for my use of "UN*X," either...I won't
give any of you any for using "VMess..."
Thanks in advance,
--Shane Davis
Programming Assistant
Texas A&M Univ. Computing Svcs. Ctr. Software Systems Group
********************************************************************************
BITnet THEnet Internet
XPMAINT@TAMVENUS THOR::XPMAINT xpmaint@venus.tamu.edu
RSD1901@TAMSIGMA ZAC::RSD1901 --------
X233SD@TAMVM1 ------ x233sd@tamvm1.tamu.edu
------ CONS::RSD1901 rsd1901@cons.tamu.edu
SPAN: UTSPAN::UTADNX::(THEnet addr)
********************************************************************************
-------
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 07:17:58 GMT From: bzs@BU-CS.BU.EDU (Barry Shein) To: comp.protocols.tcp-ip Subject: Zero windows in SUN Unix
Get in touch with Sun software service, they've been distributing a fix for that for a while now. It exists in 3.4 also. Not all systems prompt it but we ran right into it with tn3270. -Barry Shein, Boston University
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 14:18:00 GMT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Zero windows in SUN Unix
Date: 3 Feb 88 19:18:16 GMT
From: dcatla!dnwcv@gatech.edu (William C. VerSteeg)
Is this closed window scenario common? Would it be advisable to reduce the
terminal server's timer length from 2 minutes to something like 10 seconds?
My opinion is that the terminal server should know little if anything
that it is talking to a TCP stream as opposed to any other kind of
stream. It should be the stream's (TCP in this case) responsibility to
let the program (the terminal server in this case) let one more byte
pass through (because that is how TCP works) which will get the flow of
data working again. Under this scenario, you needn't change the
terminal server, only the variable that controls the timeouts for all of
TCP.
Another opinion is that when the TCP data receiver has acknowledged all
the data yet still offers a zero window, the sender should be allowed to
send the one byte probe immediately, instead of having to wait for a
timer to go off. Again, this is at the TCP stream level, not at the
level of any program.
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 17:26:43 GMT From: X233SD@TAMVM1.BITNET (Shane Davis) To: comp.protocols.tcp-ip Subject: TCP/IP for Amdahl UTS System V
Greetings...
We are looking for some way to run TCP/IP from our UTS UN*X system. UTS is
being run as a virtual machine on an Amdahl 5860 under VM/SP HPO Rel. 4.2.
The VM system is connected to Internet via Spartacus K200 Ethernet Controller
and running KNET software. UTS version is System V.2/UTS 1.1.3. We would like
to know what options we have with this setup. Is another Ethernet box required?
Is it possible, impossible, difficult, feasible to make KNET route packets
bound for a pseudo-hardware address to the UTS virtual machine, such as has
been done with RSCS here? What vendors can provide TCP/IP software for UTS and
can that software work under the UTS system which runs as a virtual machine?
We're still in the fact-finding stage and I am only helping a little bit with
this project but as I am already on this list I am making the request for info
for the one who will be responsible for implementing any plans we make toward
setting up UTS for TCP/IP.
Please don't give me too many flames for my use of "UN*X," either...I won't
give any of you any for using "VMess..."
Thanks in advance,
--Shane Davis
Programming Assistant
Texas A&M Univ. Computing Svcs. Ctr. Software Systems Group
********************************************************************************
BITnet THEnet Internet
XPMAINT@TAMVENUS THOR::XPMAINT xpmaint@venus.tamu.edu
RSD1901@TAMSIGMA ZAC::RSD1901 --------
X233SD@TAMVM1 ------ x233sd@tamvm1.tamu.edu
------ CONS::RSD1901 rsd1901@cons.tamu.edu
SPAN: UTSPAN::UTADNX::(THEnet addr)
********************************************************************************
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Feb 88 23:05:33 EST From: "Philip A. Prindeville" <PAP4@AI.AI.MIT.EDU> To: timk%ncsa.uiuc.edu@EDDIE.MIT.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: question about /etc/route
Am I right that the following entry is taken as a host entry and not
a network entry?
# route add 128.174.22 mygateway 3
produces a netstat -r -n output:
128.174.0.22 128.174.20.77 UGH
Seems that route isn't using the subnet mask (8 bit subnet on Class B) to
determine that the 128.174.22 is a separate subnet instead of a host.
A bug? Fixed in later release?
Actually, it's minor brain-death in the way BSD parses addreses. If you
leave dotted numbers out, all but the last set of digits get left
justified in the address, whereas the last digit gets right justified.
Therefore, 10.51 == 10.0.0.51, and 128.174.22 == 128.174.0.22.
If you try:
# route add 128.174.22.0 mygateway 3
you will find this nastiness goes away. And I thought that standard
notation for internet addresses was four dotted digits...
-Philip
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Thu, 04 Feb 88 17:09:37 CET From: HAUPTMAN%DMRHRZ11.BITNET@CUNYVM.CUNY.EDU To: tcp-ip@sri-nic.ARPA Subject: Who knows this Ethernet-board?
Here at University Marburg, Germany we have a bunch of
Siemens PCD (MS-DOS -) computers. Some have a Ethernetboard installed.
We are a bit confused about these Boards. Perhaps these cards
were manufactured by 3COM.
Description:
The boards are labeld: Siemens Ethenet Rev. 2 0
Outside is a sticker by 3COM stating the Ethernetaddress
e.g. 026080-151019. Some of the Chips on the board:
DI 0755-01 8607
SEEQ D0 8001 85344
Sony 5H06 CXK5816P
I've no idea whether these are the relevant chips, they just look most
impressive to me.
On the board is one switch and a chunt block to select between Thinwire
and Tranceiver.
Questions:
1) Where can we get more information about these cards? Low level
interfaces, addreses, registers, interrupts and such.
2) Is this board (software-)compatible to any "well known" card, like
3C501, 3C505, WD8003?
3) We would like to run Novell Netware. Where can we get the drivers?
Thanks,
Klaus Hauptmann HAUPTMAN@DMRHRZ11.BITNET
BIX-Id: msommer
-------
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 18:17:00 GMT From: art@ACC.ARPA To: comp.protocols.tcp-ip Subject: RE: X.25 Call User Data for higher level protocols
>I am in need of the protocol identifiers used in the CALL USER DATA >field of the X.25 CALL REQUEST packet for various higher level >protocols. I believe I know the following information but need to be >able to fill in the blanks. Can anyone help or provide a reference as >to where I might find this data? > >Who supplies these numbers? ISO? I would like to define an ID for a >virtual circuit that includes an extra 16 bit data field that could be >used like the ethernet type field. Has something like this already >been defined? Should I be using 802.2? Comments? > > Protocol Call User Data (byte in hex) > -------- -------------- > > PAD 0x01 > IP 0xCC > ISO IP 0xCD > XNS ?? > PUP ?? > DECNET ?? > Chaos ?? Greg, CCITT defines the high order two bits of the first octet of call user data as follows: 00 - Used for other CCITT recommendations (such as X.29) 01 - Reserved for use by "national" administrative authorities 10 - Reserved for use by international administative authorities 11 - Reserved for arbitrary use between consenting DTEs I believe (they can correct me if I'm wrong) that BBN chose 0xCC and 0xCD for use on the DDN. If you want to establish a standard for use in the Internet I would suggest contacting both DCA and ANSI to see if there is interest. I would appreciate hearing any results you find. Art Berggreen art@acc.arpa ------
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 18:21:52 GMT From: karels@OKEEFFE.BERKELEY.EDU (Mike Karels) To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
Out of curiosity, I just timed an ftp transfer through our 1822 IMP connection (10AM PST, load average 2.5 on a VAX 11/785) and got 9.6Kbytes/s. The same transfer through software loopback ran up to 68Kbytes/s (with more variance due to process scheduling). Note that even when timing TCP transfers on an idle ARPANET over short hops, the round-trip time is higher than when using most local-area networks. Depending on the ack strategy, the TCP transfer rate is limited to something on the order of one window per round-trip time. Thus, failure to reach 56 kb/s through the ARPANET using TCP is not necessarily due only to internal overhead. Mike
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 18:51:34 GMT From: bill@tifsil.UUCP (Bill Stoltz) To: comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms Subject: Pass an open socket to another process????
HELP!
I am looking for information on the feasibility of the following
design on Un*x and other operating systems. I need ideas (how to do this
on _____), comments (you must be nuts, neat idea), or suggestions on how
to solve this problem. I also have a very tight schedule, in that I need
this information by the middle of next week (2/10/88), so I can make a
decision by 2/15/88.
We want to make a decision that is not going to hurt us in the future.
If we move this to a new protocols, or a new operating systems will we
still have the basic functionality to continue with the proposed design,
or will we be stuck with this decision forever.
The need:
We have a server application that handles all incoming requests. The
server needs to pass off these requests to another process to complete
the transaction. The data will come in over the network through something
that works like Berkeley Sockets. We are using an internally developed
protocol and we do not have the option of changing any of the requester
code. It may be possible to change the socket code on the Un*x system.
Current design:
The server currently receives data into shared memory, then sends a short
message to the appropriate application telling in where the data is in shared
memory and lets the application process the data.
This is fine for this application, but it is felt that adding this new
functionality to the server would make it a bottleneck, and it would not be
able to handle new requests.
Trying fork/exec:
Using fork/exec was suggested to handle this problem, but this was
quickly rejected. The reasons given are maintainability of all the pieces,
changes the current design, lack of control and coordination if several
of the same functions are requested at the same time.
The designers plan:
The design that is being pushed is to have the server pass off the
connection (socket) to a non-related, already running process to finish
the transaction. The server must read the first part of the data to determine
which application is to receive the connection. The connection must be
passed off to the non-related process without closing the connection.
The application process must be able to continue communications
with very little interaction between itself and the server, except to say
"here is a new connection, you handle it". The server is then out of the
picture. The application then sends down the data and terminates the
connection. This gives them the control they need and does not make the
server a bottleneck.
The problem:
Can I provide this functionality under Un*x?
What do I need to hack to do this?
Is this supported under other socket implementations?
Is this possible on other operating systems?
Is this going to be available in future products?
I have posted this to several boards, so please send your comments by e-mail.
Thanks for any help or comments. The life you save may be mine.
Bill Stoltz
Texas Instruments
Process Automation Center
P.O. Box 655012, M/S 3635
Dallas, TX 75243
UUCP: {uiucdcs!convex!smu, {rice, sun!texsun}!ti-csl}!tifsie!bill
DECNET: TIFSIE::bill
Voice: (214) 995-2786
-----------[000059][next][prev][last][first]----------------------------------------------------
Date: 4 Feb 88 19:14:51 GMT
From: cheriton@PESCADERO.STANFORD.EDU ("David Cheriton")
To: comp.protocols.tcp-ip
Subject: More PSN 7 End-to-end Comments
I was referred to the 1975 AFIPS NCC paper by Crowthers et al. to understand
better the reasoning behind the current E2E protocol in the ARPAnet.
Here are a few reactions to this paper.
1. The paper argues in several places for something more than imp-to-imp
protocol and concludes that a network-level end-to-end protocol is needed.
However, it seems to me that a higher-level protocol (such as TCP)
would satisfy the reasons for the e2e protocol.
2. The paper is concerned with buffering allocation in the dst. node as
an important feature. However, this concern seems to be based on the
model of reliable comm. from IMP to host and the host being able to flow
control (block) messages/packets from the network. In the current common
environment of IMP connecting to IP gateways which are in turn connected to
much higher-speed local area networks, one might observe that:
i) the IMP/gateway should have no trouble emptying its incoming packets
onto the local network (56Kb to 10Mb).
ii) the communication to the gateway may be reliable, X.25 etc. but
the packet is then typically just tossed out on the Ethernet for
delivery to the host, with some possibility of loss.
This the reliable delivery and flow control to the destination IMP
seems to buy very little, if anything.
3. The paper mentions some discussions of the time suggesting that
some other people felt that end-to-end protocols would be best done in
the hosts, and argues against this. However, most of the arguments seem
to be objecting to TCP/IP style processing in the hosts.
From the current perspective, it seems like unless we want to throw out
TCP style transport-level processing the host, one should really
rethink the value of the network-level e2e protocol.
In general, I conclude that we are carrying a lot of history here. I would
conjecture that a best-efforts network with perhaps some rate-control
mechanism for congestion avoidance would be simpler and faster.
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 19:40:11 GMT From: timk@NCSA.UIUC.EDU (Tim Krauskopf) To: comp.protocols.tcp-ip Subject: question about /etc/route
/etc/route on SunOS 3.3 Am I right that the following entry is taken as a host entry and not a network entry? # route add 128.174.22 mygateway 3 produces a netstat -r -n output: 128.174.0.22 128.174.20.77 UGH Seems that route isn't using the subnet mask (8 bit subnet on Class B) to determine that the 128.174.22 is a separate subnet instead of a host. A bug? Fixed in later release? Tim Krauskopf timk@ncsa.uiuc.edu (ARPA) National Center for Supercomputing Applications 14013@ncsavmsa (BITNET)
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 21:06:23 GMT From: rfox@AMES-NAS.ARPA (Richard Fox) To: comp.protocols.tcp-ip Subject: Re: TCP/IP for Amdahl UTS System V
We currently run a Wollongong package that should meet your needs. I believe the package is a basic bsd 4.2 implementation. We some work we were able to upgrade the software to bsd4.3. rich
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 21:55:10 GMT From: slevy@UC.MSC.UMN.EDU (Stuart Levy) To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
I did try running two TCP connections to our own interface as well as one. If round trip time is the limiting factor, then two TCPs should give better total throughput. But (in the one case I tried, sending 50K bytes to our own net-10 address at 3 AM local time) the total rate actually decreased -- ~ 31 kilobits/s on one connection, ~ 12 kb/s for each of two.
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 22:09:00 GMT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Re: TCP-IP Verification Suite
Date: 2 Feb 88 19:32:51 GMT
From: thumper!karn@faline.bellcore.com (Phil R. Karn)
a) getting rid of gaps and ambiguities in the specs themselves that can
allow different implementations to "conform" yet not be interoperable, and
You forgot (that goes between a and b):
Convincing a vendor that his implementation is broken.
I remember when I was testing the TCP I wrote for Symbolics LispMs. We
were one of the first to use segments with overlapping sequence numbers
in a big way (mostly for telnet). It didn't work with Unix machines.
The response was "Well, Unix is right, so you must be doing something
wrong." We still have this problem with Unix TCP/FTP giving a reply
code for some operation, DELETE I think, that is not what the FTP spec
says it should be. The typical answer from Unix people is "You should
only look at the first digit; the others are secondary information."
And we respond with "The spec says it should return <xyz>." And it goes
'round and 'round.
b) figuring out how to armtwist the vendor of a broken implementation to
fix it once a problem has been identified.
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 22:12:02 GMT From: HAL@SRI-NIC.ARPA (Hal Huntley) To: comp.protocols.tcp-ip Subject: Re: Old articles and RFC
Vint, The RFCs are now kept in their own directory <RFC> and a person can get them by either one of two forms: a) RFC:RFCnnn.TXT b) <RFC>RFCnnn.TXT Where "nnn" is the number of the RFC that you are trying to get (they now go up to four digits long). We think the first way is easier to remember. Hal Huntley/NIC -------
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 22:15:00 GMT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Re: TCP-IP Verification Suite
Date: 2 Feb 88 19:32:51 GMT
From: thumper!karn@faline.bellcore.com (Phil R. Karn)
a) getting rid of gaps and ambiguities in the specs themselves that can
allow different implementations to "conform" yet not be interoperable, and
You forgot (that goes between a and b):
Convincing a vendor that his implementation is broken.
I remember when I was testing the TCP I wrote for Symbolics LispMs. We
were one of the first to use segments with overlapping sequence numbers
in a big way (mostly for telnet). It didn't work with Unix machines.
The response was "Well, Unix is right, so you must be doing something
wrong."
We then got calls from people trying to communicate between our machines
and Apollo. Apollo said "We have no trouble talking to Unix machines."
We still have a similar problem with Unix TCP/FTP giving a reply code
for some operation, DELETE I think, that is not what the FTP spec says
it should be. The typical answer from Unix people is "You should only
look at the first digit; the others are secondary information." And we
respond with "The spec says it should return <xyz>." And it goes 'round
and 'round.
I'm not saying we don't occaisionally pass the buck without looking; I'm
just relaying anecdotes of how difficult things can be.
b) figuring out how to armtwist the vendor of a broken implementation to
fix it once a problem has been identified.
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 88 22:21:54 GMT From: zjat02@apctrc.UUCP (Jon A. Tankersley) To: comp.protocols.tcp-ip Subject: Re: Who sells TCP/IP for AT&T 3B2/300's?
Wollagong sells some or AT&T does. It's expensive. ($6500 over a year ago.) It works. -tank-
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 01:08:58 GMT From: philipp@GMUVAX2.GMU.EDU (Philip Prindeville) To: comp.protocols.tcp-ip Subject: MX/Sendmail on Ultrix
Has anyone had any experience with porting the MX/sendmail to Ultrix? I'm using it with the BIND 4.7.2 resolver, and I'm getting some funky core dumps. Any ideas? -Philip
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 01:16:19 GMT From: HAUPTMAN@DMRHRZ11.BITNET To: comp.protocols.tcp-ip Subject: Who knows this Ethernet-board?
Here at University Marburg, Germany we have a bunch of
Siemens PCD (MS-DOS -) computers. Some have a Ethernetboard installed.
We are a bit confused about these Boards. Perhaps these cards
were manufactured by 3COM.
Description:
The boards are labeld: Siemens Ethenet Rev. 2 0
Outside is a sticker by 3COM stating the Ethernetaddress
e.g. 026080-151019. Some of the Chips on the board:
DI 0755-01 8607
SEEQ D0 8001 85344
Sony 5H06 CXK5816P
I've no idea whether these are the relevant chips, they just look most
impressive to me.
On the board is one switch and a chunt block to select between Thinwire
and Tranceiver.
Questions:
1) Where can we get more information about these cards? Low level
interfaces, addreses, registers, interrupts and such.
2) Is this board (software-)compatible to any "well known" card, like
3C501, 3C505, WD8003?
3) We would like to run Novell Netware. Where can we get the drivers?
Thanks,
Klaus Hauptmann HAUPTMAN@DMRHRZ11.BITNET
BIX-Id: msommer
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: Fri, 05 Feb 88 09:47:12 -0500 From: Craig Partridge <craig@NNSC.NSF.NET> To: slevy@uc.msc.umn.edu Cc: mills@udel.edu, tcp-ip@sri-nic.ARPA Subject: re: PSN 7 End-to-End question
Stuart,
Two TCP connections run in parallel are not guaranteed not to affect
each other. Van Jacobson can show you interesting graphs which show
TCP connections fighting with each other for bandwidth.
Craig
-------
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 02:49:23 GMT From: slevy@UC.MSC.UMN.EDU (Stuart Levy) To: comp.protocols.tcp-ip Subject: Re: question about /etc/route
You seem to need to say route -n add ... in which case it's forced to consider it a network route.
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 03:10:35 GMT From: karn@THUMPER.BELLCORE.COM (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: TCP-IP Verification Suite
I agree with you except for the part where you place all of the blame for the FTP problem on UNIX. The specs say that you should be conservative in what you send, liberal in what you accept. So in the case of the FTP reply code, you're *both* at fault -- UNIX for not generating the correct code, your code for not looking at just the first digit. Phil
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Feb 88 09:14:38 CST From: timk@ncsa.uiuc.edu (Tim Krauskopf) To: tcp-ip@sri-nic.arpa Subject: answer about /etc/route
Thanks to all who replied. I received several messages which reminded me that 128.174.22 is interpreted as 128.174.0.22 if you don't specify that the last part is 0 or use a trailing period. This doesn't help. Entering 128.174.22.0 produces a UGH (host) entry in the table because it still doesn't take it as a network address, only a host address. True for SunOS 3.3, I don't know about 4.3BSD. Stuart Levy wins the prize for the correct answer -- Special thanks. # route -n add 128.174.22.0 mygate 3 works because the undocumented (not on my man page) option of -n forces the address to be a network entry. Maybe the documentation is buried in the update pages for SunOS 3.3 or is in the 4.3 documentation. Tim Krauskopf timk@ncsa.uiuc.edu (ARPA) National Center for Supercomputing Applications 14013@ncsavmsa (BITNET) -------
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 03:28:52 GMT From: bzs@BU-CS.BU.EDU (Barry Shein) To: comp.protocols.tcp-ip Subject: question about /etc/route
I think you want to change: # route add 128.174.22 mygateway 3 to # route add 128.174.22.0 mygateway 3 The parsing routine is pretty dumb, give it all four octets. Also, last I looked it doesn't matter what you pass for that last integer (3), it's just checked for 0 or not 0 (or if it's not there at all.) I assume this may change in the future (note: the original question was specific to Sun/OS, your mileage may vary.) -Barry Shein, Boston University
-----------[000074][next][prev][last][first]----------------------------------------------------
Date: 5 Feb 88 04:04:48 GMT
From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To: comp.protocols.tcp-ip
Subject: Re: question about /etc/route
Am I right that the following entry is taken as a host entry and not
a network entry?
# route add 128.174.22 mygateway 3
produces a netstat -r -n output:
128.174.0.22 128.174.20.77 UGH
Seems that route isn't using the subnet mask (8 bit subnet on Class B) to
determine that the 128.174.22 is a separate subnet instead of a host.
A bug? Fixed in later release?
Actually, it's minor brain-death in the way BSD parses addreses. If you
leave dotted numbers out, all but the last set of digits get left
justified in the address, whereas the last digit gets right justified.
Therefore, 10.51 == 10.0.0.51, and 128.174.22 == 128.174.0.22.
If you try:
# route add 128.174.22.0 mygateway 3
you will find this nastiness goes away. And I thought that standard
notation for internet addresses was four dotted digits...
-Philip
-----------[000075][next][prev][last][first]----------------------------------------------------
Date: 5 Feb 88 04:07:56 GMT
From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To: comp.protocols.tcp-ip
Subject: (none)Mumble. Sorry about that. Mailer burped on the first try... -Philip
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 04:14:37 GMT From: guyton%condor@RAND-UNIX.ARPA To: comp.protocols.tcp-ip Subject: Re: question about /etc/route
> # route add 128.174.22 mygateway 3 > > produces a netstat -r -n output: > > 128.174.0.22 128.174.20.77 UGH You need to add the trailing zero: # route add 128.174.22.0 mygateway 3 -- Jim
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 1988 10:39:57 CST From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: AFDDN.TCP-IP@GUNTER-ADAM.ARPA Subject: SLIP for Ultrix
Forgive if this was posted and I missed it. We have a uVAX running Ultrix that I would "like" to have SLIP on. Is such a beastie available? I saw the postings for UNIX, but not being a Unix or Ultrix wizard, I don't know how compatible the two really are. Any Ultrix wizards out there know about SLIP?? Thanks in advance, Darrel Beach -------
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Feb 88 10:16:54 est From: John Swanson <swanson@EDN-VAX.ARPA> To: tcp-ip@sri-nic.arpa, thumper!karn@faline.bellcore.com Subject: Re: TCP-IP Verification Suite
Phil, Having helped produce the verification suite for DoD I can't keep quiet any longer. I think you are confusing the tools with their usage. First I wonder how much detailed thought went into the ad-hoc testing you are talking about. Are the authors concerned with compliance to the standards or "getting their Problem fixed". When we examined the specifications for each protocols we documented those descrepancies for DCA and asked for clarification and factored any response into the test suite. Obviously since the verification suite is a tool I doubt if it can twist anyones arm. However, if a vendor is required to pass the verification suite of tests perhaps there would not be as many "broken" implementations. Therefore I would think those people who really want testing would be trying to support the NVLAP process the Government is trying to start up, rather than reinvent the testing wheel. John
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 06:13:40 GMT From: nomad@mist.cs.orst.edu (Lee Vincent Damon) To: comp.protocols.tcp-ip Subject: Re: Help...looking for network anecdotes
Here's one. Someone was looking for anecdotes on how the I-net was
used, so they posted a message to a group called comp.protocols.tcp-ip
asking for them. With in days they had 5 very good responces (6?).
I know of lots of cases like that. Mailing lists and news, while they
could all be UseNet/UUCPed, are helped tremendously by the I-net, and they
in turn help speed the flow of information. Comp. Sci. at Oregon State
(CS.ORST.EDU) would be very much hampered w/o them, that is for sure.
nomad
---------------------
Lee Damon Internet: nomad@cs.orst.edu
nomad UUCP : {hp-pcd,tektronix}!orstcs!nomad
FidoNet: 152/201 (The Castle) - (503) 757-8841
Alt. UUCP: ...!orstcs!castle!nomad (A FidoNet gateway)
aliases: hostmaster, hpsysop, support, root
"Say what you like, the bicycle has a great past ahead of it!"
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Feb 88 16:21:47 EST From: beh@monk.proteon.com (Brian Hackley) To: tcp-ip@sri-nic.arpa Subject: TCP/IP Support for VRTX Operating System
HELP! One of our customers has been asking for support of TCP/IP under the VRTX Operating System (A modular operating system for VME/68020 systems). If you know of a source for TCP/IP under VRTX, please respond as soon as you can. Also, anyone hear of an outfit in Edinburgh, Scotland called Spider Systems? Brian E. Hackley Proteon Inc.
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 1988 17:04-EST From: CERF@A.ISI.EDU To: LYNCH@A.ISI.EDU Cc: Mills@LOUIE.UDEL.EDU, thumper!karn@FALINE.BELLCORE.COM, tcp-ip@SRI-NIC.ARPA Subject: Re: PSN 7 End-to-End question.
Dan, Bob Kahn and I got about 42 kb/s on stress tests of the ARPANET in its early stages. In later years, there was more code in the IMP and it slowed down some. But then came end/end protocols like TCP and, depending on the delay, I seem to recall we managed ony about 35 kb/s through a single IMP, less if many hops were involved. As to Lenny Kleinrock's 37%, that is 1/e and is the kind of result you get with multi-access links - and even then, that number did not guarantee stability (the packet satellite protocols demonstrated that when running ALOHA style). Vint
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 13:24:54 GMT From: brian@ucsd.EDU (Brian Kantor) To: comp.protocols.tcp-ip Subject: X.25 to Milnet PSN problems - the continuing saga
A few weeks ago I mentioned here that we're having a problem with the Milnet IMP we're connected to being completely unable to open X.25 virtual circuits to us, so only those VCs that we open to it will allow data to pass to mailbridges and other hosts on the milnet. We're still having the problem, and I wonder if anyone else has seen this happening on their host? Misery loves company, maybe? Our interface is an ACC6250 board (in a VAX780 4.3BSD), and the people at ACC (especially Lars Poulson) have been extremely helpful in attempting to get this problem resolved, but so far it isn't. I'm told that a trace in the PSN code shows that the IMP wasn't even trying to open the circuit to us, so it's probably in or related to the PSN code and not the interface - especially since it just started happening without us making and hardware or software changes. It DID start around the time the Arpanet cut over to PSN-7, but we're on the Milnet. We're currently running a process that sends a single ping packet to each of the Milnet mailbridges once every 45 seconds to ensure that the X.25 VC stays open so that traffic will find an already-open VC instead of blocking because it can't open one of its own. Now that I've finished crying on your collective shoulders (waah), I'm wondering if anyone else has seen any evidence of this happening to them? I have trouble believing we've been singled out for this dubious honor. Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA brian@ucsd.edu ucsd!brian BRIAN@UCSD
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 13:55:52 GMT From: sanand@radha.UUCP (Sanand Patel) To: comp.protocols.tcp-ip Subject: RE: TCP/IP Performance
For the gentleman, and others who may be interested in published papers:
"User-Process Communication Performance in Networks of Computers",
Cabrera, Hunter, Karels, Mosher.
in: IEEE Transactions on Software Engineering, Jan 1988, pg 38.
--- sanand@HUB.TORONTO.EDU
--- {uunet!mnetor, lsuc, dciem}!radha!sanand
--- 416-756-4100
--
---
--- sanand@hub.toronto.edu
--- UUCP: {uunet!mnetor, lsuc, dciem}!radha!sanand
--- 416-756-4100
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 14:47:08 GMT From: mminnich@UDEL.EDU (Mike Minnich) To: comp.protocols.tcp-ip Subject: Re: question about /etc/route
> # route add 128.174.22 mygateway 3 > produces a netstat -r -n output: > 128.174.0.22 128.174.20.77 UGH You need to force the interpretation of 128.174.22 as a network address rather than as a host address. Do this by using the keyword "net" in front of 128.174.22: route add net 128.174.22 mygateway 3 The manual page in Sun/OS 3.4 (and I suspect 3.3 as well) for /etc/route does not explain this -- it seems to be out of sync with the installed binary. mike
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 14:47:12 GMT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: re: PSN 7 End-to-End question
Stuart,
Two TCP connections run in parallel are not guaranteed not to affect
each other. Van Jacobson can show you interesting graphs which show
TCP connections fighting with each other for bandwidth.
Craig
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 15:16:54 GMT From: swanson@EDN-VAX.ARPA (John Swanson) To: comp.protocols.tcp-ip Subject: Re: TCP-IP Verification Suite
Phil, Having helped produce the verification suite for DoD I can't keep quiet any longer. I think you are confusing the tools with their usage. First I wonder how much detailed thought went into the ad-hoc testing you are talking about. Are the authors concerned with compliance to the standards or "getting their Problem fixed". When we examined the specifications for each protocols we documented those descrepancies for DCA and asked for clarification and factored any response into the test suite. Obviously since the verification suite is a tool I doubt if it can twist anyones arm. However, if a vendor is required to pass the verification suite of tests perhaps there would not be as many "broken" implementations. Therefore I would think those people who really want testing would be trying to support the NVLAP process the Government is trying to start up, rather than reinvent the testing wheel. John
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 15:54:12 GMT From: jas@MONK.PROTEON.COM (John A. Shriver) To: comp.protocols.tcp-ip Subject: question about /etc/route
Classically, /etc/route (in most implmentations I have dealt with) discerns the difference between hosts and routes not on the basis of address, but on the basis of whether the NAME you give is in the file /etc/networks. This is a rather tricky little gotcha, and barely documented. This may not be the case anymore in SunOS 3.3. (It certainly caught be with WIN/VX 2.3.) Also, I beleive Sun has noted problems with subnet routes with /etc/routed in 3.3, as noted in the Sun Technical Bulletin. There may be a patch tape, or it may be fixed in a higher release.
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 16:39:57 GMT From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To: comp.protocols.tcp-ip Subject: SLIP for Ultrix
Forgive if this was posted and I missed it. We have a uVAX running Ultrix that I would "like" to have SLIP on. Is such a beastie available? I saw the postings for UNIX, but not being a Unix or Ultrix wizard, I don't know how compatible the two really are. Any Ultrix wizards out there know about SLIP?? Thanks in advance, Darrel Beach -------
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 18:54:32 GMT From: sma@GVAX.CS.CORNELL.EDU (Susan Armstrong) To: comp.protocols.tcp-ip Subject: Re: C binding interfaces for TCP/IP
Uh, Sun RPC may be widespread, and it may be a peachy protocol, but it was not "first". Xerox's Courier was published and used before Sun RPC was ever conceived.
Cheers,
Susie Armstrong
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 18:59:37 GMT From: jru@etn-rad.UUCP (John Unekis) To: comp.protocols.tcp-ip Subject: XE520 tcp-ip
Has anyone seen or heard of tcp-ip for the UNISYS (formerly burroughs) megaframe (XE520) . Does it run under BTOS or UNIX? Where can I get it ? Any help is appreciated. Thanks in advance ihnp4 or voder!wlbr!etn-rad!jru
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 20:18:28 GMT From: rcoltun@GATEWAY.MITRE.ORG (Robert Coltun) To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
We have a version of ping that transmits packets based on the ARPANET
1822 interface considerations: number of outstanding rfnms for the
destination and the total in the output queue. Ping (in its original
form) is excellent for looking at IP delays but it is difficult to get
to actual throughput using it. With the interface scanner, which is based
on netstat -h, we can send packets out as fast as the net can take them;
the transmitter can be throttled by a rfnm high-water mark and a high-water
mark of total packets in the output queue.
Our definition of throughput is:
total # bits sent/(time of last received - time of first received)
Our previous delay tests showed delay and variance of delays increasing
as the number of PSN hops increase. We tried the new tests for 3, 4, and
5 (minimum) PSN hops sending bursts of 30 512 byte packets out.
The results of these test are preliminary and much work is still
need to draw any real conclusions. The results of the 3 hop case ranged
from 35Kb to 16Kb averaging around 23Kb. A rfnm high-water mark of <= 2
seemed to give us the best throughput values as well as the lowest rtt
delays for this case. The 4 hop case worked well with a 2 rfnm high-water
mark (best throughput was around 28Kb); 5 PSN hop case worked well with a
5 rfnm high-water mark (best throughput was around 22KB).
I too have seen low FTP transmission times. If these tests are
an indication of subnet throughput, where has all the throughput gone?
--- Rob Coltun
The MITRE Corporation
rcoltun@gateway.mitre.org
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 22:04:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question.
Dan, Bob Kahn and I got about 42 kb/s on stress tests of the ARPANET in its early stages. In later years, there was more code in the IMP and it slowed down some. But then came end/end protocols like TCP and, depending on the delay, I seem to recall we managed ony about 35 kb/s through a single IMP, less if many hops were involved. As to Lenny Kleinrock's 37%, that is 1/e and is the kind of result you get with multi-access links - and even then, that number did not guarantee stability (the packet satellite protocols demonstrated that when running ALOHA style). Vint
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 88 22:17:18 GMT From: Z3000JD@AWITUW01.BITNET To: comp.protocols.tcp-ip Subject: Installation of an Excelan EXOS 225 Card on Toshiba AT
I have an Excelan EXOS 225 Card (LanAnalyser) which I want to install
on a Toshiba T3200 AT.
When I jumper the Cache-Memory of the EXOS-Board to Addresses
8000, 9000 it does not work, because there is the normal memory
B000 it does not work, because there is the Display memory
A000 I get a PARITY ERROR 2 during Power-on Selftest of
the Toshiba.
Does anyone now,
what the PARITY ERROR 2 on the Toshiba means,
has already installed such a board on a Toshiba PC (this one?)
and what jumper-setting he has used,
has any Idea what to do.
Johannes Demel,
Technical University Vienna
Z3000jd@awituw01.bitnet
P.S. The card works on a XT-clone and another AT-clone.
I have already tested using IRQ 2 and 3, and different
IO-Base-addresses (300,310,320,360). Nothing helps
to remove the Parity Error.
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 88 05:06:24 GMT From: brian@wb6rqn.UUCP (Brian Lloyd) To: comp.protocols.tcp-ip Subject: Re: TCP-IP Verification Suite
Phil,
Although a protocol test suite is not perfect, it will tend to catch
errors before the software is released (hopefully). Perhaps this will
reduce the amount of ad-hoc testing required. I agree with you that
there is no test like trial-by-fire but perhaps the VS can shake out the
more flagrant bugs ahead of time.
In any case, I have a feeling that your stuff will get tested against
the suite anyway.
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 88 10:11:20 GMT From: sunny@hoptoad.uucp (Sunny Kirsten) To: comp.protocols.tcp-ip Subject: Re: Who knows this Ethernet-board?
These sound very much like the original 3-Com Ethernet board for
IBM-PC... so I'd suggest contacting 3-Com, who are on the uucp net.
If you can't find them in your uucp maps, let me know and I'll
chase down an e-mail address, a physical address, or phone number
for you.
The SEEQ 8001 chip was not used in very many designs, but it was
one of the earliest available. I don't know if 3-Com has a newer
design out (they probably do), but their original IBM-PC board
was the first to use the SEEQ-8001.
Sunny
--
Sunny Kirsten, Astral Consultants (415)457-7555 (voice)
233 Humboldt St., San Rafael, CA 94901 GEnie: astral (415)457-7705 (modem)
USENET: {amdahl,frog,ihnp4,lll-crg,nsc,ptsfa,pyramid,sun,ucsfcgl,well}
!hoptoad!astral!sunny
-----------[000096][next][prev][last][first]----------------------------------------------------
Date: 6 Feb 88 19:24:13 GMT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: TCP/IP Support for VRTX Operating SystemSpider Systems has been around a while, but I don't know exactly how long. Products that I know they offer include a Sys V Streams TCP/IP in source form, the "SpiderMonitor", a hardware-based Ethernet analyzer which is (or at least was) sold in the US by CMC, and a version of our TCP/IP for the IBM PC. I believe they have also done contract development of code in the U.K. and Europe. Their address is: Spider Systems 65 Bonnington Rd. Edinburgh EH6 5JQ tel: 031-554 9197 I believe they also can be reached via UUCP as ...mcvax!spider!... James B.VanBokkelen FTP Software Inc.
-----------[000097][next][prev][last][first]----------------------------------------------------
Date: 6 Feb 88 19:36:59 GMT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: SLIP for UltrixWe got binary modules from a co-operative DEC support office (of course, we're on our own for setup and if it breaks). It is going to be quite difficult, if not impossible, for you to add it without either source, or help from someone who has source. We are using Ultrix 2.0 on a Microvax, and the SLIP line is our link to the ARPAnet. Seems to work ok, even when used as a router from our local ether to the wide world. James VanBokkelen FTP Software Inc. jbvb@vax.ftp.com
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 88 19:54:33 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: SUN Serial Line Interface
With all the discussions in this forum concerning Sun Workstations, perhaps someone can answer a question concerning serial line interfaces for the Sun. We have a LAN with, among other workstations, Sun Workstations which must be interfaced to a secure network over a synchronous serial channel using DDCMP 4.0 as the data link protocol which must be capable of supporting, at least, a 9600 baud circuit. We would like to use a Sun Workstation to interface to the secure network. Sun marketing types indicate that there is no such interface available. Is this an accurate statement? Are there any synchronous serial line interfaces that can be used and are there drivers available? It would be preferable to have the DDCMP 4.0 implementation on the board and to be compatible with the DEC DMR11 implementation but not absolutely necessary. Thanks in advance, Merton Campbell Crockett EATON Information Management Systems AN/GYQ-21(V) Program mcc@etn-wlv.EATON.COM
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 88 20:30:46 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: TCP/IP Protocol Testing Laboratory Program
Well, It looks like there is a chance that we will get to have some official testing labs for the TCP/IP protocols suite if those interested in seeing it come about read the following information carefully and supply their comments to the appropriate parties named below. It is important that users and vendors make their desires known to those who are empowered to establish this testing program. We all know it is " bit late in coming" but as TCP/IP spreads even farther into the world it is important to many that those implementations be wrung out against some test before the products are brought to market. I have extracted the following from the Federal Register (what ever that is!) and urge you to "vote". Dan Federal Register/ Vol 52, No. 232/ Thursday December 3, 1987 National Bureau of Standards (Docket No. 71156-7256) National Voluntary Laboratory Accreditation Program: Defense Department Communications Protocols AGENCY: National Bureau of Standards, Commerce. Action: Notice: Request for Comments SUMMARY: The National Bureau of Standards (NBS) has received a request to establish a laboratory accreditation program under the procedures of the National Voluntary Accreditation Program (NVLAP) (15 CFR Part 7). In a letter dated October 27, 1987, the Defense Communications Agency (DCA) Defense Communications Engineering Center requests NBS to establish a program to accredit laboratories that test the computer industry's implementations of communications protocols used by the Department of Defense. A copy of the DCA letter is appended to this notice. Announcement of this request and of the NBS request for comments with respect to the need for this program is being made under para 7.13(d) of the referenced procedures. DATE: Comments should be received at the addresses below on or before February 1, 1988. (They will still take comments, no sweat...) ADDRESSES: Persons desiring to comment on the need for such a program are invited to submit their comments in writing to Captain Steven Skipper, DCEC, Code R620, 1860 Wiehle Avenue, Reston, Va. 22090. A copy of such comments should be sent to the Associate Director for Industry and Standards, National Bureau of Standards, ADMIN A603, Gaithersburg, Md. 20899. For Further Information Contact: Harvey W. Berger, Manager Laboratory Accreditation, National Bureau of Standards, ADMIN A527, Gaithersburg, Md. 20899 (301) 975-4017. Supplementary Information: NVLAP Accreditation NVLAP is a voluntary system for accrediting laboratories found competent to perform specific testing operations. Competence is defined as a laboratories ability to meet the NVLAP criteria and technical requirements of the test methods for which it seeks accreditation. NVLAP accreditation does not confer or imply certification of products or test date. Scope of LAP The scope of this program is set forth in the [un]appended letter from the Defense Communications Agency (DCA). The program will address (A) Defense Data Network (DDN) X.25 Link and Network Layer protocols as specified in the DCA DDN X.25 Host Interface Specification; (B) the five DoD packet switching High Level protocols (HLP): (1) Internet Protocol (IP), MIL_STD 1777; (2) Transmission Control Protocol (TCP), MIL-STD 1778; (3) File Transfer Protocol (FTP), MIL-STD 1780; (4) Simple Mail Transfer Protocol (SMTP), MIL-STD 1781; and (5) TELNET, MIL-STD 1782, and (C) the AUTODIN Mode I protocol testing. Laboratories may be accredited for testing one or more of the protocol types. Procedures Following Receipt of Comments: After 60 days comment period, DCA will evaluate all comments pertaining to the need for the proposed program. Upon completion of that evaluation and further consultation with NBS, interested persons (those who submit comments or request to be placed on the NVLAP mailing list) will be notified of the decision by the Director of NBS whether NBS will proceed with the development of this program. NBS plans to coordinate this matter with DCA. Documents in Public Record All comments in response to this notice will be made part of the public record and will be available for inspection and copying at the NBS NVLAP office. Administration Building, Room A531. Gathersburg, Maryland. -------
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 88 22:23:13 GMT From: chris@GYRE.UMD.EDU (Chris Torek) To: comp.protocols.tcp-ip Subject: Re: TCP-IP Verification Suite
>Although a protocol test suite is not perfect, it will tend to catch >errors before the software is released (hopefully). On the other hand, it can also induce the `well we passed the protocol test suite so if it fails to work it must be your fault' syndrome. I think the only cure for this is to state clearly that an implementation must not only pass the verification tests, but also interoperate with other such implementations, and that the end users reserve the right to change the test suite as needed and retest. >Brian Lloyd, President >Sirius Systems, Inc. Share and enjoy, Share and enjoy, Journey though life with a plastic boy Or girl by your side, Let your pal be your guide. . . . (sorry) Chris
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 88 02:08:39 GMT From: melohn@SUN.COM (Bill Melohn) To: comp.protocols.tcp-ip Subject: Re: SUN Serial Line Interface
Sun sells no such interface; we support DECnet as an Ethernet end-node only, and the sync drivers we sell do HDLC, SLDC, and Bisync using the Sun CPU serial port, or optionally a Sunlink comm processor board. Assuming you are planning on doing DDCMP with a DEC host of some kind, I would imagine that it is possible to get a DMR11 driver from DEC that supports HDLC (probably with X.25). I would think you would find it easier to talk to many systems (including Suns) if you used industry standard sync protocols such as HDLC.
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 88 03:03:23 GMT From: bzs@BU-CS.BU.EDU (Barry Shein) To: comp.protocols.tcp-ip Subject: SUN Serial Line Interface
I think I went around that circle a few years ago with DMR-11s. As I remember they support DDCMP in on-board microcode and only DDCMP (it starts doing it as soon as you enable.) You could only hook the other end of a DMR up to either another DMR or a DUP-11 (truly raw sync port) which had software pumping DDCMP through it, or possibly a similar hookup using the sync port on a DMF32, same difference, ya gotta have DDCMP. I suppose that's the answer for that person, get something like a DMF32, DUP-11 or a DV-11 (no, no, you don't really want one of those) and some HDLC software etc but I can't tell from their posting what their real situation is, are they committed to a DMR11 or was that an idle comment about a possible board to purchase? What are they *really* trying to do etc.? Sounds like they'd be better off locating a SLIP implementation for both ends if they're only after a 9600b hookup, a DMR is mostly overkill (unless you happen to have one.) -Barry Shein, Boston University
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 88 16:04:38 GMT From: hassler@NAP1.ARPA (Barry D. Hassler) To: comp.protocols.tcp-ip Subject: Dynamic routing support for Wollongong WIN/TCP
Is anyone aware of any dynamic routing programs for Wollongong's WIN/TCP running under VAX/VMS? According to Wollongong, they will support something like the UNIX 'routed' (RIP protocol) in release 3.2 (due out "in a couple of months"), but until that time, I'm out of luck. We have several networks with multiple redundant gateways and LOTS of VMS machines running the Wol- longong software. Unfortunately, right now these machines don't have any way to fall back to alternate routes should one die. Any leads anyone can offer would be greatly appreciated. Thanks, Barry D. Hassler Control Data Corp
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 88 16:07:13 GMT From: bobj@MCL.UNISYS.COM (Bob Jones) To: comp.protocols.tcp-ip Subject: DCA Protocol Lab Test Tools
I recently saw a message from Hal Peterson at Cray (hrp%ishmael.cray.com @uc.msc.umn.edu) regarding the DCA protocol laboratory test tools which were being beta tested and Cray submitted to those tests. I have just one rebuttal to a comment made by Hal. The tests themselves do not take a significant amount of time to run. On the contrary, the complete protocol suite can be tested fully in one or two days - providing the remote drivers are working properly and the network is not giving us problems. We do have direct dial up to the facility also. The problem that Hal alluded to in terms of time is really that of trying to correct the bugs found and being retested. That is what took so long. If the drivers are working and net is ok, the following times are generally common for testing the protocols: TCP - 2 hours IP - 6 hours (this is being reduced to approx 2 hours) FTP - 1 hour Telnet - 1 hour SMTP - 1 hour I want to reiterate that this is the actual testing time and not the attempts to go off and correct problems and come back up for testing. bobj
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 88 18:46:21 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: DCA Protocol Lab Test Tools
Bob, Holy Cow. If the network is okay almost anything will work, even ISOspeak. What you want to know is how the implementations work when the net ISN'T okay, when the remote drivers are buggy and at arbitrary times during the day when packets are falling off the Earth and so forth. I would give the okay-network test only a Journeyman Certificate, hardly more worthy that an Ethernet Certificate. The heavy dudes claim Mailbridge Certificates and the real wowsers claim the most exclusive of all, the NSFNET Medal. Dave
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 88 19:25:53 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: SUN Serial Line Interface
Barry, Bill, et. al.: You're recollection of the operational characteristics of the DMR11 is accu- rate. It starts transmitting START messages as soon as it is initialized at either 1 or 3 second intervals depending upon the initialization parameters. The basic problem is that a DIA approved "black box" will be inserted into the serial link between the network node and the LAN which was developed, unfortunately, with the assumption that a DMR11 would be present at both ends of the serial link. The "black box" uses a Simpact IPC 1622 to interface to the communication link using a DMR11 DDCMP 4.0 compatible prtocol implement- ation. Merton Campbell Crockett EATON Information Management Systems AN/GYQ-21(V) Program mcc@etn-wlv.EATON.COM
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 88 20:18:06 GMT From: bobj@MCL.UNISYS.COM (Bob Jones) To: comp.protocols.tcp-ip Subject: Re: DCA Protocol Lab Test Tools
Dave, thanks for comments. The test system is robust enough to recover from net-induced perturbations. Thats not a real problem. What has happened from our experience is that we spend a lot, (lots!) of time doing recoveries and not getting on with real testing. Also the test system has a rather extensive corruption capability to test the implementations without the network adding to the pot. I believe we can claim the Mailbridge Certificate. The NSFNET Medal? I refuse to die on my sword. bobj
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 88 20:50:00 GMT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Re: C binding interfaces for TCP/IP
Date: Fri, 5 Feb 88 13:54:32 EST
From: sma@gvax.cs.cornell.edu (Susan Armstrong)
Uh, Sun RPC may be widespread, and it may be a peachy protocol, but it
was not "first". Xerox's Courier was published and used before Sun RPC
was ever conceived.
Not only was it not first, it wasn't even third: The ITS MLDEV protocol
is an RPC-like protocol (MIT AI lab, late 60's or early 70's), and it
existed before there were 68000s, let alone companies building products
based on 68Ks. Chaos QFILE is a richer RPC protocol (MIT AI lab, late
70's?).
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 88 23:29:48 GMT From: torben@dorsai.ics.hawaii.edu (Prof. Torben N. Nielsen) To: comp.protocols.tcp-ip Subject: Re: SLIP for Ultrix
In article <8802060858.AA08978@ucbvax.Berkeley.EDU> AFDDN.TCP-IP@GUNTER-ADAM.ARPA writes: >We have a uVAX running Ultrix that I would "like" to have SLIP on. Is such >a beastie available? I saw the postings for UNIX, but not being a >Unix or Ultrix wizard, I don't know how compatible the two really are. >Any Ultrix wizards out there know about SLIP?? Can't claim to be an Ultrix wizard, but I seem to recall Fred Avolio of the Ultirx Group at DEC posting a message saying that he did have SLIP for Ultrix. I took a look at an Ultrix system at one time and kind of came to the conclusion that trying to do it yourself to a binary Ultrix distribution was no fun. ---Torben
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 13:41:00 PST From: "Jerry Scott" <jerry@twg.arpa> To: "hassler" <hassler@nap1.arpa> Cc: <tcp-ip@sri-nic.arpa> Subject: RE: Dynamic routing support for Wollongong WIN/TCP
Release 3.2, due in March or April will support GATED version 1.3.1. It is currently being beta tested at several sites. Once we feel the version is solid it will be made available via anonymous ftp to host twg.arpa. Regards, Jerry -------
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 13:59:00 PST From: <art@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: protocol verification
With the recent discussion about TCP testing and verification, I thought that I would pass on an observation. I don't know if this reflects on just the specific instances or protocol testing in general. I was involved with GM in testing of MAP protocols for Autofact '84 and '85. Both times, all of the vendors eventually were able to successfully pass the conformance test suite. When interoperability testing began, MOST of the vendors found problems affecting interoperability. On other occasions, I have seen systems working on real networks fail conformance tests and systems which passed the conformance tests fail on the real network. I feel that this probably stems from a tendency by the test writer(s) to concentrate more on the protocol details (such as which diagnostic error code should be returned), than on the basic functionality of the protocol. The protocol writer may then end up spending effort just trying to make the test suite happy at the expense of a robust design. Art Berggreen art@acc.arpa ------ -------
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 11:32:54 GMT From: hd@philtis.UUCP (Henk D. Davids @ MSD) To: comp.protocols.tcp-ip Subject: telnet performance
At our site we have serious performance problems when using telnet - character echo sometimes takes more than 20 seconds even when the cpus involved are lightly loaded. Is there anyone who has the same experience, or maybe even an explanation? Our situation is as follows: we are running Excelan TCP/IP on VAX/VMS, to Scald workstations running Unix. These are stations for circuit design made by Valid. Telnet from one of the Scalds to another one is not that fast either, but not nearly as slow as from the VAX to a Scald. Any input will be appreciated.
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 13:33:25 GMT From: mtune!codas!usfvax2!pdn!larry@rutgers.edu (Larry Swift) To: tcp-ip@sri-nic.arpa Subject: bounced mail to Jim Baldo
Jim: I tried to respond to your last e-mail, but it got bounced and I
no longer have your original address. Please send again.
Larry Swift UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207 Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981
-------
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 14:11:22 GMT From: LYMAN_CHAPIN@ICE9.CEO.DG.COM To: comp.protocols.tcp-ip Subject: IP-level echo/ping
In <[A.ISI.EDU] 2-Feb-88 21:23:38.CERF>, Vint Cerf writes: > In the absence of anything else, your proposal seems the only option; > is there really no thinking in the ISO standards for some kind of > echo packet capability at the IP level? Vint, DG brought a proposal for just such a beast to the joint ANSI/IETF meeting at BB&N last April (or thereabouts), at which it received a cool (silent) reception. We intend to re-introduce it at an ANSI meeting in three weeks. We're proposing to put pinging at the IP level, but not IN the IP (making IP more complicated - read "more prone to break" - so that you can poke around diagnostically when you suspect that something IS broken has never impressed me as a great idea). A separate ECHO protocol, which looks a lot like IP (similar packet format; packets are processed by gateways [almost] exactly like IP packets), gives you the diagnostic tool without piggybacking stuff onto IP that doesn't belong there. ECHO can also contain more elaborate diagnostic functions that you would probably not want to add to IP source routing, such as having each gateway along the path return a diagnostic packet to the source (I would have said "NEVER want to add" rather than "probably not want to add", but have recently talked with two people who think that adding this capability to source routing would be really neat.....). If the ECHO proposal finds favor at the ANSI meeting, I'll distribute it to the list for comment. ----------------------------------------------------------------------------- Lyman Chapin lyman@ice9.ceo.dg.com Data General Corp. [lyman%ice9.ceo.dg.com@relay.cs.net] (617) 870-6056 -----------------------------------------------------------------------------
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 14:16:28 GMT From: larry@pdn.UUCP (Larry Swift) To: comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms Subject: Re: Pass an open socket to another process????
In article <291@tifsil.UUCP> bill@tifsil.UUCP (Bill Stoltz) writes:
>I have posted this to several boards, so please send your comments by e-mail.
Bill,
I, and I suspect many others, are interested in any replies you get.
Could you post a summary?
Larry Swift UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207 Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 15:24:40 GMT From: brian@wb6rqn.UUCP (Brian Lloyd) To: comp.protocols.tcp-ip Subject: TCP/IP for Unisys (Burroughs) XE-520
We have TCP/IP for the B-20 and XE-500 product lines. Please contact me
for further information.
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 17:31:09 GMT From: jbeard@quintus.UUCP (Jeff Beard) To: comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms Subject: Re: Pass an open socket to another process????
Your problem is of interest to anyone concerned with nested servers. I for one would appreciate a posting of the summary of your findings. Tnx.
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 17:59:48 GMT From: lekash@ORVILLE.NAS.NASA.GOV (John Lekashman) To: comp.protocols.tcp-ip Subject: Subnet support in SunOS 3.3
Some more esoteric configurations with multiple (DIFFERENT) non-standard netmasks on the same machine are supported in a release that is currently in Beta test. Any comment on when this might make it out of beta test? We have these suns about to become cray gateways, and there will be two different subnetted networks connected to them. One to two months is the time frame in which I have to figure out some workaround to deal with this subnet problem. thanks, john
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 20:53:52 GMT From: tpmsph@ecsvax.UUCP (Thomas P. Morris) To: comp.os.vms,comp.protocols.tcp-ip Subject: TCP-IP processor boards for BI VAXen?
Are there any companies producing "intelligent" TCP-IP communications boards for BI-bus VAXen? By `intelligent TCP-IP communications board,' I mean something like the Bridge Communications IVECS or Micom NPxxx boards: these beasts have their own ethernet interface, and microprocessor and memory, and handle TCP-IP, TELNET and FTP protocols on the board, freeing up the VAX from the overhead of managing the communications protocol. All t he boards of this type with which I am familiar are Q-bus or UNIBUS boards. We have no interest in retrofitting our 8530 with a UBA, and want to know if there is anyone out there who makes a BI-bus version of such a product. Thanx in advance. Reply by mail: if there are enough responses, I'll summarize to the net. Tom Morris, UNC School of Public Health BITNET: TOM@UNCSPHVX USENET: ...!mcnc!ecsvax!tpmsph
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 21:05:20 GMT From: tpmsph@ecsvax.UUCP (Thomas P. Morris) To: comp.os.vms,comp.protocols.tcp-ip Subject: Need info on TWG TCP-IP processor overhead
Our site is looking into the purchase of some TCP-IP terminal servers, to be connected to our VAX VMS 8530, using the Wollongong TCP-IP (if we cannot find any IVECS-type BI-bus processor board). We have heard from other sites that there is `some' overhead in running TCP-IP terminal server connections using the TWG software. Claims about CPU overhead have varied wildly. Can anyone who is actually using TWG TCP-IP and VMS with BRIDGE or Micom or XYPLEX or DEVELNET servers please comment? "Hard" data would be much preferred. Something like "The cpu overhead is x%/connected process" or "we find that xx connections use yy% cpu just for communications via TCP-IP". Thanx in advance. Please reply via mail. I'll summarize and post back to the net. Tom Morris UNC School of Public Health BITNET: TOM@UNCSPHVX USENET: ...!mcnc!ecsvax!tpmsph
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 21:07:11 GMT From: kleonard@PRC.Unisys.COM (Ken Leonard --> kleonard@gvlv2@prc.unisys.com) To: comp.protocols.tcp-ip Subject: Re: DCA Protocol Lab Test Tools
In article <8802071346.aa05817@Huey.UDEL.EDU> Mills@UDEL.EDU writes: >Bob, > >Holy Cow. If the network is okay almost anything will work, even ISOspeak. >... What Bob meant by "network OK" was the simple ability to keep ANY connection open, for the test-control channel, for even 10 minutes or so! You ain't seen nuthin, in the way of netcrap, until you've been on the wrong side of an imp with experimental (pre-alpha grade) code working thru a gate with equivalent code. Otherwise, the point is correct, and the test tools in question not only work thru garbage--they can make garbage when it is needful. Regardz, Ken
-----------[000122][next][prev][last][first]----------------------------------------------------
Date: 8 Feb 88 21:41:00 GMT
From: jerry@TWG.ARPA ("Jerry Scott")
To: comp.protocols.tcp-ip
Subject: RE: Dynamic routing support for Wollongong WIN/TCPRelease 3.2, due in March or April will support GATED version 1.3.1. It is currently being beta tested at several sites. Once we feel the version is solid it will be made available via anonymous ftp to host twg.arpa. Regards, Jerry
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 88 21:59:00 GMT From: art@ACC.ARPA To: comp.protocols.tcp-ip Subject: protocol verification
With the recent discussion about TCP testing and verification, I thought that I would pass on an observation. I don't know if this reflects on just the specific instances or protocol testing in general. I was involved with GM in testing of MAP protocols for Autofact '84 and '85. Both times, all of the vendors eventually were able to successfully pass the conformance test suite. When interoperability testing began, MOST of the vendors found problems affecting interoperability. On other occasions, I have seen systems working on real networks fail conformance tests and systems which passed the conformance tests fail on the real network. I feel that this probably stems from a tendency by the test writer(s) to concentrate more on the protocol details (such as which diagnostic error code should be returned), than on the basic functionality of the protocol. The protocol writer may then end up spending effort just trying to make the test suite happy at the expense of a robust design. Art Berggreen art@acc.arpa ------
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 88 05:11:31 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: DCA Protocol Lab Test Tools
Ken, Point taken, with the exception of your comment on the depth of excrement in the swamp. Having swept the alligators from the wrong end of the IMP, you are cordially invited to swat the lizards on the NSFNET Backbone and dependent tributaries. It's much like a municipal waterworks system going out to the users, but also like a municipal sewer system coming back. Soon you may apply for a Merit Badge Gongfermer Grade for demonstrated competence in reptile extermination, which would seem a lot more fun than creepy-crawling on the ARPANET and EIN. Dave
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 88 14:57:00 PST From: <art@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: DDCMP Implementations
Does anyone know of any synchronous DDCMP implementations written in C which are available in source form (I know about TCI)? art@acc.arpa ------ -------
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: Tue, 9 Feb 88 17:53:10 EST From: "Alan R. Hill" <ahill@cc7.bbn.com> To: <art@acc.arpa> Cc: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: Re: protocol verification
Art, My experience in providing support to host subscribers trying to bring new software products onto the DDN indicates that the biggest oversight of protocol testing is imparement testing. Sure, products obey all the rules if the operating or test environment is perfect and also obeys the rules but products routinely mis-behave or fail if the environment is degraded or the communicating partner is not obeying protocol. Regards, Alan -------
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 88 15:44:13 GMT From: MKG@PSUVM.BITNET To: comp.protocols.tcp-ip Subject: Guidelines to write Subject
Will the persons making use of the net please follow the guidelines
below to write subject of their posting which is more intelligent
and reflect some percentage of the contents.
1. If the posting is an enquiry or a question, then at least follow
the subject line with a question mark. ( For those who are not aware
of this, "?" key on the keyboard used for q.m.)
2. If its a humor article and you want more people to read your posting
then you should follow the subject line with a bang !
3. If the posting is supposed to be for serious netters, then I think
just a period (".") is enough.
Please direct any/all comments to mkg@psuvm.BITNET
Enjoy posting intelligently..
Kamal Maheshwari.
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 88 18:32:20 GMT From: scott@scirtp.UUCP (Scott Crenshaw) To: comp.protocols.tcp-ip Subject: Re: TLI and Sockets
>
> Now, if you question really was: "I have a program written to use
> Berkeley sockets but I want to run it on a SVR3 machine which only
> has streams, what can I do?" Then the answer is that some people
> who are "heavy into Streams/TLI" have written libraries on top of
> TLI which make it look like sockets. The inverse operation,
> making sockets look like TLI is probably not possible without adding a
> bit of functionality to sockets.
>
Incidentally, System V Release 4 will integrate sockets,
as well as other goodies from Sun's OS, into the AT&T product.
--
Scott Crenshaw {akgua,decvax}!mcnc!rti-sel!scirtp!scott
SCI Systems , Inc. Research Triangle Park, NC
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 88 19:05:21 GMT From: kozel@SPAM.ISTC.SRI.COM (Edward R. Kozel) To: comp.protocols.tcp-ip Subject: Re: protocol verification
Art, I could not agree more with you. Validation of a protocol based on the formal specification is certainly fundamental but does not ensure either proper operation or interoperability. As another observation, I know of one officially validated DDN X.25 implementation which broke when put into actual operation, yet it passed the DCA protocol tests. "Bake offs", while perhaps colloquial, serve a very useful and important function. Ed Kozel
-----------[000130][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 88 22:06:21 GMT From: scott@scirtp.UUCP (Scott Crenshaw) To: comp.protocols.tcp-ip Subject: TCP/IP-NETBIOS Info Wanted
I'd appreciate any information you can give me concerning
TCP/IP-NETBIOS. Thanks very much.
--
Scott Crenshaw {akgua,decvax}!mcnc!rti-sel!scirtp!scott
SCI Systems , Inc. Research Triangle Park, NC
-----------[000131][next][prev][last][first]----------------------------------------------------
Date: 9 Feb 88 22:53:10 GMT
From: ahill@CC7.BBN.COM ("Alan R. Hill")
To: comp.protocols.tcp-ip
Subject: Re: protocol verificationArt, My experience in providing support to host subscribers trying to bring new software products onto the DDN indicates that the biggest oversight of protocol testing is imparement testing. Sure, products obey all the rules if the operating or test environment is perfect and also obeys the rules but products routinely mis-behave or fail if the environment is degraded or the communicating partner is not obeying protocol. Regards, Alan
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 88 22:57:00 GMT From: art@ACC.ARPA To: comp.protocols.tcp-ip Subject: DDCMP Implementations
Does anyone know of any synchronous DDCMP implementations written in C which are available in source form (I know about TCI)? art@acc.arpa ------
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 88 00:26:51 GMT From: eric@otc.oz (Eric Dutkiewicz) To: aus.general,comp.dcom.lans,comp.protocols.tcp-ip Subject: fast line coders/decoders
We are looking for an encoder/decoder chip(set) capable of supporting data
rates of at least 150Mbit/s. An example is the AMD TAXI chipset Am7968 &
Am7969 which uses NRZI, 4B/5B coding, runs at 100Mbit/s, and complies with
FDDI standard.
While a faster version of this chipset would be ideal, what we're
looking for doesn't necessarily have to use 4B/5B coding etc, but would have
to be fast (i.e. 150Mbit/s).
E-mail replies direct to myself, and I will summarise and release to the net.
Eric Dutkiewicz
|||| OTC ||
ACSnet: eric@otc.oz
UUCP: {uunet,mcvax}!otc.oz!eric
Snail: GPO Box 7000, Sydney 2001, Australia
Fax : +33 2 287 4990
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 88 02:33:40 GMT From: lamaster@ames.arpa (Hugh LaMaster) To: comp.os.vms,comp.protocols.tcp-ip Subject: Re: Need info on TWG TCP-IP processor overhead
In article <4582@ecsvax.UUCP> tpmsph@ecsvax.UUCP (Thomas P. Morris) writes: >Our site is looking into the purchase of some TCP-IP >terminal servers, to be connected to our VAX VMS 8530, >using the Wollongong TCP-IP (if we cannot find any >IVECS-type BI-bus processor board). I'm not sure what an IVECS board is. The following tests were done on an 8650, VMS 4.5, recent Wollongong (Not sure of version, but it is much improved over the earlier, much maligned, versions.) I'm not sure which DEC Ethernet board we are using either. BUT ... > >We have heard from other sites that there is `some' >overhead in running TCP-IP terminal server connections >using the TWG software. Claims about CPU overhead have >varied wildly. Can anyone who is actually using TWG >TCP-IP and VMS with BRIDGE or Micom or XYPLEX or DEVELNET >servers please comment? > > "Hard" data would be much preferred. Something like >"The cpu overhead is x%/connected process" or "we find that >xx connections use yy% cpu just for communications via TCP-IP". I have measured CPU overhead to: Ultrix, SunOS 3.2, and Annex Terminal Servers (X2.1.8). Unlike in the past, before TWG was so much improved, I am now unable to discern ANY difference in CPU overhead between a TWG Telnet Connection and a DM- type connection. Recent measurements showed that a TYPE of a large file on a machine with few interactive users and some idle time (batch jobs off and on, which didn't seem to have an effect on the test) produced about the same total usage whether going to the network or to a terminal. (Speed scaled appropriately). I haven't observed horrendous overheads due to terminals since we got rid of our DZ-11's (I think that is what the interrupt per character boards were). If you have many many low CPU usage terminals connected, and every last CPU cycle counts, you should probably do a formal study. If, on the other hand, you just want to make sure that you won't lose half the machine because of terminal servers, it doesn't look like an issue anymore (yes, it was in the past). The total throughput of an 8650 appears to be about 12-14KBytes/sec from TYPE, which may be doing line at a time output - 2KBytes/sec/MIPS. In either case, there is substantial overhead from doing terminal output, but it is about the same in either case. If most of your usage is in EDT (or its successors) there may be special efficiency issues- the Annex is supposed to put multiple characters from cursor control in one packet. Does a DMZ produce only one interrupt in that case? I suspect you get three, so potentially the terminal server could be more efficient. etc. etc. (By the way, the Annex has been up for 112 days -probably our last power outage. It has been reliable.)
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: Wed, 10 Feb 88 12:55:44 EST From: Carol_Feder@um.cc.umich.edu To: Dan Lynch <LYNCH@A.ISI.EDU> Subject: Summary of MCA Ethernet Cards
Subject: Re: MCA Ethernet Cards To: BIG-LAN@SUVM.BITNET From: Carol_Feder@um.cc.umich.edu > I'm interested in finding out what Ethernet Cards exist > for the Micro Channel. I'm most interested in finding > some that will run with Banyan Vines, 3Com's 3Plus, and Novell's > Netware. I know a few exist out there. If you know of any, > I'd be interested in finding out which card you're using and > what kind of performance you're experiencing for your network. Here's a summary of the responses I received: - - - - - We've had several 3Com Etherlink/MC (3c523) cards in PS/2-60s for a few weeks now. No problems. We're using 3Com 3PLus. 150 stations, mostly PCs, but not all. - - - - - Here at Virginia Tech we have used the Ungermann-Bass Nic/ps2 card in a PS/2 model 60. We are running the IBM PC/IP code version 1.1 without any problems. - - - - - Ungermann-Bass have already released their PC-NIC for the Micro-Channel. The device is known as the NICps/2. It hasnt got a local processor like the PC-NIU but the price is very favourable. I just received a piece but have not tested it. Still trying to beg, borrow or steal a PS/2. - - - - - I'm not using any, but I know of the following two which are currently available: 3COM 3C523, which I believe 3Plus will support; and Ungermann-Bass NIC/2 (or something like that). Other vendors like Micom-Interlan and Western Digital have announced that they are working on MCA interfaces but have not delivered anything yet. - - - - - Hi. I know of only two MCA ether cards out now. The Ungermann-Bass NIC PS/2 and the 3Com Etherlink/MC. I've done drivers for both for pc/ip here and get comprable throughput from both. I would prefer the 3Com card as for less price one gets the thin transceiver onboard. I also doubt that the UB board would work with 3Plus, but can not comment on support of Vines or Netware for either card. ------------------------------ If anyone finds out anything new or different on this topic, send a message to me and I'll be glad to summarize to the network. Thanks everyone for your input! Carol Ann Feder LAN Consultant The University of Michigan Computing Center User Services Bitnet Address: carol_feder@um.cc.umich.edu -------
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 88 14:26:30 GMT From: dnwcv@dcatla.UUCP (William C. VerSteeg) To: comp.protocols.tcp-ip Subject: TCP/IP books
There have been a couple of books about TCP/IP announced recently. I have been asked by some support people at my site which one would be a good one to read. I have not read any of the new ones. Please give me your impressions of the available books. A pointer to a book review would be also appreciated. Reply to me. I will summarize to the net. Thanks in Advance Bill VerSteeg Digital Communications Associates
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 88 15:03:41 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: SGMP support
Hans-Werner writes: > ... SGMP information should also get translated into Netview/PC > information somewhere to stage it up to the NOC machine (an IBM 4381). What does it mean translate SGMP to Netview/PC to "stage it up"? What's a NOC machine? Is the NOC on the Internet? Why would one want to "translate" a protocol to another protocol, and "stage" it to a some machine having nothing to do with the Internet? Phil Wood Los Alamos National Laboratory
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 88 17:55:44 GMT From: Carol_Feder@UM.CC.UMICH.EDU To: comp.protocols.tcp-ip Subject: Summary of MCA Ethernet Cards
Subject: Re: MCA Ethernet Cards To: BIG-LAN@SUVM.BITNET From: Carol_Feder@um.cc.umich.edu > I'm interested in finding out what Ethernet Cards exist > for the Micro Channel. I'm most interested in finding > some that will run with Banyan Vines, 3Com's 3Plus, and Novell's > Netware. I know a few exist out there. If you know of any, > I'd be interested in finding out which card you're using and > what kind of performance you're experiencing for your network. Here's a summary of the responses I received: - - - - - We've had several 3Com Etherlink/MC (3c523) cards in PS/2-60s for a few weeks now. No problems. We're using 3Com 3PLus. 150 stations, mostly PCs, but not all. - - - - - Here at Virginia Tech we have used the Ungermann-Bass Nic/ps2 card in a PS/2 model 60. We are running the IBM PC/IP code version 1.1 without any problems. - - - - - Ungermann-Bass have already released their PC-NIC for the Micro-Channel. The device is known as the NICps/2. It hasnt got a local processor like the PC-NIU but the price is very favourable. I just received a piece but have not tested it. Still trying to beg, borrow or steal a PS/2. - - - - - I'm not using any, but I know of the following two which are currently available: 3COM 3C523, which I believe 3Plus will support; and Ungermann-Bass NIC/2 (or something like that). Other vendors like Micom-Interlan and Western Digital have announced that they are working on MCA interfaces but have not delivered anything yet. - - - - - Hi. I know of only two MCA ether cards out now. The Ungermann-Bass NIC PS/2 and the 3Com Etherlink/MC. I've done drivers for both for pc/ip here and get comprable throughput from both. I would prefer the 3Com card as for less price one gets the thin transceiver onboard. I also doubt that the UB board would work with 3Plus, but can not comment on support of Vines or Netware for either card. ------------------------------ If anyone finds out anything new or different on this topic, send a message to me and I'll be glad to summarize to the network. Thanks everyone for your input! Carol Ann Feder LAN Consultant The University of Michigan Computing Center User Services Bitnet Address: carol_feder@um.cc.umich.edu
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 88 18:17:52 GMT From: ks@pur-ee.UUCP (Kirk Smith) To: comp.protocols.tcp-ip Subject: Re: DDCMP Implementations
In article <8802100151.AA10942@ucbvax.Berkeley.EDU> <art@acc.arpa> writes: > >Does anyone know of any synchronous DDCMP implementations written in C >which are available in source form (I know about TCI)? > > art@acc.arpa I wrote a DDCMP interface in C for our robots. It is complete enough to talk to both a Cincinnatti Milacron and a Unimate robot. It is not overly efficient, but should work for 4.2BSD or 4.3BSD. It includes a tty line discipline to form incoming characters into packets for increased efficiency. It seems to be able to recover properly from unplugging the cable in the middle of communications. It does not do all the maintenance mode stuff, and has no documentation or support. It only does async I/O lines (no synchronous stuff). It has been in use without problems for about 2 years. I can make it available via ftp. Kirk Smith ks@ee.ecn.purdue.edu
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 1988 07:42-EST From: GBELING@A.ISI.EDU To: tcp-ip-request@SRI-NIC.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Guidelines to write Subject, BANG = !
hi, sometimes nice ideas come over the net. yours has 2 disadvatages: 1.) you forgot to mark your subject - therefore i suppose a big bang is missing following your own text 2.) most mail-access programs shorten the subject line randomly - so the marker HAS to be at the beginning of the subject line regrads gerd beling -------
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 05:51:51 GMT From: halls@boulder.Colorado.EDU (Andy Halls) To: comp.protocols.tcp-ip Subject: What is SLIP?
Excuse me, do I unserstand it right. Is Serial Line IP (SLIP) a
protocol that works over serial lines that supports tcp stuff, like
ftp and rlogin ???
Would someone be so kind as to educate me. Also how can I get my hands
on such a thing.
Andy Halls
phone: home (303) 455-9139 work (303) 282-2166
uucp: {cires | hao | nbires}boulder!halls
internet: halls@boulder.colorado.edu
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 12:36:00 EST From: <enger@bluto.scc.com> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Cc: <@ucbvax.berkeley.edu:mkg@psuvm.bitnet> Subject: Subject Field policy "." "?" "!" ":-)"
Discussion has taken place on the need for a "protocol police", but I never thought it would come to controlling the content of the Subject: line.. The message that sparked this response has a From: field containing @psuvm.bitnet . Repair of the From: field should take precedence over commenting on the Subject: field. Bob Enger -------
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 12:42:00 GMT From: GBELING@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Guidelines to write Subject
hi, sometimes nice ideas come over the net. yours has 2 disadvatages: 1.) you forgot to mark your subject - therefore i suppose a big bang is missing following your own text 2.) most mail-access programs shorten the subject line randomly - so the marker HAS to be at the beginning of the subject line regrads gerd beling
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 13:24:23 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: Guidelines to write Subject
Due to the absence of any appropriate terminator on your subject line, I am not entirely sure how I should treat your comments. Could you please provide a Bachus-Naur Form description of the subject line syntax you wish to see implemented? Could you also provide a category for levity? Merton Campbell Crockett
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 13:52:26 GMT From: symchych@SKL-CRC.ARPA (Tim Symchych) To: comp.protocols.tcp-ip Subject: Add one to the rules. or ? or !
If we make rules, and do not follow them, then perhaps we should add a bang (#) to the subject line. tim
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 14:07:32 GMT From: symchych@SKL-CRC.ARPA (Tim Symchych) To: comp.protocols.tcp-ip Subject: !Add one more
Sorry about the bang. A crunch (#) for not following the rules. tim
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 15:52:16 GMT From: Peter_Cutting@newcastle.ac.uk (P. G. Cutting) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Ethernet Monitoring/Management and Planning Information
This is the first posting that we have put on usenet, so bare with us. We are 9 students on a Computing Science advanced MSc course (Computing Softwareand Systems Design) at Newcastle University, England. We have been assigned a group project concerning the monitoring/management and planning of an ethernet network. The project has been set because the Computing Lab wishes to expand its ethernet to the whole campus. Departments linked by the new Ethernet will be allowed to connect what ever hardware they desire so it is likely that a hetrogenous network will develop. At present we have a Spider ethernet monitoring tool, and a Nest network simulator (from Columbia University) . We hope to use the first to provide us with quantative load information on the current ethernet, and the second to help us predict the loads that will occur on the future ethernet. Obviously we will have to consult each university department about how they will use the future ethernet to achieve this. One of the tasks specified in the project is to produce a set of network management tools. Some of which are noted below :- * a broadcast facility which allows the manager to send a message to some or all users on the network. * a fault monitor which can tell the manager of any faults (both physical and software) that occur on the network. * a load monitor which can tell the manager what load each device is putting on the network, etc. If anyone has anything they think might be useful, be they tools, references, reports, problems encountered or advice then we would be more then pleased to hear from you. The project must be completed by the end of April so it is important that replies be sent as soon as possible to - CSSD@UK.AC.NEWCASTLE We will post our results including an annotated bibliography to the net if there is sufficient demand. Thanks in advance.
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 21:30:00 EST From: <enger@bluto.scc.com> To: "mcc" <mcc@etn-wlv.eaton.com> Cc: <tcp-ip@sri-nic.arpa> Subject: RE Subject field policy.!@#$%^&*()_+ (that should cover everything)
Merton: True to your message, I have already received a mail failure notice from some place off in the land of the big blue machines. (probably sent by printing to a virtual card punch, or worse). In reading the exploded copy of my own mail, I realized that some might missinterpret my comment about the Subject field. It was meant to suggest that the original author should fix his own mailer before critiquing the subject field content of others. The new End to End has turned up some strange things: I regularly found two subnet VCs used to talk to an MIT host. I wrote and asked them why; they told me they didn't know. I asked them what they had their 1822 handling type set to. They told me 7. Best wishes, Bob -------
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 17:36:00 GMT From: enger@BLUTO.SCC.COM To: comp.protocols.tcp-ip Subject: Subject Field policy "." "?" "!" ":-)"
Discussion has taken place on the need for a "protocol police", but I never thought it would come to controlling the content of the Subject: line.. The message that sparked this response has a From: field containing @psuvm.bitnet . Repair of the From: field should take precedence over commenting on the Subject: field. Bob Enger
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 18:57:06 GMT From: fedor@NISC.NYSER.NET (Mark Fedor) To: comp.protocols.tcp-ip Subject: Re: Guidelines to write Subject
kamal, since your subject neither contained a "?", ".", or "!" what category does it fall under? couldn't resist.... :^) Mark
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 19:32:13 GMT From: hrp@windsor.CRAY.COM (Hal Peterson) To: comp.protocols.tcp-ip Subject: DCA Protocol Lab Test Tools
Bob, You are correct and I was being too flip with my wording: the tests are indeed quickly RUN. What I meant to say is that it takes a long time TO BE ABLE TO RUN the tests, because of the time necessary to develop a ``remote driver'' program to run on the machine under test. [The remote driver sits on top of the protocol under test and responds to commands and data from the central test site, opening and closing connections, echoing data, and so forth.] Our experience indicates that anyone who wants to run these tests should allocate several people and several months to the task. On a machine for which remote drivers are available, that time would be shortened to a couple of weeks for one person. We've been at this for a year and a half now and we have yet to run all of the tests. This has happened for a number of reasons: some are unique to Cray, some are political, and some are a result of working with a system in progress, whose specifications have been changing while we work. I am still convinced that our time is being well spent, that this is a worthy effort, and that users of the production version of the test suite will have a much easier time of it than we have. -- Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-3145
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 19:40:36 GMT From: hrp@windsor.CRAY.COM (Hal Peterson) To: comp.protocols.tcp-ip Subject: ``If the network is okay . . .''
Dave, The suite includes tests for things like dropped packets, garbled packets, and out of order packets. But the testing machine and the machine under test are separated by a network, and the testing machine has to be able to check the results of the tests. If the network is dropping packets on its own, then the testing machine will be wildered. Does that make you willing to upgrade the certificate? Mailbridge second class, at least! -- Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-3145
-----------[000153][next][prev][last][first]----------------------------------------------------
Date: 11 Feb 88 19:50:15 GMT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: What is SLIP?SLIP is a primitive encapsulation for IP on serial lines (usually asynchronous). IP using it works the same way as IP using Ethernet, or IP over X.25, or IP over Token Ring. I have been told that SLIP has its roots in an old serial protocol 3Com came up with for communicating between fileservers, and was adopted for use with IP and asynchronous serial lines some time later, initially for use between gateways (IP routers). Rick Adams did a public domain implementation for 4.2 Unix, and now one is distributed with 4.3. It is only relatively recently that SLIP has been supported by any commercial vendors. Commercial implementations that I know of include ours, for the IBM PC, and cisco Systems' SLIP port concentrator/terminal concentrator/IP router. I have heard that Sun will support it soon, if not already, and that Encore has or will have something for their Annex. James B. VanBokkelen FTP Software Inc.
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 20:14:55 GMT From: MKG@PSUVM.BITNET To: comp.protocols.tcp-ip Subject: Response to "Guidelines to write Subjects" !
Hi,
Thank you everyone for the hearty comments and corrections.
I realized (after I posted my article) that I myself forgot
to observe those Guidelines but that, by no means, should
affect the suggestion. In any case, I'm sorry about the faux-pas.
I assure you all that in future I'll be more careful.
Thanks once again.
Kamal Maheshwari.
" Code of *Subject* makes the contents Artificially Intelligent!!"
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 20:33:51 GMT From: hrp@windsor.CRAY.COM (Hal Peterson) To: comp.protocols.tcp-ip Subject: protocol verification
Alan,
You wrote that
Sure, products obey all the rules if the operating or test
environment is perfect and also obeys the rules but products
routinely mis-behave or fail if the environment is degraded or the
communicating partner is not obeying protocol.
This is absolutely correct, and is a widespread problem in the testing
of ANY software: most programmers don't think to try invalid inputs.
For an excellent treatment of the topic read the first chapter of
``The Art of Software Testing'' by Glenford J. Myers; then read the
rest of the book, which is well worth the time of anyone who tests,
builds, or otherwise copes with software.
On the matter at hand: the DCA Protocol Laboratory Suite includes
lots of tests which deliberately violate the protocols.
This points up a couple of arguments in favor of having a verification
suite as a part of comprehensive testing. First, the test procedure
can create arbitrary errors at arbitrary intervals, taking into
account known implementation mistakes of the past and anticipating
tomorrow's buggy code. Second, once such violations are in the suite,
they are there for good; with bake-off testing, implementors fix their
bugs as they go along and some flakinesses become extinct, so some of
everyone's error detection code goes untested. A good (and
well-maintained!) verification suite can give you the effect of
talking to every dumb mistake that's been made plus a few still
waiting to be made.
I should stress, though, that a verification suite is only part of a
comprehensive testing strategy, and that bake-offs can be extremely
valuable for finding bugs. A verification suite is software, and like
all software it is imperfect. It is entirely possible that two
implementations both pass the suite but don't interoperate. Bake-offs
can catch that, and when they do they have found as many as FOUR bugs:
1. a bug in one of the implementations.
2. a bug in the other implementations; after all, they could both be
at fault.
3. a bug in the specification. It may be unclear or inconsistent or
incomplete and so have misled the implementors.
4. a bug in the verification suite. It should have caught the
problem, and next time it will, since it's a simple matter to add
a test to a well-designed suite. The suite gets better as time
goes on.
--
Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120
hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-3145
-----------[000156][next][prev][last][first]----------------------------------------------------
Date: 11 Feb 88 20:44:51 GMT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: TCP/IP-NETBIOS Info WantedThe details of the protocol are in RFCs 1001 and 1002. There is a write-up of the history of NETBIOS and its implementation over TCP/IP in the most recent issue of the Connexions newsletter (from Advanced Computing Environments), written by John Romkey. Basically, what it is is the use of TCP and UDP to transport data between pairs of programs which make Int 5C calls on PCs, or something similar (but not yet standardized) on non-DOS systems. The programs that call Int 5C are either LAN programs (like Microsoft Networks or the IBM PC LAN Program), which redirect the DOS filesystem via the network, or applications like central SNA gateways, or shared databases where a more user-level application makes the calls. The TCP is just substituting for proprietary protocols (XNS-derived in the case of 3Com, Banyan or Novell), or incompatible subsets of OSI transport protocols, or whatever else. The major benefit conformance to the TCP standard brings is the ability to interoperate between different vendors' implementations. A couple of commercial versions are available now, for PCs, and more should be (for some other systems, too) within 30 to 90 days. James B. VanBokkelen FTP Software Inc.
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 21:41:23 GMT From: bill@tifsil.UUCP (Bill Stoltz) To: comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms Subject: SUMMARY - Re: Pass an open socket to another process???
Thanks to everyone who sent me mail on the passing an open socket
request.
A quick summary is that this capability does exist on 4.[23] BSD
systems, and in a more restricted environment on AT&T V.3.
We are running Ultrix 2.0 (a 4.[23] derivative) here, and I have
tested this capability and it does work. I did not hear any
thing from anyone else (no VMS or Xenix systems) so I don't know if
this will work on any of these system. (Maybe someone can post
something on whether these systems support this type of system call).
The following is a summary of the responses that I received during
the last week. Again thanks to everyone who sent in a response.
At the end I will give an account of the day and a half I spent
getting a test case working.
Most of the responses were to use sendmsg/recvmsg in 4.[23] BSD.
These calls are defined in the recv(2) and send(2) man pages.
Thanks to the explanation by several people, I was informed that the
accessrights field is actually an array of file descriptors.
Doug McCallum <ti-csl!im4u!ut-sally!violet.ico.isc.com!dougm>, explained it
the best when he said:
> On a 4.2/4.3 BSD system, there is the concept of access rights
> passing. It only works in the AF_UNIX domain but could be made to
> work with other protocols given a little work. Basically, it lets you
> pass any file descriptor to another process. It uses the AF_UNIX
> SOCK_DGRAM mechanism and is an array of int's in the structure used in
> recvmsg/sendmsg. I've used this as a way to implement a file password
> server to allow opening a restricted access file if you knew the
> password.
>
> It works like a "dup" across process boundaries.
Doug went on to say that this capability is a standard feature of AT&T V.3.
> On V.3, the Streams mechanism allows a process to send a stream
> descriptor over a connected stream pipe (a stream pipe is a stream
> that connects two processes on the same machine). Since Streams is
> protocol independent, you could implement any protocol underneath and
> have the same capability. Note that Streams by itself isn't a
> protocol and V.3 may come with Streams but no protocols. V.3 does
> have a stream pipe which is very simple minded and appears to exist
> solely as a way to get other streams descriptors to an unrelated
> process.
>
> Streams is the abstraction that AT&T is using for future network
> support.
>
> The big difference between the two mechanisms is that BSD allows any
> file descriptor and V.3 only allows streams file descriptors.
A couple people also mentioned the "inetd" or Sun inet program. They
felt that this also provided this type of cabability. I did not spend
much time looking into this option, The Ultrix 2.0 inetd did not
use the sendmsg/recvmsg calls so I stopped looking at it.
Once I received all this information, I decided that I could put together
a simple test case in a matter of hours. Well, I found a few stumbling
blocks along the way that I would like to let everyone know about. Hopefully
I can help some people and save them some time.
First the send(2) and recv(2) man pages that describe the sendmsg/recvmsg
calls are VERY cryptic. They briefly mention the parameters by name but
give you very little information on what to put in them.
To get started I took an already working program and hacked it into
2 programs. The first process was the main server and the second process
was basically one of the subroutines from the old server that only
sent back a datetime string.
At this point I now had to add a socket(2) and a bind(2) call to both
processes. The socket used AF_UNIX and SOCK_DGRAM parameters. The bind
call was a little tricky. You have to give bind a valid Unix file name.
So, I set up both processes the same way, except for different file names.
struct sockaddr_un sktname;
sc = socket(AF_UNIX, SOCK_DGRAM, 0);
sktname.sun_family = AF_UNIX;
unlink(path);
strcpy(sktname.sun_path, "/tmp/test.serv");
err = bind(sc, &sktname, sizeof(sktname));
The bind actually creates a file on the system. The unlink is there to
remove the socket if it already exists, so the bind can create a new one.
I don't know if this is necessary, but I noticed this in the elcsd(8) program.
The next step was to modify the server process to send the file descriptor
to the datetime process, instead of calling this subroutine to send back
the response. The following is the code I inserted to send over the
connection.
struct msghdr sktmsg;
struct sockaddr_un sktname;
struct iovec iov;
char buf[80];
int rights[1];
int socket2pass;
sktname.sun_family = AF_UNIX;
strcpy(sktname.sun_path, "/tmp/test.dt");
iov.iov_base = buf;
iov.iov_len = 0;
rights[0] = socket2pass;
sktmsg.msg_name = (caddr_t) &sktname;
sktmsg.msg_namelen = sizeof(sktname);
sktmsg.msg_iov = &iov;
sktmsg.msg_iovlen = 1;
sktmsg.msg_accrights = rights;
sktmsg.msg_accrightslen = sizeof(rights);
sendmsg(sc, &sktmsg, 0);
Notice several things that are not clear in the man pages. First, you must
pass in a sockaddr structure for the name of the socket to send this too,
and the size is the size of the structure, not the length of the string name.
If you just pass in the path name and length of the string you will get errors
like "No such file or directory". Second the iovlen is the number of iovec
structures passed in. Also, on a send, you must provide at least one iovec
structure. I also filled in the buffer address, but left the length at 0,
I have not tried it to see if a buffer is required, my guess is yes.
Last is the accrights. I made the assumption that the rights worked like the
iovec structures, WRONG. For this you give the total number of bytes
you want the kernel to read in. You must also be sure that every value you
put into the rights array is a valid file descriptor for the sending process
or you will get back an EBADF error.
Once I got all the parameters straight it worked great.
I then changed the new datetime process to block on a recvmsg call waiting
for this new connection so I could send back the datetime string.
The following is what I added to the datetime program.
struct iovec iov;
int rights[5];
struct msghdr sktmsg;
char buf[80];
iov.iov_base = buf;
iov.iov_len = sizeof(buf);
sktmsg.msg_name = 0;
sktmsg.msg_namelen = 0;
sktmsg.msg_iov = iov;
sktmsg.msg_iovlen = 1;
sktmsg.msg_accrights = rights;
sktmsg.msg_accrightslen = sizeof(rights);
recvmsg(sc, &sktmsg, 0);
Since this was a test program I ignored the name on the receive side.
I setup the iovec buffer, even though I knew there was no data coming in.
The last step was to retrieve the new file descriptor and issue the
send of the datetime string. The file descriptor was now converted to
a new unused descriptor for the datetime process. After sending out the
string, I just closed the new file descriptor and went back to wait for the
next message. The server also closed the connection right after the
sendmsg call.
new_fd = rights[0];
dt_send(new_fd);
close(new_fd);
This has been a rather long summary of the responses I got and the
work that I have done. I hope this helps some of the people that asked
me for a response.
I feel very comfortable with this solution. I am recommending to the
other people in our group to use the sendmsg/recvmsg calls as a way
to implement the passing of a socket to a non-related process. I hope
this will help someone, I know it has helped me.
Thanks again for the responses.
bill
-----------
Bill Stoltz
Texas Instruments
Process Automation Center
P.O. Box 655012, M/S 3635
Dallas, TX 75243
UUCP: {uiucdcs!convex!smu, {rice, sun!texsun}!ti-csl}!tifsie!bill
DECNET: TIFSIE::bill
Voice: (214) 995-2786
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 22:37:10 GMT From: sklower@sequoia.Berkeley.EDU.berkeley.edu (Keith Sklower) To: comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms Subject: Re: Pass an open socket to another process????
In article <633@eden.quintus.UUCP> jbeard@quintus.UUCP (Jeff Beard) writes:
>
>
>Your problem is of interest to anyone concerned with nested servers.
>I for one would appreciate a posting of the summary of your findings.
>
>Tnx.
4.2 and 4.3 BSD provide a means of passing an open file descriptor
of any sort (including sockets) between two co-operating processes
by means of the sendmsg system call.
In fact, I am presently engaged in reducing the latency in providing
XNS courier services under UNIX by use of this mechanism. The Courier
RPC protocol imbeds requests for services as part of the data of a stream,
so one would like to pass the stream between processes, and fork + exec
is a relatively slow way to do it.
For greatest speed, you want to establish an additional UNIX-domain
socket connection between the two processes prior to when the "passing
of the baton" will occur. You can do this with either a stream or datagram
connection (but if you use a datagram connection you must be careful
to check that the sendmsg system call doesn't fail due to lack of buffer
space; if it does, don't close the socket you are handing off, but try
the sendmsg() system call over again later).
Here is a code fragment to send the file descriptor:
(You can pass data in addition to the socket, like any excess
data you may have drained from it by mistake).
pass_fd_rights(s, fd, buf, buflen)
int s, fd, buflen;
char *buf;
{
static struct msghdr msg;
static struct iovec iov[1];
iov->iov_base = buf;
iov->iov_len = buflen;
msg.msg_iov = iov;
msg.msg_iovlen = 1;
msg.msg_accrights = (caddr_t)&fd;
msg.msg_accrightslen = sizeof (fd);
sendmsg(s, &msg, 0);
}
recvmsg() is the system call you use to collect the passed file descriptor.
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 88 23:18:09 GMT From: hrp@windsor.CRAY.COM (Hal Peterson) To: comp.protocols.tcp-ip Subject: Life in the Swamps / Testing
Dave, In view of your remark Having swept the alligators from the wrong end of the IMP, you are cordially invited to swat the lizards on the NSFNET Backbone and dependent tributaries. It's much like a municipal waterworks system going out to the users, but also like a municipal sewer system coming back. I (as a tester of TCP/IP and user of the Internet) hope that somebody out there is collecting the gooiest, scaliest monsters for eventual domestication in a test suite. If there is bizarre behavior that uncovers bugs and happens out there in the swamps, then we must have samples with which to inoculate our implementations. ``Those who cannot remember the past are condemned to repeat it.'' - George Santyana -- Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-3145
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 01:05:55 GMT From: jonab@CAM.UNISYS.COM (Jonathan P. Biggar) To: comp.protocols.tcp-ip Subject: Bug in Sun OS 3.4 tcp?
Does anyone know about a problem with tcp under Sun OS 3.4 where receiving a packet with the maximum segment size option messes up the window? Our Suns can talk find to each other, but when they receive data from a machine that uses the MSS option, the connection eventually hangs because the Sun never updates the window. I have tried using diff on the 3.4 source and the 4.3bsd tcp and have found no substantial differences, so this bug might exist in 4.3bsd also. Thanks, Jon Biggar
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 01:13:34 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: Subject Field policy "." "?" "!" ":-)"
Bob: Thank you for the remark about the "From:" field. It may not be relevant but it does seem that since the implementation of the new End/End Protocol that there has been a marked increase of comments/suggestions in this forum from interested parties without valid return addresses. Belay that remark, it probably started with the change to "name servers" from "host tables", it just got worse. Perhaps its a problem with my view of electronic mail, particularly mail that is for forwarded to "tcp-ip@sri-nic.arpa"; it is irrelevant to me whether a subscriber to this service from "bangland" failed to leave his PC powered-up to receive my comment or retort of questionable significance. Why should I be inundated with "unable to deliver to xxx" messages? Its "tcp-ip" that needs the knowledge as it may signify some network problem! It does raise some questions about SMTP and its interpretation of "From:" and "Forwarded by:". The reporting of delivery errors should always be delivered to the "Forwarded by:" individual not the "From:" individual who may not have authorized the dissemination of the message. Merton Campbell Crockett
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 01:32:30 GMT From: jtn@potomac.ads.com (John T. Nelson) To: comp.protocols.tcp-ip Subject: Re: X.25 to Milnet PSN problems - the continuing saga
In article <7@ucsd.EDU>, brian@ucsd.EDU (Brian Kantor) writes: > > I'm told that a trace in the PSN code shows that the IMP wasn't even > trying to open the circuit to us, so it's probably in or related to the > PSN code and not the interface - especially since it just started > happening without us making and hardware or software changes. It DID > start around the time the Arpanet cut over to PSN-7, but we're on the > Milnet. > > We're currently running a process that sends a single ping packet to > each of the Milnet mailbridges once every 45 seconds to ensure that the > X.25 VC stays open so that traffic will find an already-open VC instead of > blocking because it can't open one of its own. Well aside from you being on the Milnet this sounds just like our experiences. However we have a Sun III/180 running 3.4 of their operating system with the Sun X.25 DDN software and an SCP board. Our PSN is running 7.0 and we talk to it only via HDH (although we are configured to talk via X.25 "extended"). I run a ping on a host that we peer with every second. We are still talking to BBN about these problems. -- John T. Nelson UUCP: sun!sundc!potomac!jtn Advanced Decision Systems Internet: jtn@potomac.ads.com 1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611 "Hi... My name is Hobbes. I'm the product of a malicious 5-year old's twisted and destructive imagination. Would YOU like to be my friend?"
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 02:30:00 GMT From: enger@BLUTO.SCC.COM To: comp.protocols.tcp-ip Subject: RE Subject field policy.!@#$%^&*()_+ (that should cover everything)
Merton: True to your message, I have already received a mail failure notice from some place off in the land of the big blue machines. (probably sent by printing to a virtual card punch, or worse). In reading the exploded copy of my own mail, I realized that some might missinterpret my comment about the Subject field. It was meant to suggest that the original author should fix his own mailer before critiquing the subject field content of others. The new End to End has turned up some strange things: I regularly found two subnet VCs used to talk to an MIT host. I wrote and asked them why; they told me they didn't know. I asked them what they had their 1822 handling type set to. They told me 7. Best wishes, Bob
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 02:33:49 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Life in the Swamps / Testing
Hal, Once upon a time Vint Cerf was keeper of the alligators and even Bob Braden collected a few. I've got a backyard full of the critters myself. However, the point of my remark was that we don't need to invent bizarre test suites, just how well it works in the current environment. What may be more useful for you would be to find out what the current environment really is (loss rates, mangle angles, quench characteristiccs, etc., then build a flakeway (broken network simulator) with similar characteristics and do war with it. That's in fact how we did the initial IP testing (with credit to Bob Braden) in the bakeoffs of antiquity. I'll rephrase my homily: We have met the enemy and he is us. Now you may understand my preocupation with swamps. Pass the stogies, Albert. Dave
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 04:29:51 GMT From: chris@trantor.umd.edu (Chris Torek) To: comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms Subject: Re: Pass an open socket to another process????
In article <22952@ucbvax.BERKELEY.EDU> sklower@sequoia.Berkeley.EDU.UUCP ----? (Keith Sklower) writes: >4.2 and 4.3 BSD provide a means of passing an open file descriptor >of any sort (including sockets) between two co-operating processes >by means of the sendmsg system call. Beware, however, of some rather serious bugs in the implementation in 4.2BSD. For instance, using MSG_PEEK with recvmsg() on a message with rights can cause multiple acceptance of the passed file descriptor, resulting in eventual file system corruption (without the closef firewall) or a panic (with the firewall). All of this is fixed in 4.3BSD (with the possible exception of the fd garbage collection code---try not to send pipe descriptors to yourself over those pipe descriptors, please). Which SunOS releases may have which bugs I cannot say. -- In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163 (hiding out on trantor.umd.edu until mimsy is reassembled in its new home) Domain: chris@mimsy.umd.edu Path: not easily reachable
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: Fri, 12-Feb-88 10:41:10 EST From: lamy@ai.toronto.edu (Jean-Francois Lamy) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip.domains Subject: Re: What is SLIP?
On a related note: I'm curious to know how an asynchronous SLIP (is there such a beast?) would fare on high-speed Telebit style modems. Anybody tried such a setup? Jean-Francois Lamy AI Group, Department of Computer Science lamy@ai.toronto.edu University of Toronto, Canada M5S 1A4 uunet!ai.toronto.edu!lamy
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 06:17:04 GMT From: van@LBL-CSAM.ARPA (Van Jacobson) To: comp.protocols.tcp-ip Subject: Dynamic Congestion Avoidance / Control (long message)
A dozen people forwarded Phil Karn's question about TCP
congestion control to me, usually with pithy subject lines like
"how much longer till you publish something?". I do have three
RFCs and two papers in various stages of preparation, but innate
laziness combined with this semester's unexpectedly large
teaching load means it will probably be late spring before
anything gets finished. In the interim, here's a sort-of
overview of our congestion control work.
I should point out these algorithms are joint work with Mike
Karels of UC Berkeley (I guess my name got stuck on things
because I make the presentations while Mike is off fighting the
battles on EGP or routing or domains or ...). I should also
mention that there's not a whole lot that's original. In
particular, the two most important algorithms are quite close to
(prior) work done by DEC's Raj Jain. This was by accident in
one case and deliberate in the other.
This stuff has been discussed on the ietf and end2end lists
(Phil participated in some of those discussions and was, in
fact, one of the early beta testers for our new tcp -- I have
this nagging suspicion I was set up). I've appended a couple of
those mail messages.
Mike and I have put a number (six, actually) of new algorithms
into the 4bsd tcp. Our own measurements and the reports of our
beta testers suggest that the result is quite good at dealing
with current, congested conditions on the Internet. The various
algorithms were developed and presented at different times over
the past year and it may not be clear to anyone but the
developers how, or if, the pieces relate.
Most of the changes spring from one observation: The flow on a
TCP connection (or ISO TP-4 or XNS SPP connection) should, by
the design of the protocol, obey a `conservation of packets'
principle. And, if this principle were obeyed, congestion
collapse would become the exception rather than the rule.
Thus congestion control turns into finding places where
conservation is violated and fixing them.
By `conservation of packets' I mean the following:
If you look at the connection "in equilibrium", i.e., running
stably with a full window of data in transit, you notice that
the flow is what a physicist would call "conservative": A new
packet isn't put into the network until an old packet leaves.
Two scientific disciplines that deal with flow, hydrodynamics
and thermodynamics, predict that systems with this conservation
property should be extremely robust in the face of congestion.
Observation of the Arpanet or NSFNet suggests that they were not
particularly robust in the face of congestion. From whence
comes the discrepancy?
[Someone asked me for a simple explanation of why a conservative
flow system should be stable under load. I've been trying to
come up with one, thus far without success -- absolutely nothing
in hydrodynamics admits to simple explanations. The shortest
explanation is that the inhomogenous forcing terms in the
Fokker-Planck equation vanish and the remaining terms are highly
damped. But I don't suppose this means much to anyone (it
doesn't mean much to me). My intuition is that conservation
means there's never an `energy difference' between the outside
world and the system that the system could use to `pump up' an
instability to a state of collapse. Thus the only mechanism the
system can use for self-destruction is to re-arrange its
internal energy and create a difference large enough to break
something. But entropy (or diffusion) always trys to erase
large internal energy differences so collapse via these
mechanisms is improbable. Possible, but improbable, at least
until the load gets so outrageous that collective, non-ergodic
effects start to dominate the overall behavior.]
Packet conservation can fail three ways:
1) the connection doesn't get to equilibrium, or
2) a sender injects a packet before an old packet has exited, or
3) the equilibrium can't be reached because of resource
limits along the path.
(1) has to be from a connection starting or restarting after a
packet loss. Another way to look at the conservation property
is to say that the sender uses acks as a "clock" to strobe new
packets into the network. Since the receiver can generate acks
no faster than data packets can get through the network, the
protocol is "self clocking" (an ack can't go in until a packet
comes out, a packet can't go in until an ack comes out). Self
clocking systems automatically adjust to bandwidth and delay
variations and have a wide dynamic range (an important issue
when you realize that TCP spans everything from 800 Mbit/sec
Cray channels to 1200 bit/sec packet radio links). But the same
thing that makes a self-clocked system stable when it's running
makes it hard to get started -- to get data flowing you want acks
to clock packets out but to get acks you have to have data flowing.
To get the `clock' started, we came up with an algorithm called
slow-start that gradually increases the amount of data flowing.
Although we flatter ourselves that the design of this algorithm
is quite subtle, the implementation is trivial -- 3 lines of
code and one new state variable in the sender:
1) whenever you're starting or restarting after a loss,
set your "congestion window" to 1 packet.
2) when you get an ack for new data, increase the
congestion window by one packet.
3) when you send, send the minimum of the receiver's
advertised window and the congestion window.
(This is quite similar to Raj Jain's CUTE algorithm described in
IEEE Transactions on Communications, Oct, '86, although we didn't
know about CUTE at the time we were developing slowstart).
Actually, the slow-start window increase isn't all that gradual:
The window opening takes time proportional to log2(W) where W is
the window size in packets. This opens the window fast enough
to have a negligible effect on performance, even on links that
require a very large window. And the algorithm guarantees that
a connection will source data at a rate at most twice the
maximum possible on the path. (Without slow-start, by contrast,
when 10Mb ethernet hosts talk over the 56Kb Arpanet via IP
gateways, the gateways see a window's worth of packets (8-16)
delivered at 200 times the path bandwidth.)
Once you can reliably start data flowing, problems (2) and (3)
have to be addressed. Assuming that the protocol implementation
is correct, (2) must represent a failure of sender's retransmit
timer. A good round trip time estimator (the core of the
retransmit timer) is the single most important feature of any
protocol implementation that expects to survive heavy load. And
it almost always gets botched.
One mistake seems to be not estimating the variance of the rtt.
From queuing theory we know that rtt and rtt variation increase
very quickly with load. Measuring the load by rho (the ratio of
average arrival rate to average departure rate), the rtt goes up
like 1/(1-rho) and the variation in rtt goes like 1/(1-rho)^2.
To make this concrete, if the network is running at 75% of
capacity (as the Arpanet was in last April's collapse), you
should expect rtt to vary by a factor of 16 around its mean
value. The RFC793 parameter "beta" accounts for rtt variation.
The suggested value of "2" can adapt to loads of at most 30%.
Above this point, a connection will respond to load increases by
retransmitting packets that have only been delayed in transit.
This makes the network do useless work (wasting bandwidth on
duplicates of packets that have been or will be delivered) at a
time when it's known to be having trouble with useful work.
I.e., this is the network equivalent of pouring gasoline on a
fire.
We came up a cheap method for estimating variation (see first of
attached msgs) and the resulting retransmit timer essentially
eliminates spurious retransmissions. A pleasant side effect of
estimating "beta" rather than using a fixed value is that low
load as well as high load performance improves, particularly
over high delay paths such as satellite links.
Another timer mistake seems to be in the backoff after a
retransmit: If we have to retransmit a packet more than once,
how should the retransmits be spaced? It turns out there's only
one scheme that's likely to work, exponential backoff, but
proving this is a bit involved (one of the two papers alluded to
in to opening goes through a proof). We might finesse a proof
by noting that a network is, to a very good approximation, a
linear system. (That is, it is composed of elements that behave
like linear operators -- integrators, delays, gain stages,
etc.). Linear system theory says that if a system is stable,
the stability is exponential. This suggests that if we have a
system that is unstable (a network subject to random load shocks
and prone to congestive collapse), the way to stabilize it is to
add some exponential damping (read: exponential timer backoff)
to its primary excitation (read: senders, traffic sources).
Once the timers are in good shape, you can state with some
confidence that a timeout really means a lost packet and not a
busted timer. At this point you can do something about (3).
Packets can get lost for two reasons: they are damaged in
transit or the network is congested and somewhere on the path
there was insufficient buffer capacity. On most of the network
paths we use, loss due to damage is rare (<<1%) so it is very
probable that a packet loss is due to congestion in the network.
Say we try to develop a `congestion avoidance' strategy like the
one Raj Jain, et.al., propose in DEC TR506 and ISO 8473. It
must have two components: The network must be able to signal
the transport endpoints that congestion is occurring (or about
to occur). And the endpoints must have a policy that decreases
utilization if this signal is received and increases utilization
if the signal isn't received.
If packet loss is (almost) always due to congestion and if a
timeout is (almost) always due to a lost packet, we have a good
candidate for the `network is congested' signal. Particularly
since this signal is delivered automatically by all existing
networks, without special modification (as opposed to, say, ISO
8473 which requires a new bit in the packet headers and a mod to
*all* existing gateways to set this bit).
[As a (lengthy) aside:
Using `lost packets' to communicate information seems to bother
people. The second of the two papers mentioned above is devoted
to analytic and simulation investigations of our algorithm under
various network conditions. I'll briefly mention some of the
objections we've heard and, I think, addressed.
There have been claims that signaling congestion via dropping
packets will adversely affect total throughput (it's easily
proved that the opposite is true) or that this signal will be
`too slow' compared to alternatives (The fundamental frequency
of the system is set by its average round trip time. From
control theory and Nyquist's theorem, any control strategy that
attempts to respond in less than two round trip times will be
unstable. A packet loss is detected in at most two rtt, the
minimum stable response time).
There have also been claims that this scheme will result in
unfair or sub-optimal resource allocation (this is untrue if
equivalent implementations of ISO and our schemes are compared)
or that mistaking damage for congestion will unnecessarily
throttle the endpoints on some paths with a high intrinsic loss
rate (this is mostly untrue -- the scheme we propose is
analytically tractable so we've worked out its behavior under
random loss. It turns out that window flow control schemes just
don't handle high loss rates well and throughput of a vanilla
TCP under high, random loss is abysmal. Adding our congestion
control scheme makes things slightly worse but the practical
difference is negligible. As an example (that we have calculated
and Jon Crowcroft at UCL has measured), it takes 40 256-byte
packets to fill the Satnet pipe. Satnet currently shows a
random, 1% average packet loss. The maximum throughput a
vanilla tcp could achieve at this loss rate is 56% of the 40kbs
channel bandwidth. The maximum throughput our TCP can achieve at
this loss rate is 49% of the channel bandwidth.
In theory, the use of dynamic congestion control should allow
one to achieve much better throughput under high loss than is
possible with normal TCP -- performance comparable to, say,
NETBLT over the same lossy link. The reason is that regular TCP
tries to communicate two different things with one number (the
window field in the packet): the amount of buffer the receiver
has available and the delay-bandwidth product of the pipe. Our
congestion control scheme separates these two numbers. The
sender estimates the pipe size so the receiver window need only
describe the receiver's buffer size. As long as the receiver
advertises a sufficiently large buffer, (twice the delay-
bandwidth product) a 1% loss rate would translate into a 1%
throughput effect, not a factor-of-two effect. Of course, we
have yet to put this theory to test.]
The other part of a congestion avoidance strategy, the endnode
action, is almost identical in Jain's DEC/ISO scheme and our
TCP. This is not an accident (we copied Jain's scheme after
hearing his presentation at the Boston IETF & realizing that the
scheme was, in a sense, universal): The endnode strategy
follows directly from a first-order time-series model of the
network. Say we measure network `load' by average queue length
over fixed intervals of some appropriate length (something near
the rtt). If L(i) is the load at interval i, a network not
subject to congestion can be modeled by saying L(i) changes
slowly compared to the sampling time. I.e.,
L(i) = N
(the average queue length doesn't change over time). If the
network is subject to congestion, this zero'th order model
breaks down. The average queue length becomes the sum of two
terms, the N above that accounts for the average arrival rate
of new traffic and a new term that accounts for the left-over
traffic from the last time interval:
L(i) = N + a L(i-1)
(As pragmatists, we extend the original model just enough to
explain the new behavior. What we're doing here is taking the
first two terms in a taylor series expansion of L(t) when we
find that just the first term is inadequate. There is reason to
believe one would eventually need a three term, second order
model, but not until the Internet has grown to several times its
current size.)
When the network is congested, the `a' term must be large and
the load (queues) will start increasing exponentially. The only
way to stabilize the system is if the traffic sources throttle
back at least as fast as the queues are growing. Since the way
a source controls load in a window-based protocol is to adjust
the size of the window, W, we end up with the sender policy
On congestion: W(i) = d W(i-1) (d < 1)
I.e., a multiplicative decrease of the window size. (This will
turn into an exponential decrease over time if the congestion
persists.)
If there's no congestion, the `a' term must be near zero and the
network load is about constant. You have to try to increase the
bandwidth you're using to find out the current limit (e.g., you
could have been sharing the path with someone else and converged
to a window that gives you each half the available bandwidth. If
he shuts down, 50% of the bandwidth will get wasted unless you
make some effort to increase your window size.) What should the
increase policy be?
The first thought is to use a symmetric, multiplicative increase,
possibly with a longer time constant. E.g., W(i) = b W(i-1),
1 < b <= 1/d. This is a mistake. The result will oscillate
wildly and, on the average, deliver poor throughput. The reason
why is tedious to explain. It has to do with that fact that it
is easy to drive the net into saturation but hard for the net
to recover (what Kleinrock, vol.2, calls the "rush-hour effect").
Thus overestimating the available bandwidth is costly. But an
exponential, almost regardless of its time constant, increases
so quickly that large overestimates are inevitable.
Without justification, I'll simply state that the best increase
policy is to make small, constant changes to the window size (if
you've had a control theory course, you've seen the justification):
On no congestion: W(i) = W(i-1) + u (u << the path delay-
bandwidth product)
I.e., an additive increase policy. This is exactly the policy that
Jain, et.al., suggest in DEC TR-506 and exactly the policy we've
implemented in TCP. The only difference in our implementations is
the choice of constants for `d' and `u'. We picked .5 and 1 for
reasons that are partially explained in the second of the attached
messages. A more complete analysis is in the second in-progress
paper (and may be discussed at the upcoming IETF meeting).
All of the preceding has probably made it sound as if the
dynamic congestion algorithm is hairy but it's not. Like
slow-start, it turns out to be three lines of code and one new
connection state variable (the combined slow-start/congestion
control algorithm is described in the second of the attached
msgs).
That covers about everything that's been done to date. It's
about 1/3 of what we think clearly needs to be done. The next
big step is to do the gateway `congestion detection' algorithms
so that a signal is sent to the endnodes as early as possible
(but not so early that the gateway ends up starved for traffic).
The way we anticipate doing these algorithms, gateway `self
protection' from a mis-behaving host will fall-out for free (that
host will simply have most of its packets dropped as the gateway
trys to tell it that it's using more than its fair share). Thus,
like the endnode algorithm, the gateway algorithm will improve
things even if no endnode is modified to do dynamic congestion
avoidance. And nodes that do implement congestion avoidance
will get their fair share of bandwidth and a minimum number of
packet drops.
Since congestion grows exponentially, detecting it early is
important. (If it's detected early, small adjustments to the
senders' windows will cure it. Otherwise massive adjustments
will be necessary to give the net enough spare capacity to pump
out the backlog.) But, given the bursty nature of traffic,
reliable detection is a non-trivial problem. There is a scheme
proposed in DEC TR-506 but we think it might have convergence
problems under high load and/or significant second-order dynamics
in the traffic. We are thinking of using some of our earlier
work on ARMAX models for rtt/queue length prediction as the
basis of the detection. Preliminary results suggest that this
approach works well at high load, is immune to second-order
effects in the traffic and is cheap enough to compute that it
wouldn't slow down thousand-packet-per-second gateways.
In addition to the gateway algorithms, we want to apply the
endnode algorithms to connectionless traffic (e.g., domain
server queries, RPC requests). We have the rate-based
equivalent of the TCP window algorithm worked out (there should
be a message describing it on the tcp list sometime in the near
future). Sun Microsystems has been very interested, and
supportive, during the development of the TCP congestion control
(I believe Sun OS 4.0 will ship with our new TCP) and Sun has
offered to cooperate in developing the RPC dynamic congestion
control algorithms, using NFS as a test-bed (since NFS is known
to have congestion problems).
The far future holds some work on controlling second-order, non-
ergodic effects, adaptively determining the rate constants in
the control algorithm, and some other things that are too vague
to mention.
- Van
----------------------------
To: markl@PTT.LCS.MIT.EDU
Subject: Re: interpacket arrival variance and mean
In-reply-to: Your message of Mon, 08 Jun 87 12:31:33 EDT.
Date: Mon, 15 Jun 87 06:08:01 PDT
From: Van Jacobson <van@lbl-csam.arpa>
Mark -
I'm working on long paper about transport protocol timers (models,
estimation, implementations, common implementation mistakes, etc.).
This has me all primed on the subject so attached is a long-winded
explanation and example C code for estimating the mean and variance
of a series of measurements.
Though I know your application isn't tcp, I'm going to use a new
tcp retransmit timer algorithm as an example. The algorithm
illustrates the method and, based on 3 months of experiment, is
much better than the algorithm in rfc793 (though it isn't as good
as the algorithm I talked about at IETF and am currently debugging).
Theory
------
You're probably familiar with the rfc793 algorithm for estimating
the mean round trip time. This is the simplest example of a
class of estimators called "recursive prediction error" or
"stochastic gradient" algorithms. In the past 20 years these
algorithms have revolutionized estimation and control theory so
it's probably worth while to look at the rfc793 estimator in some
detail.
Given a new measurement, Meas, of the rtt, tcp updates an
estimate of the average rtt, Avg, by
Avg <- (1 - g) Avg + g Meas
where g is a "gain" (0 < g < 1) that should be related to the
signal- to-noise ratio (or, equivalently, variance) of Meas.
This makes a bit more sense (and computes faster) if we rearrange
and collect terms multiplied by g to get
Avg <- Avg + g (Meas - Avg)
We can think of "Avg" as a prediction of the next measurement.
So "Meas - Avg" is the error in that prediction and the
expression above says we make a new prediction based on the old
prediction plus some fraction of the prediction error. The
prediction error is the sum of two components: (1) error due to
"noise" in the measurement (i.e., random, unpredictable effects
like fluctuations in competing traffic) and (2) error due to a
bad choice of "Avg". Calling the random error RE and the
predictor error PE,
Avg <- Avg + g RE + g PE
The "g PE" term gives Avg a kick in the right direction while the
"g RE" term gives it a kick in a random direction. Over a number
of samples, the random kicks cancel each other out so this
algorithm tends to converge to the correct average. But g
represents a compromise: We want a large g to get mileage out of
the PE term but a small g to minimize the damage from the RE
term. Since the PE terms move Avg toward the real average no
matter what value we use for g, it's almost always better to use
a gain that's too small rather than one that's too large.
Typical gain choices are .1 - .2 (though it's always a good
idea to take long look at your raw data before picking a gain).
It's probably obvious that Avg will oscillate randomly around
the true average and the standard deviation of Avg will be
something like g sdev(Meas). Also that Avg converges to the
true average exponentially with time constant 1/g. So
making g smaller gives a stabler Avg at the expense of taking
a much longer time to get to the true average.
[My paper makes the preceding hand-waving a bit more rigorous
but I assume no one cares about rigor. If you do care, check
out almost any text on digital filtering or estimation theory.]
If we want some measure of the variation in Meas, say to compute
a good value for the tcp retransmit timer, there are lots of
choices. Statisticians love variance because it has some nice
mathematical properties. But variance requires squaring (Meas -
Avg) so an estimator for it will contain two multiplies and a
large chance of integer overflow. Also, most of the applications
I can think of want variation in the same units as Avg and Meas,
so we'll be forced to take the square root of the variance to use
it (i.e., probably at least a divide, multiply and two adds).
A variation measure that's easy to compute, and has a nice,
intuitive justification, is the mean prediction error or mean
deviation. This is just the average of abs(Meas - Avg).
Intuitively, this is an estimate of how badly we've blown our
recent predictions (which seems like just the thing we'd want to
set up a retransmit timer). Statistically, standard deviation
(= sqrt variance) goes like sqrt(sum((Meas - Avg)^2)) while mean
deviation goes like sum(sqrt((Meas - Avg)^2)). Thus, by the
triangle inequality, mean deviation should be a more "conservative"
estimate of variation.
If you really want standard deviation for some obscure reason,
there's usually a simple relation between mdev and sdev. Eg.,
if the prediction errors are normally distributed, mdev =
sqrt(pi/2) sdev. For most common distributions the factor
to go from sdev to mdev is near one (sqrt(pi/2) ~= 1.25). Ie.,
mdev is a good approximation of sdev (and is much easier to
compute).
Practice
--------
So let's do estimators for Avg and mean deviation, Mdev. Both
estimators compute means so we get two instances of the rfc793
algorithm:
Err = abs (Meas - Avg)
Avg <- Avg + g (Meas - Avg)
Mdev <- Mdev + g (Err - Mdev)
If we want to do the above fast, it should probably be done in
integer arithmetic. But the expressions contain fractions (g < 1)
so we'll have to do some scaling to keep everything integer. If
we chose g so that 1/g is an integer, the scaling is easy. A
particularly good choice for g is a reciprocal power of 2
(ie., g = 1/2^n for some n). Multiplying through by 1/g gives
2^n Avg <- 2^n Avg + (Meas - Avg)
2^n Mdev <- 2^n Mdev + (Err - Mdev)
To minimize round-off error, we probably want to keep the scaled
versions of Avg and Mdev rather than the unscaled versions. If
we pick g = .125 = 1/8 (close to the .1 that rfc793 suggests) and
express all the above in C:
Meas -= (Avg >> 3);
Avg += Meas;
if (Meas < 0)
Meas = -Meas;
Meas -= (Mdev >> 3);
Mdev += Meas;
I've been using a variant of this to compute the retransmit timer
for my tcp. It's clearly faster than the two floating point
multiplies that 4.3bsd uses and gives you twice as much information.
Since the variation is estimated dynamically rather than using
the wired-in beta of rfc793, the retransmit performance is also
much better: faster retransmissions on low variance links and
fewer spurious retransmissions on high variance links.
It's not necessary to use the same gain for Avg and Mdev.
Empirically, it looks like a retransmit timer estimate works
better if there's more gain (bigger g) in the Mdev estimator.
This forces the timer to go up quickly in response to changes in
the rtt. (Although it may not be obvious, the absolute value in
the calculation of Mdev introduces an asymmetry in the timer:
Because Mdev has the same sign as an increase and the opposite
sign of a decrease, more gain in Mdev makes the timer go up fast
and come down slow, "automatically" giving the behavior Dave
Mills suggests in rfc889.)
Using a gain of .25 on the deviation and computing the retransmit
timer, rto, as Avg + 2 Mdev, my tcp timer code looks like:
Meas -= (Avg >> 3);
Avg += Meas;
if (Meas < 0)
Meas = -Meas;
Meas -= (Mdev >> 2);
Mdev += Meas;
rto = (Avg >> 3) + (Mdev >> 1);
Hope this helps.
- Van
---------------------------------
To: jain%erlang.DEC@decwrl.dec.com (Raj Jain, LKG1-2/A19, DTN: 226-7642)
Cc: ietf@gateway.mitre.org
Subject: Re: Your congestion scheme
In-Reply-To: Your message of 03 Nov 87 12:51:00 GMT.
Date: Mon, 16 Nov 87 06:03:29 PST
From: Van Jacobson <van@lbl-csam.arpa>
Raj,
Thanks for the note. I hope you'll excuse my taking the liberty
of cc'ing this reply to the ietf: At the last meeting there was a
great deal of interest in your congestion control scheme and our
adaptation of it.
> I am curious to know what values of increase amount and decrease
> factor did you use. In our previous study on congestion using
> timeout (CUTE scheme, IEEE JSAC, Oct 1986), we had found that the
> decrease factor should be small since packet losses are
> expensive. In fact, we found that a decrease factor of zero
> (decreasing to one) was the best.
We use .5 for the decrease factor and 1 for the increase factor.
We also use something very close to CUTE (Mike Karels and I were
behind on our journal reading so we independently rediscovered
the algorithm and called it slow-start). Since we use a lost
packet as the "congestion experienced" indicator, the CUTE
algorithm and the congestion avoidance algorithm (BTW, have you
picked a name for it yet?) get run together, even though they are
logically distinct.
The sender keeps two state variables for congestion control: a
congestion window, cwnd, and a threshhold size, ssthresh, to
switch between the two algorithms. The sender's output routine
sends the minimum of cwnd and the window advertised by the
receiver. The rest of the congestion control sender code looks
like: On a timeout, record half the current window size as
"ssthresh" (this is the multiplicative decrease part of the
congestion avoidance algorithm), then set the congestion window
to 1 packet and call the output routine (this initiates
slowstart/CUTE). When new data is acked, the sender does
something like
if (cwnd < ssthresh) // if we're still doing slowstart
cwnd += 1 packet // open the window exponentially
else
cwnd += 1/cwnd // otherwise do the Congestion
// Avoidance increment-by-1
Notice that our variation of CUTE opens the window exponentially
in time, as opposed to the linear scheme in your JSAC article.
We looked at a linear scheme but were concerned about the
performance hit on links with a large bandwidth-delay product
(ie., satellite links). An exponential builds up fast enough to
accomodate any bandwidth-delay and our testing showed no more
packet drops with exponential opening that with linear opening.
(My model of what slowstart is doing -- starting an ack "clock"
to meter out packets -- suggested that there should be no
loss-rate difference between the two policies).
The reason for the 1/2 decrease, as opposed to the 7/8 you use,
was the following hand-waving: When a packet is dropped, you're
either starting (or restarting after a drop) or steady-state
sending. If you're starting, you know that half the current
window size "worked", ie., that a window's worth of packets were
exchanged with no drops (slowstart guarantees this). Thus on
congestion you set the window to the largest size that you know
works then slowly increase the size. If the connection is
steady-state running and a packet is dropped, it's probably
because a new connection started up and took some of your
bandwidth. We usually run our nets with rho <= .5 so it's
probable that there are now exactly two conversations sharing the
bandwidth. Ie., that you should reduce your window by half
because the bandwidth available to you has been reduced to half.
And, if there are more than two conversations sharing the
bandwidth, halving your window is conservative -- and being
conservative at high traffic intensities is probably wise.
Obviously, this large decrease term is accounting for the high
cost of our "congestion experienced" indicator compared to yours --
a dropped packet vs. a bit in the ack. If the DEC bit were
available, the preceding "logic" should be ignored. But I wanted
tcp congestion avoidance that we could deploy immediately and
incrementally, without adding code to the hundreds of Internet
gateways. So using dropped packets seemed like the only choice.
And, in system terms, the cost isn't that high: Currently packets
are dropped only when a large queue has formed. If we had a bit
to force senders to reduce their windows, we'd still be stuck
with the queue since we'd still be running the bottleneck at 100%
utilization so there's no excess bandwidth available to dissipate
the queue. If we toss a packet, a sender will shut up for 2 rtt,
exactly the time we need to empty the queue (in the ususal case).
If that sender restarts with the correct window size the queue
won't reform. Thus we've reduced the delay to minimum without
the system losing any bottleneck bandwidth.
The 1-packet increase has less justification that the .5
decrease. In fact, it's almost certainly too large. If the
algorithm converges to a window size of w, you get O(w^2) packets
between drops with an additive increase policy. We were shooting
for an average drop rate of <1% and found that on the Arpanet
(the worst case of the 4 networks we tested), windows converged
to 8 - 12 packets. This yields 1 packet increments for a 1%
average drop rate.
But, since we've done nothing in the gateways, the window we
converge to is the maximum the gateway can accept without dropping
packets. I.e., in the terms you used, we are just to the left of
the cliff rather than just to the right of the knee. If we
now fix the gateways so they start dropping packets when the
queue gets pushed past the knee, our increment will be much too
agressive and we'll have to drop it by at least a factor of 4
(since all my measurements on an unloaded Arpanet or Milnet
place their "pipe size" at 4-5 packets). Mike and I have talked
about a second order control loop to adaptively determine the
appropriate increment to use for a path (there doesn't seem to
be much need to adjust the decrement). It looks trivial to
implement such a loop (since changing the increment affects
the frequency of oscillation but not the mean window size,
the loop would affect rate of convergence but not convergence
and (first-order) stability). But we think 2nd order stuff
should wait until we've spent some time on the 1st order part
of the algorithm for the gateways.
I'm tired and probably no longer making sense. I think I'll
head home and get some sleep. Hope to hear from you soon.
Cheers.
- Van
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Feb 88 11:24:15 EST From: terry@DVAX To: tcp-ip@sri-nic.arpa Cc: terry@dec-vax-11-750.arpa Subject: Data Acceptance Algorithms?
Hello All, I am trying to weigh the pros and cons of "in-order" versus "in-window" data acceptance algorithms for use in TCP. To do this, I need to know the "real" chances of a packet arriving out of order. It would seem to me that the extra overhead involved in an "in-window" algorithm would be wasted if packets are "almost always" delivered in order. Has anyone out there ever attempted to measure the percentage of out of order packets? I would like to collect as many samples from as many different networks as I can. Any help is appreciated. You may send your replies directly to me, and I will summarize to the net. Thanks in advance... Terry Robb ************************************************************************ *- Terence A. Robb -* *- Network Solutions -* *- Systems Programming Specialist -* *- MILnet: terry@dec-vax-11-750.arpa -* *- PHONEnet: (703) 749-1918 -* *- MAILnet: 8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180 -* ************************************************************************ *! !* *! Disclaimer !* *! !* *! I alone take responsiblity for the content of this message... !* *! but if there is any problem, blame my wife. !* *! !* ************************************************************************ -------
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 06:30:10 GMT From: guy@sun.uucp (Guy Harris) To: comp.protocols.tcp-ip Subject: Re: What is SLIP?
> I have been told that SLIP has its roots in an old serial protocol 3Com
> came up with for communicating between fileservers, and was adopted for
> use with IP and asynchronous serial lines some time later, initially for
> use between gateways (IP routers). Rick Adams did a public domain
> implementation for 4.2 Unix, and now one is distributed with 4.3.
The history, as I understand it (the CCI parts are correct - I was there - but
I don't know the history of this encapsulation scheme at 3Com):
3Com's UNET TCP/IP implementation had a serial line encapsulation
for IP packets. I don't know for what this encapsulation was
originally designed, but it was used in UNET for getting two machines
with serial port hardware and nothing else to talk IP to each other;
it was not just used between gateways.
The Naval Surface Weapons Center put out a bid for an office
automation system; Computer Consoles, Inc. bid a system consisting of
two VAXes running 4.2BSD (with S5 compatibility additions) and lots of
CCI Power 5/20 machines running S3 with UNET. There needed to be
*some* way to get the 5/20s to talk to the VAXes, so Rick whipped up
the original SLIP; it used the 3Com encapsulation so it could talk to
the 5/20s running UNET.
He subsequently reimplemented it while at the Center for Seismic
studies.
> I have heard that Sun will support it soon, if not already,
We don't have it now; I don't expect it to be officially supported in the next
release, but Rick does have a version that can, I believe, be put into current
SunOS releases, and I expect there will be versions to put into future
releases. It may end up in a future release, but I don't know one way or the
other.
--
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
guy@sun.com (or guy@sun.arpa)
-----------[000170][next][prev][last][first]----------------------------------------------------
Date: 12 Feb 88 12:32:00 EST
From: <enger@bluto.scc.com>
To: "terry" <terry@DEC-VAX-11-750.ARPA>
Cc: <tcp-ip@sri-nic.arpa>
Subject: TCP/IP posting regarding Data Acceptance Algorithms "!@#$%^&(){}."I would like to recommend that consideration also be given to the pros and cons of sending out mail containing an incomplete From: field. Bob -------
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Feb 88 13:32:07 EST From: terry@DVAX To: tcp-ip@sri-nic.arpa Cc: terry@dec-vax-11-750.arpa Subject: Complete FROM: field.
(Note the FROM: field of all my outgoing mail contains "terry@DVAX") >I would like to recommend that consideration also be given to the pros and >cons of sending out mail containing an incomplete From: field. > >Bob Bob, If your message is meant to suggest that my mail message contained an incomplete "FROM:" field, I feel compelled to answer. The address was complete. It is the COMPLETE address of my node on our local net. I will agree is doesn't conform to standards. If I had the authority to change the name to meet the standard format, I would. (Not that you could use it anyway.) However, please note I did include my COMPLETE MILNET address at the bottom of my message, and, most importantly, I included the proper punctuation at the end of my subject line. --- Terry Robb --- P.S. If your mail message meant something else... nevermind. ************************************************************************ *- Terence A. Robb -* *- Network Solutions -* *- Systems Programming Specialist -* *- MILnet: terry@dec-vax-11-750.arpa -* *- PHONEnet: (703) 749-1918 -* *- MAILnet: 8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180 -* ************************************************************************ *! !* *! Disclaimer !* *! !* *! I alone take responsiblity for the content of this message... !* *! but if there is any problem, blame my children. !* *! !* ************************************************************************ -------
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 1988 13:37-EST From: CLYNN@G.BBN.COM To: tcp-ip@SRI-NIC.ARPA Subject: Re: DCA Protocol Lab Test Tools
Bob, Could you summarize the sorts of problems that the testing suite has found? I think that the list of "common" bugs, maybe sorted in order of decreasing frequency, would be helpful both to those who are doing implementations and to those who are trying to make the specs clearer. Charlie -------
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Feb 88 15:09 EDT From: <JFISHER%USGSRESV.BITNET@CUNYVM.CUNY.EDU> (James R. Fisher) To: tcp-ip@sri-nic.arpa Subject: Re: DCA Protocol Lab Test Tools (& NSFnet Medal)
My eyebrows recently raised on seeing reference to the NSFnet Medal for implementations. We are thinking of joining NSFnet and I would VERY much like to hear of known defects and perceived problems with NSFnet, AND of any implementations which are worthy of the Medal. Flames welcome. -------
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 14:19:11 GMT From: kleonard@gvlv2.UUCP (Ken Leonard --> kleonard@gvlv2@prc.unisys.com) To: comp.protocols.tcp-ip Subject: bouncepass
just checking to see if addresses work--please do minimum reply thanx Ken
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Feb 88 19:36 From: John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@relay.MOD.UK> To: tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa> Subject: Re: Dynamic Congestion Avoidance / Control
Delighted by Van Jacobson's msg. It merits a NOBEL prize. Is the King of Sweden on the net? John -------
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 15:18:38 GMT From: merlin@hqda-ai.UUCP (David S. Hayes) To: comp.protocols.tcp-ip Subject: Re: What is SLIP?
In article <41751@sun.uucp>, guy@sun.uucp (Guy Harris) writes:
> We don't have it now; I don't expect it to be officially supported
> in the next release, but Rick does have a version that can, I
> believe, be put into current SunOS releases, and I expect there
> will be versions to put into future releases. It may end up in a
> future release, but I don't know one way or the other.
>
> Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy
> guy@sun.com (or guy@sun.arpa)
Sun should be adding this. Yes, there is a SLIP that runs on
Suns. It was "solarized" by Chris Torek at the University of
Maryland. I have tried it, and it does work.
The problem is that in a binary-only Sun release, there is
no way to support a "disconnect-interface" procedure. This
results in a kernel crash if the remote end goes away. With a
dedicated hardwire line, that's not too much of a problem, but it
can be a real pain when you've got some intervening hardware.
Sun should add a full SLIP, including disconnect,
immediately. The code is already available from Chris Torek,
including the disconnect business. For a company that claims that
"The network is the computer," here's an opportunity to put that
motto into practice.
--
David S. Hayes, The Merlin of Avalon PhoneNet: (202) 694-6900
UUCP: *!uunet!cos!hqda-ai!merlin ARPA: ai01@hios-pent.arpa
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 16:24:15 GMT From: terry@DVAX To: comp.protocols.tcp-ip Subject: Data Acceptance Algorithms?
Hello All, I am trying to weigh the pros and cons of "in-order" versus "in-window" data acceptance algorithms for use in TCP. To do this, I need to know the "real" chances of a packet arriving out of order. It would seem to me that the extra overhead involved in an "in-window" algorithm would be wasted if packets are "almost always" delivered in order. Has anyone out there ever attempted to measure the percentage of out of order packets? I would like to collect as many samples from as many different networks as I can. Any help is appreciated. You may send your replies directly to me, and I will summarize to the net. Thanks in advance... Terry Robb ************************************************************************ *- Terence A. Robb -* *- Network Solutions -* *- Systems Programming Specialist -* *- MILnet: terry@dec-vax-11-750.arpa -* *- PHONEnet: (703) 749-1918 -* *- MAILnet: 8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180 -* ************************************************************************ *! !* *! Disclaimer !* *! !* *! I alone take responsiblity for the content of this message... !* *! but if there is any problem, blame my wife. !* *! !* ************************************************************************
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 16:49:29 GMT From: kleonard@gvlv2.UUCP (Ken Leonard --> kleonard@gvlv2@prc.unisys.com) To: comp.protocols.tcp-ip Subject: oops
Hal... Unfortunately (or vice-versa), I'm now mostly out of the loop on ProtoLab, and on testing in general. Am now dealing with new species of lizards--sort of armored on the outside but, as usual, not very well done on the inside. Regardz, Ken
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 16:51:36 GMT From: kleonard@gvlv2.UUCP (Ken Leonard --> kleonard@gvlv2@prc.unisys.com) To: comp.protocols.tcp-ip Subject: oops
Dave... A flakeway, humm.... Sounds like time to get out the flatboat and go fishin'. Talk to bobj and judym about the flakerizing abilities of ProtoLab corruption mode testing. Deck us all with Boston Charlie! Ken
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 16:58:57 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Life in the Swamps / Testing
Dave,
I love the idea and wish it were mine, but I cannot take credit for
the flakeway. I stole both the concept and the term from the BBN
wizards Bill Plummer and Ray Tomlinson. They came up with the first
flakeway under TOPS-20, during the early TCP/IP days. [I have seen
the listing of that program, and I think I remember Ray actually
wrote it; but Bill was responsible for popularizing it in the
research community at that time [[about 1976-1978]]]. My only
contribution was to write a flakeway for the UCLA ACP; it ran
for there many years, reachable via source routing.
(For those who don't know, "flakeway" is a contraction of "flakey
gateway", a test gateway implementation set to deliberately
and randomly reorder, delay, and/or drop packets with some set
specified frequency distributions. The idea was to test your
TCP/IP implementation through such a monster).
From an historical perspective, it is interesting that the
early work DID include real concern about robustness in the
presence of long delays and packet losses, and there was active
testing implementations under such conditions. Then the second-
generation of implementors came along, and worked entirely in the
Ethernet environment, promptly ignoring/forgetting the lessons
already learned. One can speculate that if there were no LAN's
in the world, we would have discovered (perforce) all the wonderful
Van Jacobson ideas about 8 years ago.
Bob Braden
-----------[000181][next][prev][last][first]----------------------------------------------------
Date: 12 Feb 88 17:32:00 GMT
From: enger@BLUTO.SCC.COM
To: comp.protocols.tcp-ip
Subject: TCP/IP posting regarding Data Acceptance Algorithms "!@#$%^&(){}."I would like to recommend that consideration also be given to the pros and cons of sending out mail containing an incomplete From: field. Bob
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 17:43:38 GMT From: kleonard@gvlv2.UUCP (Ken Leonard --> kleonard@gvlv2@prc.unisys.com) To: comp.protocols.tcp-ip Subject: OUCH
WOW! when this mailer and this user decide to munge an alias, we do it RIGHT!
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 18:10:00 GMT From: SRA@XX.LCS.MIT.EDU (Rob Austein) To: comp.protocols.tcp-ip Subject: A plea for sanity
Date: Thursday, 11 February 1988 20:13-EST
From: mcc@etn-wlv.eaton.com (Merton Campbell Crockett)
[...]
Perhaps its a problem with my view of electronic mail,
particularly mail that is for forwarded to "tcp-ip@sri-nic.arpa";
it is irrelevant to me whether a subscriber to this service from
"bangland" failed to leave his PC powered-up to receive my comment
or retort of questionable significance. Why should I be inundated
with "unable to deliver to xxx" messages? Its "tcp-ip" that needs
the knowledge as it may signify some network problem!
It does raise some questions about SMTP and its interpretation of "From:"
and "Forwarded by:". The reporting of delivery errors should always be
delivered to the "Forwarded by:" individual not the "From:" individual who
may not have authorized the dissemination of the message.
Merton,
First off, TCP-IP is not really the place for this discussion (I know,
you didn't start it either). If people want to continue it, please do
so in private or on Header-People@MC.LCS.MIT.EDU, the list for
discussion of mail protocols and lossage in the implementation of
those protocols.
Second, you should know that the SRI-NIC.ARPA mailer does everything
in its power to keep you from ever seeing those bounce messages:
specificly, it bashes the SMTP return-path of outgoing TCP-IP messages
to "TCP-IP-RELAY@SRI-NIC.ARPA". Thus, anybody playing the game
correctly will send any and all automatic delivery flames to the list
maintainers at SRI-NIC, not to you (see RFC821 if this isn't clear).
The problem is that there are an awful lot of broken mailers out
there. Chief offender in recent months has been one or more BITNET
mailers that discard the envelope ((B)SMTP) information and rewrite
the RFC822 message headers (which they then use for mail routing) in
completely bizzare ways. This is worse than just throwing all the
mail on the floor, these mailers are very "smart" at figuring out who
the original sender of a message was so that they can torment her with
useless bug reports. It has gotten to the point where posting a dozen
messages to one of the mailing lists I maintain produces over a
megabyte of mis-addressed garbage; I've started getting complaints
from subscribers because their (de)subscription requests are getting
lost under all this junk and thus being accidently ignored.
So, in closing (and as I've said on Header-People before), the problem
is not deficiencies in the existing mail protocols. The problem is
mailers that don't implement the existing protocols and system
administrators who are unwilling/unable to install versions of the
mailers that DO implement the protocols correctly. The main reason I
keep bringing this up in various forums is a hope that part of the
problem is ignorance on the part of the maintainers of the machines
running the broken mailers.
--Rob
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 18:32:07 GMT From: terry@DVAX To: comp.protocols.tcp-ip Subject: Complete FROM: field.
(Note the FROM: field of all my outgoing mail contains "terry@DVAX") >I would like to recommend that consideration also be given to the pros and >cons of sending out mail containing an incomplete From: field. > >Bob Bob, If your message is meant to suggest that my mail message contained an incomplete "FROM:" field, I feel compelled to answer. The address was complete. It is the COMPLETE address of my node on our local net. I will agree is doesn't conform to standards. If I had the authority to change the name to meet the standard format, I would. (Not that you could use it anyway.) However, please note I did include my COMPLETE MILNET address at the bottom of my message, and, most importantly, I included the proper punctuation at the end of my subject line. --- Terry Robb --- P.S. If your mail message meant something else... nevermind. ************************************************************************ *- Terence A. Robb -* *- Network Solutions -* *- Systems Programming Specialist -* *- MILnet: terry@dec-vax-11-750.arpa -* *- PHONEnet: (703) 749-1918 -* *- MAILnet: 8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180 -* ************************************************************************ *! !* *! Disclaimer !* *! !* *! I alone take responsiblity for the content of this message... !* *! but if there is any problem, blame my children. !* *! !* ************************************************************************
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 18:37:00 GMT From: CLYNN@G.BBN.COM To: comp.protocols.tcp-ip Subject: Re: DCA Protocol Lab Test Tools
Bob, Could you summarize the sorts of problems that the testing suite has found? I think that the list of "common" bugs, maybe sorted in order of decreasing frequency, would be helpful both to those who are doing implementations and to those who are trying to make the specs clearer. Charlie
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 18:50:23 GMT From: isns01@ms3.UUCP (Jim Chappell) To: comp.protocols.tcp-ip Subject: DDN Connection Problems
I've followed the PSN 7.0 dialog, but haven't seen my aspect of the problem discussed: Occasionally, near an hour hack, (9:58, for example,) we begin getting syslog msgs: 'No buffer space available' from sendmail, mconnect, etc. accessing particular systems. At the same time we have no problems getting to other systems. The milnet NOC tells us to reboot; but I doubt their veracity. The problem clears up at near another hour hack. Could someone be turning us on and off at the PSN side? Wwe are running vanilla 4.2BSD (We are getting ready to upgrade to 4.3BSD) and 1822. -- Jim Chappell UUCP: ...!umd5!vrdxhq!ms3!jrc ISN Corp. (703) 979-8900 ARPA: jrc@hios-pent 1235A Jeff Davis Hwy, Suite 220 Arlington, Va 22202
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 19:09:00 GMT From: JFISHER@USGSRESV.BITNET (James R. Fisher) To: comp.protocols.tcp-ip Subject: Re: DCA Protocol Lab Test Tools (& NSFnet Medal)
My eyebrows recently raised on seeing reference to the NSFnet Medal for implementations. We are thinking of joining NSFnet and I would VERY much like to hear of known defects and perceived problems with NSFnet, AND of any implementations which are worthy of the Medal. Flames welcome.
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 88 22:09:49 GMT From: schoff@NISC.NYSER.NET (Martin Lee Schoffstall) To: comp.protocols.tcp-ip Subject: sgmp v2.0 documentation available
Due to demand the documentation for the V2.0 of the NYSERNet implementation of SGMP/SNMP (man pages, interface description, and overall description) is now available via anonymous ftp from nisc.nyser.net in snmp/v2doc.tar This is about 90Kbytes. Marty Schoffstall
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 88 01:46:17 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Re: Life in the Swamps / Testing
Regarding Testing: It is an economic issue. Who could argue that bakeoffs aren't very useful? Who can argue that conformance testing against a "standard" isn't useful? Neither is sufficient to ensure interoperability in all cases. Heck, the randomness of network behaviour ensures that we will never get it perfect. (Folks stil find bugs in 20 year old Fortran and Cobol compilers...) If we had a test suite that was in some sense 'official" we would not have fiascos like I saw at Uniforum this week! There was the usual "hook all the TCP/IP speaking booths together" party. And it barely worked. Why? Two reasons: 1) Not everyone did subnetting "right" and 2) the rwho broadcast storms made the net unusable much of the time. If we had a conformance test suite available that everyone could test against, then these two rather simple hurdles could be tested for and vendors would have to pass them to get a "certificate". Would this make the world "perfect"? Probably not, but it would make it a lot, lot better! Folks, we are actually trying to get our work done with these marvelous networks. And the world is going to be a lot better off when we are all able to communicate with each other with ease. Let's all vote to support whatever it takes to make it work well. No one approach will suffice. Dan -------
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 88 03:36:00 GMT From: LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE) To: comp.protocols.tcp-ip Subject: Re: Dynamic Congestion Avoidance / Control
Delighted by Van Jacobson's msg. It merits a NOBEL prize. Is the King of Sweden on the net? John
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: Sat, 13 Feb 88 12:18:47 PST From: satz@clash.cisco.com To: Dan Lynch <LYNCH@a.isi.edu> Cc: Mills@louie.udel.edu, hrp%windsor.CRAY.COM@umn-rei-uc.arpa, kleonard@burdvax.prc.unisys.com, bobj@mcl.unisys.com, dcmartin@protolaba.arpa, tcp-ip@sri-nic.arpa Subject: Re: Life in the Swamps / Testing
>> If we had a test suite that was in some sense 'official" we would not >> have fiascos like I saw at Uniforum this week! There was the usual >> "hook all the TCP/IP speaking booths together" party. And it barely >> worked. Why? Two reasons: 1) Not everyone did subnetting "right" >> and 2) the rwho broadcast storms made the net unusable much of >> the time. If we had a conformance test suite available that everyone >> could test against, then these two rather simple hurdles could be tested >> for and vendors would have to pass them to get a "certificate". Would >> this make the world "perfect"? Probably not, but it would make it a lot, lot >> better! The major problem with the Uniforum network was misconfiguration and lack of understanding of all of the broadcast addresses. However the misconfiguration was so bad the it was almost impossible to discern broadcasts from other packets. What happened was that the show-net started out to be network 89 with a subnet number of 1. People who requested individual subnet numbers got them starting at some larger number. Interestingly enough, however, was that people weren't able to live with this arrangement for some reason networks like 8.0.0.0 and 1.0.0.0 started appearing instead. Unfortunately some hosts were still sending out [IP] subnet broadcasts instead of network broadcasts or general broadcasts (all ones). Test suites can do little to solve this problem. I also saw random ICMP message types flying around and packets with bad checksums. A real live test suite would go along way toward eliminating this problem. The unusability of the network stemmed from a few hosts that were generating error rates of 10%. Excelan, the show-net manager, quickly resolved the problem when it was pointed out to them, much to their credit. Aside from all of that, it seems that Sun was advertising all of its many networks via RIP and HP was offering a portal into its network with an IGRP route. Sun refused to pass packets to the MILnet and HP blocked access to the ARPAnet. -------
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: Sat, 13 Feb 88 10:03:21 EST From: Frank Kastenholz <KASTEN@MITVMA.MIT.EDU> To: TCP/IP List <TCP-IP@SRI-NIC.ARPA> Subject: Verification Suite
Hal Peterson (hrp%windsor.CRAY.COM@uc.msc.umn.edu) at Cray wrote >I should stress, though, that a verification suite is only part of a >comprehensive testing strategy, and that bake-offs can be extremely >valuable for finding bugs. A verification suite is software, and like >all software it is imperfect. It is entirely possible that two >implementations both pass the suite but don't interoperate. Bake-offs >can catch that, and when they do they have found as many as FOUR bugs: > >1. a bug in one of the implementations. >2. a bug in the other implementations; after all, they could both be > at fault. >3. a bug in the specification. It may be unclear or inconsistent or > incomplete and so have misled the implementors. >4. a bug in the verification suite. It should have caught the > problem, and next time it will, since it's a simple matter to add > a test to a well-designed suite. The suite gets better as time > goes on. His last two points bring two simple(?) questions to mind - How do the Specification Bugs get resolved? Who Verifies the Verification Suite???? (Qui Ipsos Custode Custodiet) Frank Kastenholz Atex Inc. -------
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 1988 12:17-EST From: CERF@A.ISI.EDU To: JBVB@AI.AI.MIT.EDU Cc: rti!scirtp!scott@MCNC.ORG, tcp-ip@SRI-NIC.ARPA Subject: Re: TCP/IP-NETBIOS Info Wanted
James, Doesn't the use of TCP/IP to support NETBIOS also open up the possibility of interactions between PCs in the TCP/IP-extended NETBIOS environment and hosts in the rest of the Internet (or private internet)? I think it was this extension of interaction which was the major motivating factor for people like Dave Crocker (then of Ungermann-Bass, now of Wollongong). Vint
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 88 07:22:01 GMT From: chris@GYRE.UMD.EDU (Chris Torek) To: comp.protocols.tcp-ip Subject: Re: What is SLIP?
Careful! I only rewrote Rick Adams' code for 4.3BSD, removing the horrible hacks needed to make it work in a binary-only system, where there is no way to attach the interfaces at kernel startup. Mark Weiser re-re-edited the code to run under several different SunOS releases; various versions of this are available via anonymous FTP from host mimsy.umd.edu. At the moment, mimsy is being emulated by a Sun-3/50 with less than 5% of the disk space of the Vax-11/780-5 whose place it is holding, and the FTP archives are unavailable. We anticipate that the machine should be working again by the middle of next week, assuming that nothing major went wrong when it was moved across the campus. Please also restrict anonymous FTP access to 7 AM to 7 PM EST (1200 to 0000 UTC) if possible. Chris
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 88 12:37:39 GMT From: leonid@TAURUS.BITNET To: comp.protocols.tcp-ip Subject: Ip gateways vs. RFC 1009
I am researching the available equipment that is able to interconnect
TCP/IP LANs via leased lines, i.e. IMPlets. If you are running such
a network or have seen a report on this subject I would be most greteful
if you send me your comments, or a pointer to such a report.
We know about the Proteon, CISCO and Bridge GS/3M gatewys, are there many
more ? How do these and others comply with RFC 1009 specifications and
recommendations ? Another aspect of interest is the ability of the Gateway
to act as a DECNET gateway at the same time.
Please send your replies directly to me via e-mail, since I am not subscribed
to this mailing list. Many thanks.
Leonid Rosenboim, Tel-Aviv University, Israel.
leonid@taurus.BITNET
@cunyvm.cuny.edu:leonid@taurus.BITNET
leonid%taurus.BITNET@cnuce-vm.arpa
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 88 15:03:21 GMT From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: Verification Suite
Hal Peterson (hrp%windsor.CRAY.COM@uc.msc.umn.edu) at Cray wrote >I should stress, though, that a verification suite is only part of a >comprehensive testing strategy, and that bake-offs can be extremely >valuable for finding bugs. A verification suite is software, and like >all software it is imperfect. It is entirely possible that two >implementations both pass the suite but don't interoperate. Bake-offs >can catch that, and when they do they have found as many as FOUR bugs: > >1. a bug in one of the implementations. >2. a bug in the other implementations; after all, they could both be > at fault. >3. a bug in the specification. It may be unclear or inconsistent or > incomplete and so have misled the implementors. >4. a bug in the verification suite. It should have caught the > problem, and next time it will, since it's a simple matter to add > a test to a well-designed suite. The suite gets better as time > goes on. His last two points bring two simple(?) questions to mind - How do the Specification Bugs get resolved? Who Verifies the Verification Suite???? (Qui Ipsos Custode Custodiet) Frank Kastenholz Atex Inc.
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 88 17:17:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: TCP/IP-NETBIOS Info Wanted
James, Doesn't the use of TCP/IP to support NETBIOS also open up the possibility of interactions between PCs in the TCP/IP-extended NETBIOS environment and hosts in the rest of the Internet (or private internet)? I think it was this extension of interaction which was the major motivating factor for people like Dave Crocker (then of Ungermann-Bass, now of Wollongong). Vint
-----------[000198][next][prev][last][first]----------------------------------------------------
Date: 13 Feb 88 19:05:20 GMT
From: slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To: comp.protocols.tcp-ip
Subject: Re: A plea for sanity(In reply to Rob Austein's message <SRA.12374181810.BABYL@XX.LCS.MIT.EDU>) I don't think it's fair to call a mailer "broken" because it retains the address of the original sender for reply purposes. If mailing-list redistributions eradicated the original From: line, replacing the original sender's address with that of the redistributor, their mailing lists would be far less useful. Ditto if our mailers replied according to the SMTP envelope rather than the body of the message. Note that the envelope's format is not specified by RFC 822, only the message header is -- and messages can be delivered by other means besides SMTP. Though RFC 822 doesn't define it, I've seen some mailing lists distribute messages with an Errors-To: line. This seems to be just what's needed to separate message replies from delivery error replies. Sendmail seems to support "Errors-To"; how many other mailers do? Stuart Levy, Minn. Supercomputer Center
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 88 20:18:47 GMT From: satz@clash.cisco.COM To: comp.protocols.tcp-ip Subject: Re: Life in the Swamps / Testing
>> If we had a test suite that was in some sense 'official" we would not >> have fiascos like I saw at Uniforum this week! There was the usual >> "hook all the TCP/IP speaking booths together" party. And it barely >> worked. Why? Two reasons: 1) Not everyone did subnetting "right" >> and 2) the rwho broadcast storms made the net unusable much of >> the time. If we had a conformance test suite available that everyone >> could test against, then these two rather simple hurdles could be tested >> for and vendors would have to pass them to get a "certificate". Would >> this make the world "perfect"? Probably not, but it would make it a lot, lot >> better! The major problem with the Uniforum network was misconfiguration and lack of understanding of all of the broadcast addresses. However the misconfiguration was so bad the it was almost impossible to discern broadcasts from other packets. What happened was that the show-net started out to be network 89 with a subnet number of 1. People who requested individual subnet numbers got them starting at some larger number. Interestingly enough, however, was that people weren't able to live with this arrangement for some reason networks like 8.0.0.0 and 1.0.0.0 started appearing instead. Unfortunately some hosts were still sending out [IP] subnet broadcasts instead of network broadcasts or general broadcasts (all ones). Test suites can do little to solve this problem. I also saw random ICMP message types flying around and packets with bad checksums. A real live test suite would go along way toward eliminating this problem. The unusability of the network stemmed from a few hosts that were generating error rates of 10%. Excelan, the show-net manager, quickly resolved the problem when it was pointed out to them, much to their credit. Aside from all of that, it seems that Sun was advertising all of its many networks via RIP and HP was offering a portal into its network with an IGRP route. Sun refused to pass packets to the MILnet and HP blocked access to the ARPAnet.
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 88 20:20:05 GMT From: MRC@PANDA.PANDA.COM (Mark Crispin) To: comp.protocols.tcp-ip Subject: Re: A plea for sanity
Stuart -
You completely misunderstand the issue. SMTP (RFC 821) defines an
address that mailer error reports (as distinguished from replies) are
sent to. The BITNET mailers in question are using the reply address,
ignoring the errors address, to send errors reports to.
The BITNET mailers which do this are broken.
Errors-To: is completely unnecessary if SMTP is correctly implemented.
If you are using a non-SMTP transport, it should possess this functionality
OR it should do whatever equivalent exists in that transport to pass on that
address.
-- Mark --
PS: I am the implementor of one of the major electronic mail packages in
use on the Internet, and have been for 9 years. I know what I'm
talking about.
-------
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 88 02:09:22 GMT From: roy@phri.UUCP (Roy Smith) To: comp.protocols.tcp-ip Subject: Re: A plea for sanity (Errors-To: lines)
Stuart Levy writes:
> Sendmail seems to support "Errors-To"; how many other mailers do?
A couple of years ago I was running a small mailing list and decided
to add "Errors-To:" headers to outgoing messages. Much to my surprise I got
some rather angry mail from a system administrator somewhere in Europe who
said that his mailer didn't grok the "Errors-To:" lines. Not only didn't his
mailer grok the lines, but it couldn't digest them or even consume them and
pass them through unchanged. It seems that when his mailer saw the
"Errors-To:" line it died, wreaking all sorts of havok and mayhem on his
machine. He urgently requested that I either stop adding the non-standard
headers or stop sending mail to his machine!
Personally I thought he (and/or his mailer) was over-reacting, but I
decided to drop the "Errors-To:" anyway.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: Sun, 14 Feb 88 16:18:38 PST From: JLarson.pa@Xerox.COM To: Header-People@MC.LCS.MIT.EDU, TCP-IP@SRI-NIC.ARPA Cc: SRA@XX.LCS.MIT.EDU, JLarson.pa@Xerox.COM Subject: Xerox experience with broken mailer behaviour
We at Xerox were badly burned recently by sites which;
1) Do not use the domain name system to look up IP addresses
2) Pick the "best" address (usually net 10) from the host table,
and never try any other address in the list.
Our story should explain why I now consider 2) to be severely broken mailer
behaviour. We installed an IP gateway at our PSN where the Xerox.Com mail
gateway used to be, so the address for Xerox.Com changed from a net 10 address
to a net 13 subnet address. The Xerox.Com domain name server had the correct
information, so those sites properly using the domain name system did not have a
problem. But our update to the host table (to remove the net 10 address from
Xerox.Com) got stalled in DDN red tape for several weeks (even though that same
net net 10 address was already in the host table in the GATEWAY entry!). So,
although we were allowed to place the correct net 13 subnet address as the first
address in the host table, the bogus net 10 address (now the IP gateway) could
not be removed from the host table for those several weeks.
You guessed it; those mailers in 2) picking the "best" address from the host
table were picking a BOGUS address, mail failed to go through for several weeks
from these sites, and the result was irate many mail users and flurries of mail
between postmasters. Note that the equivalent problem would have resulted if
that net 10 interface went down for an extended period, and there were an
alternate route to our net 13 subnet. (Yes folks, network interfaces do go
down, sometimes even for extended periods.)
There is little excuse for this broken mailer behaviour since it should be easy
to fix, even for mailers which are very heavily loaded.
The solution is quite simple; using that "best" address is fine for the FIRST
attempt, but on later retries the BEST address to use is a DIFFERENT address in
the address list. Simply rotate the previously used address to the end of the
list, and use the next address in the address list on the next retry attempt.
Note that you need only try one address each attempt, so there is no detrimental
impact on a busy mailer. (The Xerox.com mailer implementation in fact knows how
busy it is and adjusts timeout values and multiple address attempts accordingly
to keep keep sick sites from affecting throughput when busy. When not busy, it
tries all the addresses, and uses longer timeout values.)
Hopefully this message will prompt certain mail implementers to fix their broken
mailers, and prompt sites to start using the domain name system so others can
avoid our painful transition experience.
Cheers,
John Larson
Xerox PARC
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 88 18:12:07 GMT From: brian@wb6rqn.UUCP (Brian Lloyd) To: comp.protocols.tcp-ip Subject: SLIP and Telebit modems
We use Telebit Trailblazer+ modems here to communicate between systems
running TCP/IP/SLIP. Throughput is enhanced by sending large segments
and very large windows but if you get things too large you run the risk
of overflowing the buffers in the TB+.
The solution here is to enable the hardware handshaking (Trailblazer+
drops CTS and the host stops sending data). This will guarantee that
the TB+ buffers will never overflow. Flow control in the reverse
direction, e.g. from the modem to the host, has not been a problem
since our implementation of SLIP on the Convergent boxes seems happy to
accept data at 19,200 bps.
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Feb 88 13:27-0800 From: The Mail Server<Postmaster@locke.hs.WASHINGTON.EDU> To: <TCP-IP@SRI-NIC.ARPA> Subject: Undeliverable mail
Message had a bad or missing To address. The entire text of the message follows: Received: by BYUADMIN (Mailer X1.25) id 5978; Mon, 15 Feb 88 14:15:10 MST Date: Mon, 15 Feb 88 15:51:52 EST From: Bob Jones <bobj@MCL.UNISYS.COM> Subject: Re: DCA Protocol Lab Test Tools Sender: "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN> To: "(no name)" <BRUCE@UWALOCKE> Reply-to: <TCP-IP@SRI-NIC.ARPA> X-To: hrp%windsor.CRAY.COM@uc.msc.umn.edu X-cc: mills@udel.edu, tcp-ip@sri-nic.arpa Hal, thanks for comments. I am hoping some industrious laboratory will offer the remote drivers in some generic for that can be quickly adapted to any machine environ (with generic hooks?). If it will be of any comfort to you, we are at a point where all of the specs are firm now. Thanks to you, we have learned a lot and your persistence has helped us to debug our test system in the process. Cray deserves a hand! bobj -------
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Feb 88 13:36-0800 From: The Mail Server<Postmaster@locke.hs.WASHINGTON.EDU> To: <TCP-IP@SRI-NIC.ARPA> Subject: Undeliverable mail
Message had a bad or missing To address. The entire text of the message follows: Received: by BYUADMIN (Mailer X1.25) id 5437; Mon, 15 Feb 88 14:12:36 MST Date: Mon, 15 Feb 88 11:11:38 IST From: Hank Nussbacher <HANK%TAUNIVM.BITNET@CNUCE-VM.ARPA> Subject: cisco AGS vs. Proteon p4200 Sender: "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN> To: "(no name)" <BRUCE@UWALOCKE> Reply-to: <TCP-IP@SRI-NIC.ARPA> X-To: tcp-ip@sri-nic.ARPA Does anyone have any comparison study of these two multiprotocol routers? If you have any comparison numbers, I would love to see them. Thanks, Hank
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 88 02:18:09 GMT From: MRC@PANDA.PANDA.COM (Mark Crispin) To: comp.protocols.tcp-ip Subject: trying multiple addresses
I am sure the advocates of trying multiple mail addresses would
feel quite differently if they had to pay per-packet charges for network
access. Historically, only a small percentage of network connection
failures -- typically less than 1% -- have been due to a dysfunctional
IP address. The remaining (= overwhelming majority of) failures have
been due to dysfunctional networks, dysfunctional hosts, or dysfunctional
servers.
It is possible that trying a different IP address may help in the
dysfunctional network case, although typically the "non-best" IP addresses
all involve the dysfunctional network in some way (look at some network
topology maps some time). This is a relatively rare case anyway.
Many times, the "non-best" IP address is substantially inferior to
the point where it should not be used under ANY circumstance. No site
outside of Stanford should *ever* use SAIL's, Score's, or SUMEX-AIM's
net 36 IP address; the gateway between net 10 and net 36 (as well as the
net 36 subnet from that gateway) is seriously overloaded.
If I understand JLarson.pa correctly, he's saying that Xerox.COM
will use SUMEX-AIM's net 36 address just because they couldn't connect
to the net 10 address the last time. If this is common behavior it's
no wonder those of us who must use the net 10/36 gateway find it so
unusable. Will I have to instruct the servers on multi-homed net 10/36
hosts to refuse connections on net 36 from non-net 36 hosts to get them
to stop?
What about those guys multi-homed on a "free" and a pay-per-packet
X.25 net? Do they appreciate this behavior?
The *correct* solution to this problem is NOT kludgy algorithms in
the mailer. The correct solution is multi-part, and involves:
1) complete the migration from the host table to the domain system. The
NIC simply cannot keep up with the changes in network topology (as the
Xerox experience showed), and, frankly, it's unreasonable for us to
expect them to.
2) domain database managers need to keep their name servers updated with
changes to network topology. TTL's should not be allowed to be so long
that topology changes go unnoticed by resolvers for excessive periods
of time.
3) better support needs to exist in the domain infrastructure for "best"
IP address selection.
This last point is important. Presently, it is up to the local host
to decide upon a "best" IP address, based on quite incomplete information.
Many hosts (all Unix hosts?) simply pick the first IP address listed in
the NIC host table (or returned as A RR's from the domain system). TOPS-20
selects in priority order: (1) first IP address from a directly connected
net that is "preferred" (e.g. a fast LAN), (2) first IP address from a
directly connected net that is "default" (e.g. a core net such as ARPANET),
(3) first IP address from any other directly connected net, (4) first IP
address. "First IP address" means first from the address list from the
host table (or a set of A RR's from the domain system). Note that there
is nothing whatsoever to do with "net 10".
Almost 100% of the time, this makes the best possible choice of an
IP address. It's only in those very few cases (which come up perhaps
2 or 3 times a YEAR!!!) where an otherwise highly desirable path breaks
for a long period of time that a problem comes up. I consider it highly
objectionable to cycle through every other IP address (waiting a minute
or more for an IP retransmission timeout if the network is courteous
enough to tell me the other guy ain't there) every time I attempt to
connect to a dead host.
JLarson's suggestion is less objectionable, but it involves one
piece of software (the mailer) telling a completely different piece of
software (host table or domain resolver) that the IP address given it
was sick. Nobody wants to do the work to the host table software to
add such a feature. It might be doable with the domain resolver (SRA
can comment on this); it certainly wouldn't be hard for the mailer to
pass on the word to the domain resolver.
The problem is, what does "this IP address was sick" really mean?
How does "retransmission timeout" differ from "host dead" (a type 7
1822 message) differ from "host sent a reset" (refused the connection)
differ from any of the other ways a connection failed? In which one(s)
of these do you say try another IP address, and in which one(s) do you
assume the host is really down, or really doesn't want to talk now?
Again, what do you do about those cases when we really shouldn't
be using a particular IP address because of charging, or other
administrative issues?
The domain system may be able to help; it was always my belief (I
remember suggesting this at the meeting when the domain system concept
was first invented) that nameservers should be allowed to tailor their
responses based on who was asking the question. A domain query should
be something like: "I am on net 128.43 seeking an SMTP server for
FOO.BAR.COM, which is the best address for me to use?" and later on "I
am on net 128.43 seeking an SMTP server for FOO.BAR.COM and I already
tried 69.105.8.3, is there any other I should try?"
The point is that a perfectly valid answer may be "if 69.105.8.3
ain't answering, he ain't up; try again later."
This also gives the remote organization (which presumably knows
the status of their hosts) control over the IP address selection criteria,
based upon their knowledge instead of the local host's educated guesswork.
Please, no flames. If you're going to babble on and on about how I
should break my mailer to conform to your fantasy of how the world should
work, send it to *NUL: or /dev/null or whatever you call it. Furthermore,
I'm not interested in any comments about a host table based means of IP
address selection. The systems I support do not use host tables (and, for
the record, are currently the only TOPS-20's supporting MX mailing). I
can't help but feel that if the problem of a sick "best" IP address happens
to a domain-based mailer, that the fault is that of the management of the
nameserver for that organization and not that of the mailer.
If you have constructive observations, then let's talk. Remember
that this is not about porting arguably "better" (or "worse") ideas from a
16-year-old operating system to a 19-year-old operating system. This is
about what's going to be done in the next generation, that maybe will be
ported to the 16 and 19 year-olds. I think we can do better than any of
the guesswork, and we should, if the threats of pay-per-packet come to
pass.
-- Mark --
-------
-----------[000207][next][prev][last][first]----------------------------------------------------
Date: 15 Feb 88 03:35:00 GMT
From: WANCHO@SIMTEL20.ARPA ("Frank J. Wancho")
To: comp.protocols.tcp-ip
Subject: trying multiple addressesFor those who may be unaware, Mark's pay-per-packet comments *will* apply to all MILNET hosts for outgoing traffic and TAC access sometime in FY 89, unless the plans have been rescinded by some miracle. And, from what I've seen of the algorithm DCA intends to impose on us, it ain't cheap! When that happens, those sites, such as this one, which support large mailing lists and anonymous ftp service may be forced to withdraw those services... (or move to ARPANET where flat fees will continue - no :). --Frank
-----------[000208][next][prev][last][first]----------------------------------------------------
Date: 15 Feb 88 07:24:11 GMT
From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To: comp.protocols.tcp-ip
Subject: Re: What is SLIP?Jean-Francois, This was actually the basis of a BOF (birds of a feather) meeting at the TCP/IP Interoperability Conference last December. The conclusion was (as I remember hearing -- I was not there) it works, but has some hitches: You have to use the right kind of flow-control i.e. your interface must implement RTS/CTS handshaking. Dialing is tricky (I don't remember the details). And the turn-around-time (since it is a pseudo full-duplex modem) makes it undesireable for interactive applications, but works quite nicely with batch data transfers e.g. mail and ftp. -Philip
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 88 07:38:00 GMT From: melohn@SUN.COM (Bill Melohn) To: comp.protocols.tcp-ip Subject: Re: Bug in Sun OS 3.4 tcp?
In article <8802120105.AA05436@PHOEBE.CAM.UNISYS.COM> jonab@CAM.UNISYS.COM (Jonathan P. Biggar) writes: >Does anyone know about a problem with tcp under Sun OS 3.4 where receiving >a packet with the maximum segment size option messes up the window? A zero window size bug was fixed in the current release of SunOS, 3.5. This release also fixes problems with the TCP MSS being set incorrectly, which was introduced in 3.4.
-----------[000210][next][prev][last][first]----------------------------------------------------
Date: 15 Feb 88 07:40:21 GMT
From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To: comp.protocols.tcp-ip
Subject: Re: A plea for sanity (Errors-To: lines)I don't have 822 handy, but aren't you supposed to pass through lines that you don't grok? I've seen mail headers that include "Fruit-of-the-day:" and other such stuff (not to mention "Organization:", "Distribution:", "Newsgroup:", and "X-Comment:"). Why should "Errors-To:" be a problem, unless there was a bug in his mailer in handling this specific string? How long ago was this, anyway? -Philip
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 88 12:11:33 GMT From: HANK@TAUNIVM.BITNET (Hank Nussbacher) To: comp.protocols.tcp-ip Subject: cisco AGS vs. Proteon p4200
Does anyone have any comparison study of these two multiprotocol routers? If you have any comparison numbers, I would love to see them. Thanks, Hank
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Feb 88 11:11:38 IST From: Hank Nussbacher <HANK%TAUNIVM.BITNET@CNUCE-VM.ARPA> To: tcp-ip@sri-nic.ARPA Subject: cisco AGS vs. Proteon p4200
Does anyone have any comparison study of these two multiprotocol routers? If you have any comparison numbers, I would love to see them. Thanks, Hank -------
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 88 16:37:30 GMT From: gross@gateway.mitre.ORG (Phill Gross) To: comp.protocols.tcp-ip Subject: Re: Complete FROM: field.
> If your message is meant to suggest that my mail message contained > an incomplete "FROM:" field, I feel compelled to answer. Terry, The heck with your `From:' line--I want to complain about your 15 line signoff message! Your signoff is generally longer than the message itself. Please help reduce bit chaff on the network. (You will also be showing consideration for folks who read mail over 1200 baud dial-up lines.) Phill Gross
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 88 20:51:52 GMT From: bobj@MCL.UNISYS.COM (Bob Jones) To: comp.protocols.tcp-ip Subject: Re: DCA Protocol Lab Test Tools
Hal, thanks for comments. I am hoping some industrious laboratory will offer the remote drivers in some generic for that can be quickly adapted to any machine environ (with generic hooks?). If it will be of any comfort to you, we are at a point where all of the specs are firm now. Thanks to you, we have learned a lot and your persistence has helped us to debug our test system in the process. Cray deserves a hand! bobj
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 88 21:28:52 GMT From: bobj@MCL.UNISYS.COM (Bob Jones) To: comp.protocols.tcp-ip Subject: Re: Life in the Swamps / Testing
Dan, I was not nearly as verbose as you in my response to Dave, but you expressed my sentiments exactly. Anyway perfection is found only in heaven. This is earth, and all of the solutions for that perfect world are just not here..yet. Again, thanks for your input. bobj
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 88 23:27:07 GMT From: AI.CLIVE@MCC.COM (Clive Dawson) To: comp.protocols.tcp-ip Subject: Re: trying multiple addresses
Re: Date: Sun, 14 Feb 88 18:18:09 PST From: Mark Crispin <MRC@PANDA.PANDA.COM> Subject: trying multiple addresses Mark-- Your message implies that trying an alternate IP address after the best one has failed will only win 1% of the time. I disagree. As somebody who still has the job of dealing with the day-to-day hassles of "keeping the mail flowing", I cannot afford to sit back and consider what the "correct solution" will ultimately be once the whole world arrives at some standard. I will gladly accept any "kludgy algorithms" that get the job done with no adverse effects. Not counting the host-table-related problems (I know, you don't want to hear this!) such as SU's Sierra, whose 10 address still appears over a year after it died, or the more recent HI-MULTICS/CIM-VAX address problem at Honeywell, where both addresses work, but SMTP listens only on one, I have also had to deal with a multitude of other problems in just the last week which were all solved by using non-"best" IP addresses. The following scenario comes up A LOT, at least at this site: Q: Why isn't my mail getting through to host X? A: The host must be down. Q: Then why can I Telnet to it? A: Ah, your workstation is not directly connected to net 10, and is so "dumb" that it doesn't realize that net 10 is the only way out of this place anyway, so it chooses to use host X's 128 address. Meanwhile, our "smart" mail relay host (and gateway) is directly connected to net 10 and therefore insists on sticking to host X's 10 address regardless. How am I supposed to tell users that "correct failure" is better than "kludgy success"? They could care less about these details, and rightfully so. If I understand JLarson.pa correctly, he's saying that Xerox.COM will use SUMEX-AIM's net 36 address just because they couldn't connect to the net 10 address the last time. If this is common behavior it's no wonder those of us who must use the net 10/36 gateway find it so unusable. Will I have to instruct the servers on multi-homed net 10/36 hosts to refuse connections on net 36 from non-net 36 hosts to get them to stop? Mark, that's not how I understood JLarson at all. He said that this procedure was followed on RETRIES, and then ONLY at the next retry interval. This is quite different from adopting the alternative IP address "permanently" thereafter for all deliveries. It seems to me that this procedure is almost a complete win. There is no extra load on the sending mailer, and non-"best" IP addresses are used only when they have to be, on a message-by-message basis. It might possibly be improved by a heuristic which says that if, on the first retry, the second address is found to be down too, then 4 out of every 5 (say) future retries should go back to using the "best" IP address. This way, if SCORE is really down, the poor 10/36 gateway won't get so much of a pounding with doomed connection attempts from everybody. Cheers, Clive -------
-----------[000217][next][prev][last][first]----------------------------------------------------
Date: 16 Feb 88 00:27:00 GMT
From: WANCHO@SIMTEL20.ARPA ("Frank J. Wancho")
To: comp.protocols.tcp-ip
Subject: Correction on MILNET packet chargesThe scheduled implementation for charge-back to directly connected MILNET hosts is FY90, not FY89. Sorry for the confusion. --Frank
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Feb 88 07:49:08 EST From: terry@DEC-VAX-11-750.ARPA To: tcp-ip@sri-nic.arpa Subject: Conforming!
Hello All, > Re: "From: address of terry@dvax " MY host administrator has changed our official sitename to match our MILnet sitename (dec-vax-11-750.arpa). This will cause the "FROM" address of my mail to conform network requirements. Seems only fair... Terry Robb ************************************************************************ *- Terence A. Robb -* *- Network Solutions -* *- Systems Programming Specialist -* *- MILnet: terry@dec-vax-11-750.arpa -* *- PHONEnet: (703) 749-1918 -* *- MAILnet: 8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180 -* ************************************************************************ -------
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Feb 88 9:59:21 EST From: "Alan R. Hill" <ahill@cc7.bbn.com> To: gross@gateway.mitre.org Cc: tcp-ip@sri-nic.arpa, terry@dec-vax-11-750.arpa Subject: Re: Complete FROM: field.
It might also help if the current trend of including excerpts and complete text of subject messages in responses wasn't so popular. It seems as though messages are getting more and more verbose as time passes (please don't construe this to mean that I think messages contain useless input). Alan
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 88 06:41:10 GMT From: MRC@PANDA.PANDA.COM (Mark Crispin) To: comp.protocols.tcp-ip Subject: Re: trying multiple addresses
Clive -
The NIC host table is a disaster, and the only way to fix the many
problems associated with it is to abandon it for domains. Supported
TOPS-20 domain and mail software was announced a while ago; perhaps you
should consider adopting it at your site. [As a side note, the problem
with Sierra's net 10 address being in the host table will go away very
soon since the plug is being pulled on Sierra.]
Trying every possible IP address for a host which fails to respond
on its "primary" IP address is a recipe for performance disaster for any
background mailer with a large workload. We're talking about thousands
of messages/day, friends, not a piddly couple of hundred.
Furthermore, we all can rattle off the cases where the primary IP
address was wrong. We can do this because there have been so few of
them! What's more, most of those few are host-table only problems. If
you run obsolete software, you should expect to have to put in some
maintenance on your own.
-- Mark --
-------
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 88 12:49:08 GMT From: terry@DEC-VAX-11-750.ARPA To: comp.protocols.tcp-ip Subject: Conforming!
Hello All, > Re: "From: address of terry@dvax " MY host administrator has changed our official sitename to match our MILnet sitename (dec-vax-11-750.arpa). This will cause the "FROM" address of my mail to conform network requirements. Seems only fair... Terry Robb ************************************************************************ *- Terence A. Robb -* *- Network Solutions -* *- Systems Programming Specialist -* *- MILnet: terry@dec-vax-11-750.arpa -* *- PHONEnet: (703) 749-1918 -* *- MAILnet: 8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180 -* ************************************************************************
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 88 13:34:17 GMT From: AI.CLIVE@MCC.COM (Clive Dawson) To: comp.protocols.tcp-ip Subject: Re: trying multiple addresses
Trying every possible IP address for a host which fails to
respond on its "primary" IP address is a recipe for performance
disaster for any background mailer with a large workload. We're
talking about thousands of messages/day, friends, not a piddly couple
of hundred.
Yes, Mark, I know what large workloads are. Considering that
a) this discussion deals with multi-homed hosts which
comprise only about 5% of the total host population, and
b) the success rate for first delivery attempts exceeds 95%, and
c) once a message is in the retry queue the average number of
retries is greater than 1,
I would appreciate it if you would elaborate on just how this
"performance disaster" you predict will come about, especially for
sites using the algorithm we've discussed in the last few messages.
I'm glad to see you acknowledge that only "most" of these problems are
host-table related. OK, let's eliminate these from consideration.
What do you propose that we do about the rest of the problems which
are not host-table related? You seem to be resigned to the idea that
they should just be ignored because there are so few of them. If
this is true, then a solution which only affects THESE FEW can hardly
cause a performance disaster.
Clive
-------
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 88 13:35:59 GMT From: dan@MITRE-BEDFORD.ARPA To: comp.protocols.tcp-ip Subject: IP security options (again)
This is my second request for information on systems that can handle IP
security options. I previously asked about systems that allowed the use of
the options. I'd like to expand that request to include systems that will
ignore the security options without choking on the datagram.
Also, if there are any methods of setting the options on output, I would
appreciate hearing about them.
Thank you.
Daniel Willhite
dan@mitre-bedford.arpa
-----------[000224][next][prev][last][first]----------------------------------------------------
Date: 16 Feb 88 14:59:21 GMT
From: ahill@CC7.BBN.COM ("Alan R. Hill")
To: comp.protocols.tcp-ip
Subject: Re: Complete FROM: field.It might also help if the current trend of including excerpts and complete text of subject messages in responses wasn't so popular. It seems as though messages are getting more and more verbose as time passes (please don't construe this to mean that I think messages contain useless input). Alan
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 88 15:44:57 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Re: Life in the Swamps / Testing
Bob, You're welcome. I calls 'em as I sees 'em, eh? Actually it is time for some leadership in all this and I have been a patient person for over a year now. Things don't get fixed if there's no incentive to fix them. Something as simple as doing subnetting right or pluggin in the right broadcast address should be done by now. Must be we have to kick the vendors in the butt! Dan -------
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: Tue, 16 Feb 88 21:56:08 EST From: Lyle Evans <EVANSL%VTVM1.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Re: Complete FROM: field.
Amen. Besides using net capacity excessive signatures use up disk space for tho se who store messages. -------
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 88 17:17:00 GMT From: retrac@titan.rice.edu (John Carter) To: comp.protocols.tcp-ip Subject: Summary of responses to my tcp-ip performance query
Hello,
Back in late November I posted the following request for information
to the network. I had intended to post this summary of the responses that
I received, but I forgot. What follows is my original posting followed by
the responses that I received. Hope people find this to be useful! Many
thanks to all of you who answered my query!!!
==============================================================================
> I'm a fairly new reader of this newsgroup, so I apologize if this has
> already been discussed. I would like to know what the best performance
> figures are for large memory to memory transfers using TCP-IP. More
> specifically, what are the fastest reported average transfer times for
> transferring 10 Mbytes over a 10 Mbit/sec ethernet? (or) What is the
> highest reported throughput of DATA across a 10 Mbit/sec ethernet using
> TCP-IP?
>
> Def.: Memory to memory above means, the client generates the data
> out of thin air and the server puts them all in one buffer
> (the "best case" situation). I'm interested in raw transfer
> rates and the cost of TCP-IP overhead on performance.
>
> I have seen performance figures for van Jacobson's modifications to
> Berkeley 4.3 TCP-IP which gave measurements of 23.3 secs for 10 MB over
> a 10 Mbit/sec ethernet (effective throughput of 3.4 Mbit/sec). Are there
> any better?
>
> John Carter
> Dept. of Computer Science, Rice University
==============================================================================
From: David Robinson <david@elroy.jpl.nasa.gov>
To: retrac@rice.edu
Subject: TCP performence
The best I have personally seen is between two Sun-3/260's doing
memory-memory transfers is 3.2Mbits/sec. Their UDP topped out
at 5Mbits/sec. This was on a fairly quite net, rwhod and routed
traffic only. From my experience excelan boards have been the
worst, slower than my lowly Sun-2, but what can be expected from
a 80186??
I do not know what the limiting factor of the Sun's is by I suspect
that it is CPU bound, the e-net controllers each have large
memmory buffers (256K?).
-David Robinson
david@elroy.jpl.nasa.gov
[Wishing for an IP pure hardware chip!]
---------------------------------------------------------------------
Subject: Re: What's the "best" TCP/IP throughput?
Date: 26 Oct 87 07:37:25 PST (Mon)
From: lekash@orville.nas.nasa.gov
Better performance for ethernet is not that likely until someone
builds a better interface card. Thats the current bottleneck.
If you go to other media, say pronet-80, or hyperchannel, you
can get much higher rates. we were seeing up to 17mbits/sec over
hyperchanel, proteon claims over seven for their ring. I
would guess with performance tuning, those numbers will
increase. (We might even do some here.)
john
---------------------------------------------------------------
From: nowicki%rose@sun.com (Bill Nowicki)
Message-Id: <8710272303.AA03617@rose.sun.com>
To: retrac@rice.edu
Subject: Re: What's the "best" TCP/IP throughput?
Disclaimer: this is NOT an official number, just my latest test in an
uncontrolled environment with an unannounced software configuration.
But between a pair of Sun-4/260s I am able to transfer with TCP over an
Ethernet at 5.0 Mbits/second.
-- WIN
---------------------------------------------------------------------
From: Richard Fox <rfox@ames-nas.arpa>
Organization: NASA Ames Research Center, Mountain View, CA
I have just spent some time using the FTP protocol using tcp-ip over
an ethernet, gathering stats. As you are probably aware the results
at this point have been pretty disappointing.
I would like to start investigating new and different protocols. So
any info you get could you please forward. Also, if you have other
protocols that need testing I would be glad to help. We have ethernets,
hyperchannels, satellites etc. and a strong interest in finding a more
efficient protocol than the current TCP-IP.
By the way, we have just received a new TCP implementation that is
supposed to have rate-control. If you are interested I will send you
the results after I have some time to play with it.
rich fox
(415)694-4358
-------------------------------------------------------------------------
From: erikn@sics.se (Erik Nordmark)
Summary: 1.8 Mbps between Vaxstation II's, about 4 Mbps between Sun-3's
When I was at Stanford I was working on David Cheriton's VMTP protocol.
There was already an implementation in the V distributed system and I
did one in the 4.3BSD kernel.
These are the number we got:
Memory-to-memory bulk data transfer between 2 VAXstation II's on a 10 Mbps
Ethernet running 4.3BSD Unix:
1.8 Mbps
Short request-reponse interaction: a 32 byte request and a 32 byte response
message (same system):
send -----> recv
<----- reply
8.6 milliseconds
The implementation in V performs with about 4 Mbps and 2.3 ms between two
Sun-3's on a 10 MBPS Ethernet.
Note: The Unix implementation uses IP for datagram delivery whereas
the V implementation has its own mechanisms for delivery, routing
et.c. on the local net. An optimized version of the Unix
implementation that uses "raw" ethernet for packets on the local net
(and IP for internet packets) achieves about 2.1 Mbps between the two
microVAXes.
About VMTP:
The Versatile Message Transaction Protocol is a reliable transport
protocol based on the transaction style of communication. A
transaction consists of a request and a response message which are
limited in size to 1 Mbyte. Current implementations limit the message
size to 16 kbytes, so there is room for performance improvements in
the implementations.
The protocol has:
better naming then tcp/ip (stable, location independent identifiers)
support for real-time communication
support for security
multicasting on LAN as well as WAN (latter relying on the Internet
Group Management Protocol and extensions to IP)
solves the speed mismatch problem on the local net by using rate
based flow control
etc.
David Cheriton (cheriton@pescadero.stanford.edu)
"VMTP: a Transport Protocol for next generation ..."
Proc. Communications and Architecture and Protocols
Aug. 1986 (ACM)
Steve Deering
"Host extensions for IP multicasting"
RFC 988
Karen C. Lam
"4.3bsd Internet Multicast {Implementation Notes,Installation and Usage Notes}"
BBN Laboratories Inc, 10 Moulton Street, Cambridge MA
** Erik Nordmark **
Swedish Institute of Computer Science, Box 1263, S-163 13 SPANGA, Sweden
Phone: +46 8 750 79 70 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30
uucp: erikn@sics.UUCP or {seismo,mcvax}!enea!sics!erikn
Domain: erikn@sics.se
-------------------------------------------------------------------------
From: Jack Jansen <mcvax!cwi.nl!jack@uunet.uu.net>
The protocol used in the Amoeba distributed OS is probably the fastest
around currently (at least, that's what we like to think:-).
We do 420Kb/sec between two microvaxen, and 600+Kb/sec between two
68020 systems. This is all running the protocol between machines
running amoeba. I got up to 250Kb/sec once between two uVaxen running
ultrix 1.2.
References to amoeba should be easy to find, there's quite a bit
published, mainly written by Andrew S. Tanenbaum and Sape J. Mullender.
If you cannot find anything, drop me a line and I'll send you
a list of references.
Another protocol to look at might be the one used in David Cheriton's
V operating system. He does almost as good as we do.
--
Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp)
The shell is my oyster.
-------------------------------------------------------------------------
From: dmc%tv.tv.tek.com@relay.cs.net
Subject: Bulk data transfer protocol timings
We are running Stanford's V-system Version 6 kernels in
Tektronix 4405 workstations, which have 16.6 Mhz. 68020 processors.
The ethernet interface used is the AMD LANCE, with 64 receive
packet buffers and 8 transmit packet buffers of 1518 bytes.
The Inter-Kernel measurement program `timeipc' gives us the following
figures for segment transfers between the user process memory of
two 4405's. The program runs at a real-time scheduling priority,
and normal process execution is essentially suspended while the test
is in progress. The protocol is an early version of VMTP.
Send-Receive-ReplyWithSegment (5 trial average):
Size (bytes) elapsed time/100 transactions effective bit rate
0 .20 seconds
1024 .34 seconds 2.409 Mbit/sec.
Send-Receive-MoveTo-Reply (5 trial average):
Size (bytes) elapsed time/100 transactions effective bit rate
2048 .66 seconds 2.482 Mbit/sec.
4096 .99 seconds 3.310 Mbit/sec.
8192 1.40 seconds 4.681 Mbit/sec.
16384 2.32 seconds 5.650 Mbit/sec.
32768 4.18 seconds 6.271 Mbit/sec.
65536 7.91 seconds 6.628 Mbit/sec.
131072 15.30 seconds 6.853 Mbit/sec.
Send-ReceiveWithSegment-Reply (5 trial average):
Size (bytes) elapsed time/100 transactions effective bit rate
1024 .35 2.341 Mbit/sec.
Send-Receive-MoveFrom-Reply (5 trial average):
Size (bytes) elapsed time/100 transactions effective bit rate
2048 .78 2.101 Mbit/sec.
4096 1.01 3.244 Mbit/sec.
8192 1.58 4.148 Mbit/sec.
16384 2.62 5.003 Mbit/sec.
32768 4.57 5.736 Mbit/sec.
65536 7.87 6.662 Mbit/sec.
131072 15.2 6.899 Mbit/sec.
Don Craig
Tektronix Television Systems
------------------------------------------------------------------------------
From: Mike Muuss <mike@brl.arpa>
A pair of Sun-3/50 machines running SUNOS 3.3 with tcp_sndspace and
tcp_rcvspace (or whatever they are called) increased to 16K (ie,
increased offered windows). Test is typically 1 Mbyte memory to memory
using the TTCP program (copies on request). Typical data rate is
3 Mbits/sec. For two pairs, typically see 6 Mbits/sec total for both
connections. Never bothered to do three pairs. Trailers were off.
6 Mbits/sec is fairly close to the maximum usable bandwidth of an Ethernet.
On an NSC Hyperchannel, between a Gould PN9080 running UTX 2.0, using a
PI32 to access an A400, with an otherwise idle trunk to an A130 adaptor
connected to a Cray XMP48 running UNICOS 2.0 (at the time), I was able
to achieve 11 Mbits/sec aggregate, using MTU of 4144 and Cray-IP
encapsulation. This was not using TCP at all, but merely IP/ICMP_Echo
request/response packets, in a "flood ping" test.
Best,
-Mike
-----------------------------------------------------------------------
From: aeh@j.cc.purdue.edu (Dale Talcott)
Re your query about high speed network protocols: Several of our
mainframes here at Purdue are connected using Control Data's LCN
(loosely coupled network). This is not a 10Mbs based network, but may
provide some insight into limiting factors.
The LCN is somewhat Ethernet-like in that it is tapped-trunk using
coaxial cable, but it runs at 50Mbs instead of 10Mbs and uses 3/4 inch
coax. There is carrier-sense, but collisions are avoided by providing
fixed time slots for each host to start a transmission. In practice,
there are occasional collisions. The maximum trunk length is limited
to about 2000 feet. The typical number of taps on a trunk is small
(5 - 10). The hardware level protocol is point-to-point, with no
broadcasts. The hardware level protocol packet limit is 65535 16-bit
words. The software packet size is 4096 bytes of data with a 12 byte
software header and 21 bytes of hardware framing, addressing, crc, etc.
However, there is a mode called "streaming" in which a sender can
"grab" the trunk and keep it for as long as it wants by holding the
carrier asserted between packets.
The hosts do not connect directly to the LCN. Rather, there are
specialized minicomputers to do the connection. These are called NADs
(network access devices). There are several kinds of NADs, according
to the device the NAD is connecting to the LCN. We have NADs for tape
controllers, disk controllers, VAXes, and various CDC Cyber mainframes.
Simplified network:
+-----+ +-----+
|host | |host |
+-----+ +-----+
| |
+---+ +---+
|nad| |nad|
+---+ +---+
| |
=============================================== trunk
|
+---+
|nad|
+---+
|
+-----+ +---+ +---+ +----+
|host |---|nad|====|nad|---|disk|
+-----+ +---+ +---+ +----+
There are different protocols used, according to the devices being
connected. When a host talks to another host, the protocol is called
RHF (remote host facility) and is more-or-less ISO seven layer in
philosophy. In practice, there is much mingling of layers.
When a NAD pair with dedicated trunk is being used to connect a host to
its disks (as in the bottom example), the NADs use a simplified
protocol, idiosyncratic to the device and host operating system.
---
Now, for the numbers:
("Mbs" = "megabits per second", throughout.)
A Cyber 205 host to CDC 819 disk drives, over a dedicated trunk
achieved a sustained transfer rate of 30Mbs. The instantaneous rate at
which the drives read is 36Mbs. The 205 usually reads/writes data in
65536 byte chunks (memory small page size), and often reads .5Mbyte
chunks (memory large page). The disk NADs use streaming mode between
themselves. I do not remember the actual size of the file used to
determine this transfer rate, but it was at least 8 Mbytes.
--
Transfers among hosts using the RHF protocol, exclusive of the time
needed to build a connection:
CDC 6600 to CDC 6500, no other load on the network, 6 Mbit of
fabricated data at sending end, discarded at receiving end, packet size
of 3840 bytes: 6.5Mbs.
CDC 6600 to Cyber 205, disk to disk, both systems idle, 16 Mbytes of
data: 2.6Mbs.
Same file, opposite direction: 2.0Mbs.
VAX 11/780 (dual processor) running 4.3BSD to Cyber 205. VAX
multiuser, but idle. Cyber running typical middle-of-the-night, CPU
intensive, low priority workload. Transfer rate for 1 Mbyte, "holey"
file on VAX to 205 disk file: 1.3Mbs.
(A holey Unix file does not require disk accesses to read the holes:
the system just fabricates a chuck of zeros.) Same file, only real and
residing on Fuji Eagle disk: 1.1Mbs.
Statistics for transfers during normal production from 205 to 780 give
numbers in the .5Mbs range for moderately large files (~1Mbyte) when the
780 has to translate each '\037' character into '\n' (done with the VAX
movtc instruction). Highest rate noticed was .8Mbs for ~.25Mbyte
transfer.
For a transfer from CDC Cyber 720 to VAX 780, no character translation,
disk to disk, the transfer rate was .96Mbs. This was a while ago, and
I don't remember the loads on the two systems, but I suspect both were
idle.
For Cyber 205 to VAX 8600 running Ultrix 2.?, both systems in normal
daytime production (but the VAX still lightly loaded), a .5Mbyte file
transferred disk to disk with character translation at 1.05Mbs.
Normal rates are 20 - 30% better than the 780. (Note: the 8600 is
at JVNC at Princeton, not at Purdue.)
---
Notice the huge disparity between the data rate the hardware (NADs and
LCN trunk) is capable of and that actually obtained once several layers
of host resident protocol are placed on top. In developing the RHF
implementation for the VAXes, we noticed that every optimization in
host code (placing data blocks on page boundaries, using the movtc
instead of a C loop, etc) showed up in the transfer statistics. (Our
first cut got only 24kbs!). We have an open project to find why it
is still so slow.
Dale Talcott Systems programmer
ARPANET: aeh@j.cc.Purdue.EDU Purdue University Computing Center
BITNET: AEH@PURCCVM Mathematical Sciences Bldg.
Phone: (317) 494-1787 West Lafayette, IN 47907
------------------------------------------------------------------------------
From ogud@sdag.cs.umd.edu Tue Nov 24 00:05:11 1987
Sorry I did not read your mail earlier but I trying to finish my thesis on
the behavior of Ethernet here in the CS Dep.
One part of my study was to look at bandwith between SUN's and more machines
Another part was to examine the behavior of the net under overload conditions
The results are in short: (all load figures include headers)
sun3/50 to sun3/50 transferrate 2Mbits for Max size TCP packets
max 500 pack per sec of min size TCP packets
sun3/160 to sun3/160 multiply by 1.2
I had sun3/160 and sun3/50 listening to all the traffic using modified
Etherspy program and killed of all UNIX processes that are not needed
and at sun3/50 started to report dropped packets at around 25% load (2.5Mb)
Both machines where shot down a(dropping lot of packets) at 40% load and
started showing erratic behavior.
How does this affect the transfer rate?
Well no protcol using TCP will get any better rate because the SUN's are the
bottleneck not the NET. When running FTP here at night on large files I
see max 140Kbytes per sec or (140 * 1090 * 8 = 1.2Mb). The higest number
I have heard about is 190 KBytes/sec or( 1.6 Mb). This number is probably for
a SUN3/260 and scales well down to the 140 for 3/50.
If you want more info send my questions and Hopefully I will be able to
answer them for you.
Olafur Gudmundsson Dept. of Computer Science University of Maryland
ARPA: ogud@brillig.edu
UUCP: {...}!seismo!umcp-cs!brillig!ogud Tel: (301)-454-6153 (w)
UPS: College Park MD. 20742 ATT: (301)-595-4154 (h)
------------------------------------------------------------------------------
From mangler@csvax.caltech.edu Tue Nov 24 04:22:59 1987
> From: David Robinson <david@elroy.jpl.nasa.gov>
>
> The best I have personally seen is between two Sun-3/260's doing
> memory-memory transfers is 3.2Mbits/sec.
What wasn't mentioned is that this was on SunOS 3.2. Prior and later
versions of SunOS aren't nearly as fast at TCP. SunOS 3.4 is 2X slower!
Don Speck speck@vlsi.caltech.edu {amdahl,scgvaxd}!cit-vax!speck
==============================================================================
___
/ \ John Carter
=======O \ Rice Univerity
| _ | \ Houston, Texas
| (_) | (( ))
|__#__| O/ \\O ARPA/CSNET: retrac@rice.edu
| | /+ -+. UUCP: {Backbone or Internet site}!rice!retrac
[N] = |
[B] // // Rockets record with me at the game: 13 - 0
[A] )) \\ Rockets record w/o me at the game: 4 - 4 Home
|_| =/ 15 - 18 Total
/___\ ^^^ ME, *superstitious*?!? ^^^ No way! :-)
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 88 18:50:11 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: trying multiple addresses
Egad! I thought this question was settled about 4 years ago! And the answer was... JLarson is entirely right, and Mark Crispin is confusing a settled issue. Bob Braden
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 88 19:17:04 GMT From: golds@rlgvax.UUCP (Rich Goldschmidt) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: "Standards" for PC sockets
There was a BOF at the 2nd TCP/IP Interoperability Conference about defining application level and interrupt level standards for sockets for PC's. It was also discussed on this list prior to the conference. I have heard nothing since. Has anything really happened with this, and will the manufacturers really get on board and make this happen any time soon? Rich Goldschmidt rlgvax!golds@uunet.UU.NET uunet!rlgvax!golds sun!sundc!rlgvax!golds
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Feb 88 08:57:45 -0800 From: David Walker <dwalker@orion.cf.uci.edu> To: tcp-ip%sri-nic.arpa@orion.cf.uci.edu Cc: Iglesias@orion.cf.uci.edu, Ct_Network_Services@orion.cf.uci.edu Subject: tn3270 for Wollongong VAX software?
Does anyone know of a tn3270 that has been developed for the
Wollongong's WINS software? We've heard that there is one that runs
under EUNICE, but we'd rather not have to buy the rest of the UNIX
emulation.
David Walker
Network Services Manager
UC Irvine
-------
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 88 19:44:00 GMT From: jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes) To: comp.protocols.tcp-ip Subject: Re: trying multiple addresses
Mark talks all about "host table this" and "obsolete software this" but the problem that I had (and I think J Larson had) was that, due to NIC paperwork (i.e., chan ging *anything* about a host/gateway that requires an NCD), there are things that will hose you for sure. I couldn't get the host table *or the domain database* changed, so places like sushi.stanford.edu, mcc.com, a.isi.edu (a *root domain server*!!!) bounced mail headed our way for 5 weeks. I'm running all the correct software, i'm hip to the "now it's your namespace, now you have control over it" thang, but I think it's a bit naive to say that "Ah well, 1% of the time, you'll lose" ... Summary: Mark, i'd appreciate it if you'd try a bit harder not to bounce my mail. Thanks. /jordan
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 88 19:59:08 GMT From: MRC@PANDA.PANDA.COM (Mark Crispin) To: comp.protocols.tcp-ip Subject: Braden on secondary IP addresses
I've been in the NWG for at least 12 years, and I remember no
pronouncement that implementations *must* try all possible IP addresses.
I can think of just as many cases where it is undesirable as I can of
ones where it is desirable.
Let's set the record straight on one thing. The mailer in question
has no knowledge whatsoever of how to look up an address in a host table
or from a domain server. It hasn't any notion of multi-homed hosts. It
simply knows that it has to send a set of bits to a set of mailboxes at
a set of hosts. The hosts are stored by name. When the mailer attempts
to deliver a message, it does an operating system call which takes the
host name as an argument and returns a single IP address.
Any change in IP address selection would have to be done at the
software at the other end of that system call. One way for be for the
mailer to pass "advice" that a particular IP address has been shown to
fail. Nobody is going to work on the host table software to do this.
The amount of work to do such a task is much more work that it would be
for Clive Dawson to upgrade his system to support domains.
It would, I think, be relatively simple to put in such a function
into the domain software. The only change to the mailer would be to
pass "advice"; presumably a 3 or 4 line code change. I don't know what
sort of effort it would take to put this in the domain software.
The question then becomes, what sort of criterion should the domain
software use beyond the current choice of "best" network, modified with
mailer "advice"? Nobody has offered any suggestions.
I again want to emphasize that the DEC-20 mailer does NOT "use the
first address and ignore the rest". It has no way of knowing that any
other addresses exist; it is totally dependent upon external software
for any host information. Don't assume that because your mailer has
internalized host table parsing routines that all mailers are written
that way. I am a bit annoyed that the same people who are willing to
accept BITNET mailers which toss away RFC821 return path information
are quite happy to crucify software that isn't at fault.
-------
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 88 21:53:28 GMT From: mar@ATHENA.MIT.EDU To: comp.protocols.tcp-ip Subject: getting the host tables right
Recent discussion about mail problems indicates that some people have been having problems coordinating host configuration changes. Here are some hints from an address change I performed a while back. The goal was to change the address on every host in our installation, including 2 listed in the hosttable, our domain nameserver, and our mail hub. We planned this a couple of months in advance. The steps we followed were: 1. Turn on both sets of addresses in our gateways, and use a PC configured on the new network address to make sure we had connectivity with the rest of the internet. 2. Notified the NIC that we were planning the change for about a month later, and got back confirmation that they could change the hosttables on the day we chose. Also notified the system administrator at the machine serving as secondary nameserver for our domain, and got confirmation that they would be able to make the change on the correct day. 3. Changed the timeouts in our name domain to 1 hour so that resolvers wouldn't cache our old address for 3 days after the change. 4. A couple of days before the change we changed the sendmail.cf on our mailhub to put: Notice: foo.arpa's address will be 1.2.3.4 after April 1 lines in the headers of all mail passing through. 5. We also started changing the addresses of PC's and lesser known workstations a day early, just because it would take too long to change everything at once. 6. On the flag day, we first checked with the NIC to see that they had the new information. We would have called off the change if they hadn't done it yet. We then changed the addresses of our well known machines, and swapped in the new domain database. We changed the text of the extra header line in the message slightly. Since our secondary nameserver is run by a different organization at a different site, as suggested in the RFC, hosts that had cached the old information could still get to us. They would be unable to contact our primarhy nameserver at the old address, so try the secondary nameserver (which hadn't moved) and get our new addresses from there. 7. I then monitored our gateway log for the next week to catch hosts attempting to contact our old address. When I spotted these, I sent mail to the postmaster at those sites informing them of our move and that they should get new hosttables. The whole thing was relatively painless, with not much disruption of service. The flag day was on a Friday, so that caches would have a better chance of timing out by Monday when people wanted to do work again. The key to the operation was planning it a couple of months in advance, and not going from one stage to the next until we were sure it was going to work. If you are forced to make a change like this on short notice, I imagine that there would be many more problems. -Mark
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 88 01:49:03 GMT From: karn@THUMPER.BELLCORE.COM (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Jain paper citation correction
The CUTE paper by Raj Jain that Van Jacobson referred to was actually in the IEEE Journal on Selected Areas in Communications (aka "JSAC"), not Transactions on Communications. The full paper title is "A Timeout-Based Congestion Control Scheme for Window Flow-Controlled Networks". It is on page 1162 of the October 1986 issue. Many thanks to Van for his highly informative summary. I immediately coded much of it into my own TCP and am now experimenting with it. Phil
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: Wed, 17 Feb 88 7:28:41 EST From: "Kenneth A. Turkewitz" <turkewit@CCV.BBN.COM> To: Jim Chappell <vrdxhq!ms3!isns01@UMD5.UMD.EDU> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: DDN Connection Problems
Jim, The host "hios-pent.arpa" is a MILNET host, which is running PSN Release 6.0, not PSN Release 7.0. --Ken Turkewitz -------
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 88 02:56:08 GMT From: EVANSL@VTVM1.BITNET (Lyle Evans) To: comp.protocols.tcp-ip Subject: Re: Complete FROM: field.
Amen. Besides using net capacity excessive signatures use up disk space for tho se who store messages.
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 88 07:25:46 GMT From: david@ms.uky.edu (David Herron -- Resident E-mail Hack) To: comp.protocols.tcp-ip Subject: ftp hang while trying to talk to cu20b.columbia.edu
I'm experiencing some strange hangs while attempting to ftp files
from cu20b. Specifically, the pattern is that I make the connection,
log in as anonymous and david@ms.uky.edu as the password. Then I
start transferring some data (either a directory listing or an
actual get command) and after some short time (approximately 15K
worth of data has been transmitted) the transfer hangs and stops
doing things.
Running tcpdump to watch things and telling it to restrict itself
to the ftp port, sure enough the packets simply stop going by
after a time.
The local machines I have tried this from are an 11/750 with deuna
running mtxinu 4.3+nfs (we're one MR behind the current version),
uXavII's with DEQNA's and the same OS, Sun 3/something running 3.4,
and uVaxStation2000's with whatever the ether hardware is and
the next-to-current version of Ultrix. Our sequent didn't
know how to reach that network so I wasn't le to try from
that machine.
Using ping, I get an response times like 250 ms at best, 2500 ms
at worst, and 600-700 avg and with packet lossage at somewhere
between 5% to 30% depending on the tides, or some other somewhat
unrelated/unknown effect. I'm doing these transfers at night
most recently at 3AM on a saturday morning.
Our net is an ethernet attached to a proteon p4200 ip router which
is the gateway to suranet/nsfnet. From there we go through some
gateway in wash dc (maryland?) to get to net 10.
One thing we've noticed recently on our net is something which may
be rwho related broadcast storms. I haven't traced this down yet,
but will be doing some tracing on this in the next couple of days.
One thing I notice from ping is that occasionally there are
bursts of packets being lost and surrounding the lost packets
are long ping times.
um, some hard facts gathered with ping. I watched for about 5 or 6
minutes just now. Every minute like clockwork we'd experience some
packet loss, and generally for the next 20-30 seconds the ping
time would be much worse than the rest of the time. But there was
enough variance in the details of what happened, as well as variation
in other parts of the minute, that it's not completely clear what
is happening. I did see one extreme example in that time where
we lost about 40 packets and didn't have ANY pings come back for
about 30-40 seconds.
This does seem to be extreme lossage ... however, isn't tcp supposed
to be able to handle loss of packets and do re-transmissions? Why
is tcp getting wedged? Or possibly is it something in the way that ftp
works? (I must admit that I know very little about how ftp operates
other than it runs using two tcp channels, one for data transfers
and the other for commands).
Any ideas?
--
<---- David Herron -- The E-Mail guy <david@ms.uky.edu>
<---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<----
<---- It takes more than a good memory to have good memories.
-----------[000238][next][prev][last][first]----------------------------------------------------
Date: 17 Feb 88 12:28:41 GMT
From: turkewit@CCV.BBN.COM ("Kenneth A. Turkewitz")
To: comp.protocols.tcp-ip
Subject: Re: DDN Connection ProblemsJim, The host "hios-pent.arpa" is a MILNET host, which is running PSN Release 6.0, not PSN Release 7.0. --Ken Turkewitz
-----------[000239][next][prev][last][first]----------------------------------------------------
Date: 17 Feb 88 16:37:52 GMT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: IP security options (again)Our PC/TCP accepts datagrams with the security option in them, and ignores it just fine (since December 1987). We presently have no means of setting any options in outgoing IP datagrams. James B. VanBokkelen FTP Software Inc.
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 88 16:57:45 GMT From: dwalker@ORION.CF.UCI.EDU (David Walker) To: comp.protocols.tcp-ip Subject: tn3270 for Wollongong VAX software?
Does anyone know of a tn3270 that has been developed for the
Wollongong's WINS software? We've heard that there is one that runs
under EUNICE, but we'd rather not have to buy the rest of the UNIX
emulation.
David Walker
Network Services Manager
UC Irvine
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 88 19:53:13 GMT From: ras@blade.UUCP (R.A. Schnitzler) To: comp.protocols.tcp-ip Subject: Re: "Guidelines to write Subjects"
Of course the biggest problem with this is one we already face. Most
messages on most (unmoderated) groups are followups. More
specifically, for most postings, people do not do a thing to the
subject line, resulting in obsolete or uninformative subjects. This
coding scheme would in practice, then, refer to the original message,
not necessarily the current one.
Also, I would have much preferred this topic coming up as a suggestion
("What do people think about...?" rather than an autocratic decree
"Please follow the guidelines below...." I also resented the
implication that strict adherence to these guidelines had a direct
relationship to the intelligence of a posting.
Perhaps I missed some earlier postings that might have given a more
polite motivation to this decree.
--
"It's worse than that, Ray Schnitzler
it's physics, Jim" Bell Communication Research
arpa: schnitz!bellcore.com
uucp: ...!bellcore!schnitz
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 88 20:58:36 GMT From: sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman) To: comp.protocols.tcp-ip Subject: Re: ftp hang while trying to talk to cu20b.columbia.edu
I'm experiencing some strange hangs while attempting to ftp files from cu20b. Specifically, the pattern is that I make the connection, log in as anonymous and david@ms.uky.edu as the password. Then I start transferring some data (either a directory listing or an actual get command) and after some short time (approximately 15K worth of data has been transmitted) the transfer hangs and stops doing things... You are by far not the only site having this problem with FTP to CU20B. We're getting lots of complaints about it. Near as I can tell, what we're doing is running out of IP free space, after which, all of our daemons get very confused and stop working properly. No one is really working on this problem here because CU20B's lifetime is only a few more months, but if anyone happens to have collected up some pertinent IP free space manager monitor patches, and they don't look too complex to put in, I guess I'll take a crack at them. At least this is what I *think* is going on here... /Ken -------
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 88 21:03:54 GMT From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) To: comp.protocols.tcp-ip Subject: Re: "Standards" for PC sockets
Nothing must has come of this. I was hoping that some group of the vendors would pick it up after the conference, but this has not happened and I haven't had the time to continue feeding the fire. Drew
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 1988 11:17-PST From: STJOHNS@SRI-NIC.ARPA To: CRB%NIHCUDEC.BITNET@CUNYVM.CUNY.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Conforming
Don't blame the "DEC-VAX-11-750.ARPA" name on hostmaster. She was told to allow it by someone from my organization. *sigh* I've asked her to alert me the next time someone pushes a name like this at her so I can try and prevent a repeat. Mike (DDN Program Office) -------
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 88 05:21:53 GMT From: bzs@BU-CS.BU.EDU To: comp.protocols.tcp-ip Subject: "Guidelines to write Subjects"
Actually, I preferred the evil little editings in the political flamage groups on USENET where subject lines like "Re: Urine testing" became "Re: Urine tasting" and got bounced back and forth blindly...
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 88 06:26:44 GMT From: pavlov@hscfvax.harvard.edu (G.Pavlov) To: comp.protocols.tcp-ip Subject: Re: ftp hang while trying to talk to cu20b.columbia.edu
In article <8377@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: > I'm experiencing some strange hangs while attempting to ftp files > from cu20b. Specifically, the pattern is that I make the connection, > log in as anonymous and david@ms.uky.edu as the password. Then I > start transferring some data (either a directory listing or an > actual get command) and after some short time (approximately 15K > worth of data has been transmitted) the transfer hangs and stops > doing things. According to the Kermit folks at Columbia, there are known problems at the cu20b end. I experienced the same synptoms for several months (trying to get thru on a variety of machines) and finally gave up. Used KERMSRV instead; greg pavlov, fstrf, amherst, ny
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Feb 88 14:52:56 PST From: mcc@etn-wlv.eaton.com (Merton Campbell Crockett) To: CRB%NIHCUDEC.BITNET@cunyvm.cuny.edu, tcp-ip@sri-nic.arpa Subject: Re: Conforming
If you have all your ducks in order, are really robust (no excrement out--but accept excrement without complaint, and pass the DCA verification suite; you could call yourself HUBBA.HUBBA.ARPA or in Robb's case TOP.GUN.MIL if the Navy groups in San Diego haven't used it already. -------
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Feb 88 12:59:51 EST From: "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Re: Complete FROM: field.
> It might also help if the current trend of including excerpts and > complete text of subject messages in responses wasn't so popular. It seems > as though messages are getting more and more verbose as time passes (please > don't construe this to mean that I think messages contain useless input). I like to see an excerpt from the message being responded to. It helps me keep track of the several threads of conversation that I am trying to follow on multiple lists. -------
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Feb 88 13:31:02 EDT From: "C. BACON" <CRB%NIHCUDEC.BITNET@CUNYVM.CUNY.EDU> To: <tcp-ip@sri-nic.arpa> Subject: Conforming
Originatedby: <terry@DEC-VAX-11-750.ARPA> OTo: <CRB@NIHCUDEC> Received: from NIHCU(Mailer) by NIHCUDEC(BitDae) on Thu, 18 Feb 88 10:37:26 EDT` Received: by BYUADMIN (Mailer X1.25) id 5466; Thu, 18 Feb 88 08:32:49 MST Date: Tue, 16 Feb 88 07:49:08 EST Reply-To: <TCP-IP@SRI-NIC.ARPA> Sender: "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN> X-To: tcp-ip@sri-nic.arpa Hello All, > Re: "From: address of terry@dvax " MY host administrator has changed our official sitename to match our MILnet sitename (dec-vax-11-750.arpa). This will cause the "FROM" address of my mail to conform network requirements. Seems only fair... Terry Robb ************************************************************************ *- Terence A. Robb -* *- Network Solutions -* *- Systems Programming Specialist -* *- MILnet: terry@dec-vax-11-750.arpa -* *- PHONEnet: (703) 749-1918 -* *- MAILnet: 8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180 -* ************************************************************************ Comment by C. BACON I take it from the name that DEC-VAX-11-750.ARPA is the definitive and authoritative gateway to all the 750s on the Internet! You could get just a wee bit dumber and name your site NETWORK-HOST.ARPA (=: --Or how about ARPA.ARPA (hostmaster could let it slip past!) -------
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Feb 88 18:49:44 PST From: Paul Mockapetris <pvm@venera.isi.edu> To: Mark Crispin <MRC@panda.panda.com> Cc: TCP-IP@sri-nic.arpa, Header-People@mc.lcs.mit.edu Subject: Re: Braden on secondary IP addresses
Mark, Bob, There are real issues behind this debate, and they are 1) what are the right policies with regard to hosts with multiple addresses and 2) where should the policies be implemented. It would be nice if everyone agreed what the rules are, but the waters are pretty muddy. There can be a large difference in performance depending on which address you use. My experience with domain and mail services suggests that sometimes a host offers different services on different addresses, and sometimes only a subset of the addresses are reachable due to gateway, etc factors. The bottom line is that sometimes whether you win or lose depends on the source and/or destination address you choose. There may always be a best address, but it isn't always possible to know which one it is without empirical information. I can always prefer destination addresses which share a common network, but sometimes the problem is "Given N non-local class C addresses, which one should I use?" Since the answer would seem to depend on both the identity of the source and the identity of the destination, it doesn't seem that either can solve the problem alone. Its not really just a mail issue. For example, domain resolvers and mailers have similar options. [A resolver has to decide (1) which sending address to use, (2) which name server to ask, and (3) which destination address to use when it targets a query. A mailer has to decide (1) which sending address to use (2) which MX RR (i.e. mail server) to use, and (3) which destination address to use. The parallels continue when you think about what to do in case of errors, how you tradeoff network resources vs local resources vs time to finish a request, etc. Admittedly, there are also large differences, but dealing with multiple addresses is an issue which comes up whenever you have such network services.] The domain system won't solve this problem. In fact, it will make it worse by spreading multiple addresses in more contexts. What we need is a consensus on policies regarding the use of multiple addresses and single module that can be used by all applications to implement the policies. (Maybe we have discovered one of the missing layers in the Internet 7 layer cake.) paul -------
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 88 16:25:33 GMT From: neerma@COD.NOSC.MIL (Merle A. Neer) To: comp.protocols.tcp-ip Subject: Need help with UNIX tcp
------- It just occurred to me that this list may be the best place to go for help with a problem we have been struggling with for years. We have been developing client/server processes on tcp for going on ten years and have had the unfortunate experience of having to sometimes do it on UNIX. The problem simply stated is this: the user process cannot get the status of its tcp connections from UNIX. Yeah, we know about SIGPIPE but it only works sometimes. What I'm really concerned about is that so many other implementations of tcp seem to be derived directly from the UNIX bsd versions of tcp. They in turn inherit the deep dark mysteriousness of the status of connects. Have any UNIX guru-types ever considered offering a 'status(myconnect)' call? We'll gladly pay for one. Or even just a 'signal(YOURCONNECTISBOGUS,letmeknow)' would be nice? I would like also to hear from other unfortunate souls that have to program on UNIX tcp to see how they have dealt with this problem. Yes, we have worshipped at the UNIX altar long enough to deserve some secrets. Just a few. Merle Neer neerma@nosc -------
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 88 16:32:05 GMT From: karn@thumper.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: IP security options (again)
My IP should also correctly ignore any options it doesn't understand. I've never seen a datagram with options, so I can't confirm this for sure, but the code looks right... Phil
-----------[000253][next][prev][last][first]----------------------------------------------------
Date: 18 Feb 88 17:31:02 GMT
From: CRB@NIHCUDEC.BITNET ("C. BACON")
To: comp.protocols.tcp-ip
Subject: ConformingOriginatedby: <terry@DEC-VAX-11-750.ARPA> OTo: <CRB@NIHCUDEC> Received: from NIHCU(Mailer) by NIHCUDEC(BitDae) on Thu, 18 Feb 88 10:37:26 EDT` Received: by BYUADMIN (Mailer X1.25) id 5466; Thu, 18 Feb 88 08:32:49 MST Date: Tue, 16 Feb 88 07:49:08 EST Reply-To: <TCP-IP@SRI-NIC.ARPA> Sender: "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN> X-To: tcp-ip@sri-nic.arpa Hello All, > Re: "From: address of terry@dvax " MY host administrator has changed our official sitename to match our MILnet sitename (dec-vax-11-750.arpa). This will cause the "FROM" address of my mail to conform network requirements. Seems only fair... Terry Robb ************************************************************************ *- Terence A. Robb -* *- Network Solutions -* *- Systems Programming Specialist -* *- MILnet: terry@dec-vax-11-750.arpa -* *- PHONEnet: (703) 749-1918 -* *- MAILnet: 8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180 -* ************************************************************************ Comment by C. BACON I take it from the name that DEC-VAX-11-750.ARPA is the definitive and authoritative gateway to all the 750s on the Internet! You could get just a wee bit dumber and name your site NETWORK-HOST.ARPA (=: --Or how about ARPA.ARPA (hostmaster could let it slip past!)
-----------[000254][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 88 17:36:04 GMT From: robert@richp1.UUCP (Robert Miller) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: TCP/IP <-> SNA gateway products
Having trouble with mail to Ron Natalie:
Warning From uucp
We have been unable to contact machine 'ucbvax' since you queued your job.
ucbvax!mail topaz.rutgers.edu!ron (Date 02/16)
#############################################
##### Data File: ############################
>From richp1!robert Tue Feb 16 04:35:36 1988 remote from ihnp4
Received: by ihnp4.ATT.COM id AA15074; 16 Feb 88 04:35:36 CST (Tue)
Received: by richp1.UUCP (smail2.5)
id AA23845; 15 Feb 88 08:40:40 CST (Mon)
From: ihnp4!laidbak!spl1!richp1!robert
To: laidbak!ihnp4!ucbvax!topaz.rutgers.edu!ron (Ron Natalie)
Subject: Re: TCP/IP <-> SNA gateway products
Message-Id: <8802150840.AA23845@richp1.UUCP>
Date: 15 Feb 88 08:40:40 CST (Mon)
>Do they (Bridge CS-1/SNA) allow you to define new terminals and keyboard
>maps yet? This is the main reason why we panned them.
>-Ron
The Bridge CS/1-SNA will not allow you to define new terminals.
The sysgen menu does allow you to select, for each virtual circuit,
one of 17 pre-defined terminals or just display a terminal menu and
let the user select. Keyboard mapping is two things. The sysgen
menu has changed from asking you to select a character set of a
particular country or language to providing EBCDIC/ASCII and
ASCII/EBCDIC translation tables you can tailor to your needs. In
addition to this, my company modified the telnet command to make
use of an external (to the CS/1-SNA) keymap file. This was
accomplished with assistance from Bridge Communications. Our
CS/1-SNA is sysgen'ed to always appear as a VT100 terminal. Since
my company makes its own keyboards, we customize the keymap file to
map our keyboards to the VT100. This is working great.
Robert Miller
--
.......................................
"To open, cut along dotted line." ....:.......................................
: : Robert Miller @ ihnp4!richp1!robert
.....
-----------[000255][next][prev][last][first]----------------------------------------------------
Date: 18 Feb 88 17:59:51 GMT
From: RAF@NIHCU.BITNET ("Roger Fajman")
To: comp.protocols.tcp-ip
Subject: Re: Complete FROM: field.> It might also help if the current trend of including excerpts and > complete text of subject messages in responses wasn't so popular. It seems > as though messages are getting more and more verbose as time passes (please > don't construe this to mean that I think messages contain useless input). I like to see an excerpt from the message being responded to. It helps me keep track of the several threads of conversation that I am trying to follow on multiple lists.
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 88 18:50:00 GMT From: WWB.TYM@OFFICE-1.ARPA (Bill Barns) To: comp.protocols.tcp-ip Subject: Re: ftp hang while trying to talk to cu20b.columbia.edu
Readers not interested in the guts of TCP implementation might as well skip this message. I've had to muck about with Tenex TCP which is "related" to TOPS-20 TCP, and has much worse constraints with buffer space due to being part of a single section monitor. Some of what I've done to try to cope with free storage problems may be relevant to your monitor, but only you can tell for sure. I think there must be a jillion locally-hacked subflavors of this TCP code, and who knows how much resemblance remains between yours and mine. I can say that I do have a copy of "DEC's source" as of about 2.5 years ago and it seems to have the same problems which I'm about to describe, so maybe you have them too. Refer to the TCP packetizer near PKTZ10 (in source file TCPPZ or TCPTCP). The call on TCPIPK will nonskip-return if you are indeed out of space. Code in a literal tries to queue you to retry but as I understand the code, there's a problem. Your TCB is not queued anywhere at this instant, but TSFP or TSEP is very probably on (else why are you here?) So ENCPKT and/or DLAYPZ will effectively no-op and you're out of the packetizer without being queued anywhere. Any future Force or Encourage will meet the same fate because of those same bits. You're trapped in the Twilight Zone. Cure: SETZRO <TSFP,TSEP>,(TCB) as the first thing in the literal that calls ENCPKT after TCPIPK failure. If this scenario happened, it would be likely to yield the symptoms described by David Herron; but so might other things. I made several changes to TCPPRC routine, a little too long to list here. Basically they are: not to run a free-storage scavenge more than once a second, so as not to hog the CPU; and don't run TVTOPR on any pass that did a scavenge, in hopes of making fewer and bigger Telnet packets. It's better to avoid running out of space in the first place, even if that takes something drastic. With an 1822 interface it's absolutely crucial not to let the input interrupt level run out of buffers, so as to avoid RFNM-related deadlocks. Solution: Never give Internet the "last" input buffer. Put it back on the input buffer list after processing the 1822 leader. I suspect this isn't your problem though, since your addresses are class B/C, thus probably not 1822. It would help to have some idea of what most of your space is being used for when you run out. Absent specific data, I'd suspect huge retransmit queues caused by big windows and slow gateways between you and the FTPers. You can brute-force cope with this somewhat either by clamping received windows, or by finagling the packetizer to refuse to packetize for any connection that has more than n packets on the RX queue, or where the first packet on the RX queue has actually been retransmitted (a quick test for congestion). This will slow things down, but that's what you need to do when you're short of space. You can condition this code on INTFSP being less than some threshold and shove it into the PKTZ10 area too. If you have a lot of TVT (Telnet) tinygram traffic, you might want to add code in this same area to ask TCPIPK for only the size of buffer you need, rather than a max size buffer, when space is below the threshold. Also in the OPSCAN routine (TTTVDV or TTANDV source file?) around OPSCA1+10 or so, just after the JUMPE T3,OPSCA7 you might add JN TSEP,(TCB),OPSCA7 which will prevent this routine from undoing any delay previously imposed by some other routine. Further down in this same routine you should also have a change published by Westfield and Crispin about 2-3 years ago which includes a test on whether the RX queue is empty. This change is mainly performance-oriented but will save free storage too in some situations. These cover the highlights of things I've done that seem relevant. You can talk bits with me further if you're interested, of course. I wanted to post this much in case it stirs up any comments from TOPS-20 hackers out there. Maybe someone out there has already done these changes in a form that will slide directly into CU20B monitor. -b
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 88 19:17:00 GMT From: STJOHNS@SRI-NIC.ARPA To: comp.protocols.tcp-ip Subject: Re: Conforming
Don't blame the "DEC-VAX-11-750.ARPA" name on hostmaster. She was told to allow it by someone from my organization. *sigh* I've asked her to alert me the next time someone pushes a name like this at her so I can try and prevent a repeat. Mike (DDN Program Office)
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 88 20:30:26 GMT From: NIC@SRI-NIC.ARPA (DDN Reference) To: comp.protocols.tcp-ip Subject: TCP/IP, X.25 and ISO products
Many of you are probably interested in tracking the development of ISO products since the DoD announcement to support ISO. The Defense Data Network (DDN) document, the "DDN Protocol Implementations and Vendors Guide", produced by the DDN Network Information Center (NIC), contains product descriptions of TCP/IP, X.25 and ISO products. It is being updated for release at the end of the month. For those of you who are fairly new to the network, this document is a guide to implementations and products associated with the DDN suite of data communications protocols. It is published for informational purposes only. Although inclusion does not constitute an endorsement on behalf of DoD, the product descriptions may help you to locate useful products or implementations. To assist with the network's transition to ISO protocols, we are making every attempt to include descriptions of ISO-based products. Over the last few months many vendors have been letting us know about their TCP/IP and ISO product line. If you know of any work being done in support of TCP/IP, ISO, or X.25 that you would like to see listed in this guide, please let the NIC know. For your convenience, we developed an online template for easily filling out the type of information we are seeking. The template is on the SRI-NIC.ARPA host in the file NETINFO:VENDORS-TEMPLATE.TXT and may be FTPed or obtained through SERVICE, the NIC's automatic mail service. For instructions or questions about any of the above, contact NIC@SRI-NIC.ARPA or call us at 1-800-235-3155 or 415-859-3695. -Francine Perillo /DDN NIC -------
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 1988 06:21-PST From: STJOHNS@SRI-NIC.ARPA To: sra@MITRE-BEDFORD.ARPA Cc: LYNCH@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA Subject: Re: Life in the Swamps / Testing
Stan, the reason no one has done this (and it has crossed my mind more than once) is that is leaves them liable to a law suite. Without some sort of *formal* testing procedure, with objective results, a vendor could sue and most probably win if I got up and said its product didn't work. Unfortunately, passing the formal testing is no guarantee of being able to interoperate. We could start holding the internet bake-offs as an annual event and publish a matrix of who could talk to who and the type of performance we saw. And we could also publish which vendors declined to compete. Comments?
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 1988 10:41 EST From: Charles Jerian <cpj@citi.umich.edu> To: tcp-ip@sri-nic.arpa Subject: a ping with record route
A ping that works tolerably well with record route is on citi.umich.edu 35.1.128.16 via anonymous ftp in pub/ping.tar.Z It works on 4.3 systems like RT's and on a vax running ultrix with some kernel changes. It crashes a vax running stock ultrix. Suns drop RR packets. It used to work for me to arpa sites running dec-10s but now that my arpa path goes to psc-gw instead of terp, it has stopped working for me. Various machines do different things with record route. Fuzzs turn them around but don't record their presence, protogaters and 4.3 systems record their presence but don't turn them around. Kinetics boxes turn them around. HP/UX turns them around. Mailbridges don't turn them around or record their presence. -------
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Feb 88 14:08:10 PST From: braden@venera.isi.edu To: LYNCH@a.isi.edu Cc: STJOHNS@sri-nic.arpa, sra@mitre-bedford.arpa, tcp-ip@sri-nic.arpa Subject: Re: Life in the Swamps / Testing
Testing a "network" product is just a lot harder because you have the end systems and the network(s) all wrapped up in some kind of non deterministic swamp. And we are asking for a "rating" or a pass/fail grade? Or what? Dan, Neither of these seems very useful. What we really need for each product is a list of its deficiencies, bonuses, and "features" (things that cannot be classified as either - or +). There is a pretty well-known list of deficiencies -- ie failure to meet the written/commonly-accepted specification. E.g., a host that cannot handle subnetting, a host that does not act on redirects, a host that does not timeout or somehow remove stale redirect information, a host that bombs when it receives an X for some value of X, a host that cannot switch to an alternative gateway when the one it is using fails, a host that cannot be multihomed, etc, etc., etc. Or, a gateway that does not implement IP option Y for some value of Y, a gateway that cannot send redirects, a gateway that has no provision for sending Source Quench, etc., etc. Or, a TCP that does not follow the retransmission guidelines that (we hope) will be published as a result of Van Jacobson's work. I think you get the idea. The point is that there are qualitative (algorithmic) features that are the most important to the survival/ success of the Internet. If a host implementation included every single wonderful thing except subnetting, it might get a good "score"; yet it still has a grievous deficiency that needs to get fixed. Bob Braden
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Feb 88 11:41:07 EST From: "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU> To: tcp-ip@SRI-NIC.ARPA Subject: Re: Life in the Swamps / Testing
I like Mike's idea of a bakeoff, but a list wouldn't bother us either (as long as it was kept current, and some effort was made to let people know when it was updated). We try fairly hard to keep our code nicely fixed up, and I think we would benefit (as well as the Internet community) from any public effort that let the world know the gory details. One problem with a bakeoff is that there are a number of fairly large TCP vendors who aren't on the Internet, and so they'd have to have a proxy site, if they chose to participate at all. Regarding lawsuits, I don't think vendor X would have a leg to stand on if someone said "Vendor X's product Y, in version Z, does not support IP subnets as described in RFC 950", or "...is shipped with a sendmail.cf that causes them to not terminate SMTP commands with CR LF". James B. VanBokkelen FTP Software Inc.
-----------[000263][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Feb 88 11:45:42 EST From: H. Craig McKee <mckee@mitre.arpa> To: tcp-ip@sri-nic.arpa Subject: Re: Life in the Swamps / Testing
Mike StJohns notes: >We could start holding the internet bake-offs as an annual event >and publish a matrix of who could talk to who and the type of >performance we saw. And we could also publish which vendors >declined to compete. Comments? I'd like to hear from the Corporation for Open Systems.
-----------[000264][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Feb 88 12:20:24 EST From: Doug Montgomery <dougm@icst-osi.arpa> To: iso@nrtc.northrop.COM, satz@clash.cisco.com, tcp-ip@sri-nic.ARPA Subject: Re: X.25 Call User Data for higher level protocols
Greg, The reference you are looking for is "PDTR 9577: Protocol Identification in the OSI Network Layer". This proposed draft technical report contains a description of the means used to identify network layer protocols/services and where such information is located in a protocol. The document also provides a record of those values of protocol identifiers which have been used by various authorities. An annex of the PDTR decribes the location and use of protocol identifiers in X.25. The source of the document is ISO/TC 97/SC 6/WG 2. If you can't get your hands on it elsewhere drop a note and I'll send you a copy. +------------------------------------------------------------+ | Doug Montgomery dougm@icst-osi.arpa | | National Bureau of Standards | | Technology Building, B217 (301) 975-3630 | | Giathersburg, MD 20899 TELEX: 89-8493 | +------------------------------------------------------------+ -------
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: Fri 19 Feb 88 16:10:06-EST From: Dan Lynch <LYNCH@A.ISI.EDU> To: STJOHNS@SRI-NIC.ARPA Cc: sra@MITRE-BEDFORD.ARPA, tcp-ip@SRI-NIC.ARPA, lynch@A.ISI.EDU Subject: Re: Life in the Swamps / Testing
Mike, We all see product reviews in many of the trade magazines for PC software and hardware. The reviews vary as the products vary. I've never heard of a lawsuit stemming from one. But I do see retractions and clarifications! But that is for testing PC level products. Testing a "network" product is just a lot harder because you have the end systems and the network(s) all wrapped up in some kind of non deterministic swamp. And we are asking for a "rating" or a pass/fail grade? Or what? I tried to get the "serious vendors" to establish a permanent "interoperability demonstration center" starting about a year ago. It never flew because the costs are high and after you get it up and running and the "score cards" are in, who needs to keep running it all the time? So, we are going to do it on a temporary basis at the next TCP/IP Interoperability conference. It will still cost a bundle to put it all together, but it will give the "serious vendors" a chance to show how well their products interoperate against the others. I don't know where this activity will lead, but I do know that something like this has to happen if we are ever to get lots of the nagging bugs out. Vendors will be given a list of "known bugs" and be warned to not bring them along or the whole world will know how far behind they are. On the positive side, those vendors who show off well will get the publicity that should enable them to sell more product to those who are trying to buy effective solutions. Dan -------
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: Fri, 19 Feb 88 16:46:26 EST From: terry@DEC-VAX-11-750.ARPA To: tcp-ip@sri-nic.arpa Cc: terry@vax1.arpa Subject: Re: Data Acceptance Algorithms
I wish to thank those persons who sent me mail in response to my "in-window" vs "in-order" algorithm question. All of the responses recommended "in-window". Those who said they have a TCP using "in-order" wished they had "in-window". The results were not surprising. I must confess I was really more interested in the statistics concerning out-of-order packets which accompanied many of the responses. When the mail finishes coming in (33 messages last count), I will combine the statistics with those I have collected and post the results. Thanks Again.... Terry "top gun" Robb -------
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 88 12:59:52 GMT From: sra@MITRE-BEDFORD.ARPA (Stan Ames) To: comp.protocols.tcp-ip Subject: Re: Life in the Swamps / Testing
Dan It has been bad enough that existing vendors have not seen fit to fix such simple things as using the correct IP broadcast address. What I see as troubling is that entirely new products are perpetuating the problem. Perhaps the emerging ISO vendors will learn from our mistake and control products that claim to implement the protocols but have taken creative interpretations. Perhaps it is time for the internet group to list vendors that implement the protocols correctly and also publish a list of those that do not. Stan Ames
-----------[000268][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 88 13:50:10 GMT From: galbp!gja@gatech.edu (Greg Ansley) To: tcp-ip@sri-nic.arpa Subject: SLIP (what & where??)
< Line eater food > I know this has been asked before recently but it wasn't important to me at the time ! :-) A need a discription of SLIP, what it is and what it can do as well as a pointer to where I can get the code! Please reply be mail so as not to bore the rest of the net! Thanks, Greg Ansley gja@galbp.LBP.HARRIS.COM Harris/Lanier, Atlanta, GA ...!gatech!galbp!gja (404) 329-8200 -- Thanks, Greg Ansley gja@galbp.LBP.HARRIS.COM Harris/Lanier, Atlanta, GA ...!gatech!galbp!gja (404) 329-8200 -------
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 88 14:21:00 GMT From: STJOHNS@SRI-NIC.ARPA To: comp.protocols.tcp-ip Subject: Re: Life in the Swamps / Testing
Stan, the reason no one has done this (and it has crossed my mind more than once) is that is leaves them liable to a law suite. Without some sort of *formal* testing procedure, with objective results, a vendor could sue and most probably win if I got up and said its product didn't work. Unfortunately, passing the formal testing is no guarantee of being able to interoperate. We could start holding the internet bake-offs as an annual event and publish a matrix of who could talk to who and the type of performance we saw. And we could also publish which vendors declined to compete. Comments?
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 88 14:34:04 GMT From: lyle%asbi-sid.huachuca-em.arpa@HUACHUCA-EM.ARPA (Lyle Johnson) To: comp.protocols.tcp-ip Subject: MMDF E-MAIL Systems
I am attempting to find information on the MMDF E-MAIL package. I especially need information on who developed it and what organization they worked for at the time. I need information on contractual and legal aspects of the development as well as the subsequent distribution rights. I would like to know who in fact has distribution rights to MMDF and who owns the source code, and who is now responsible for software maintenance. Please address any comments to: LYLE%ASBI-SID@HUACHUCA-EM.ARPA Thank you for any help you can give me. Lyle Johnson
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 88 15:12:50 GMT From: jqj@uoregon.UUCP (JQ Johnson) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: KA9Q as an IP router?
Has anyone made any serious effort to use a PC with two Ethernet interfaces as an IP router? My impression is that the KA9Q code is about 95% there to make this possible. Such a beast would be very nice if possible, since current commercial routers (CISCO, Proteon, Bridge, etc.) all cost in the $9K or more range; one could configure a 12MHz PC-AT clone with disk, memory, 2 Ethernets, etc. for substantially under $2K. One would not expect performance to be comparable to that of a P4200 or CISCO, but for some applications that would not be a problem. My questions: 1/ is anyone actually doing this? What sorts of packet forwarding rates do you get on what hardware? 2/ what are the current limitations on the KA9Q code that make this idea unfeasible? I haven't looked at KA9Q in a while; does a current version have (1) support for any Ethernet I/F except 3C501? (2) packet frag/reassembly? (3) support for a range of routing protocols (RIP, HELO, EGP)? (4) all the other things RFC1009 says a gateway has to do properly? 3/ has anyone considered doing this based on one of the other IP implementations for the PC? 4/ Is there any commercial product I've missed that provides a cheap (under $5K) moderate-performance IP router?
-----------[000272][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 1988 23:15-PST From: STJOHNS@SRI-NIC.ARPA To: JBVB@AI.AI.MIT.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Life in the Swamps / Testing
"Regarding lawsuits, ..." You are right, under the circumstances you described, where you can objectively state "facts" like vendor w doesn't implement subnets. Unfortunately, on the net we get things like "vendor y has poor performance when talking to anyone but vendor y products" Or "vendor z has a garbage implementation". I.e. difficult to quantify things. And difficult to prove in court. Saying those things without the facts to back thme up is very dangerous, especially when coming from a *official* organization as it can lead to a loss of business for the vendor and the vendor trying to recoup by suing the person or org who ruined their business. Mike
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 88 16:02:27 GMT From: morgan@brambo.UUCP (Morgan W. Jones) To: comp.protocols.tcp-ip Subject: Re: TLI and Sockets
} Now, if you question really was: "I have a program written to use
} Berkeley sockets but I want to run it on a SVR3 machine which only
} has streams, what can I do?" Then the answer is that some people
} who are "heavy into Streams/TLI" have written libraries on top of
} TLI which make it look like sockets.
Does anyone know where a copy of these can be obtained (and don't say
anonymous FTP)? Have they been posted to the net somewhere?
--
Morgan Jones - Bramalea Software Inc. morgan@brambo.UUCP
...!{uunet!mnetor!lsuc!ncrcan, utgpu!telly}!brambo!morgan
"These might not even be my opinions, let alone anyone else's."
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 88 18:52:23 GMT From: rminnich@udel.EDU (Ron Minnich) To: comp.protocols.tcp-ip Subject: DDCMP for Unix
It never fails. Somebody posted an article about DDCMP for Unix here a few days ago, and after the article was expired someone here asked me if i knew of a ddcmp for unix. Can anybody who can point me at such a beast please send e-mail? Thanks? ron -- ron (rminnich@udel.edu)
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: Sat, 20 Feb 88 10:42:05 EST From: Frank Kastenholz <KASTEN@MITVMA.MIT.EDU> To: TCP/IP List <TCP-IP@SRI-NIC.ARPA> Subject: Where is the KA9Q TCP?
I know this was on the list recently, but who/where can I get the packet Radio TCP/IP from? Also, while you are reading, who/where do I go at UCB to get the Unix/BSD sources? (I have a valid AT&T Unix Source Licence). Thanks Frank Kastenholz Atex Inc. p.s. I suggest that responses be sent direct to me - no need to clutter the net. -------
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: 20 Feb 88 07:03:40 GMT From: david@ms.uky.edu (David Herron -- Resident E-mail Hack) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: KA9Q as an IP router?
I am tentatively planning on building a gateway this summer using a
pc/at and a couple of ether cards and the software you were
suggesting. I seem to recall, however, there being various pieces of
PD gateway software available -- for instance, the BRL gateway code.
Where/how could I get my hands on that?
A gateway for a couple thou' is very tempting
--
<---- David Herron -- The E-Mail guy <david@ms.uky.edu>
<---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<----
<---- It takes more than a good memory to have good memories.
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: 20 Feb 88 15:42:05 GMT From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: Where is the KA9Q TCP?
I know this was on the list recently, but who/where can I get the packet Radio TCP/IP from? Also, while you are reading, who/where do I go at UCB to get the Unix/BSD sources? (I have a valid AT&T Unix Source Licence). Thanks Frank Kastenholz Atex Inc. p.s. I suggest that responses be sent direct to me - no need to clutter the net.
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 1988 10:13-PST From: STJOHNS@SRI-NIC.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: Re: IP security options (again)
Umm... the security option is *COPIED* upon fragmentation. Or is supposed to be copied. Check the documentation. Mike
-----------[000279][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 88 05:17:22 GMT From: bc@halley.UUCP (Bill Crews) To: comp.protocols.tcp-ip Subject: Re: "Guidelines to write Subjects"
In article <958@blade.UUCP> ras@blade.UUCP (R.A. Schnitzler) writes: >Of course the biggest problem with this is one we already face. Most >messages on most (unmoderated) groups are followups. More >specifically, for most postings, people do not do a thing to the >subject line, resulting in obsolete or uninformative subjects. This >coding scheme would in practice, then, refer to the original message, >not necessarily the current one. This discussion is all very informative, I guess, but I wonder who had the eNORmous imagination to choose comp.protocols.tcp-ip for this subject. A bad choice of newsgroup FAR outweighs any consideration of exact syntax. People, let us just let this drop. If someone must discuss this, how about news.misc or somewhere like that? Please do not follow up to this message. Over and out. -bc -- Bill Crews Tandem Computers bc@halley.UUCP Austin, Texas ..!rutgers!im4u!halley!bc (512) 244-8350
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 1988 14:37-PST From: STJOHNS@SRI-NIC.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: Re: IP security options (again)
The new RFC is out. Check the index. Its been out about a month. BUT... contrary to what the document says, it is still not the final form. Specifically, the IDs for the various levels are changing to spread out the coding. *sigh* I'll try and keep you posted as I find out the contortions the BLACKER people are twisting the IPSO into. Mike
-----------[000281][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 88 17:33:16 GMT From: tucker%vger@GSWD-VMS.GOULD.COM (Tim Tucker) To: comp.protocols.tcp-ip Subject: IP security options (again)
We have found that any system using 4.3 BSD TCP/IP code can't handle the IP security option. The reason follows. If you fragment a packet with the IP security option, the option should only appear in the first fragment. On BSD 4.3 systems this is done correctly, but the IP header in the second or more fragments is too long! The option is removed correctly, but the IP header size is not adjusted. This bug causes fragmented packets with the IP security option to be dropped in reassembly. A big bug, since most people using the option are connected to a link like the ARPAnet thru ethernet. Tim Tucker tucker@claudius.Gould.COM
-----------[000282][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 88 18:13:00 GMT From: STJOHNS@SRI-NIC.ARPA To: comp.protocols.tcp-ip Subject: Re: IP security options (again)
Umm... the security option is *COPIED* upon fragmentation. Or is supposed to be copied. Check the documentation. Mike
-----------[000283][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 88 18:16:46 GMT From: rochester!ritcv!cci632!ccicpg!arnold!dave@cu-arpa.cs.cornell.edu (Dave Arnold) To: tcp-ip@sri-nic.arpa Subject: Network Interface Working Group
In a previous posting, I asked a question regarding standard C-binding
network interfaces, and any work currently in progress on the
subject. Following is what I considered to be the definitive
repsonse.
=======================================================================
From: <uunet!likewise!attunix!sfdic!ssa>
Posted-Date: Tue, 26 Jan 88 10:29:34 est
To: vdelta!dave
Subject: Re: /usr/group Network Interface Working Group
Status: R
Dave,
I have good news and bad news for you. Luckily, most of it
is good. First of all, I am the right person to contact. I've been
chairing the committee for a little over a year now. Unfortunately,
we have not made a tremendous amount of progress for various
reasons.
The interface that you proposed is exactly what I am personally shooting
for. The committee's goal is to propose an interface that is source
code portable across POSIX-conforming systems. To do this, we classified
networking applications into 3 catagories:
1) sophisticated - an application that knows it is running on a network
and makes use of protocol or network-specific features (we do
not address this type of application - it is inherently non-
portable)
2) knowledgeable - an application that knows it is running on a network
but does NOT make any use of protocol or network-specific
features (in other words, it really wants a "reliable" bit pipe).
We are working on this type of application first.
3) naive - an application that does not know that it is running over
a network (e.g. a cat process that has its output directed to a
network device). We deferred dealing with this type of
application until we finish the knowledgeable application.
It took a fair amount of time to define the problem as stated above.
At our last meeting, one of the members volunteered to write a proposal
off-line to present at the next meeting in Dallas on Feb. 8&9.
This proposal (nor any other) has not been approved yet.
Anyhow, to obtain our documents, you should call the /usr/group office at
408-986-8840 and ask for whichever documents your interested.
The complete list is:
NI-86-001 A Comparison of Sockets and the Transport Library Interface
NI-86-002 Palo Alto Meeting Minutes
NI-87-001 Portable Network Interface
NI-87-002 Washington D.C. Meeting Minutes
NI-87-003 Toronto Meeting Minutes
NI-87-004 POSIX Portable Network Interface (PNI) Issues Pertinant(sic) to
Definition of a Theory of Operation
NI-87-005 Seattle Meeting Minutes
NI-87-006 Nashua Meeting Minutes
NI-87-007 Proposal for a POSIX Portable Network Interface (PNI) Definition
If you have any trouble obtaining any of them, let me know. If you would
like, I can add you to our mailing list so you can obtain everything
as it is written. Of course, you are also welcome to attend our meetings.
They are completely open; all that you have to do is be there.
Another note of interest is that we have had a newsgroup
(usrgroup.netinter) established for us to stimulate discussion.
Unfortunately, that group is not being fed into my machine at the moment,
so I have no idea what, if anything, has been posted.
If you have more specific questions, feel free to contact me.
BTW, if you didn't get the implication above, the bad news is that the
interface is not even close to being a standard, so if you had hoped to
use it in a soon-to-be-released product, it won't be there. The good
news is that the work is underway and that you can help shape the
standard.
Steve Albert
AT&T
190 River Road
Room A-114
Summit, NJ 07901
(201)-522-6104
...!attunix!ssa
--
Dave Arnold
dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!dave
-------
-----------[000284][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 88 19:39:41 GMT From: tucker%vger@GSWD-VMS.GOULD.COM (Tim Tucker) To: comp.protocols.tcp-ip Subject: Re: IP security options (again)
> Umm... the security option is *COPIED* upon fragmentation. Or > is supposed to be copied. Check the documentation. Mike Ok, your correct. I guess I should say that the problem with the Berkeley code is that it doesn't fragment packets correctly containing IP options that don't get copied to all fragments. By the way, anyone know when the new IP security option RFC will be out? Tim Tucker tucker@claudius.Gould.COM
-----------[000285][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 88 21:41:16 GMT From: gross@GATEWAY.MITRE.ORG (Phill Gross) To: comp.protocols.tcp-ip Subject: Re: X.25 Call User Data for higher level protocols
Doug, I would like to get a copy of that document. My version is at least a year old. If you are coming to the IETF meeting in a couple weeks, why don't you bring a few extra copies? Thanks, Phill
-----------[000286][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 88 22:37:00 GMT From: STJOHNS@SRI-NIC.ARPA To: comp.protocols.tcp-ip Subject: Re: IP security options (again)
The new RFC is out. Check the index. Its been out about a month. BUT... contrary to what the document says, it is still not the final form. Specifically, the IDs for the various levels are changing to spread out the coding. *sigh* I'll try and keep you posted as I find out the contortions the BLACKER people are twisting the IPSO into. Mike
-----------[000287][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 88 05:42:49 GMT From: johnr@intro.oz (John Andrew Rosauer [Network]) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: NFS for Macintoshes?
We have a thin Ethernet running through our building (and effectively
throughout the University) with IP running on top of this.
We run telnet, ftp and NFS on our UNIX boxes and our PCs (using SUN's
PC-NFS).
It would be nice to include Macintoshes (the standard ones, not Mac IIs)
into this network. I have seen lots of gateways to tcp/ip which
give you telnet and ftp but not NFS. Does anyone know if such products
exist and what are the hardware requirements? I am particularly interested
in solutions for an Ethernet card for a MAC SE and for the Kinetics
AppleTalk/Ethernet-tcp/ip gateway.
Thanks in advance.
________________________________________________________________________________
John Andrew Rosauer ISD: +61 2 692 3495
Network Group ACSnet: johnr@fibro.ucc.su.oz (also CSNET)
University Computing Service ARPA: johnr%fibro.ucc.su.oz@uunet.uu.net
University of Sydney. NSW 2008. UUCP: {enea,hplabs,mcvax,uunet,ubc-vision, \
AUSTRALIA. prlb2,ukc}!munnari!fibro.ucc.su.oz!johnr
-----------[000288][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Feb 88 15:01:51 -0500 From: Andy Malis <malis@OAKLAND.BBN.COM> To: Jim Chappell <vrdxhq!ms3!isns01@UMD5.UMD.EDU> Cc: tcp-ip@SRI-NIC.ARPA, malis@OAKLAND.BBN.COM Subject: Re: DDN Connection Problems
Jim, As Ken Turkewitz already pointed out, your host is on the MILNET, which is using PSN 6.0. If this helps, when my local host ran ULTRIX 1.2 (based upon 4.2 BSD), and its PSN was down following a power failure, it would also type out the "No buffer space available" message. When the PSN came back up, the messages went away. So this may just be the same problem - when you are receiving these messages, your host's PSN is probably down. You should check this with the Milnet MC at (202) 692-5726. Andy -------
-----------[000289][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 88 17:08:58 GMT From: postel@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: re: IP security options (again)
The IP Security Option must be copied into every fragment of an IP-fragmented datagram. RFC-791 page 18, MIL-STD-1778 page 36, RFC-1038 page 2 --jon.
-----------[000290][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 88 19:04:22 GMT From: kleonard@PRC.Unisys.COM (Ken Leonard --> kleonard@gvlv2@prc.unisys.com) To: comp.protocols.tcp-ip Subject: Re: Life in the Swamps / Testing
In article <[SRI-NIC.ARPA]Fri,.19.Feb.88.06:21:34.PST.STJOHNS> STJOHNS@SRI-NIC.ARPA writes: >... >more than once) is that is leaves them liable to a law suite [sic]. >... >results, a vendor could sue and most probably win if I got up and >said its product didn't work. Unfortunately, passing the formal >testing is no guarantee of being able to interoperate. >... Which is why the DCA/NBS "ProtoLab NVLAP" program needs our support. The output from a ProtoLab test suite of a protocol implementation IS NOT JUST a good/nogood tag; it is a COMPLETE and TRACEABLE standard-compliance report. Which means that any potential user can evaluate, in light of OWN/REAL/ACCEPTABLE/NECESSARY task to be accomplished, whether or not to buy a particular implementation. And, properly done, the ProtoLab results show a HECK OF A LOT about the chances of interoperability, too. Regardz, [Engineering: The Art of Science] Ken Leonard --- --- This represents neither my employer's opinion nor my own: It's just something I overheard in a low-class bar down by the docks.
-----------[000291][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 88 20:01:51 GMT From: malis@OAKLAND.BBN.COM (Andy Malis) To: comp.protocols.tcp-ip Subject: Re: DDN Connection Problems
Jim, As Ken Turkewitz already pointed out, your host is on the MILNET, which is using PSN 6.0. If this helps, when my local host ran ULTRIX 1.2 (based upon 4.2 BSD), and its PSN was down following a power failure, it would also type out the "No buffer space available" message. When the PSN came back up, the messages went away. So this may just be the same problem - when you are receiving these messages, your host's PSN is probably down. You should check this with the Milnet MC at (202) 692-5726. Andy
-----------[000292][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 88 20:51:03 GMT From: jerry@oliveb.olivetti.com (Jerry Aguirre) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: KA9Q as an IP router?
The 3C501 ethernet interface supported by the KA9Q sofware will never make a high performance gateway. It has only one buffer and drops packets sent too close together or while it is transmitting.
-----------[000293][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Feb 88 11:19 CST From: <GREG%FNALNET.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: CMU package
I have just installed the CMU TCP/IP package on several Microvax'en and am experienced a strange Telnet situation. The DEC TPU editor screen and cursor functions do not work properly if the terminal is defined as device=VT200, but work if defined as device=VT100. Have I done somthing wrong? Is this a known or documented bug (feature)? Have any of you experienced this as well? Thanks, Greg Chartrand - Fermilab P.O. Box 500 - Batavia, Il. 60510 (312) 840-3727 GREG@FNAL.BITNET or GREG%FNAL.HEPNET@LBL.ARPA -------
-----------[000294][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 88 05:39:37 GMT From: van@LBL-CSAM.ARPA (Van Jacobson) To: comp.protocols.tcp-ip Subject: more on tcp congestion control
Phil - Thanks for correcting the CUTE reference (I've got to start putting JSAC and COM in separate piles) and thanks for your interesting message on changes to the ka9q package. You bring up a lot of things that I should have covered so I'm cc'ing this reply to the tcp/ip list (in the unlikely event that anyone else is interested). > I suggest rounding your computed RTO values up to the next > highest number of ticks when setting the timer. This is > especially important when you calculate retransmission timeouts > based on mean deviations, since they can be very small. > Otherwise it's possible for truncation effects to set the timer > LESS than the current SRTT. Good point. I should have edited that timer msg I inserted because it contained several rounding errors. The line rto = (Avg >> 3) + (Mdev >> 1); should have read rto = ((Avg >> 2) + Mdev + 3) >> 1; which is how things read in the timer rfc & the bsd code -- Avg could also be rounded but it doesn't make much practical difference. The mysterious "+ 3" is half a tick for rounding plus one tick because the send is phased randomly with respect to the clock (i.e., there's a +-1/2 tick uncertainty in when the timer goes off). Also, because of the timer uncertainty, the minimum value for rto should be two ticks. You can save a "if (rto < 2) rto = 2" step, at the cost of a half-tick bias in rto, if you make the above rto = ((Avg >> 2) + Mdev + 4) >> 1; > 3. When you refer to "packets" in the context of setting the > congestion window in TCP, what do you mean? One MSS? Yes, by "packet" without a qualifier (such as "arbitrary size packet") I always mean a one MSS sized packet. > I tried that first, but I ran into problems. When I have an > entire SLIP link to myself, the mean deviation sits at a very > low value. Thus the RTO sits just above the SRTT. But when > slowstart opens up the window to send more, the round trip time > immediately increases beyond the retransmission timeout and an > unnecessary retransmission occurs. The congestion window > oscillates rapidly, with an unnecessary retransmission in each > cycle. I think I understand the problem (although I think you're confusing the slowstart & congestion control algorithms -- more on that in the next section) but I'm not sure I agree with the analysis. I run tcp stuff, bind & NFS over a 2400 baud slip link from home to work and I've spent a bit of time investigating the link's behavior (waiting for the damn slow link gave me a lot of time when I couldn't do anything but investigate the link behavior :-). Having the rtt variance in addition to the rtt is a big help when you're trying to start a bandwidth-limited link. Since errors in the variance decay quickly, you can afford to pump it up whenever you're uncertain about how long a send is going to take. In particular, when starting we set the variance to a `big number' (default is 3 sec but this can be overridden on a per-route basis) and the rtt to either our best estimate (also kept in the route) or zero. After the syn packet, we'll know the rtt for a zero length packet and rttvar will get decayed by at most 25%. As long as the the rtt for the first data packet changes by < 2*.75*bigNumber, we won't get a spurious timeout. We're free to overestimate bigNumber initially because even a factor of 10 error will be `forgotten' in 8 packet exchanges. The same scheme applies for the 2nd and future packet exchanges. If the link is delay limited, increasing the window from one to two packets will have no effect. If the link is bandwidth limited, doubling the window size will double the rtt. In general, given that we know the rtt, R(W), for a window size of W, the worst case rtt change for a window size of W+dW is R(W)*dW/W. We don't know if we'll see the worse case but the above reflects our "uncertainty" in the rtt of the next packet if we increase the window size. Thus it should get lumped into rttvar: rttvar += rtt * dW/W; During slowstart, dW is the max segment size, mss, and W is snd.cwnd so the above becomes rttvar += rtt * mss/snd.cwnd before each snd.cwnd change. (The above needs appropriate scaling and rounding but they're implemenatation dependent. Also, it overestimates the possible rtt change when snd.cwnd is small but that turns out to be desirable.) > So I'm trying something else. I initialize the congestion window > at one MSS, but then I increase the congestion window by the > actual amount of data acked each time an ACK comes in. This > effectively slows the slow-start algorithm so the timer can have > more time to adapt. Or at least the congestion window > oscillation occurs at a much lower rate. What do you think? If you mean open cwnd by MIN(amount.acked, mss), that's a real interesting idea and I'm going to think about it. The above timer hacking takes care of spurious retransmits but there's another problem: Slowstart is designed to prevent hitting a gateway with bursts of packets. If you send a few small packets when the connection starts, their acks will open the window so that if you suddenly decide to send a bunch of data, you'll hit the gateway with a burst. This small/large switch is exactly what happens in an SMTP conversation & it looks like your mod will cure the problem. But, if you mean what you said, I don't think it's a good idea. Consider what happens when you send 1,2,3,4 and 1 is dropped. 2-4 are cached on the other side so when you retransmit 1 and fill the hole in the sequence space, all four packets will be acked. If you increment by the amount acked, cwnd will get fully opened and you'll blast out a window's worth of back-to-back packets, almost guaranteeing another drop. (I've shown the IETF lots of pictures of this kind of stable failure mode.) > 4. I'm confused by the modified slow-start algorithm you > described, the one that uses a threshold to change the amount > the congestion window is increased. Again, what does it mean to > increase the congestion window by 1/cwind? Is cwind in packets > (what size?) or bytes (increase the window by fractions of a > byte?) We found it was important to distinguish startup behavior from steady-state behavior. (It sounds as if you're lumping the two together.) The thing we call "slow start" just has to do with starting data flowing. The algorithm has a very short lifetime -- it typically runs for the first 3-5 rtt after you first start sending on a connection or restart after a drop. When slow start shuts down, the link is in equilibrium (the pipe is full and you've exchanged a full window of data so you know the ack "clock" is working). At this point another algorithm, congestion avoidance, takes over. This algorithm is responsible for estimating how much data is needed to fill the pipe under the current (time-varying) load. The congestion avoidance & slowstart are separate algorithms with completely different objectives. They just happen to run consecutively and just happen to accomplish their individual objectives by twiddling the same state variable (cwnd). The congestion avoidance algorithm is described well in DEC technical report DEC-TR-506, "Congestion Avoidance in Computer Networks with a Connectionless Network Layer" by Raj Jain, K. K. Ramakrishnan, Dah-Ming Chiu, August, 1987. The idea is that when you try to use a window larger than the bandwidth*delay of the network path, the excess window won't fit in the pipe so it must show up in a queue somewhere. In the usual case, "somewhere" will be the outbound queue of the slowest link in the path. That link will probably be a bottleneck for a lot of other conversations and it's likely its queue will fill up and overflow. We treat this as a signal that our window is too large and reduce it (Jain doesn't wait for an overflow -- his signal is a bit in packet that the gateway can set to say its congested.) But the `bandwidth' in the delay-bandwidth product is *your share* of the fixed link bandwidth and your share can change as conversations using the same path come and go. The gateway tells you when you're using too much but says nothing when you're using too little. To find out if someone has shut down and your share is now larger, you continuously test by slowly increasing your window size until the gateway says you're using too much. (Thus the window will oscillate around some mean value. The algorithm is designed to do this. But we've tried to set the adjustable parameters that determine the oscillation so that the bandwidth lost to testing the path is at most 1%.) From a linear system argument, you can show that best probe policy is to make your bandwidth vs. time obey dB/dt = C for some constant C. Since B = W / R, where W is the window size and R is the round trip time, and R is constant, this says you want dW/dt = c for some other c. In other words, in one rtt we want the window to go smoothly from size W to size W+c. I want the algorithm to be "self clocked" so we go looking for how to do the above change using acks rather than time to drive the dW. If the max packet size is mss and we have decent silly window code, a window of W will generate at most W/mss acks and it will generate them spread out over one rtt. Thus if we increment by c/(W/mss) = c*mss/W per ack, we will have opened the window by c after one rtt. An appropriate c for current arpanet conditions turns out to be one mss so the increment part of the congestion avoidance turns into snd.cwnd += mss*mss / snd.cwnd; (you might have to worry about the the fixed-point in this if you were trying to send small packets over a net with a large bandwidth delay product but it's not a problem in any net I know of.) > 5. You didn't specifically mention ICMP source quench, but I > assume you mean that the congestion window should be cut in half > each time you get one. To make this meaningful I also limit the > congestion window to be no more than the offered window. One > question: should the congestion window be allowed to decrease > below one MSS? I would say yes, but I'd like to hear your > opinion. I didn't mention source quench because it's a disaster and I keep hoping it will go away. There must be at least one rtt of hysteresis or "dead time" for any control algorithm to be stable. By using packet drops and timeouts to drive things, we get this automatically. But it's very, very hard to get the right kind of hysteresis with source quench. It's also possible to show that source quench leads to a very unfair bandwidth allocation -- SQ is preferentially delivered to the hosts using the smallest windows (I have lots of trace data showing this and can explain why it happens but the explanation is mathematical and quite involved). So, since SQ currently happens only when one or more packets has been dropped, all we do is close snd.cwnd down to one packet (so no more will get dropped) but we don't touch snd.ssthresh (because the slowstart time is short, ssthresh is the crucial window control, not cwnd). Ssthresh and the rest of the congestion control stuff will get handled correctly, and with the right "time constants", when we eventually take the timeout for the lost packet. We limit cwnd to be at most the offered window (you violate rfc793 if you ever send more than the offered window). I don't think it's a good idea to let cwnd get below one mss. Dropping cwnd below mss forces you to send small packets, increasing the overhead per data byte xferred. Thus you are using the network less efficiently at a time it's heavily loaded and you really want to make the most efficient possible use of it. This is an unstable positive feedback that can lead to collapse. If mss is set correctly, it never makes sense to send a smaller packet. > 6. It's interesting to note that the "set the congestion window > to one packet after a timeout" rule automatically implies the > "first-only retransmission" rule, thus simplifying my code > somewhat. In effect, a timeout is just a very drastic source > quench. Yes, there were several sort-of ad-hoc pieces of code, like the first-only rexmit and all the source quench handling, that were taken out because their job was handled in a more unified way by the slowstart/cong. avoidance framework -- it was very satisfying. We removed something like 15 lines and replaced them with 6. Of course, we then stuck in your clamped retransmit backoff algorithm, a fast retransmit algorithm (that got described at one of the IETF meetings) and a few more goodies, and ended up +3 lines from the original 4.3 code instead of the -9 we expected (not including, of course, dozens of lines of bug fixes). I prefer to think of source quench as a poorly considered, ill behaved timeout :-). - Van
-----------[000295][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Feb 88 12:48:19 CST From: "Paul Lustgraaf" <GR.PJL%ISUMVS.BITNET@CUNYVM.CUNY.EDU> To: <tcp-ip@sri-nic.arpa>
; Why one specific hosts ethernet packets are not passed ; through a "bridge"? The first thing to check, given that some hardware/software combinations allow you to change it (WHY?), is that you don't have a duplicate ethernet address. Paul Lustgraaf GR.PJL@ISUMVS.BITNET Network Specialist Computation Center Iowa State University Ames, IA 50011 515-294-0324 -------
-----------[000296][next][prev][last][first]---------------------------------------------------- Date: Tue, 23 Feb 88 13:10:52 EST From: Gary Malkin <PETTY@MITVMA.MIT.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: TALK Protocol
======================================================================== Date: Tue, 23 Feb 88 12:55:39 EST From: Gary Malkin <PETTY@MITVMA> Subject: TALK Protocol To: TCPIP@SRI-NIC.ARPA Spartacus's KNET allows multiple forms o file transfer and remote login between IBM and non-IBM nodes. What it does not have is the ability to allow a user on an IBM node to communicate with a user on a non-IBM node. I have been thinking about implementing TALK on the IBM side to provide this service. What I need to know is: what is the inter-daemon protocol (the UDP handshake). I also need info about error codes and timeout parameters. If anyone has this information handy, please let me know. Thank you in advance for your help. ' Gary Malkin TCPIP@SRI-NIC.ARPA 2/23/88 TALK Protocol -------
-----------[000297][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 88 19:53:00 EST From: <enger@bluto.scc.com> To: "greg%fnal.hepnet" <greg%fnal.hepnet@LBL.GOV> Cc: <tcp-ip@sri-nic.arpa> Subject: Using DEC VT200 mode through telnet
Greg: I believe VT200 mode allows the system to transmit 8-bit control codes to the terminal. TPU takes advantage of this. For instance, the "<esc>[" sequence is replaced by "<csi>" (9B in hex). This makes the host/terminal communications more compact, and perhaps quicker. Unfortunately, the intervening com facilities must pass 8-bit codes. I don't think telnet normally does this. I logged into my Sun running their latest software, but couldn't find an option to put its telnet into binary mode. I logged onto our VMS Vax, and fired up the Wollongong telnet. It does support a "binary" mode, and this successfully runs TPU. Unfortunately, the command cannot be placed into their TELINIT. telnet startup configuration file; instead it must be typed in manually once the connection has been opened. Best wishes, Bob Enger -------
-----------[000298][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 88 16:44:29 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Link level Ethernet bridges
Does anyone on this list have an inkling about why given the following
configuration that one specific hosts ethernet packets are not passed
through a "bridge":
segment 1 segment 2
Ha--| |--Hz
| |
Hb--| |--Hz-1
| |
Hp--| |
. .
. .
. .
Hq--| |--Hr
|--[D]--|
All the hosts Ha through Hz with the exception of Hp can communicate over
the ether. All the hosts Ha through Hq INCLUDING Hp can communicate over
segment 1.
Phil Wood
P.S. I'm afraid to mention any vendor's names for fear of getting sue'd.
-----------[000299][next][prev][last][first]----------------------------------------------------
Date: 23 Feb 88 16:47:34 GMT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: Life in the Swamps / TestingWell, the unclear comments and generalizations had better not get any stamp of approval from the organization involved (just like a good bug-reporting system will bounce anything like that right back to the originator for clarification without a developer ever having to read it...). The list needs an editor. I think a simple list of easy-to-prove facts would do a good deal of good, and it could be done in fairly short order. List the vendors who are perpetuating 4.2 bugs (UDP checksums, TFTP, non-RFC959 FTP, the old broadcast address, thinking they're a router by default). List the vendors who don't support nameservers (the majority). List the vendors who don't support subnets (maybe a minority, now?). List the vendors who don't support ICMP redirects (harder to determine). Millitary-related people might even be able to collect a list of who can and can't handle IP packets with options. The sophisticated, repeatable data from a test suite is desirable, but we can begin the process much sooner. Perhaps we can even get many of the simple problems out of the way (RFC959 FTP only requires adding 4 table entries to the server's parser), and maybe even get most of the vendors used to sophisticated input from the field, perhaps even including directions for new development... jbvb PS: maybe it all looks too easy for me, because both of my PCs can run our network monitor program at a moment's notice, but the Sun people have their own tools, too.
-----------[000300][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 88 17:19:00 GMT From: GREG@FNALNET.BITNET To: comp.protocols.tcp-ip Subject: CMU package
I have just installed the CMU TCP/IP package on several Microvax'en and am experienced a strange Telnet situation. The DEC TPU editor screen and cursor functions do not work properly if the terminal is defined as device=VT200, but work if defined as device=VT100. Have I done somthing wrong? Is this a known or documented bug (feature)? Have any of you experienced this as well? Thanks, Greg Chartrand - Fermilab P.O. Box 500 - Batavia, Il. 60510 (312) 840-3727 GREG@FNAL.BITNET or GREG%FNAL.HEPNET@LBL.ARPA
-----------[000301][next][prev][last][first]----------------------------------------------------
Date: 23 Feb 88 18:48:19 GMT
From: GR.PJL@ISUMVS.BITNET ("Paul Lustgraaf")
To: comp.protocols.tcp-ip
Subject: (none); Why one specific hosts ethernet packets are not passed ; through a "bridge"? The first thing to check, given that some hardware/software combinations allow you to change it (WHY?), is that you don't have a duplicate ethernet address. Paul Lustgraaf GR.PJL@ISUMVS.BITNET Network Specialist Computation Center Iowa State University Ames, IA 50011 515-294-0324
-----------[000302][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 88 19:21:26 GMT From: BILLW@MATHOM.CISCO.COM (William Westfield) To: comp.protocols.tcp-ip Subject: PSN Physical connections.
Is there an RFC or other document someplace that describes the physical connection between a host and a PSN? This was a lot easier in the 1822 days, but now there is rs232, rs449, v.35, dce, dte, internal clocking, external clocking, providing an external clock, and all sorts of other things that are necessary to get X.25 working properly... There are apparently several varieties of interface available on the PSN, not to mention several types of PSNs. Id like to know ALL the available configurations, so that I can tell people "yes, to connect a cisco Gateway to your PSN, you will also need and X, a Y, and a Z, or you can get the PSN reconfigured to be FOO, in which case you won't need the Z any more". Thankyou Bill Westfield cisco Systems. -------
-----------[000303][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 88 21:44:43 GMT From: catlett@NCSA.UIUC.EDU (Charlie Catlett) To: comp.protocols.tcp-ip Subject: TCP/IP Terminal Servers
NCSA is considering the purchase of terminal servers for asynchronous access to our suite of machines. Can I get some testimonials or horror stories from those who have experience using these boxes? Does anyone have an opinion on which vendor has the best/worst? Thanks in advance, Charlie Catlett National Center for Supercomputing Applications catlett@ncsa.uiuc.edu catlett@ncsavmsa.bitnet
-----------[000304][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 88 22:23:24 GMT From: oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) To: comp.protocols.tcp-ip Subject: Re: a ping with record route
Actually the ping program referenced creates echo request packets with the Loose Source and Record Route (LSRR, type 131) IP option not the RR (type 7) IP option. And my Sun, for one, does not ignore them. Mike
-----------[000305][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 88 23:12:20 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Link level Ethernet bridges (Modified)! does that mean joke?
Naming names. No dispersions intended. But, hey, I want to know!
Does anyone on this list have an inkling about why given the following
configuration that 99.9% packets destined for an HP system are not passed
through a DEC MacLevel Bridge? (Thats right, one maybe every 300 to 400
packets)
segment #1 segment #2
8:0:20:1:33:1e Ha--| |--Hz 8:0:2b:3:92:23
| |
8:0:20:1:47:d2 Hb--| |--Hz-1 8:0:20:1:d7:e5
|icmp icmp |--Hy 2:7:1:0:a6:59
8:0:9:0:65:3d Hp*--|echo-> echo->|--Hx aa:0:4:0:da:4 hummmm.
nada <-reply |
. .
. .
. .
8:0:20:1:66:6a Hq--| |--Hr 8:0:2b:3:91:5c
|----?[DEC lanBridge]?---|
SUBNET 1 of Class B network 128.165, mask==0xfffffc00
There is probably alot of irreverent/irrelevant, but, it was fun.
All the hosts Ha through Hz with the exception of Hp can communicate over
the ether. By communicate, I mean ICMP echo, vanilla, no ip options.
All the hosts Ha through Hq ***INCLUDING*** Hp* CAN communicate
over segment #1. When attempting an ICMP Echo between Hp and Hx, an
'etherfind' on segment #2 shows an echo and echo reply
reply packet. While an 'etherfind' on segment #1 shows an echo packet,
one out of 400 reply's make it. Do this with any other pair, like
Ha -- Hx, or Hp -- Ha, and it works bwainoh.
* Hp == HP-UX hp320 6.01 B 9000/320 Is there something strange about that
address? ... I don't think so.
(Little is known about this one of a kind on our net. It would be
nice if we could look at its "arp" tables, but they did it their
way, what if? ..., Rumor has it that the system is BSD3.4 made
to look like system V.)
Ha == Sun UNIX 4.2 Release 3.4
(This release is known to be worthless on a subnet, however, it
appears to work if it stands alone and does not use the yellow
pages.)
Hr == VAX-11/785 running VMS/Wollengon (3.1) (They do ICMP mask request
replys correctly, its about time!, but don't send them too many
packets in a row!)
Hz == VAX-11/785 running BSD 4.3 (They forget to swap their subnetmask
and mess up anyone foolish enough to broadcast an ICMP mask request,
fixed by me, cause I got source!)
Hz-1 == Sun 3/260 running 3.5 (Hey, I can ifconfig netmasks and broadcast
addresses, but darn I still can't ip route between 128.165.4.xx
(mask == 0xfffffc00) and 192.5.16.96 (mask == 0xffffffe0), and
double darn the routed just chewed up all my cpu and flooded
the net with gosh knows what kind of "routing" packets, and those
yellow lights on the DEC LanBridge just don't blink anymore, their
SOLID.)
Hx == VAX-8600 running Ultrix V2.0-1 (Talk about skizoid, this dude
talks DECNET and INTERNET of'n a one DEUNA and it's network
application suite has been loaded at j random times with:
gethostbyname from /etc/hosts
gethostbyname from /etc/yp
gethostbyname from /etc/resolv.conf (yup, ypserv -i)
So try, and answer a vanilla users question like "why can I rsh
and not rlogin!")
Hy == Celerity running Accel UNIX, (They were nice to rush us a patch
for their systems that fixed a bug that stomped on SUN clients
attempting to boot.
... == Bridge, Inc. terminal servers, Bridge, Inc. GS7's and GS3's, pure
DECNET VMS VAX systems, IBMPC's, KINETICS MacInTosh "gateway's",
miscelaneous DEC terminal servers, IBM RT's which respond to
ICMP echo requests and return the IP Record Route option, bless
there heart!)
Phil Wood
P.S. I'm not afraid anymore. I think I'll save this one.
-----------[000306][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 88 23:28:44 GMT From: neerma@COD.NOSC.MIL (Merle A. Neer) To: comp.protocols.tcp-ip Subject: Re: Link level Ethernet bridges
In our own experience in a similar configuration we discovered that some segments have more errors occurring on them. In turn some hosts are less tolerant of errors and refused to talk over a 'corrupted' cable. I dont know if this is your problem but you might look at the local ether segment to see if some transcievers have been installed improperly etc. As I mentioned we had a similar problem in that some hosts could not communicate throught a bridge yet could talk to each other if they were on a local cable. When we moved these particular hosts to a new cable they were ok. What can I say..it worked! Merle. neerma at nosc ------- -------
-----------[000307][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 88 00:08:42 GMT From: neerma@COD.NOSC.MIL (Merle A. Neer) To: comp.protocols.tcp-ip Subject: Forwarded: Message of 23-Feb-88 15:27:07
------- Forwarded mail follows: From Mailer@SRI-NIC.ARPA Tue Feb 23 15:30:50 1988 Message-Id: <8802232330.AA00584@cod.nosc.mil> Date: Tue, 23 Feb 88 15:28:48 PST From: The Mailer Daemon <Mailer@SRI-NIC.ARPA> To: neerma Subject: Message of 23-Feb-88 15:27:07 Message failed for the following: tcp-ip-RELAY@SRI-NIC.ARPA: No such directory name ------------ Received: from cod.nosc.mil by SRI-NIC.ARPA with TCP; Tue 23 Feb 88 15:27:12-PST Received: by cod.nosc.mil (5.58/1.27) id AA00402; Tue, 23 Feb 88 15:28:44 PST Date: Tue, 23 Feb 88 15:28:44 PST From: neerma@cod.nosc.mil (Merle A. Neer) Message-Id: <8802232328.AA00402@cod.nosc.mil> To: tcp-ip-RELAY@sri-nic.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: Link level Ethernet bridges In-Reply-To: Your message of Tue Feb 23 11:24:48 1988 In our own experience in a similar configuration we discovered that some segments have more errors occurring on them. In turn some hosts are less tolerant of errors and refused to talk over a 'corrupted' cable. I dont know if this is your problem but you might look at the local ether segment to see if some transcievers have been installed improperly etc. As I mentioned we had a similar problem in that some hosts could not communicate throught a bridge yet could talk to each other if they were on a local cable. When we moved these particular hosts to a new cable they were ok. What can I say..it worked! Merle. neerma at nosc ------- ------- ------- -------
-----------[000308][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 88 00:53:00 GMT From: enger@BLUTO.SCC.COM To: comp.protocols.tcp-ip Subject: Using DEC VT200 mode through telnet
Greg: I believe VT200 mode allows the system to transmit 8-bit control codes to the terminal. TPU takes advantage of this. For instance, the "<esc>[" sequence is replaced by "<csi>" (9B in hex). This makes the host/terminal communications more compact, and perhaps quicker. Unfortunately, the intervening com facilities must pass 8-bit codes. I don't think telnet normally does this. I logged into my Sun running their latest software, but couldn't find an option to put its telnet into binary mode. I logged onto our VMS Vax, and fired up the Wollongong telnet. It does support a "binary" mode, and this successfully runs TPU. Unfortunately, the command cannot be placed into their TELINIT. telnet startup configuration file; instead it must be typed in manually once the connection has been opened. Best wishes, Bob Enger
-----------[000309][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 88 02:20:07 GMT From: gaw@columbia-pdn (Glen A. Warholic) To: comp.protocols.tcp-ip Subject: Re: PSN Physical connections.
If such a document existed it would be worth a fortune and I doubt if asking for it would get you it. Seriously I have never seen one and as you stated during the days of 1822 you could pull out good old report 1822 and be ready to go. But now with V.35 on an RS-449 connector and the new move to put a clock generator in the PSN(DTE) so that it can connect to another DTE(host/gateway) without the use of a modem eliminator, the number of possibilities of the ways to connect to a PSN can be mind boggling.
-----------[000310][next][prev][last][first]---------------------------------------------------- Date: Wed, 24 Feb 88 8:46:29 EST From: "Kenneth A. Turkewitz" <turkewit@CCV.BBN.COM> To: William Westfield <BILLW@MATHOM.CISCO.COM> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: PSN Physical connections.
Bill, There is such a document that was written by BBN Communications for DCA last year. It is called "C/30E Physical Layer Interface Guide." I believe that DCA was going to add a few things and publish this in some easily obtainable mode. (The cover of the document includes, "DCAI No: DCAI-350-180-()." I'm not sure whether or not this will help uniquely identify the document to DCA.) I would check with DCEC (start with Charlie Morgan, "CEMorgan@DDN1.arpa") to find out the status of this document. He might also know how to obtain a copy of it. --Ken Turkewitz
-----------[000311][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 88 08:20:34 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: 4.3BSD IP Option / Fragmentation Bug Fix
4.3BSD network bug (#?, ip_output)
Index: sys/netinet/ip_output.c 4.3BSD FIX
Introduction:
This is not official, if a fix already exists, then excuse me. I have
shown an IP Option/fragmentation problem to exist by generating IP
Security Option packets large enough to be fragmented. I was able to
see the corruption via SUN's 'etherfind' on a 4.0beta LAN. And,
consequently, fixed the problem. Success being a "correct" response
to an ICMP Echo with IP Security Option, packet size > 1500 bytes,
generating 2 fragments. I personally would have liked to see the
Security option come back, but what the hey, I got the Echo Reply!.
Description:
When sending IP packets which have to be fragmented, ip_output would
do strange things if any IP Options were included. The result was that
the packets were discarded by Gateways, or thrown out by receiving
hosts because:
IP options were essentially copied twice to the outgoing
fragment due to having incorrectly set the offset
for copies from the source mbuf. The IHL was not taken into
account. This generated a bogus data portion in the packet.
If the IP option was one that should only appear in the first
fragment, then the checksum was calculated wrong on the second
and succeeding fragments due to the use of the original IHL which
included the option section length.
I assume that this is only a problem with packet origination, and
not with the 'ip forwarding mode'.
Fix:
Apply the diffs shown below, if you are not a feared of viruses.
Signed:
Phil Wood, cpw@lanl.gov
*** ip_output.c.orig Tue Jul 28 10:27:53 1987
--- ip_output.c Wed Feb 24 00:48:34 1988
***************
*** 5,7 ****
*
! * @(#)ip_output.c 7.1 (Berkeley) 6/5/86
*/
--- 5,7 ----
*
! * @(#)ip_output.c 7.1 (LANL) 2/24/88
*/
***************
*** 44,46 ****
register struct ifnet *ifp;
! int len, hlen = sizeof (struct ip), off, error = 0;
struct route iproute;
--- 44,46 ----
register struct ifnet *ifp;
! int len, hlen = sizeof (struct ip), off, error = 0, ohlen;
struct route iproute;
***************
*** 177,180 ****
*/
! m->m_len -= sizeof (struct ip);
! m->m_off += sizeof (struct ip);
for (off = 0; off < ip->ip_len-hlen; off += len) {
--- 177,181 ----
*/
! m->m_len -= hlen;
! m->m_off += hlen;
! ohlen = hlen;
for (off = 0; off < ip->ip_len-hlen; off += len) {
***************
*** 182,183 ****
--- 183,185 ----
struct ip *mhip;
+ register olen = 0;
***************
*** 191,194 ****
if (hlen > sizeof (struct ip)) {
! int olen = ip_optcopy(ip, mhip, off);
! mh->m_len = sizeof (struct ip) + olen;
} else
--- 193,198 ----
if (hlen > sizeof (struct ip)) {
! olen = ip_optcopy(ip, mhip, off);
! ohlen = sizeof (struct ip) + olen;
! mh->m_len = ohlen;
! mhip->ip_hl = ohlen >> 2;
} else
***************
*** 204,206 ****
}
! mhip->ip_len += sizeof (struct ip);
mhip->ip_len = htons((u_short)mhip->ip_len);
--- 208,210 ----
}
! mhip->ip_len += sizeof (struct ip) + olen;
mhip->ip_len = htons((u_short)mhip->ip_len);
***************
*** 214,216 ****
mhip->ip_sum = 0;
! mhip->ip_sum = in_cksum(mh, hlen);
if (error = (*ifp->if_output)(ifp, mh, (struct sockaddr *)dst))
--- 218,220 ----
mhip->ip_sum = 0;
! mhip->ip_sum = in_cksum(mh, ohlen );
if (error = (*ifp->if_output)(ifp, mh, (struct sockaddr *)dst))
-----------[000312][next][prev][last][first]----------------------------------------------------
Date: 24 Feb 88 13:46:29 GMT
From: turkewit@CCV.BBN.COM ("Kenneth A. Turkewitz")
To: comp.protocols.tcp-ip
Subject: Re: PSN Physical connections.Bill, There is such a document that was written by BBN Communications for DCA last year. It is called "C/30E Physical Layer Interface Guide." I believe that DCA was going to add a few things and publish this in some easily obtainable mode. (The cover of the document includes, "DCAI No: DCAI-350-180-()." I'm not sure whether or not this will help uniquely identify the document to DCA.) I would check with DCEC (start with Charlie Morgan, "CEMorgan@DDN1.arpa") to find out the status of this document. He might also know how to obtain a copy of it. --Ken Turkewitz
-----------[000313][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 88 15:51:43 GMT From: dannyb@kulcs.uucp (Danny Backx) To: comp.protocols.tcp-ip Subject: Re: Need help with UNIX tcp
> sometimes do it on UNIX. The problem simply stated is
> this: the user process cannot get the status of its
> tcp connections from UNIX.
[...]
> Have any UNIX guru-types ever considered offering a
> 'status(myconnect)' call? We'll gladly pay for one.
> Or even just a 'signal(YOURCONNECTISBOGUS,letmeknow)'
> would be nice?
[...]
> Merle Neer
> neerma@nosc
Could you post a more complete list of what you think a user interface to TCP
should include ?
As for your request on 'YOURCONNECTISBOGUS', I think you can arrange something
like that on BSD. (I don't know whether you're talking about BSD or Sys-V).
If you are interested, look in the manual entries for socket(2),
setsocketopt(2) - look for the SO_KEEPALIVE option.
I'm not sure if you can detect dead connections with select(2), or maybe
with SIGIO or SIGURG.
If you find a way, please post it. I'm sure lots of people are interested.
Danny
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Danny Backx | mail: Katholieke Universiteit Leuven
Tel: +32 16 200656 x 3537 | Dept. Computer Science
E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A
... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven
dannyb@kulcs.BITNET | Belgium
-----------[000314][next][prev][last][first]----------------------------------------------------
Date: 24 Feb 88 16:17:24 GMT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: CMU packageDEC editors usually have strong opinions about using VT220s in 8-bit mode, and most Telnet streams won't pass 8-bit unless the 'binary' option has been agreed upon. Few Telnet clients or servers even support 'binary', and there is still a group of Neanderthals out there who insist on sending parity in the 8th bit, so you just can't turn off the masking operation. Some time back, I suggested a concerted campaign to identify and sit upon those who send parity, so the rest of us can just make the masking operation optional, but I got shot at, and am now quietly implementing 'binary' in my own Telnets. Fat lot of good that will do most people. jbvb
-----------[000315][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 88 21:22:12 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: PSN Physical connections.
This reminds me of the time, about 2 months ago, when we attemted to use Sun Microsystems, Inc. MCP board, their SUNLINK X.25 software, and a PDN to see what kind of connectivity we could get. Like communicating with other nodes off the PDN. We had a serial line junky in here, with mucho patents to his name, a million dollor serial line analyzer with lots of beautiful color monitor displays, and various loopback plugs. It took a couple of days, and visits from various Mountain Bell types before we could "pad" on over to a Microvax, via Phoenix at 56 Kbits. We never did get the Internet Router to work, but thats another story which is "fixed in 4.0" Phil Wood cpw@lanl.gov
-----------[000316][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 88 21:38:45 GMT From: jch@DEVVAX.TN.CORNELL.EDU (Jeffrey C Honig) To: comp.protocols.tcp-ip Subject: Re: Using DEC VT200 mode through telnet
The SET TERM command on VMS has a qualifier /NOEIGHTBIT or something similar that will solve your problem. Jeff
-----------[000317][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 88 00:56:47 GMT From: pitstop!sundc!rlgvax!dennis@sun.com (Dennis.Bednar) To: tcp-ip@sri-nic.arpa Subject: Re: SLIP (what & where??)
In article <3805@galbp.LBP.HARRIS.COM>, gja@galbp.LBP.HARRIS.COM (Greg Ansley) writes:
>
> A need a discription of SLIP, what it is and what it can do as well as
> a pointer to where I can get the code!
> Please reply be mail so as not to bore the rest of the net!
I prefer to bore the net. Here's what I know:
SLIP = Serial Line Internet Protocol
IP packets are sent over an RS-232C serial wire encapsulated
and decapsulated according to the packet formatting rules.
There is no packet header, and only a single byte for the
packet trailer. Since the byte used for the packet trailer
could appear as data in the packet, certain escape conventions
are used to prevent this possiblity. The sending side adds
extra escape prefix characters while sending a packet, and
the receiving side removes the extra escape chars and stores
the unencoded packet for further processing.
SLIP is just another oe of the possible lowest level protocols
between TCP/IP and the raw hardware. SLIP is at the same level
as ethernet/ARP, or an 1822 "bit-banger" protocol, or the newer
DDN X.25 (I think levels 3 and 2) interface.
Historically, as I know it, SLIP was invented by 3com Corp. when
Bruce Borden et.al. developed a TCP/IP package known as UNET.
But it might have been invented at Ford Aerospace, because the
comments in the source code indicated that Ford had some role
as far as helping 3com with some of the software.
Above 4 years ago, Rick Adams worked here at CCI, and ported
UNET to a CCI 5/20 processor running Unix S3. We required
communications between our VAX 780 and the 5/20, and at that
time, the VAX only supported TCP/IP/ethernet, but not SLIP,
and the 5/20 only supported SLIP, but not ethernet. So Rick
Adams wrote the first SLIP driver for the 4.2BSD kernel that
allowed TCP/IP communication between our 4.2BSD VAX and our
S3 5/20. End of story.
As for the packet format, TCP/IP packets are sent "serially",
one-byte-at a time, left-to-right, high-order to low-order
as you might expect if you look at the IP or TCP specs.
The following encoding rules apply (below is the output of
a dumb program called "unetchars" which I wrote several
years ago): I wrote it to document the packet format when we had
to understand and analyze protocol problems seen on a Data
Line Monitor:
How IP Packets are Sent over an Asynchronous Line
+------------+--------------------------------------------+-------------+
| LNI header | LNI (Local Network Interface) data | LNI Trailer |
+------------+-----------+------------+-------------------+-------------+
| IP header | TCP header | optional TCP data |
+-----------+------------+-------------------+
|<------------ Data Encoding Rules --------->|
Special Octets Used For Data Encoding
Name Hex Octal Decimal Description
FRMEND 0xc0 0300 192 Frame End Character
FRMESC 0xdb 0333 219 Frame Escape Character
M_FRMEND 0xdc 0334 220 Meta Frame End Character
M_FRMESC 0xdd 0335 221 Meta Frame Escape Character
There is no LNI header for an asynchronous serial line.
That is, there is no special character to introduce a sent frame.
In the LNI data field, the sender applies the following rules:
A data FRMEND octet is sent as FRMESC, M_FRMEND sequence.
A data FRMESC octet is sent as FRMESC, M_FRMESC sequence.
All other octets are sent without any translation.
The receiving IP decodes by stripping and translating the extra octets.
The LNI trailer contains only the FRMEND octet.
That is, a frame is sent ending with the FRMEND character.
Example:
Want to send ('a', FRMESC, 'b', FRMEND, 'c').
Sent as ('a', FRMESC, M_FRMESC, 'b', FRMESC, M_FRMEND, 'c', FRMEND).
Note the last sent octet is not part of the LNI data field.
Data Octet To Send Data Sequence Actually Sent
Hex Octal Decimal Hex Octal Decimal
0xdb 0333 219 (0xdb, 0xdd) (0333, 0335) (219, 221)
0xc0 0300 192 (0xdb, 0xdc) (0333, 0334) (219, 220)
Justification of the Rules:
1. Sending the FRMEND data octet as a FRMESC, M_FRMEND sequence:
We must be able to send the FRMEND as a data character,
so the FRMEND has to be escaped, otherwise the receiver would
misinterpret it as a premature end of packet.
2. Sending the FRMESC data octet as a FRMESC, M_FRMESC sequence:
Because the FRMESC is used as an escape, there has to be a way
of treating a FRMESC as data. For example, if this rule weren't
defined, then there would be an ambiguous packet. Suppose the
sender wanted to send the (data_char, FRMESC, M_FRMEND, data_char)
sequence. According to rule 1 only, there would be no translation
of octets. Therefore the receiver would receive it as
(data_char, FRMEND_data_char, data_char),
which is not what is intended.
--
FullName: Dennis Bednar
UUCP: {uunet|sundc}!rlgvax!dennis
USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone: +1 703 648 3300
-----------[000318][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 88 01:12:24 GMT From: tcs@USNA.MIL (Terry Slattery) To: comp.protocols.tcp-ip Subject: Re: Life in the Swamps / Testing
Is there any reason why the regular vendor list cannot be expanded to include additional 'facts' about an implementation. Such facts would be subnet support, nameserver support, specific questions relating to whether known widespread bugs are fixed (i.e. udp checksums, TFTP, etc). Vendors then voluntarily complete the form. It then becomes a "keep up with the Jones'" task to fill out the form with as much positive information as possible. False listings would be discovered and possible negative publicity would eliminate them. Someone who knows most of the pitfalls needs to come up with the first template. As new items need be added, a new field is added to each entry. Old fields can be aged away as the problem subsides (i.e. we don't need to decide right here and now ALL the right questions to ask - just get close.) Announcements of a new field will eventually get the vendors and they will answer the empty item. -tcs
-----------[000319][next][prev][last][first]---------------------------------------------------- Date: Thu, 25 Feb 88 07:35 CST From: <GREG%FNALNET.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: CMU Telnet problem
Thank you all for your assistance. Problem solved and totally understood! Regarsd, Greg Chartrand - Fermilab
-----------[000320][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 88 02:03:50 GMT From: MRC@PANDA.PANDA.COM (Mark Crispin) To: comp.protocols.tcp-ip Subject: Re: CMU package
I sympathize with JBVB's problem. I've been fighting it for almost 10 years now, both in my own code (Telnet implementations for 3 different operating systems) and in other's code. As far as I know, Telnet implementations which get various of these complexities right are few and far between. Here's my own list of Neanderthals: . host systems which send parity over Telnet connections. These are becoming rarer over time, but there's still a few out there. . operating systems which can't tell the difference between a terminal which sends parity and one which doesn't, making it virtually impossible for the Telnet client to know what to do with that 8th bit. ITS is the only OS I know that lets an application know that the 8th bit is significant. WAITS gets partial credit for supporting this for terminals it recognizes under its display service. VAX/VMS may also be a winner. I believe Unix flunks, as does most versions of TOPS-20 (only PANDA TOPS-20 has a "parity terminal" status bit). . Telnet servers which confuse Telnet binary state with some local concept of what is binary. Tenex gets a big, red F in this (this was the infamous "new Telnet performance bug" of the late 70's), as do certain versions of Unix which associate Telnet binary with something called "raw mode." This is one of the most serious problems facing Telnet application developers trying to do something useful with 8-bit I/O. . operating systems which have no way to instruct the Telnet server to get out of binary mode. WAITS and PANDA versions of TOPS-20 are the only OS's I know of that handle this problem, which is what once a TAC user does @B I S he can't get out of binary mode. . Telnet servers which fail to double '377 (FFh for you Unix guys). Most versions of TOPS-20 (except for PANDA) have this serious bug, and it's led to a plethoria of programs which manually double FFh. Guess what happens when you try to run such programs on a PANDA system which does it right... The most distressing part about all of this is that these bugs are ancient bugs, that intelligent hackers have fixed years ago, but still broken versions continue to proliferate. -------
-----------[000321][next][prev][last][first]---------------------------------------------------- Date: Thu, 25 Feb 88 08:24 EDT From: "Eliot Moss, GRC A351B, x5-4206 25-Feb-1988 0821" <MOSS@CS-UMASS.ARPA> To: tcp-ip@sri-nic.ARPA Subject: Re: VT200 and CMU/TEK TCP/IP Telnet
If Telnet'ing from/to a CMU/TEK TCP/IP host, use the /BINARY option to go into binary mode so as to allow the 8-bit controls to flow. Of course, as pointed out in a number of recent messages, if there is a non-CMU/TEK host involved that does not do the right thing with binary mode, this will not work right. We do know it to work right between two CMU/TEK hosts running version 6.2 of that software. Eliot Moss Assistant Professor Dept. of Comp. and Info. Sci. Univ. of Mass., Amherst
-----------[000322][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 88 06:53:15 GMT From: VSRAANAN@WEIZMANN.BITNET (raanan michael) To: comp.protocols.tcp-ip Subject: Re: Using DEC VT200 mode through telnet
Greg, Bob. i had the same problem here wile telnet vms (excelan exos board) to unix machine. we succeeded to make telnet connection by typing "<cntrl> j" (linefeed) after <cr> during logon time (userid and password). another command that helped was "set term/noeight" before telnet. in that case the connection will be done with 7 bit, so vt220 8 bit functions will not work. raanan.
-----------[000323][next][prev][last][first]---------------------------------------------------- Date: Thu, 25 Feb 88 08:53:15 +0200 From: raanan michael <VSRAANAN%WEIZMANN.BITNET@CNUCE-VM.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: Re: Using DEC VT200 mode through telnet
Greg, Bob. i had the same problem here wile telnet vms (excelan exos board) to unix machine. we succeeded to make telnet connection by typing "<cntrl> j" (linefeed) after <cr> during logon time (userid and password). another command that helped was "set term/noeight" before telnet. in that case the connection will be done with 7 bit, so vt220 8 bit functions will not work. raanan.
-----------[000324][next][prev][last][first]----------------------------------------------------
Date: 25 Feb 88 12:24:00 GMT
From: MOSS@CS-UMASS.ARPA ("Eliot Moss, GRC A351B, x5-4206 25-Feb-1988 0821")
To: comp.protocols.tcp-ip
Subject: Re: VT200 and CMU/TEK TCP/IP TelnetIf Telnet'ing from/to a CMU/TEK TCP/IP host, use the /BINARY option to go into binary mode so as to allow the 8-bit controls to flow. Of course, as pointed out in a number of recent messages, if there is a non-CMU/TEK host involved that does not do the right thing with binary mode, this will not work right. We do know it to work right between two CMU/TEK hosts running version 6.2 of that software. Eliot Moss Assistant Professor Dept. of Comp. and Info. Sci. Univ. of Mass., Amherst
-----------[000325][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 88 13:35:00 GMT From: GREG@FNALNET.BITNET To: comp.protocols.tcp-ip Subject: CMU Telnet problem
Thank you all for your assistance. Problem solved and totally understood! Regarsd, Greg Chartrand - Fermilab
-----------[000326][next][prev][last][first]---------------------------------------------------- Date: Thu, 25 Feb 88 19:20 EST From: The Mail Server <Postmaster%TRINCC.BITNET@MITVMA.MIT.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Undeliverable mail
Message had a bad or missing To address. The entire text of the message follows: Received: From MARIST(MAILER) by TRINCC with RSCS id 1286 for SHAVER@TRINCC; Thu, 25-FEB-1988 19:20 EST Received: by MARIST (Mailer X1.25) id 1277; Thu, 25 Feb 88 19:22:08 EST Date: Thu, 25 Feb 88 07:35:00 CST From: GREG%FNALNET.BITNET@CUNYVM.CUNY.EDU Subject: CMU Telnet problem Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@MARIST> To: JERRY SHAVER <SHAVER@TRINCC> Reply-to: TCP-IP@SRI-NIC.ARPA Comments: Warning -- original Sender: tag was TCPIP-L@BYUADMIN Thank you all for your assistance. Problem solved and totally understood! Regarsd, Greg Chartrand - Fermilab
-----------[000327][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 88 14:20:37 GMT From: golds@rlgvax.UUCP (Rich Goldschmidt) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: PC Application Support for Ethernet
How do others out there support the many different ethernet boards for PCs. Sun's PC-NFS does not support any of the "smart" boards, comes with its own driver for each board, and tough luck for any network application which would like to coexist (unless you build it with their Toolkit). Locus's PC-Interface has their own 3Com driver that talks only to their application, so nothing else can use it. However, they use the drivers provided by Excelan or Micom, so it is at least possible to coexist, if you want to write different application back ends for each of those boards. And now Excelan has come out with a new revision of its socket development library which is incompatible with previous versions! I am curious what other approaches have been used or might work to have several applications share a driver, and work with most of the existing boards. The lack of standards here between board manufacturers causes application developers to support a subset, and really hurts the growth of PC networking. I always thought it was unfortunate that a particular product only supported a few boards, until I started looking into what it takes... Rich Goldschmidt rlgvax!golds@uunet.UU.NET uunet!rlgvax!golds sun!sundc!rlgvax
-----------[000328][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 88 14:29:36 GMT From: mohamed@hscfvax.harvard.edu (Mohamed_el_Lozy) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Time synchronization in a Distributed Environment
In article <2710@druhi.ATT.COM> aws@druhi.ATT.COM (SteereA) writes: > I am looking for articles, references, implementations, >etc. for solving the problem of keeping N machines within >a specified time of one another. I appreciate any and all pointers. I am directing followup to comp.protocols.tcp-ip, where it would be more appropriate. I assume that the machines are networked. A good start would be in three RFCs written by Dave Mills: 956 Algorithms for synchronizing network clocks 957 Experiments in network clock synchronization 958 Network time protocol (NTP) They all came out in 1985, and have reasonable references for that time. A UNIX (BSD only, as I recall) implementation of NTP has been written at trantor.umd.edu, which also maintains a mailing list. To get on it send mail to ntp-request@trantor.umd.edu. There is also often quite a bit of network time discussion in comp.protocols.tcp-ip, especially when interesting things like leap seconds turn up. BSD4.3 implementations have a timed program, discussed at some length in the documentation (not available to me right now). I would very much appreciate some post 1985 references.
-----------[000329][next][prev][last][first]---------------------------------------------------- Date: Thu, 25 Feb 88 22:30 EST From: The Mail Server <Postmaster%TRINCC.BITNET@MITVMA.MIT.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Undeliverable mail
Message had a bad or missing To address.
The entire text of the message follows:
Received: From MARIST(MAILER) by TRINCC with RSCS id 1611 for SHAVER@TRINCC;
Thu, 25-FEB-1988 22:30 EST
Received: by MARIST (Mailer X1.25) id 1602; Thu, 25 Feb 88 22:31:50 EST
Date: Thu, 25 Feb 88 16:39:36 MST
From: "C. Philip Wood" <cpw%sneezy@LANL.GOV>
Subject: Link level Ethernet bridges problem solved
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@MARIST>
To: JERRY SHAVER <SHAVER@TRINCC>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments: Warning -- original Sender: tag was TCPIP-L@BYUADMIN
I want to thank all of you who responded with many helpful suggestions.
And as usual, it appears that the original understanding of the problem
did not lead me to any reasonable conclusion. The bridge was not a factor.
In particular thanks to 'Merle'
> I dont know if this is your problem but you might look
> at the local ether segment to see if some transcievers
> have been installed improperly etc.
and Doug Blair
> I had an installation with an HP 9000 that had the same problem.
> The HP people swore up and down that their transceiver was fine, but I
> swapped it out anyway and guess what? it worked. I would assume that
> other folks might have this problem with their transceivers, and am
> not throwing stones at HP in particular.
We sent some folks in the know out to investigate the segment with the HP
on it. It turns out that the DEC lanBridge and all the hosts on the
second segment had nothing to do with the problem. What follows is a
more detailed picture of the problem and the "fix".
Ha Hp Miscellaneous hosts DEREP****LanBridge
| ? | (Apollo,Sun,IBMPC) |
| | | |
C.......+.+...................................DESTA
1 2
Ha== Sun UNIX 4.2 Release 3.4
Hp== HP-UX hp320 6.01 B 9000/320
+ == Thinnet transceiver? with BNC connectors
. == Thinnet
C == BNC connector
* == Fiber
? == no connection
No one seems to know what the extra + was doing connected via 1 foot of
Thinnet at location 1. However, 1 was swapped with 2 and things started
to work. It was decided to initial #2 with "NG" and remove it from the
configuration as follows:
| |
C.........+...................................DESTA
Phil Wood, cpw@lanl.gov
-----------[000330][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 88 23:39:36 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Link level Ethernet bridges problem solved
I want to thank all of you who responded with many helpful suggestions. And as usual, it appears that the original understanding of the problem did not lead me to any reasonable conclusion. The bridge was not a factor. In particular thanks to 'Merle' > I dont know if this is your problem but you might look > at the local ether segment to see if some transcievers > have been installed improperly etc. and Doug Blair > I had an installation with an HP 9000 that had the same problem. > The HP people swore up and down that their transceiver was fine, but I > swapped it out anyway and guess what? it worked. I would assume that > other folks might have this problem with their transceivers, and am > not throwing stones at HP in particular. We sent some folks in the know out to investigate the segment with the HP on it. It turns out that the DEC lanBridge and all the hosts on the second segment had nothing to do with the problem. What follows is a more detailed picture of the problem and the "fix". Ha Hp Miscellaneous hosts DEREP****LanBridge | ? | (Apollo,Sun,IBMPC) | | | | | C.......+.+...................................DESTA 1 2 Ha== Sun UNIX 4.2 Release 3.4 Hp== HP-UX hp320 6.01 B 9000/320 + == Thinnet transceiver? with BNC connectors . == Thinnet C == BNC connector * == Fiber ? == no connection No one seems to know what the extra + was doing connected via 1 foot of Thinnet at location 1. However, 1 was swapped with 2 and things started to work. It was decided to initial #2 with "NG" and remove it from the configuration as follows: | | C.........+...................................DESTA Phil Wood, cpw@lanl.gov
-----------[000331][next][prev][last][first]---------------------------------------------------- Date: 26 Feb 88 00:06:43 GMT From: brian@wb6rqn.UUCP (Brian Lloyd) To: comp.protocols.tcp-ip Subject: Exchanging serial numbers
Here at Sirius Systems we have been discussing a means to protect our TCP/IP software without placing undue strain on the users. The primary concern is that someone might purchase one copy of the package and then copy it to all his/her systems. The concept that we came up with is to exchange serial number information as part of the options field in the TCP header when two TCP's exchange SYNs at session establishment. TCP resets the connection and returns a protocol error if both versions of the software have the same serial number. Our reading of MIL-1778 and RFC-793 leads us to believe that the only predefi