----MESSAGE-BEGIN---- <1987030105480000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 1 Mar 87 07:49:23-PST Date: 1 Mar 1987 10:48-EST Sender: CERF@A.ISI.EDU Subject: Re: secure replacements for passwords From: CERF@A.ISI.EDU To: JSLove@MIT-MULTICS.ARPA Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 1-Mar-87 10:48:56.CERF> In-Reply-To: <870301054108.921938@MIT-MULTICS.ARPA> In the design of the TCP, we intended to detect half-open connections and to resolve them by means of the RST criteria. The line of reasoning was that the discovery would occur if an attempt were made to re-open an already (from recipient perspective) open connection. Similarly, such a half-open connection could be detected if a data packet were received on an otherwise closed connection. Once a connection had reached an established state, our primary objective was to deal with integrity in the face of various failures included pre- historic packets arriving at inopportune moments. Now, there were so many possible ways to spoof things, given the right level of access and control over the data flowing on the connection that we appealed to cryptographic methods where serious spoofing was a concern. It looks as if we overlooked the fact that the SENDER of a precognitive ACK might already have accepted bogus data. Our analysis, as I dimly recall it, centered on a bogus (prehistoric) precognitive ACK which had NOT actually been sent by the current party at the other end of the connection. I believe we assumed that the probability of the other side receiving a valid data packet which had NOT been sent was small because of the size of the sequence number space and the probably age of a packet which did, in fact, arrive so inopportunely sequence numbered. The change you suggest might catch an attempt at spoofing, but I submit that any serious concerns about spoofing are inadequately addressed by anything less than and/end security techniques. Ignoring spoofing, it is fair to say, in my view, that the scenario in which an old packet engenders what looks like a precognitive ACK is a bad case since the precognitive ACK will be sent after the data recipient has accepted as valid an ancient piece of information. Rather than quietly continuing the connection, this sounds serious enough to warrant a more drastic indication of a problem. It will be essential to assure that if a RST is used, it WILL reset the connection if the other side really has accepted bad data but will NOT reset it if the precognitive ACK is really prehistoric. It will be very interesting to see what the other members of this community have to say about the analysis and consequences. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703011641.AA00688%40unix.macc.wisc.edu] <1987030106414100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dorl@seismo.CSS.GOV@uwmacc.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8703011641.AA00688@unix.macc.wisc.edu> Date: Sun, 1-Mar-87 11:41:41 EST Article-I.D.: unix.8703011641.AA00688 Posted: Sun Mar 1 11:41:41 1987 Date-Received: Mon, 2-Mar-87 06:19:31 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Path: uwmacc!dorl From: dorl@uwmacc.UUCP (Michael Dorl) Newsgroups: mod.protocols.tcp-ip,comp.sys.dec,comp.mail.misc Subject: VMS Mail Systems Message-ID: <1163@uwmacc.UUCP> Date: 1 Mar 87 16:41:41 GMT Organization: UWisconsin-Madison Academic Comp Center Lines: 10 We run a Vax VMS system with connections to the IP Internet (The Wollongong Groups WIN/VX), BITNET (Joiners JNET and GMAIL), and DECNet. Both the IP and BITNET systems are accessable from DEC's MAIL utility but the user interface is poor. We are looking for something that presents a better more fully coordinated interface to these nets. If you have or know of such products, please mail to.... dorl@unix.macc.wisc.edu dorl@wiscmacc.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703012147.AA01454%40linc.cis.upenn.edu] <1987030111474000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: broscius@LINC.CIS.UPENN.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Standard for async port emulation under NetBIOS, MS-DOS ? Message-ID: <8703012147.AA01454@linc.cis.upenn.edu> Date: Sun, 1-Mar-87 16:47:40 EST Article-I.D.: linc.8703012147.AA01454 Posted: Sun Mar 1 16:47:40 1987 Date-Received: Mon, 2-Mar-87 20:10:43 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Hi, Does anyone know of an existing or evolving standard for emulating an async port under NetBIOS and MS-DOS ? Who are some of the contacts for the NetBIOS working group(s) ? Thanx Al broscius broscius@linc.cis.upenn.edu :Internet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870301190404.01j%40Hamlet.Caltech.Edu] <1987030117094100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ken@HAMLET.CALTECH.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: VMS Mail Systems Message-ID: <870301190404.01j@Hamlet.Caltech.Edu> Date: Sun, 1-Mar-87 22:09:41 EST Article-I.D.: Hamlet.870301190404.01j Posted: Sun Mar 1 22:09:41 1987 Date-Received: Mon, 2-Mar-87 21:37:59 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Ken@Hamlet.Caltech.Edu (Kenneth Adelman) Distribution: world Organization: The ARPA Internet Lines: 60 Approved: tcp-ip@sri-nic.arpa > We run a Vax VMS system with connections to the IP Internet (The > Wollongong Groups WIN/VX), BITNET (Joiners JNET and GMAIL), and > DECNet. Both the IP and BITNET systems are accessable from DEC's > MAIL utility but the user interface is poor. We are looking for > something that presents a better more fully coordinated interface > to these nets. The Software Tools Mail System is a public domain RFC821/2 based mailer which interfaces to MultiNet TCP/IP (compatible with WIN/VX), Jnet, and DECnet-VMSmail. Caltech uses it to provide a gateway between ARPAnet, BITnet, and our local DECnet. VMSmail users sometimes have trouble adapting to its user interface, but an interface to VMSmail is available (in a uniform fashion). Below is an adapted INFO-VAX posting of mine: --- As our VAX is now running the Multinet TCP/IP software, there has been a recent change in the location of the Software Tools Distribution. The latest distribution of the Software Tools Mail System is available from HAMLET.CALTECH.EDU [192.12.19.3] via FTP as the ASCII files: ST_SRC:DISTN.COM build kit for the Software Tools VOS ST_SRC:DOC.COM \ ST_SRC:VMS.COM | sources for the Software Tools VOS ST_SRC:SRC.COM / ST_SRC:MSGSYS.COM sources for the Software Tools Mail System. (Requires the VOS to build.) The distribution is also available via DECnet on SPAN/HEPnet from host SHAKES:: (5.859) in the same directory (ST_SRC:). I can send the distribution via BITnet to any requesters. Please specify /VMSDUMP or /NETDATA format when requesting, as some lines are over 80 characters. What you will receive is many smaller .COM files which when executed in lexical order have the same result as the one big one. Please also specify whether you want just DISTNx.COM and MSGSYSx.COM (the default) or the entire source distribution (not needed for the mail system). These are "DCL-archives". You unpack them by executing them in an empty directory, and build them by following the instructions in README.1ST or BUILD.DOC. Only DISTN.COM and MSGSYS.COM are required to build the mail system. This distribution includes the new drivers for Jnet V3.0 and Excelan's TCP/IP card. Much work has been done in the conversion of the mail system from RATFOR to C. We currently have the C version running on PC/ATs under Xenix and on VAXen under both 4.3bsd and VMS, but are not prepared to distribute this version (yet). Kenneth Adelman Caltech KEN@HAMLET.CALTECH.EDU KEN@HAMLET.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703020429.AA09878%40buita.bu.edu] <1987030118291600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jsol@buit1.bu.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: "sndmsg balks" Message-ID: <8703020429.AA09878@buita.bu.edu> Date: Sun, 1-Mar-87 23:29:16 EST Article-I.D.: buita.8703020429.AA09878 Posted: Sun Mar 1 23:29:16 1987 Date-Received: Mon, 2-Mar-87 23:10:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa Ha! I fixed that bug while working for BBN. That was like the first thing I did some 3 years ago. If some site is still running the older versions of sndmsg/smtp_server then it's manager should have his head examined. :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703020431.AA09892%40buita.bu.edu] <1987030118312800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jsol@buit1.bu.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: wollongong Message-ID: <8703020431.AA09892@buita.bu.edu> Date: Sun, 1-Mar-87 23:31:28 EST Article-I.D.: buita.8703020431.AA09892 Posted: Sun Mar 1 23:31:28 1987 Date-Received: Mon, 2-Mar-87 23:13:11 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 1 Approved: tcp-ip@sri-nic.arpa I think Wollongong got a very old copy of BBN SNDMSG for unix systems. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703020548.AA07217%40lbl-csam.arpa] <1987030119484800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: van@LBL-CSAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: tcp counters Message-ID: <8703020548.AA07217@lbl-csam.arpa> Date: Mon, 2-Mar-87 00:48:48 EST Article-I.D.: lbl-csam.8703020548.AA07217 Posted: Mon Mar 2 00:48:48 1987 Date-Received: Tue, 3-Mar-87 00:32:11 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 80 Approved: tcp-ip@sri-nic.arpa >>I realize that some UNIX(tm) systems and derivatives provide a >>netstat command with a '-s' option that gives the following >>counters for the tcp level. >> >>tcp: >> 0 bad header checksums >> 0 bad header offset fields >> 0 incomplete headers Mike Karels and I recently expanded the tcp counters in 4bsd. "netstat -s" now spits out the following tcp info: tcp: 409459 packets sent 348357 data packets (176132584 bytes) 4580 data packets (4180410 bytes) retransmitted 36809 ack-only packets (35384 delayed) 37 URG only packets 470 window probe packets 17169 window update packets 2037 control packets 388768 packets received 215725 acks (for 176151367 bytes) 31643 duplicate acks 0 acks for unsent data 204363 packets (40447108 bytes) received in-sequence 5905 completely duplicate packets (21670 bytes) 104 packets with some dup. data (195 bytes duped) 795 out-of-order packets (15985 bytes) 1 packet (1024 bytes) of data after window 7 window probes 3219 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 729 connection requests 425 connection accepts 1069 connections established (including accepts) 1183 connections closed (including 9 drops) 93 embryonic connections dropped 178425 segments updated rtt (of 179970 attempts) 3745 retransmit timeouts 1 connection dropped by rexmit timeout 315 persist timeouts 77992 keepalive timeouts 21298 keepalive probes sent 73 connections dropped by keepalive This includes almost everything you were asking about though some of the numbers require a good understanding of the 4bsd tcp implementation to interpret. I promised Mike that I would write a short document (probably an appendix to the 4bsd "Networking Implementation Notes") saying what these numbers mean and how various ratios and differences can be used to find network problems. I have about 30 pages of notes on good things to include in this document but it will probably take me two or three months to get round to writing it. This stuff will presumably go out with the next BSD release. It might even become available as a "bug fix" or something before the next release (I speak from complete ignorance -- I know nothing about BSD distribution policies or plans). I do know that Wollongong has a VMS version of the 4.3bsd networking code that includes these stats (though they don't seem to be distributing it yet -- bang on your TWG salesman if you want it). I also have a strong suspicion that SRI's Multinet will soon include these stats. - Van ps: given the problem you're working on, the socket debugging option and "trpt" might be a quicker way to find it. E.g., "ftp -d host-B" to generate some traffic with debugging enabled then "/etc/trpt -f" (with, say, an ftp data transfer running) to get a complete protocol trace including all the packet arrivals and departures, state transitions, timeouts, rtt's and srtt estimates, user process actions, etc. ("man 8 trpt" will get you more information on how to use it and what optional information is available). Trpt, like netstat, should be available to any "lowly user" on a 4bsd system. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703021453.AA06476%40roundhouse.sunuk.uucp] <1987030204532300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kluger@Sun.COM@roundhouse.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Certification tests for TCP/IP? Message-ID: <8703021453.AA06476@roundhouse.sunuk.uucp> Date: Mon, 2-Mar-87 09:53:23 EST Article-I.D.: roundhou.8703021453.AA06476 Posted: Mon Mar 2 09:53:23 1987 Date-Received: Tue, 3-Mar-87 20:52:49 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Hello fellow tcp-ip'ers, I know of the DCA conducted certification tests for DDN-X.25. But what about certification tests for TCP/IP? I heard a rumour a while back that such tests were being developed, but did anything ever happen? Thanks, Larry Kluger Sun Europe Data Communications ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703021756.AA15720%40ucbvax.Berkeley.EDU] <1987030205210000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BEAME@MCMASTER.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Ultrix TCP/IP Message-ID: <8703021756.AA15720@ucbvax.Berkeley.EDU> Date: Mon, 2-Mar-87 10:21:00 EST Article-I.D.: ucbvax.8703021756.AA15720 Posted: Mon Mar 2 10:21:00 1987 Date-Received: Tue, 3-Mar-87 22:29:33 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 63 Approved: tcp-ip@sri-nic.arpa The following is a trace (excelan monitor) of a PC communicating to a GPX micro-vax running ULTRIX. The ethernet is < 1% loaded, the GPX has no other users on it. CFB/IN is packets going to the PC, CFB/OUT is packets going to the uVax. The command executed is "cat file". The first number in the form xxx.xxx is the time since the first packet in milli.micro seconds, the second number is the time since the last packet in milli.mico seconds. QUESTION: Why does Ultrix wait about 5 seconds after the PC ACK's to send it's next packet? Remember there are no gateways and almost noload on the network or GPX. 1 : CFB/IN ether: IP aa-00-04-00-07-04 -> 02-60-8c-10-46-46 140 0.000 0.000 ip: TCP 01.00001f -> 01.004646 tcp: TELNET -> 7464 ACK tcp: seq: 64807377 ack: 40 win: 4096 len: 82 0: 66 20 25 66 20 25 66 20 25 66 20 25 75 20 25 75 |f %f %f %f %u %u| 16: 20 25 75 22 2c 26 58 6d 69 6e 2c 26 58 6d 61 78 | %u",&Xmin,&Xmax| 32: 2c 26 59 6d 69 6e 2c 26 59 6d 61 78 2c 26 44 65 |,&Ymin,&Ymax,&De| 48: 70 74 68 2c 26 47 72 69 64 78 2c 26 47 72 69 64 |pth,&Gridx,&Grid| 64: 79 29 3b 0d 0a 20 20 20 20 20 20 20 20 64 69 73 |y);.. dis| 80: 70 6c |pl | 2 : CFB/OUT ether: IP 02-60-8c-10-46-46 -> aa-00-04-00-07-04 64 6.981 6.981 ip: TCP 01.004646 -> 01.00001f tcp: 7464 -> TELNET ACK tcp: seq: 40 ack: 64807459 win: 82 len: 0 3 : CFB/IN ether: IP aa-00-04-00-07-04 -> 02-60-8c-10-46-46 140 4998.996 ***.*** ip: TCP 01.00001f -> 01.004646 tcp: TELNET -> 7464 ACK tcp: seq: 64807459 ack: 40 win: 4096 len: 82 0: 61 79 20 3d 20 58 4f 70 65 6e 44 69 73 70 6c 61 |ay = XOpenDispla| 16: 79 28 4e 55 4c 4c 29 3b 0d 0a 20 20 20 20 20 20 |y(NULL);.. | 32: 20 20 77 20 3d 20 58 43 72 65 61 74 65 57 69 6e | w = XCreateWin| 48: 64 6f 77 28 52 6f 6f 74 57 69 6e 64 6f 77 2c 31 |dow(RootWindow,1| 64: 2c 31 2c 47 72 69 64 78 2c 47 72 69 64 79 2c 31 |,1,Gridx,Gridy,1| 80: 2c 57 |,W | 4 : CFB/OUT ether: IP 02-60-8c-10-46-46 -> aa-00-04-00-07-04 64 5006.198 7.203 ip: TCP 01.004646 -> 01.00001f tcp: 7464 -> TELNET ACK tcp: seq: 40 ack: 64807541 win: 82 len: 0 5 : CFB/IN ether: IP aa-00-04-00-07-04 -> 02-60-8c-10-46-46 140 9998.735 ***.*** ip: TCP 01.00001f -> 01.004646 tcp: TELNET -> 7464 ACK tcp: seq: 64807541 ack: 40 win: 4096 len: 82 0: 68 69 74 65 50 69 78 6d 61 70 2c 42 6c 61 63 6b |hitePixmap,Black| 16: 50 69 78 6d 61 70 29 3b 0d 0a 20 20 20 20 20 20 |Pixmap);.. | 32: 20 20 58 4d 61 70 57 69 6e 64 6f 77 28 77 29 3b | XMapWindow(w);| 48: 0d 0a 20 20 20 20 20 20 20 20 58 53 65 6c 65 63 |.. XSelec| 64: 74 49 6e 70 75 74 28 77 2c 30 78 30 33 38 30 29 |tInput(w,0x0380)| 80: 3b 0d |;. | Thanks in advance, Carl Beame ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030205210001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 2 Mar 87 09:47:55-PST Received: from MCMASTER.BITNET by wiscvm.wisc.edu on 03/02/87 at 11:46:34 CST Date: Mon, 2 Mar 87 10:21 EST From: Subject: Ultrix TCP/IP To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, BEAME The following is a trace (excelan monitor) of a PC communicating to a GPX micro-vax running ULTRIX. The ethernet is < 1% loaded, the GPX has no other users on it. CFB/IN is packets going to the PC, CFB/OUT is packets going to the uVax. The command executed is "cat file". The first number in the form xxx.xxx is the time since the first packet in milli.micro seconds, the second number is the time since the last packet in milli.mico seconds. QUESTION: Why does Ultrix wait about 5 seconds after the PC ACK's to send it's next packet? Remember there are no gateways and almost noload on the network or GPX. 1 : CFB/IN ether: IP aa-00-04-00-07-04 -> 02-60-8c-10-46-46 140 0.000 0.000 ip: TCP 01.00001f -> 01.004646 tcp: TELNET -> 7464 ACK tcp: seq: 64807377 ack: 40 win: 4096 len: 82 0: 66 20 25 66 20 25 66 20 25 66 20 25 75 20 25 75 |f %f %f %f %u %u| 16: 20 25 75 22 2c 26 58 6d 69 6e 2c 26 58 6d 61 78 | %u",&Xmin,&Xmax| 32: 2c 26 59 6d 69 6e 2c 26 59 6d 61 78 2c 26 44 65 |,&Ymin,&Ymax,&De| 48: 70 74 68 2c 26 47 72 69 64 78 2c 26 47 72 69 64 |pth,&Gridx,&Grid| 64: 79 29 3b 0d 0a 20 20 20 20 20 20 20 20 64 69 73 |y);.. dis| 80: 70 6c |pl | 2 : CFB/OUT ether: IP 02-60-8c-10-46-46 -> aa-00-04-00-07-04 64 6.981 6.981 ip: TCP 01.004646 -> 01.00001f tcp: 7464 -> TELNET ACK tcp: seq: 40 ack: 64807459 win: 82 len: 0 3 : CFB/IN ether: IP aa-00-04-00-07-04 -> 02-60-8c-10-46-46 140 4998.996 ***.*** ip: TCP 01.00001f -> 01.004646 tcp: TELNET -> 7464 ACK tcp: seq: 64807459 ack: 40 win: 4096 len: 82 0: 61 79 20 3d 20 58 4f 70 65 6e 44 69 73 70 6c 61 |ay = XOpenDispla| 16: 79 28 4e 55 4c 4c 29 3b 0d 0a 20 20 20 20 20 20 |y(NULL);.. | 32: 20 20 77 20 3d 20 58 43 72 65 61 74 65 57 69 6e | w = XCreateWin| 48: 64 6f 77 28 52 6f 6f 74 57 69 6e 64 6f 77 2c 31 |dow(RootWindow,1| 64: 2c 31 2c 47 72 69 64 78 2c 47 72 69 64 79 2c 31 |,1,Gridx,Gridy,1| 80: 2c 57 |,W | 4 : CFB/OUT ether: IP 02-60-8c-10-46-46 -> aa-00-04-00-07-04 64 5006.198 7.203 ip: TCP 01.004646 -> 01.00001f tcp: 7464 -> TELNET ACK tcp: seq: 40 ack: 64807541 win: 82 len: 0 5 : CFB/IN ether: IP aa-00-04-00-07-04 -> 02-60-8c-10-46-46 140 9998.735 ***.*** ip: TCP 01.00001f -> 01.004646 tcp: TELNET -> 7464 ACK tcp: seq: 64807541 ack: 40 win: 4096 len: 82 0: 68 69 74 65 50 69 78 6d 61 70 2c 42 6c 61 63 6b |hitePixmap,Black| 16: 50 69 78 6d 61 70 29 3b 0d 0a 20 20 20 20 20 20 |Pixmap);.. | 32: 20 20 58 4d 61 70 57 69 6e 64 6f 77 28 77 29 3b | XMapWindow(w);| 48: 0d 0a 20 20 20 20 20 20 20 20 58 53 65 6c 65 63 |.. XSelec| 64: 74 49 6e 70 75 74 28 77 2c 30 78 30 33 38 30 29 |tInput(w,0x0380)| 80: 3b 0d |;. | Thanks in advance, Carl Beame ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703021530.AA09240%40jvnca.csc.org] <1987030205301100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: heker@JVNCA.CSC.ORG.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: wollongong Message-ID: <8703021530.AA09240@jvnca.csc.org> Date: Mon, 2-Mar-87 10:30:11 EST Article-I.D.: jvnca.8703021530.AA09240 Posted: Mon Mar 2 10:30:11 1987 Date-Received: Tue, 3-Mar-87 20:44:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Talking about the Wollongong mailer, which doesn't accept canonical names for a host such as i.e. "ucbarpa.berkeley.edu", does anybody know if they plan to do anything about it?. By the end of March there will not be aliases in the hosts tables without a domain specification, then the mailer will not be able to deliver any mail at all. -- SFH -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703021641.AA14109%40ucbvax.Berkeley.EDU] <1987030205563900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <8703021641.AA14109@ucbvax.Berkeley.EDU> Date: Mon, 2-Mar-87 10:56:39 EST Article-I.D.: ucbvax.8703021641.AA14109 Posted: Mon Mar 2 10:56:39 1987 Date-Received: Tue, 3-Mar-87 20:50:15 EST References: <8702270413.AA00250@bel.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 248 Approved: tcp-ip@sri-nic.arpa I had already seen the GOSIP document and been asked, under extreme time contraints, to comment on it for "my sponsor". The comments follow. They should be understood as being fragmentary, in the sense that I feel a lot more could be said, and various points don't even get the emphasis they deserve (e.g., the very negative implications of the fact that the NBS variations aren't "pure ISO"), but I wanted to get them out on the table as soon as possible, so I haven't made an editorial pass over them for this mailing. Please note that I have tried very hard to refrain from what I call Constructive Snottiness (and what many doubtless call abrasiveness) here, but I don't want anybody to think it's from lack of intensity of feelings on the subject. Quite the opposite, indeed. But let the record show that I think the promulgating of GOSIP AT THIS POINT IN TIME is utterly irresponsible, and amounts to "go sip at the public trough for years to come." I urge anybody who sees this and agrees with my negative assessment of GOSIP to alert everybody they can think of that it should be forestalled until the ISO and/or the NBS can offer an INTEGRAL suite of widely-implemented, tested, performance-acceptable protocols. (I personally believe that they're still five years away-- and attach some significance to the fact that I, and other knowledgable observers it should be noted, have been saying that very thing for at least five years.) cheers, map Comments on "GOSIP" Draft M. A. Padlipsky I urge that DIA take the strongest possible action to assure that the DoD take the strongest possible action to prevent the promulgation of a finalized version of the "GOSIP" Draft (dated December 18, 1986). There are three broad grounds on which the dissent should be based: (1) There is ample evidence within the document itself that it is premature for any branch of the Government to standardize on the ISO/OSI protocols. (2) There are leg- itimate DoD concerns and requirements that the ISO/OSI pro- tocols do not, and in some cases cannot in principle, address. (3) There are sufficient technical flaws and inconsistencies in the GOSIP document as to cast doubt on the qualifications of its progenitors to be prescribing net- working policy for the DoD, much less for the Government as a whole. Although time does not permit an exhaustive analysis of each of these areas, some indication of the lines of argument will comprise the remainder of this note. The support for (1) is as follows: The Preface states "This specification will change..." and "Appendices specify future work items needed to enrich the specification...". This is prima facie evidence that the Government is being asked to make procurements to a moving target, the costs of doing which should be well known. Since a major rationale for choosing international standards has traditionally been to save on procurement and maintenance costs, the fact that the document acknowlegdes that there is not yet in existence a stable, seasoned, integral suite of protocols in the ISO/OSI arena indicates that this rationale does not apply at the present time. On the strength of its Preface alone, then, an appropriate response to the GOSIP document would be "Come back in three or four years, when you've got something solid to plug". The absence of a Virtual Terminal Protocol stan- dard in 1.3 is further evidence of the underdeveloped state of the ISO/OSI work, since the ability such a protocol would confer to perform remote logins is fundamental to an inter- computer network worthy of the name. The presence of 1.5.2 and 1.5.3 on "Secondary Sources" and "Tertiary Sources" (of protocol specifications) is still further evidence of incom- pleteness. It is also implicit evidence of fiscal impru- dence: implementing a Draft Proposed Standard can be a waste of money when the Draft International Standard takes a sub- stantially different technical approach, as witness the experience with FTAM; reinterfacing DoD "Telnet" to "TP4"-- as would be consistent with 1.5.3--would also be expensive, and would prove to have been wasted motion whenever the "official" Virtual Terminal Protocol were proclaimed. The footnote to 1.6.1 is also suggestive: if OSI is so "new" that there's no "testing service," isn't it too new to invest in? And if, as 1.6.3 states, "GOSIP does not cite performance criteria," might we not be buying a dead pig in a poke? Finally, it is not enough to say, as 1.6.4 does, that "It is expected that most vendors will update their products..."; unless GOSIP can somehow mandate updating at known, extremely modest cost, isn't GOSIP asking the Govern- ment to sign a blank check? In summary, until ISO has pro- duced specifications for an integral suite of seasoned pro- tocols, GOSIP will almost surely generate more expenditures than savings. The support for (2) is as follows: The technical areas of concern to the DoD which are not addressed by ISO/OSI have been dealt with elsewhere; see References 1-3, for example. For present purposes, it should suffice to note that, among other technical areas, the DoD is--and must be--particularly concerned with the mobility and survivability of its commun- ications, yet GOSIP 4.1.1 mandates a choice of proximate network interface protocols that seems to preclude use of such media as Packet Radio and 5.1.3 specifies static routing--both of which dictates run counter to the DoD needs in the area--and that the DoD has deep Security concerns, yet the GOSIP section on that topic on the one hand does not necessarily reflect the DoD view and on the other hand does not even reflect the prevailing ISO/OSI view (it is, in fact, modeled apparently fairly closely on a view which has been proposed in DoD circles), so that even if it were to prove on closer inspection to be acceptable to the DoD its implementation would engender additional charges by the ven- dors. (It should also be noted that there are inherent, possibly insurmountable difficulties in addressing DoD Secu- rity concerns in the public standards arena.) There is a non-technical concern that deserves even more attention than the technical points in the present context, however. For the DoD, after all, is not "made of money," and it has in place and running an integral suite of intercomputer net- working protocols which indisputably possesses both of the significant desirable properties claimed for OSI: it is "open," in the sense that it is not vendor-idiosyncratic and anyone who implements it can interoperate, and it is widely available, in the sense that dozens of vendors offer DoD Protocol Suite products. (It is also arguable that the DoD Suite is technically superior to the ISO/OSI Suite, but that is not the point at issue here--any more than that there are probably more DoD Suite products available today than OSI Suite products.) Why should the DoD be told in effect to send a well-maintained, late-model, paid-for, "loaded" Buick to the junkyard in order to have the garage space so that it can buy a "stripped" Renault that doesn't even claim to get better gas milage and doesn't have a passenger's seat and other key components? Is this not throwing bad money after good? That is, whatever economic justification there is for ISO/OSI in the de novo case--and certainly, if the Depart- ment of Commerce, say, had no intercomputer networks whatso- ever right now, a better case could be made for "going GOSIP," even though it's premature to do so, rather than "going SNA"--it simply doesn't apply in the case where the fruits of an investment in seasoned art are actively being enjoyed, as is the case in the DoD with respect to the DoD Protocol Suite. Therefore, I would suggest that if points (1) and (3) are not deemed sufficient to put GOSIP on hold for several years the Applicability section of GOSIP (1.4) must be reworked to take cognizance of the realities, with DoD explicitly empowered to exercise its own best judgment on whether/in what specialized circumstance it will "go GOSIP." (It might not be germane to the argument, but it is at least interesting to note that the conceptual underpinnings of OSI were invented and given proof of concept in the DoD- sponsored ARPANET, which is why the statement above about "openness" in the DoD was labeled as indisputable: the prin- ciple of Layering and the goal of Host heterogeneity both come from what is now the DoD Protocol Suite. Therefore, the position I am urging the DoD to take is not one of "Not Invented Here," by any means; it was invented "here," and why should we pay to have it reinvented elsewhere when it works fine here is more like it.) The support for (3) is as follows: The very definition of "End system" in the GOSIP Glossary is inaccurate. In the first place, the defining characteristic of a "terminal" in the intercomputer networking context is that it does not implement the protocols; "intelligent terminals," "worksta- tions," and "personal computers," by contrast, can be "end systems," since they can implement the protocols (but when they merely emulate ["dumb"] terminals, they're not being end systems). More damaging to the GOSIP Draft's credibil- ity, though, the entire weight of the Outboard Processing ("Network Front-End") art militates against the assertion that the protocols must all be implemented "in" the end sys- tem. Another Glossary flaw: "intermediate systems" actually participate in routing, in concert with end systems, they do not "perform routing." Further, in 1.1 GOSIP is stated to be "consistent with and complementary to [MAP and TOP]." If so, it's not consistent with the ISO/OSI "Reference Model" it explicitly espouses elsewhere, since MAP and TOP are not consistent with the reference model. (They prescribe per- forming L6 functions in L7 and they ignore L5.) Also, in 1.4 it cannot be optional to employ the protocols in microprocessors, etc. "that will be connected as end sys- tems..."; it must be mandatory to do so if they're end sys- tems, by definition. Then there's the statement in 3.1 that "Achieving OSI...is best accomplished by using...one protocol specification at each layer": this is palpable non- sense, since if there were one protocol at each layer you wouldn't need Layering, which was invently precisely to allow the existence of different protocols at each layer without having to change the upper (or lower) layer proto- cols to take cognizance of the differences. Indeed, the statement is contradicted in both of the next two para- graphs. And the description of the "transport layer" in 3.2 is incorrect in that it omits reference to both "connection- less" L4 alternatives and to "unreliable, but rapid" L4 con- nections, both of which are necessary and desirable in many intercomputer networking contexts (including several of par- ticular interest to the DoD). Similarly, in 4.1.1, "tran- sport class 4" should not be mandatory: it's merely one of a number of L4 alternatives, even if it was NBS's "baby." For that matter, forcing a choice among a limited number of L2-1 "technologies" betrays a lack of understanding of the power of Layering (you can prefer certain technologies for certain contexts, but if you're properly layered it doesn't matter if the bits are going over a direct wire), and exempting "messaging" from having to comply with L6 (and apparently from L5) simply flouts the very reference model espoused, in a nearly scandalous fashion. (Just because CCITT has enough "clout" to ignore the ISO/OSI reference model doesn't mean that a Government standards program intended to bring good networking practice to participants economically should.) Without bothering to scrutinize the rest of the document for still more evidence, then (although the lack of definitions of terms in 5.2.1 is particularly annoying), it certainly appears that GOSIP is preaching an approach it doesn't prac- tice. Time constraints do not permit a more comprehensive adducing of evidence, but one would hope that the points raised here at least suggest that it is premature for the Government to impose GOSIP upon itself. It is folly to chase a moving target in technological implementations; it is folly to dis- card state-of-the-art technology in favor of less mature technology; and it is folly to adopt misunderstood stan- dards, irrespective of whether they are or are not ever understandable, since it will be too expensive to get them understood even if they are. Let GOSIP go sit for as many years as it takes to come up with a complete set of well- specified, well-implemented protocols that are mutually com- patible. (And then let it come up with a more reasonable position with respect to the DoD Protocol Suite.) References [I'll formalize these if anybody's willing to hand the paper to some Authority; they'll be 1: The Book, 2: Cerf and Lyons' paper on Military Networking, and 3: A Norwegian paper (in English) on the same general topic; just don't feel like digging them up at nearly 6 on Friday.] ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030205563901> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 2 Mar 87 08:26:39-PST Date: 2 Mar 1987 10:56:39 EST Subject: Re: GOSIP From: Michael Padlipsky To: postel@BEL.ISI.EDU (Jon Postel) cc: TCP-IP@SRI-NIC.ARPA, Corrigan@SRI-NIC.ARPA, Heafner@NBS-VMS.ARPA In-Reply-To: <8702270413.AA00250@bel.isi.edu> I had already seen the GOSIP document and been asked, under extreme time contraints, to comment on it for "my sponsor". The comments follow. They should be understood as being fragmentary, in the sense that I feel a lot more could be said, and various points don't even get the emphasis they deserve (e.g., the very negative implications of the fact that the NBS variations aren't "pure ISO"), but I wanted to get them out on the table as soon as possible, so I haven't made an editorial pass over them for this mailing. Please note that I have tried very hard to refrain from what I call Constructive Snottiness (and what many doubtless call abrasiveness) here, but I don't want anybody to think it's from lack of intensity of feelings on the subject. Quite the opposite, indeed. But let the record show that I think the promulgating of GOSIP AT THIS POINT IN TIME is utterly irresponsible, and amounts to "go sip at the public trough for years to come." I urge anybody who sees this and agrees with my negative assessment of GOSIP to alert everybody they can think of that it should be forestalled until the ISO and/or the NBS can offer an INTEGRAL suite of widely-implemented, tested, performance-acceptable protocols. (I personally believe that they're still five years away-- and attach some significance to the fact that I, and other knowledgable observers it should be noted, have been saying that very thing for at least five years.) cheers, map Comments on "GOSIP" Draft M. A. Padlipsky I urge that DIA take the strongest possible action to assure that the DoD take the strongest possible action to prevent the promulgation of a finalized version of the "GOSIP" Draft (dated December 18, 1986). There are three broad grounds on which the dissent should be based: (1) There is ample evidence within the document itself that it is premature for any branch of the Government to standardize on the ISO/OSI protocols. (2) There are leg- itimate DoD concerns and requirements that the ISO/OSI pro- tocols do not, and in some cases cannot in principle, address. (3) There are sufficient technical flaws and inconsistencies in the GOSIP document as to cast doubt on the qualifications of its progenitors to be prescribing net- working policy for the DoD, much less for the Government as a whole. Although time does not permit an exhaustive analysis of each of these areas, some indication of the lines of argument will comprise the remainder of this note. The support for (1) is as follows: The Preface states "This specification will change..." and "Appendices specify future work items needed to enrich the specification...". This is prima facie evidence that the Government is being asked to make procurements to a moving target, the costs of doing which should be well known. Since a major rationale for choosing international standards has traditionally been to save on procurement and maintenance costs, the fact that the document acknowlegdes that there is not yet in existence a stable, seasoned, integral suite of protocols in the ISO/OSI arena indicates that this rationale does not apply at the present time. On the strength of its Preface alone, then, an appropriate response to the GOSIP document would be "Come back in three or four years, when you've got something solid to plug". The absence of a Virtual Terminal Protocol stan- dard in 1.3 is further evidence of the underdeveloped state of the ISO/OSI work, since the ability such a protocol would confer to perform remote logins is fundamental to an inter- computer network worthy of the name. The presence of 1.5.2 and 1.5.3 on "Secondary Sources" and "Tertiary Sources" (of protocol specifications) is still further evidence of incom- pleteness. It is also implicit evidence of fiscal impru- dence: implementing a Draft Proposed Standard can be a waste of money when the Draft International Standard takes a sub- stantially different technical approach, as witness the experience with FTAM; reinterfacing DoD "Telnet" to "TP4"-- as would be consistent with 1.5.3--would also be expensive, and would prove to have been wasted motion whenever the "official" Virtual Terminal Protocol were proclaimed. The footnote to 1.6.1 is also suggestive: if OSI is so "new" that there's no "testing service," isn't it too new to invest in? And if, as 1.6.3 states, "GOSIP does not cite performance criteria," might we not be buying a dead pig in a poke? Finally, it is not enough to say, as 1.6.4 does, that "It is expected that most vendors will update their products..."; unless GOSIP can somehow mandate updating at known, extremely modest cost, isn't GOSIP asking the Govern- ment to sign a blank check? In summary, until ISO has pro- duced specifications for an integral suite of seasoned pro- tocols, GOSIP will almost surely generate more expenditures than savings. The support for (2) is as follows: The technical areas of concern to the DoD which are not addressed by ISO/OSI have been dealt with elsewhere; see References 1-3, for example. For present purposes, it should suffice to note that, among other technical areas, the DoD is--and must be--particularly concerned with the mobility and survivability of its commun- ications, yet GOSIP 4.1.1 mandates a choice of proximate network interface protocols that seems to preclude use of such media as Packet Radio and 5.1.3 specifies static routing--both of which dictates run counter to the DoD needs in the area--and that the DoD has deep Security concerns, yet the GOSIP section on that topic on the one hand does not necessarily reflect the DoD view and on the other hand does not even reflect the prevailing ISO/OSI view (it is, in fact, modeled apparently fairly closely on a view which has been proposed in DoD circles), so that even if it were to prove on closer inspection to be acceptable to the DoD its implementation would engender additional charges by the ven- dors. (It should also be noted that there are inherent, possibly insurmountable difficulties in addressing DoD Secu- rity concerns in the public standards arena.) There is a non-technical concern that deserves even more attention than the technical points in the present context, however. For the DoD, after all, is not "made of money," and it has in place and running an integral suite of intercomputer net- working protocols which indisputably possesses both of the significant desirable properties claimed for OSI: it is "open," in the sense that it is not vendor-idiosyncratic and anyone who implements it can interoperate, and it is widely available, in the sense that dozens of vendors offer DoD Protocol Suite products. (It is also arguable that the DoD Suite is technically superior to the ISO/OSI Suite, but that is not the point at issue here--any more than that there are probably more DoD Suite products available today than OSI Suite products.) Why should the DoD be told in effect to send a well-maintained, late-model, paid-for, "loaded" Buick to the junkyard in order to have the garage space so that it can buy a "stripped" Renault that doesn't even claim to get better gas milage and doesn't have a passenger's seat and other key components? Is this not throwing bad money after good? That is, whatever economic justification there is for ISO/OSI in the de novo case--and certainly, if the Depart- ment of Commerce, say, had no intercomputer networks whatso- ever right now, a better case could be made for "going GOSIP," even though it's premature to do so, rather than "going SNA"--it simply doesn't apply in the case where the fruits of an investment in seasoned art are actively being enjoyed, as is the case in the DoD with respect to the DoD Protocol Suite. Therefore, I would suggest that if points (1) and (3) are not deemed sufficient to put GOSIP on hold for several years the Applicability section of GOSIP (1.4) must be reworked to take cognizance of the realities, with DoD explicitly empowered to exercise its own best judgment on whether/in what specialized circumstance it will "go GOSIP." (It might not be germane to the argument, but it is at least interesting to note that the conceptual underpinnings of OSI were invented and given proof of concept in the DoD- sponsored ARPANET, which is why the statement above about "openness" in the DoD was labeled as indisputable: the prin- ciple of Layering and the goal of Host heterogeneity both come from what is now the DoD Protocol Suite. Therefore, the position I am urging the DoD to take is not one of "Not Invented Here," by any means; it was invented "here," and why should we pay to have it reinvented elsewhere when it works fine here is more like it.) The support for (3) is as follows: The very definition of "End system" in the GOSIP Glossary is inaccurate. In the first place, the defining characteristic of a "terminal" in the intercomputer networking context is that it does not implement the protocols; "intelligent terminals," "worksta- tions," and "personal computers," by contrast, can be "end systems," since they can implement the protocols (but when they merely emulate ["dumb"] terminals, they're not being end systems). More damaging to the GOSIP Draft's credibil- ity, though, the entire weight of the Outboard Processing ("Network Front-End") art militates against the assertion that the protocols must all be implemented "in" the end sys- tem. Another Glossary flaw: "intermediate systems" actually participate in routing, in concert with end systems, they do not "perform routing." Further, in 1.1 GOSIP is stated to be "consistent with and complementary to [MAP and TOP]." If so, it's not consistent with the ISO/OSI "Reference Model" it explicitly espouses elsewhere, since MAP and TOP are not consistent with the reference model. (They prescribe per- forming L6 functions in L7 and they ignore L5.) Also, in 1.4 it cannot be optional to employ the protocols in microprocessors, etc. "that will be connected as end sys- tems..."; it must be mandatory to do so if they're end sys- tems, by definition. Then there's the statement in 3.1 that "Achieving OSI...is best accomplished by using...one protocol specification at each layer": this is palpable non- sense, since if there were one protocol at each layer you wouldn't need Layering, which was invently precisely to allow the existence of different protocols at each layer without having to change the upper (or lower) layer proto- cols to take cognizance of the differences. Indeed, the statement is contradicted in both of the next two para- graphs. And the description of the "transport layer" in 3.2 is incorrect in that it omits reference to both "connection- less" L4 alternatives and to "unreliable, but rapid" L4 con- nections, both of which are necessary and desirable in many intercomputer networking contexts (including several of par- ticular interest to the DoD). Similarly, in 4.1.1, "tran- sport class 4" should not be mandatory: it's merely one of a number of L4 alternatives, even if it was NBS's "baby." For that matter, forcing a choice among a limited number of L2-1 "technologies" betrays a lack of understanding of the power of Layering (you can prefer certain technologies for certain contexts, but if you're properly layered it doesn't matter if the bits are going over a direct wire), and exempting "messaging" from having to comply with L6 (and apparently from L5) simply flouts the very reference model espoused, in a nearly scandalous fashion. (Just because CCITT has enough "clout" to ignore the ISO/OSI reference model doesn't mean that a Government standards program intended to bring good networking practice to participants economically should.) Without bothering to scrutinize the rest of the document for still more evidence, then (although the lack of definitions of terms in 5.2.1 is particularly annoying), it certainly appears that GOSIP is preaching an approach it doesn't prac- tice. Time constraints do not permit a more comprehensive adducing of evidence, but one would hope that the points raised here at least suggest that it is premature for the Government to impose GOSIP upon itself. It is folly to chase a moving target in technological implementations; it is folly to dis- card state-of-the-art technology in favor of less mature technology; and it is folly to adopt misunderstood stan- dards, irrespective of whether they are or are not ever understandable, since it will be too expensive to get them understood even if they are. Let GOSIP go sit for as many years as it takes to come up with a complete set of well- specified, well-implemented protocols that are mutually com- patible. (And then let it come up with a more reasonable position with respect to the DoD Protocol Suite.) References [I'll formalize these if anybody's willing to hand the paper to some Authority; they'll be 1: The Book, 2: Cerf and Lyons' paper on Military Networking, and 3: A Norwegian paper (in English) on the same general topic; just don't feel like digging them up at nearly 6 on Friday.] ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703021612.AA23939%40sotka.tut.fi] <1987030206124500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jh@seismo.CSS.GOV@tut.fi Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8703021612.AA23939@sotka.tut.fi> Date: Mon, 2-Mar-87 11:12:45 EST Article-I.D.: sotka.8703021612.AA23939 Posted: Mon Mar 2 11:12:45 1987 Date-Received: Tue, 3-Mar-87 22:28:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Path: tut!jh From: jh@tut.UUCP (Juha Hein{nen) Newsgroups: mod.protocols.tcp-ip Subject: How to have two networks in a single Ethernet? Message-ID: <646@sotka.tut.UUCP> Date: 2 Mar 87 16:12:44 GMT Reply-To: jh@tut.UUCP () Distribution: world Organization: Tampere University of Technology, Finland Lines: 15 We have just got Bridge GS-3M boxes with Vitalink software that connect protocol independently four separate Ethernets. The separate Ethernets each have their own Class C Internet numbers. Our problem is, how to configure the 4.2bsd machines (Suns and Vaxen) in each of the separate networks so that they could talk to each other. We have tried to add new entries in /etc/hosts and add new arp info but when trying to connect a machine in another network, we get back an error message "Network is unreachable". It looks like we should be able to generate one of our machines as a gateway machine with only one Ethernet controller. Any help is appreciated. -- Juha Heinanen Tampere Univ. of Technology Finland ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703021616.AA11571%40cernvax.UUCP] <1987030206162800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ben@CERNVAX.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8703021616.AA11571@cernvax.UUCP> Date: Mon, 2-Mar-87 11:16:28 EST Article-I.D.: cernvax.8703021616.AA11571 Posted: Mon Mar 2 11:16:28 1987 Date-Received: Tue, 3-Mar-87 20:49:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Path: cernvax!ben From: ben@cernvax.UUCP (ben) Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP for OS-9 Anywhere? Keywords: TCP/IP OS-9 NFS Message-ID: <445@cernvax.UUCP> Date: 2 Mar 87 16:16:25 GMT Reply-To: ben@cernvax.UUCP (via mcvax) Distribution: world Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Sw Lines: 5 We are looking for possible TCP/IP implementations for 68K systems running the Microware OS-9 operating system. We are interested both in the case where all of the protocols and utilities run on the 68K, or where an intelligent board is used, e.g. Excelan, CMC, etc. (for VME-based systems). A big bonus would be the additional availability of (at least client) NFS. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703022043.AA02103%40columbia.edu] <1987030210431100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: nobody@COLUMBIA.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8703022043.AA02103@columbia.edu> Date: Mon, 2-Mar-87 15:43:11 EST Article-I.D.: columbia.8703022043.AA02103 Posted: Mon Mar 2 15:43:11 1987 Date-Received: Wed, 4-Mar-87 00:07:06 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 58 Approved: tcp-ip@sri-nic.arpa Path: columbia!cunixc!cck From: cck@cunixc (Charlie C. Kim) Newsgroups: mod.protocols.tcp-ip Subject: Re: Ultrix TCP/IP Message-ID: <4410@columbia.UUCP> Date: 2 Mar 87 20:43:10 GMT References: <8703021756.AA15720@ucbvax.Berkeley.EDU> Sender: nobody@columbia.UUCP Reply-To: cck@cunixc.UUCP (Charlie C. Kim) Distribution: world Organization: Columbia University Center for Computing Activities Lines: 45 In article <8703021756.AA15720@ucbvax.Berkeley.EDU> BEAME@MCMASTER.BITNET writes: >The following is a trace (excelan monitor) of a PC communicating to a GPX >micro-vax running ULTRIX. The ethernet is < 1% loaded, the GPX has no other >... > >QUESTION: > Why does Ultrix wait about 5 seconds after the PC ACK's to send it's >next packet? Remember there are no gateways and almost noload on the >network or GPX. > I'm not sure what software you're running on your pc or what version of ultrix you are running, but both BSD 4.3 and Ultrix 1.2 delays sends by the TCP 'PERSIST' timeout if the window is too "small" (e.g. segment to be sent is "larger" than remotely advertised window). This might have been the case in Ultrix 1.1 and is probably the case in Ultrix 2.0. The PERSIST timeout is around 5 seconds. The tcp segments resulting from the cat output are probably pretty large, so in the following you can see that the delay happens when the window advertised by the PC TCP/IP is quite small - probably quite a bit smaller than the segment that the Unix TCP wants to send. >2 : CFB/OUT >ether: IP 02-60-8c-10-46-46 -> aa-00-04-00-07-04 64 6.981 6.981 > ip: TCP 01.004646 -> 01.00001f > tcp: 7464 -> TELNET ACK > tcp: seq: 40 ack: 64807459 win: 82 len: 0 > >3 : CFB/IN >ether: IP aa-00-04-00-07-04 -> 02-60-8c-10-46-46 140 4998.996 ***.*** > ip: TCP 01.00001f -> 01.004646 > tcp: TELNET -> 7464 ACK > tcp: seq: 64807459 ack: 40 win: 4096 len: 82 > 0: 61 79 20 3d 20 58 4f 70 65 6e 44 69 73 70 6c 61 |ay = XOpenDispla| >... Enough of the analysis, what you probably want is a workaround which I can offer for the MIT version of PC/IP: simply set the telnet low window close to the telnet window using custom and you'll find things a lot more zippy. (This I discovered by experimentation much before I tried to figure out what was really happening). Charlie C. Kim User Services Columbia University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703022102.AA00112%40Sun.COM] <1987030210502200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Certification tests for TCP/IP? Message-ID: <8703022102.AA00112@Sun.COM> Date: Mon, 2-Mar-87 15:50:22 EST Article-I.D.: Sun.8703022102.AA00112 Posted: Mon Mar 2 15:50:22 1987 Date-Received: Tue, 3-Mar-87 21:45:46 EST References: <8703021453.AA06476@roundhouse.sunuk.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Larry, As of now there is no certification program in place for TCP/IP and above. Much development work was done under contract to DCA to develop such tests. The results of that work are being considered to be released into the public domain so that testing companies can come forth and offer testing services for TCP/IP based upon that (or additional) work. I don't know when it will happen (or it is for sure) but i expect it to be in the next few months. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703031250.AA05275%40topaz.rutgers.edu] <1987030302503000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@seismo.CSS.GOV@topaz.rutgers.edu Newsgroups: mod.protocols.tcp-ip Subject: Re: Submission for mod-protocols-tcp-ip Message-ID: <8703031250.AA05275@topaz.rutgers.edu> Date: Tue, 3-Mar-87 07:50:30 EST Article-I.D.: topaz.8703031250.AA05275 Posted: Tue Mar 3 07:50:30 1987 Date-Received: Thu, 5-Mar-87 22:08:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa Let us suppose that you have the following configuration: --------- network 192.1.1 | router, with addresses 192.1.1.1 and 192.1.2.2 | --------- network 192.1.2 | router, with addresses 192.1.2.1 and 192.1.3.1 | --------- network 192.1.3 Now suppose you have a 4.2 machine on network 192.1.2, whose own address is 192.1.2.10. Here is the way I would set up routing. /usr/etc/route add 192.1.1 192.1.2.2 1 /usr/etc/route add 192.1.3 192.1.2.1 1 That is, you tell route the address of the router that is used to get to each other the other networks. The address you give must be the address of the router's interface on your own network. With this approach, you need one route command for each network other than the one your machine is on. If the router has the ability to issue ICMP redirects, you can do things with a single entry: /usr/etc/route add 0 192.1.2.1 1 A network number of 0 specifies this as a default route. That means that any address not on the local network is sent to 192.1.2.1. If that machine is not the right one, it should issue a redirect command that will cause your machine to add a proper routing entry automatically. I don't know whether the Bridge products issue ICMP redirects or not. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [20316.541782073%40nrtc-gremlin.arpa] <1987030305270100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@NRTC-GREMLIN.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <20316.541782073@nrtc-gremlin.arpa> Date: Tue, 3-Mar-87 10:27:01 EST Article-I.D.: nrtc-gre.20316.541782073 Posted: Tue Mar 3 10:27:01 1987 Date-Received: Thu, 5-Mar-87 21:50:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 67 Approved: tcp-ip@sri-nic.arpa Mike - I do not claim to have all the answers on GOSIP, but I believe that one of us is severely misinformed as to GOSIP's *intent*. GOSIP simply states (according to my paraphrasing): If a US Govt. organization wishes to buy OSI networking technology, then these are the guidelines that organization's procurement authority should use when specifying the requirements for said technology. As such, the GOSIP spec, although containing some minor errors, is entirely consistent with reality. I believe that the problem arises from the fact that you (and I) consider TCP/IP to be OSI in addition to the ISO/CCITT stuff. The people writing the spec do not view it that way, they view OSI as being "proprietary" to the international standards organizations. Given this perspective, let me make a couple of observations: GOSIP does not say "let's trash this TCP/IP and ISO". It says "if you're going to buy ISO, then in FY87, this is what you should be buying". Mike, you've really got to get this us vs. iso chip off of your shoulder, it is starting to damage your spinal cord and hence you sense of balance. GOSIP is actually quite realistic in what it suggests: There is no usable virtual terminal protocol from ISO these days, so they don't try to specify one. That is responsible. The FTAM DIS will be an IS "any day now" and the changes from DIS to IS are very minor. So, saying the FTAM DIS is OK, is again, a fine thing. Finally, the reason that the CCITT X.400 (MHS) stuff doesn't have a presentation layer, is that it pre-dates the ISO presentation layer. There are, however, several implementations of X.400 which do work (and interoperate with each other). The current joint ISO/CCITT work in message handling, called MOTIS, does make use of ISO presentation layer, adhering to that model of 7+3i that we love so well. Again, since there are X.400 implementations that are working, let me remind you what someone said in his collection of essays on networking: Do you want protocols that look nice or protocols that want nice? Given the charter of GOSIP as I interpret it, again they are doing just fine. Now, if you want to talk about unrealistic goals, I will privately tell you what other OSI mavens are proposing for the '88 time-frame (you think SDI is complex and has to do a lot? heh, heh, heh, have I got a user profile for you!) But, I digress: let me come back to the start of the message. GOSIP does not say "TRASH TCP/IP". It would be much better for the networking gurus of the Internet to look at the spec and be helpful rather than view it as an attack on motherhood. Of course, as you know, I like both technologies: that's why I'm running FTAM DIS now in a TCP/IP network. I have this great ISO application running on a stable Internet. What can I say? It's great! /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703031538.AA08488%40ucbvax.Berkeley.EDU] <1987030305400500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jon@CS.UCL.AC.UK.UUCP Newsgroups: mod.protocols.tcp-ip Subject: pings Message-ID: <8703031538.AA08488@ucbvax.Berkeley.EDU> Date: Tue, 3-Mar-87 10:40:05 EST Article-I.D.: ucbvax.8703031538.AA08488 Posted: Tue Mar 3 10:40:05 1987 Date-Received: Thu, 5-Mar-87 21:53:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Who is sending ICMP echos to our terminal gateway on it's old address (128.16.9.3). It won't answer now, nor did it ever. We are seeing a source at LINC.CIS.UPENN.EDU or UPENN-LINC.ARPA Try 128.16.9.0, or 128.16.5.1 (our primary nameserver) if you need a very remote echo host. i am interested what you are doing. jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703031610.AA08826%40ucbvax.Berkeley.EDU] <1987030305581000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <8703031610.AA08826@ucbvax.Berkeley.EDU> Date: Tue, 3-Mar-87 10:58:10 EST Article-I.D.: ucbvax.8703031610.AA08826 Posted: Tue Mar 3 10:58:10 1987 Date-Received: Thu, 5-Mar-87 22:34:24 EST References: <20316.541782073@nrtc-gremlin.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa Marshall-- Sorry, but your "paraphrase" is not supported by the words on the page. See 1.4, Applicability: "GOSIP is to be used by all Federal Government agencies when procuring ADP systems or services and communication systems or services. It is mandatory for all new network implementations and should be carefully considered for retrofits." See also 1.2, Purpose: "This specification is _the_ standard reference for all Federal Government agencies to use when procuring ADP systems or services and communication systems or services." See, for that matter, 1.1, Background: "GOSIP addresses the need fo the Federal Government to move immediately to multi vendor [sic] interconnectivity...." Perhaps you saw an earlier draft. I don't have a chip on my shoulder, I have a clear and present danger in my sights. If this be paranoia, let's make the most of it. cheers, map P.S. Just so nobody thinks I'm quoting unfairly, 1.4 does offer: "For a period of two years, agencies are permitted to procure alternative interoperable protocols, but they must provide a mechanism for those protocols to interoperate with OSI protocols as well." Perhaps you construe this as keeping the TCP/IP Suite; I can't. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030305581001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 3 Mar 87 08:05:29-PST Date: 3 Mar 1987 10:58:10 EST Subject: Re: GOSIP From: Michael Padlipsky To: Marshall Rose cc: Michael Padlipsky , Jon Postel , TCP-IP@SRI-NIC.ARPA, Corrigan@SRI-NIC.ARPA, Heafner@NBS-VMS.ARPA In-Reply-To: <20316.541782073@nrtc-gremlin.arpa> Marshall-- Sorry, but your "paraphrase" is not supported by the words on the page. See 1.4, Applicability: "GOSIP is to be used by all Federal Government agencies when procuring ADP systems or services and communication systems or services. It is mandatory for all new network implementations and should be carefully considered for retrofits." See also 1.2, Purpose: "This specification is _the_ standard reference for all Federal Government agencies to use when procuring ADP systems or services and communication systems or services." See, for that matter, 1.1, Background: "GOSIP addresses the need fo the Federal Government to move immediately to multi vendor [sic] interconnectivity...." Perhaps you saw an earlier draft. I don't have a chip on my shoulder, I have a clear and present danger in my sights. If this be paranoia, let's make the most of it. cheers, map P.S. Just so nobody thinks I'm quoting unfairly, 1.4 does offer: "For a period of two years, agencies are permitted to procure alternative interoperable protocols, but they must provide a mechanism for those protocols to interoperate with OSI protocols as well." Perhaps you construe this as keeping the TCP/IP Suite; I can't. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703031825.AA11398%40ucbvax.Berkeley.EDU] <1987030308110000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BEAME@MCMASTER.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ultrix TCP/IP Message-ID: <8703031825.AA11398@ucbvax.Berkeley.EDU> Date: Tue, 3-Mar-87 13:11:00 EST Article-I.D.: ucbvax.8703031825.AA11398 Posted: Tue Mar 3 13:11:00 1987 Date-Received: Thu, 5-Mar-87 22:08:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa Hello, Thanks to everyone who responded to my query. To those who suggested that I set the minimum window size to the maximum window size for the PC/IP, this method will send two ACK's for every packet. But it should work. The real answer is to have the PC/IP send the "maximum segment option" on connect to be the same as the PC's maximum window. Thanks again to every one, Carl Beame ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030308110001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Tue 3 Mar 87 10:12:53-PST Received: from MCMASTER.BITNET by wiscvm.wisc.edu on 03/03/87 at 12:11:49 CST Date: Tue, 3 Mar 87 13:11 EST From: Subject: Re: Ultrix TCP/IP To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, BEAME Hello, Thanks to everyone who responded to my query. To those who suggested that I set the minimum window size to the maximum window size for the PC/IP, this method will send two ACK's for every packet. But it should work. The real answer is to have the PC/IP send the "maximum segment option" on connect to be the same as the PC's maximum window. Thanks again to every one, Carl Beame ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703031818.AA09140%40trantor.UMD.EDU] <1987030308185900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: louie@TRANTOR.UMD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: UMDNET hosts to change addresses Message-ID: <8703031818.AA09140@trantor.UMD.EDU> Date: Tue, 3-Mar-87 13:18:59 EST Article-I.D.: trantor.8703031818.AA09140 Posted: Tue Mar 3 13:18:59 1987 Date-Received: Thu, 5-Mar-87 23:45:38 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa Effective 0700 EST on March 12, 1987 a subset of UMDNET hosts will change their addresses. All of the hosts on subnet 0 (those hosts whose addresses are of the form 128.8.0.x) will change to subnet 10. For example, UMD5.UMD.EDU currently has the internet address 128.8.0.5. It's address will change to 128.8.10.5. An updated HOSTS.TXT will be available from the NIC on that day. Please note that the current domain name servers (TRANTOR.UMD.EDU 128.8.0.14 and NEOTRANTOR.UMU 128.8.0.9) will migrate to TRANTOR.UMD.EDU at 128.8.10.14, TERP.UMD.EDU 128.8.10.90, UMD5.UMD.EDU 128.8.10.5, and SNOOPY.UMD.EDU 128.8.10.18. People who query the UDP TIME and UDP NTP servers on UMD1.UMD.EDU 128.8.0.1 should query UMD1.UMD.EDU 128.8.10.1 after the conversion. Please note that we actively discourage people from using TCP/TIME. In summary: Old host addr New host addr ------------- ------------- 128.8.0.x ==> 128.8.10.x 128.8.y.z ==> 128.8.y.z (no change where y != 0) Old Name servers New name servers --------------- --------------- 128.8.0.14 (trantor.umd.edu) 128.8.10.14 (trantor.umd.edu) 128.8.0.9 (neotrantor.umd.edu) 128.8.10.90 (terp.umd.edu) 128.8.10.5 (umd5.umd.edu) 128.8.10.18 (snoopy.umd.edu) Old time server New time server --------------- ---------------- 128.8.0.1 (umd1.umd.edu) 128.8.10.1 (umd.umd.edu) If you have any questions, please feel free to send me mail. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703031950.AA02390%40pacific.ARPA] <1987030309500000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stanonik@NPRDC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: xerox -> 4.3bsd telnet Message-ID: <8703031950.AA02390@pacific.ARPA> Date: Tue, 3-Mar-87 14:50:00 EST Article-I.D.: pacific.8703031950.AA02390 Posted: Tue Mar 3 14:50:00 1987 Date-Received: Thu, 5-Mar-87 23:46:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: stanonik@nprdc.arpa Distribution: world Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa Thanks. I asked about the correctness of 4.3bsd's telnet server because I was uncertain about what a host should do between sending a telnet option request and receiving a response. The rfc doesn't seem to say what the host should do, although now I notice that it (rfc 854) does say what the host may do: "may wish to buffer data, after requesting an option, until it learns whether the request is accepted or rejected". In effect, that is what 4.3bsd does, buffers all data (well, it throws some away if the buffer fills) until receiving a response. Thanks, Ron stanonik@nprdc.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3726.541809095%40nrtc-gremlin.arpa] <1987030313005200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@NRTC-GREMLIN.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <3726.541809095@nrtc-gremlin.arpa> Date: Tue, 3-Mar-87 18:00:52 EST Article-I.D.: nrtc-gre.3726.541809095 Posted: Tue Mar 3 18:00:52 1987 Date-Received: Fri, 6-Mar-87 00:23:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa We are looking at the same draft. My problem is that I attended the meeting, and formed my opinions on that, instead of interpreting the fine points of the draft. It was quite clear at the last meeting that GOSIP was not intended to mandate OSI networking. Rather it was intended to mandate the types of OSI networking technology, if one were to buy OSI. The authority to mandate OSI networking over any other technology, e.g., TCP/IP, SNA, or XNS, lies with OMB. I'm not real clear on this, but there is some OMB directive in the works which makes that mandate. If you want to get paranoid, that is where to start. It was clear to the GOSIP committee during the meeting that they were only interested in specifying the OSI technology they wanted. From this perspective, GOSIP is a reasonable thing. Perhaps someone in authority and/or with more insight can shed some light on this discussion. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030315022000> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Tue 3 Mar 87 07:17:42-PST Received: from ucl-cs-pyr1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa09753; 3 Mar 87 15:11 WET To: tcp-ip@sri-nic.arpa Subject: pings Date: Tue, 03 Mar 87 15:02:20 +0000 From: Jon Crowcroft Who is sending ICMP echos to our terminal gateway on it's old address (128.16.9.3). It won't answer now, nor did it ever. We are seeing a source at LINC.CIS.UPENN.EDU or UPENN-LINC.ARPA Try 128.16.9.0, or 128.16.5.1 (our primary nameserver) if you need a very remote echo host. i am interested what you are doing. jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703041526.AA03414%40ucbvax.Berkeley.EDU] <1987030405072900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: pogran@CCQ.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <8703041526.AA03414@ucbvax.Berkeley.EDU> Date: Wed, 4-Mar-87 10:07:29 EST Article-I.D.: ucbvax.8703041526.AA03414 Posted: Wed Mar 4 10:07:29 1987 Date-Received: Fri, 6-Mar-87 04:33:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa Marshall, But the document states (p. 2, sec. 1.4): "GOSIP is to be used by all Federal Government agencies when procuring ADP systems or services and communica- tion systems or services. It is mandatory for all new network implementations ... Specifically, this speci- fication is mandatory and applies to the procurement of all mini computers and mainframes that are to be inter- connected as end systems or intermediate systems." If the framers of this document wanted to say, "Use this specification IF you want to procure OSI stuff", it certainly didn't come out that way! My paraphrase of it would be, "If you want to buy systems that communicate, you MUST use this spec." I vote with MAP on this one (that's Michael A. Padlipsky, not Manufacturing Automation Protocol). Ken Pogran ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030405072901> Received: from ccq.bbn.com by SRI-NIC.ARPA with TCP; Wed 4 Mar 87 07:22:11-PST Date: Wed, 4 Mar 87 10:07:29 EST From: Ken Pogran Subject: Re: GOSIP In-Reply-To: Your message of Tue, 03 Mar 87 07:01:13 -0800 To: Marshall Rose Cc: Michael Padlipsky , Jon Postel , TCP-IP@sri-nic.arpa, Corrigan@sri-nic.arpa, Heafner@nbs-vms.arpa, pogran@ccq.bbn.com Marshall, But the document states (p. 2, sec. 1.4): "GOSIP is to be used by all Federal Government agencies when procuring ADP systems or services and communica- tion systems or services. It is mandatory for all new network implementations ... Specifically, this speci- fication is mandatory and applies to the procurement of all mini computers and mainframes that are to be inter- connected as end systems or intermediate systems." If the framers of this document wanted to say, "Use this specification IF you want to procure OSI stuff", it certainly didn't come out that way! My paraphrase of it would be, "If you want to buy systems that communicate, you MUST use this spec." I vote with MAP on this one (that's Michael A. Padlipsky, not Manufacturing Automation Protocol). Ken Pogran ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703041612.AA04079%40ucbvax.Berkeley.EDU] <1987030405493000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <8703041612.AA04079@ucbvax.Berkeley.EDU> Date: Wed, 4-Mar-87 10:49:30 EST Article-I.D.: ucbvax.8703041612.AA04079 Posted: Wed Mar 4 10:49:30 1987 Date-Received: Fri, 6-Mar-87 04:37:30 EST References: <3726.541809095@nrtc-gremlin.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Marshall-- It's difficult for me to see how anyone could call the Applicability section of a proposed Federal standard a "fine point." For more on the topic of how the wording of the spec can subvert the intent of the committee, see pp. 84-5 of The Book (which you must have, since you were good enough to have quoted p. 228 at me [somewhat out of context] in your previous msg). Re the presumed "OMB mandate": In my view, it's almost certainly a red herring (stipulating that it does indeed exist, which you didn't seem sure of), for two separate reasons: (1) OMB almost certainly was put up to it by NBS, so your appeal to it represents a type of circular reasoning, not an external confirmation. (2) It's manifestly premature, regardless of whose idea it was originally; see my critique of the GOSIP draft. But I'm certainly quite willing to join you in encouraging anybody who's tracking this disucssion who knows how to alert OMB to the error of its ways to do so--as quickly and as emphatically as possible. (I don't, however, agree with your implication that they shouldn't bother to try to beat on NBS, too.) cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030405493001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 4 Mar 87 07:54:41-PST Date: 4 Mar 1987 10:49:30 EST Subject: Re: GOSIP From: Michael Padlipsky To: Marshall Rose cc: Michael Padlipsky , Jon Postel , TCP-IP@SRI-NIC.ARPA, Corrigan@SRI-NIC.ARPA, Heafner@NBS-VMS.ARPA In-Reply-To: <3726.541809095@nrtc-gremlin.arpa> Marshall-- It's difficult for me to see how anyone could call the Applicability section of a proposed Federal standard a "fine point." For more on the topic of how the wording of the spec can subvert the intent of the committee, see pp. 84-5 of The Book (which you must have, since you were good enough to have quoted p. 228 at me [somewhat out of context] in your previous msg). Re the presumed "OMB mandate": In my view, it's almost certainly a red herring (stipulating that it does indeed exist, which you didn't seem sure of), for two separate reasons: (1) OMB almost certainly was put up to it by NBS, so your appeal to it represents a type of circular reasoning, not an external confirmation. (2) It's manifestly premature, regardless of whose idea it was originally; see my critique of the GOSIP draft. But I'm certainly quite willing to join you in encouraging anybody who's tracking this disucssion who knows how to alert OMB to the error of its ways to do so--as quickly and as emphatically as possible. (I don't, however, agree with your implication that they shouldn't bother to try to beat on NBS, too.) cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703041709.AA21078%40itsgw.rpi.edu] <1987030407091600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: porter%itsgw@CSV.RPI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8703041709.AA21078@itsgw.rpi.edu> Date: Wed, 4-Mar-87 12:09:16 EST Article-I.D.: itsgw.8703041709.AA21078 Posted: Wed Mar 4 12:09:16 1987 Date-Received: Fri, 6-Mar-87 03:36:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa RFC 985 "Requirements for Internet Gateways" specifies functions that are available, in some form, in some products from suppliers such as Proteon (P4200), Bridge, Cisco, etc. At RPI we have had some experience with the P4200 product through its use in NYSERNet. We are considering evaluating other competing products for further use on campus in connecting LANs to a backbone. This note is to ask for feedback from current users of such products -- in particular those from Bridge, CMC, Cisco. Warnings welcome; cheers accepted cheerfully. Don Porter RPI Information Technology Services porter@itsgw.rpi.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1104.541891929%40nrtc-gremlin.arpa] <1987030411475600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@NRTC-GREMLIN.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <1104.541891929@nrtc-gremlin.arpa> Date: Wed, 4-Mar-87 16:47:56 EST Article-I.D.: nrtc-gre.1104.541891929 Posted: Wed Mar 4 16:47:56 1987 Date-Received: Fri, 6-Mar-87 05:39:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Well Mike, what can I say? You got me on a technicality. Final defense: It is my belief that the scope and applicability sections of the GOSIP spec are mis-stated in that they are not consistent with what I thought was going on at the meeting. Perhaps I am wrong and have misinterpreted what was agreed at the last meeting. If I am correct in this assumption, then these two sections should be fixed in the final copy. If this is done, then GOSIP is a fine thing. If, on the other had, I am wrong, and these sections are to be an accurate representation of GOSIP's intent, then I have wasted everyone's time trying to defend something which is patently wrong (as most of your arguments point out) and I'll appologize. However, since none of the people in the know have commented on our discussion, it is difficult for me to gauge how right/wrong I am. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030501241000> Received: from lll-lcc.ARPA by SRI-NIC.ARPA with TCP; Thu 5 Mar 87 10:32:33-PST Received: Thu, 5 Mar 87 10:24:51 PST by lll-lcc.ARPA (5.51/) id AA17701; Thu, 5 Mar 87 10:24:51 PST Received: by well.UUCP (4.12/4.7) id AA04201; Thu, 5 Mar 87 09:24:10 pst Date: Thu, 5 Mar 87 09:24:10 pst From: well!slf@lll-lcc.ARPA (Sharon Lynne Fisher) Message-Id: <8703051724.AA04201@well.UUCP> Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Summary: Expires: References: <8703041526.AA03414@ucbvax.Berkeley.EDU> Sender: Reply-To: well!slf@lll-lcc.ARPA (Sharon Lynne Fisher) Followup-To: Distribution: world Organization: Whole Earth 'Lectronic Link, Sausalito, CA Keywords: Apparently-To: tcp-ip@sri-nic.arpa For those of us who ahve entered this discussion late, what is GOSIP? How can a person obtain a copy of this infamous document? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703051246.AA14918%40gjetost.wisc.edu] <1987030502462400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: solomon@GJETOST.WISC.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Telnet Option Negotiation to IBMish Hosts Message-ID: <8703051246.AA14918@gjetost.wisc.edu> Date: Thu, 5-Mar-87 07:46:24 EST Article-I.D.: gjetost.8703051246.AA14918 Posted: Thu Mar 5 07:46:24 1987 Date-Received: Fri, 6-Mar-87 23:57:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 132 Approved: tcp-ip@sri-nic.arpa OK, here's the "Wisconsin view" on the 3270/telnet controversy. Sorry I took so long to respond, but I somehow got deleted from the TCP/IP list. I think I tracked down all the relevant mail on this subject from the list, but if I seem to be ignoring some past message, it may be because I missed it. I used to think that no new rfc was needed, since the existing telnet specs (especially rfc885 and rfc930) told the whole story. I now think that while a new spec may not be needed, an rfc might be called for just to make things clearer. I pretty much agree with Bob Braden about what SHOULD happen: > The terminal type negotiation and the EOR negotiations may occur > in any order. If EOR has been negotiated in both directions and if a 3278 > terminal type has been negotiated, THEN negotiation of BINARY will cause > the mode to change from NVT to full-screen-3278. Note that the BINARY > is negotiated separately in each direction, which correctly synchronizes > the mode change (any NVT data in the pipeline in each direction should > be correctly handled). The remainder of this (rather long) message contains my views about the philosophy of telnet, some of the practical problems in implementing it, and some explanation of why Wiscnet behaves the way it does. Telnet assumes that there is a set of "options". Corresponding to each option is a pair of Boolean variables, one for each end of the connection. The telnet spec (rfc854) gives a protocol for changing any one of these Boolean variables. It gives no information about what they may mean. The individual options are described in separate rfc's, some in more detail than others. Telnet also provides a "suboption" facility to send more complicated out-of-band information. Finally, telnet defines a "network virtual terminal" (NVT), which is a dumb teletype-like device that dictates the default syntax and semantics of data on the connection. Telnet has no facilities for tying together a package of options that are logically interdependent. The general strategy is to hold back data during a flurry of option negotiations until everything settles down, so that you don't send anything while the options are in an inconsistent state. The ASCII option is misnamed. It should be called "NVT", since it means that data sent (from an end where ASCII is "true") will conform to NVT conventions. The negation of ASCII is BINARY (perhaps "transparent" would be a better name), which means that the data is NOT assumed to have any particular telnet-defined structure. The 327x terminals have their own protocol, which is very unlike NVT. Therefore, it seems reasonable for two consenting telnet ends to exchange data in the "raw" 327x format. Other "bilateral" agreements could similarly be defined. The BINARY option almost, but not quite, fits the bill. There are two problems. First, the details of the protocol depend on the particular model of 327x terminal, and perhaps on other information, such as the type of controller and whether SNA is in use. Thus there has to be a way of exchanging terminal type information. The set of terminal types defined in rfc930 is small, but the intention is that this option negotiation be used to convey whatever information is necessary to set up whatever ad hoc protocol is desired. Berkeley's tn3270 always says "ibm3278-2". The 3270 emulator I wrote (included with the Wiscnet distribution), says 3278-2, -3, or -4 depending on the number of line on the screen (from termcap or from the tty driver on 4.3BSD UNIX systems). If the need arises, one can easily define other "terminal types" to describe SNA, or whatever. Second, the 327x protocol is a record-oriented rather than byte-stream protocol. There has to be a way of signaling the end of a record outside the set of 256 possible octets. (By the way, for the same reason, IMAGE mode in FTP is not adequate for transferring IBM files; the end of a record is not indicated by any of the 256 EBCDIC characters, but by out-of-band data. You have to use PAGE mode instead.) I originally suggested that we simply define an escape sequence IAC EOR (where EOR is some code distinct from WILL, WONT, etc) to mark the end of a record. Since this sequence could never legally occur according to the existing spec (even in BINARY mode!), it shouldn't cause any confusion. However, Jon Postel insisted that a telnet process shouldn't send IAC EOR without first getting permission via IAC DO EOR. Thus the general scheme is as follows: Consenting telnets use BINARY to agree that they will not use NVT, but rather their own private protocol agreed upon by bilateral negotiation. Before doing so, they have to establish the details of this bilateral protocol. Thus a telnet process may refuse BINARY if it feels adequate groundwork has not been laid out. In the present case, an acceptable terminal type and permission to use EOR are required. I can imagine similar variants of this scheme for other non-NVT protocols. Now for implementation problems. If you want to implement server telnet, you either have to modify every application so that it can talk to the telnet server rather than a terminal, or you need an operating-system facility for the server to masquerade as a terminal to another process. The latter facility is called a pseudo-tty (pty) in UNIX jargon; under VM, it's called "logical device support facility" (LDSF or ldev). Under LDSF, the information passed between the application and the server must be a 327x data stream. One of the parameters to the "initiate" LDSF call is the terminal type. Once the logical device is created, there is no way to change the terminal type. Thus the Wiscnet server tries to avoid creating the logical device as long as possible. If a telnet connection begins with an appropriate negotiation for BINARY mode, the server has all the necessary information. Otherwise, it creates the logical device with type "3278-2" and goes though the painful process of translating between that protocol and NVT. If any NVT data arrives before the terminal type is established, the server is forced to create a logical device, and so it must choose a terminal type. Subsequent attempts to go into BINARY mode are simply rejected. I suppose two enhancements are possible: First, if the other end sends some NVT data and then decides to advertise a terminal type that "just happens" to match the type chosen by the server, it should be possible to accept it. Second, the server could save up a "small" amount of NVT data before setting up the LDSF device, in hopes that the necessary info will soon arrive. Both are kludgy, but both might be very helpful in practice. A similar problem comes up in backing out of BINARY mode. Backing out of BINARY/3278-2 to NVT shouldn't be too hard in principle (simply a matter of programming :-). Backing out of some other 327x model would be a bit harder. Right now Wiscnet refuses to do either. Finally, I should discuss sequencing of negotiations. As I think I've made clear, the terminal type and EOR have to be settled before BINARY makes sense. The current Wiscnet code insists on EOR before terminal type. That's probably a bug. However, the Wiscnet code will also be willing to go into BINARY mode without first agreeing on EOR. That's a "feature"--really a historical curiosity (see the discussion above and the comment in the Wiscnet code), but it also conforms to the maxim, "be conservative in what you send and liberal in what you send". Telnet can understand IAC EOR perfectly well whether or not DO EOR has been established. Well Bob, can this longwinded discussion serve as a draft of the needed rfc, or should be rfc just be the single paragraph of yours that I quoted above? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703051926.AA27626%40csv.rpi.edu] <1987030504220000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <8703051926.AA27626@csv.rpi.edu> Date: Thu, 5-Mar-87 09:22:00 EST Article-I.D.: csv.8703051926.AA27626 Posted: Thu Mar 5 09:22:00 1987 Date-Received: Sun, 8-Mar-87 07:12:08 EST References: <1104.541891929@nrtc-gremlin.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Marshall-- Tell ya what, if you'll promise to agitate through your "OSINET" channels against the Applicability stuff I'll promise not to debate whether I got you on a technicality or a TKO. cheers, map P.S. I'm told John Heafner has left NBS; trust you know some other addressee there. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D.5-Mar-87.10:06:23.CERF] <1987030505060000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <[A.ISI.EDU].5-Mar-87.10:06:23.CERF> Date: Thu, 5-Mar-87 10:06:00 EST Article-I.D.: <[A.ISI.EDU].5-Mar-87.10:06:23.CERF> Posted: Thu Mar 5 10:06:00 1987 Date-Received: Fri, 6-Mar-87 23:29:36 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Mike, John has indeed left NBS and gone to some part of DEC - don't know which, but since John is on this distribution, maybe he will say, if he still reads his Internet mail. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030505060001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 5 Mar 87 07:08:33-PST Date: 5 Mar 1987 10:06-EST Sender: CERF@A.ISI.EDU Subject: Re: GOSIP From: CERF@A.ISI.EDU To: PADLIPSKY@A.ISI.EDU Cc: mrose@NRTC-GREMLIN.ARPA, postel@BEL.ISI.EDU Cc: TCP-IP@SRI-NIC.ARPA, Corrigan@SRI-NIC.ARPA Cc: Heafner@NBS-VMS.ARPA Message-ID: <[A.ISI.EDU] 5-Mar-87 10:06:23.CERF> In-Reply-To: The message of 5 Mar 1987 09:22:00 EST from Michael Padlipsky Mike, John has indeed left NBS and gone to some part of DEC - don't know which, but since John is on this distribution, maybe he will say, if he still reads his Internet mail. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703051640.AA06645%40braden.isi.edu] <1987030506400100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <8703051640.AA06645@braden.isi.edu> Date: Thu, 5-Mar-87 11:40:01 EST Article-I.D.: braden.8703051640.AA06645 Posted: Thu Mar 5 11:40:01 1987 Date-Received: Sat, 7-Mar-87 02:11:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Marshall, It would seem that the important issue is not whether you are right or wrong; either case seems to lead to the same conclusion, that the present wording in the GOSIP document is badly damaged and damaging. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703051744.AA00844%40ACC-SB-UNIX.ARPA] <1987030507443200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bryan@ACC-SB-UNIX.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8703051744.AA00844@ACC-SB-UNIX.ARPA> Date: Thu, 5-Mar-87 12:44:32 EST Article-I.D.: ACC-SB-U.8703051744.AA00844 Posted: Thu Mar 5 12:44:32 1987 Date-Received: Sat, 7-Mar-87 00:37:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 107 Approved: tcp-ip@sri-nic.arpa The confusion and indecision that is prevalent among those in government that write network specifications and RFQ's has come about over the last several years, first by all of the different companies and types of products that were offered, and now by the much touted new protocols. They are not aware that there are "standard" protocols in use now, in networks already in operation. Moreover they are not aware that the new ISO protocols have not been completed, and will not be ready for some time. ACC is a believer in ISO and has now spent significant resource on developing products for use in networks employing the new protocols. The customers are reluctant, and rightly so since there are few suppliers of similar products today. It is interesting to find out that network planners in Europe have grown tired of waiting for the release of software modeled on ISO and have begun to specify use of TCP/IP in commercial systems. If the government planners and spec writers embrace GOSIP as the rule today and not as a guideline for future improvements, we will be waiting a long time for network growth. Most of the press and the articles that are read by these planners talk as though ISO exists and is ready "off the shelf". From the report below, it is clearly evident that GOSIP may soon be interpreted as a directive, by those ignorant of technical reality. From COMPUTERWORLD 12 January, 1987, By Mitch Betts Feds Back OSI Standards Gaithersburg, MD - The U.S. Government, a user organization with a $16 billion information systems budget, is throwing its weight behind the Open Systems Interconnect (OSI) standards with a new contracting document that will require vendors to supply off-the-shelf networking systems that meet certain OSI standards. Federal agencies may now incorporate the Government OSI Procurement (GOSIP) specification in bid requests at their discretion, but eventually GOSIP will be a mandatory part of government contracts, according to Shirley M. Radack, coordinator of standards programs at the National Bureau of Standards institute for Computer Sciences and Technology. In addition to saving money and headaches by buying open systems, the government hopes to use its own clout to prod vendors into developing standard OSI products. OSI is the seven layer reference model for communications standards that has previously been established by the International Standards Organization. MAP/TOP-compatible According to the U.S. Government OSI Users Committee, GOSIP is compatible with the industry's Manufacturing Automation Protocol (MAP) and Technical Office Protocol (TOP) and will be updated as new OSI protocols are developed and approved. For starters, the government is adopting the File Transfer and Access Management (FTAM) standard for file transfer and the Message Handling Systems (X.400) standard for electronic mail as well as X.25 for wide-area networking and the Token Bus (IEEE 802.4) for local-area networking. "GOSIP addresses the need of the federal government to move immediately to multivendor interconnectivity without sacrificing essential functionality already implemented in critical networking systems," the GOSIP document said. It noted that the capabilities required by GOSIP "exist as standard products or are close enough to market that they can be proposed by vendors." In 1988 the government expects to adopt standards for document interchange, transaction processing and the token-ring local-area network, Standards for graphics, the exchange of financial and management data, videotext and data base updates are slated for 1989. An Integrated Services Digital Network (ISDN) standard for voice, data and video traffic is expected in 1990. The Dec.18 version of GOSIP is intended for use in procurements of new networks of mainframes and minicomputers through September 1989. The National Bureau of Standards plans to adopt it as a Federal Information Processing Standard later this year, and the General Services Administration plans to incorporate it into mandatory procurement rules, Radack said. "In the past, vendor-specific implementations of data communications protocols led to isolated domains of information, very difficult and expensive to bridge," the GOSIP document explained. "By implementing open systems, the government expects to realize significant savings through reducing duplicate circuits and wiring, training, custom software, workstations and custom hardware interfaces." However, some observers said the government faces a big challenge in standardizing on OSI, given the fact that many existing networks depend on the Pentagon-developed Transmission Control Protocol/Internet Protocol and IBM's Systems Network Architecture. -----END---- Roland Bryan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030509050900> Received: from decwrl.dec.com by SRI-NIC.ARPA with TCP; Thu 5 Mar 87 17:18:12-PST Received: by decwrl.dec.com (5.54.3/4.7.34) id AA10106; Thu, 5 Mar 87 17:17:25 PST Received: by amdcad.AMD.COM (4.12/AMD/UUCP/2-22-1987) id AA27541; Thu, 5 Mar 87 17:05:09 pst Date: Thu, 5 Mar 87 17:05:09 pst From: amdcad!bandy@decwrl.DEC.COM (Andy Beals) Message-Id: <8703060105.AA27541@amdcad.AMD.COM> To: hedrick@topaz.rutgers.edu Subject: Re: Submission for mod-protocols-tcp-ip Newsgroups: mod.protocols.tcp-ip In-Reply-To: <8703031250.AA05275@topaz.rutgers.edu> Organization: Advanced Micro Devices, Sunnyvale, California Cc: tcp-ip@sri-nic.ARPA, phil@decwrl.DEC.COM >I don't know whether the Bridge products issue ICMP redirects or not. No, Bridge does not issue ICMP redirects. They implement no part of the ICMP protocol. (the first paragraph of RFC792 not withstanding) Their claim is that "until recently, ICMP was not completely described". They just came out with a new release for their GS/3 (release 11000) and claim that the next release will have full ICMP support. (due sometime during the summer?) From talking to them, it seems that they don't quite believe that they should support IP to the extent they support Xerox NS. Cheers, andy -- Andrew Scott Beals, {lll-crg,decwrl,allegra}!amdcad!bandy +1 408 749 3683 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [17145.541962925%40nrtc-gremlin.arpa] <1987030509510900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@NRTC-GREMLIN.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <17145.541962925@nrtc-gremlin.arpa> Date: Thu, 5-Mar-87 14:51:09 EST Article-I.D.: nrtc-gre.17145.541962925 Posted: Thu Mar 5 14:51:09 1987 Date-Received: Sat, 7-Mar-87 00:07:23 EST References: <8703051640.AA06645@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Yes, you are absolutely correct Bob. Tell 'ya what: Let's forget about my recollections of the subject and concentrate on the specification as published. That should be a much more productive use of our time. Sorry to have confused the list with this... /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703060207.AA00898%40nrl-csr.ARPA] <1987030516075200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kolacki@nrl-csr.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: MAILING LIST Message-ID: <8703060207.AA00898@nrl-csr.ARPA> Date: Thu, 5-Mar-87 21:07:52 EST Article-I.D.: nrl-csr.8703060207.AA00898 Posted: Thu Mar 5 21:07:52 1987 Date-Received: Sat, 7-Mar-87 02:44:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa Please put me on your mailing list. I'm currently reviewing the GOSIP document. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703060312.AA03752%40ngp.utexas.edu] <1987030517122500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mknox@NGP.UTEXAS.EDU (Margaret H. Knox) Newsgroups: mod.protocols.tcp-ip Subject: TCP retransmission header question Message-ID: <8703060312.AA03752@ngp.utexas.edu> Date: Thu, 5-Mar-87 22:12:25 EST Article-I.D.: ngp.8703060312.AA03752 Posted: Thu Mar 5 22:12:25 1987 Date-Received: Wed, 11-Mar-87 00:43:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa This is probably a simple question for most of the TCP hackers out there, but we cant agree on the information in the TCP standard. Case: A number of packets are sent and placed on the retransmission queue awaiting acknowledge. Then a packet is received acknowledging SOME of them, and also sending more data. We now send another packet, with a new acknowledge because of the additional data just received. Question: If it becomes necessary to resend the packets still on the retransmission queue, should the headers be updated to reflect the new acknowledge. The alternative is to send the packets exactly as they were sent originally. This has the interesting affect of causing us to send an acknowledge of a LOWER value than one just previously sent. Answer: ??? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703060401.AA25818%40bu-cs.bu.edu] <1987030518015400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: budd@BU-CS.BU.EDU (Philip Budne) Newsgroups: mod.protocols.tcp-ip Subject: IBMish (WISCNET) Telnet negotations Message-ID: <8703060401.AA25818@bu-cs.bu.edu> Date: Thu, 5-Mar-87 23:01:54 EST Article-I.D.: bu-cs.8703060401.AA25818 Posted: Thu Mar 5 23:01:54 1987 Date-Received: Sun, 8-Mar-87 00:47:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 55 Approved: tcp-ip@sri-nic.arpa What I find most upsetting about WISCNETs behavior is that it makes it impossible to use the terminal type subnegotion for what is was meant for: terminal types! 4.3 telnet and telnetd use the terminal type subnegotion, but if you try to use 4.3 tn3270 to connect to a 4.3 host you end up as an ibm-3277-2. We have a more recent version from Bekeley that will negotiate based on screen size. The problem is that the version of WISCNET we run sends DO TERMINAL before there is any indication that the client telnet is willing to do 327x emulation. This forces any tn3270-like program to assume the worst. IBM 327x emulation is not a simple (or unique) instance of the desire to transparently transmit binary data. Why isn't there an explicit (sub)negotiation for "DO 327x"? The reply could be WILL/WONT or the emulated 327x terminal type. I thought that EOR had been invented explicitly for this. But WISCNET negotiates EOR *AFTER* TERMINAL TYPE. oy gevalt! -Phil Here is a log of a conversation between a SUN running the most recent tn3270 we have from Berkely and our 3090, the faint of heart might wish to stop here. Connected to buacca.bu.edu. SENT do SUPPRESS GO AHEAD RCVD do TERMINAL TYPE (reply) SENT will TERMINAL TYPE (don't reply) RCVD wont SUPPRESS GO AHEAD (reply) SENT dont SUPPRESS GO AHEAD (reply) Received suboption Terminal type - request to send. Sent suboption Terminal type is IBM-3278-3 RCVD do END OF RECORD (reply) SENT will END OF RECORD (don't reply) RCVD will END OF RECORD (reply) SENT do END OF RECORD (reply) RCVD do BINARY (reply) SENT will BINARY (don't reply) RCVD will BINARY (reply) SENT do BINARY (reply) Unable to find entry for xterm in file /usr/etc/map3270 Unable to find entry for xterm in file /usr/etc/map3270 Using default key mappings. RCVD do BINARY (don't reply) RCVD will BINARY (don't reply) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703060512.AA25993%40flash.bellcore.com] <1987030519124200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM (Phil R. Karn) Newsgroups: mod.protocols.tcp-ip Subject: GOSIP vs TCP/IP Message-ID: <8703060512.AA25993@flash.bellcore.com> Date: Fri, 6-Mar-87 00:12:42 EST Article-I.D.: flash.8703060512.AA25993 Posted: Fri Mar 6 00:12:42 1987 Date-Received: Sun, 8-Mar-87 02:37:13 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 53 Approved: tcp-ip@sri-nic.arpa Indeed, one wonders if the computer public is at all aware of the fact that the Internet has been quietly doing what the ISO hawkers are only promising in big bold trade rag headlines. On the other hand, most vendors have certainly heard of TCP/IP, considering that most of them already sell it, so they have less of an excuse. I think there are other, darker forces at play here. Recent developments (or, more precisely, the lack of same) in the high definition TV standards game illustrate what I think is going on in our own field. It seems that over the past few years, certain Japanese companies have led the way by developing a complete line of compatible, working, high quality video components. You can buy their stuff off the shelf right now. At a recent international standards convention in Europe, the Americans and the Canadians enthusiastically supported the Japanese standard. After all, it works and it's available now. "Can't have that", the Europeans replied. "It'd be too hard to scan-convert back to our existing 625-line 50-Hz formats". And everybody went home without an international standard. Really now. And they said it with a straight face. This has to be about the thinnest technical excuse anyone has ever invented. The *real* reason (and this was openly stated in a EUROPEAN trade journal editorial) is that the European manufacturers deeply resent the Japanese head start into the high definition TV business. There is just no way they are going to approve anybody else's standard, regardless of how good it is technically or whether it's good for the users or not. It'd be bad for business. To the European vendors, I am truly sorry that the Americans got a head start by inventing TCP/IP and being the first to build big, operational internetworks in which the common carriers ("PTTs") are only minor subcomponents. To the American vendors of protocol software, I am truly sorry that so many public domain implementations of TCP/IP are out there stealing your sales. To those well-meaning souls in the Federal government and elsewhere who naively trust vendor groups and standards organizations to know what's best for your networking needs: take a look at the prices they're charging for the few ISO packages out there. After you've put your eyeballs back into your head, kick out the salesman and take a good close look at just what these slickly advertised protocols will do for you (as distinguished from your vendor's stock price). Then decide if you want to throw everything away and start over just so you can use the magic phrase "ISO compatible" to describe your network. TCP/IP is uniquely successful among communications standards because it was one of the very few ever designed by the USERS (who just want to get their work done as efficiently and as cheaply as possible) instead of the VENDORS (who want to make as much money as possible, an entirely different goal). What's good for General Motors may sometimes be good for the country, but in the protocol standards game it's a different story. Michael Padlipsky was right on target on this one. Only the most hopelessly naive user succumbs to the "Illusion of Vendor Support." These are obviously my own personal opinions only. Phil Karn ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030521390000> Mail-From: STJOHNS created at 6-Mar-87 05:39:53 Date: 6 Mar 1987 05:39-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Malformed mail header? Subject: [kolacki@nrl-csr (Bob Kolacki): MAILING LIST] From: STJOHNS@SRI-NIC.ARPA To: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA] 6-Mar-87 05:39:15.STJOHNS> Hmm... according to the host table, thios enclosed message came from a VAX7/50 running UNIX. Doesn't sendmail (or whatever it is) do the translation of nicnames into primary names? I mention this due to the forthcoming removal of nicnames from the host table. Mike Begin forwarded message Received: from MIT-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Fri 6 Mar 87 04:25:45-PST from SRI-NIC.ARPA by MIT-MULTICS.ARPA TCP; 06-Mar-1987 07:19:25-est from nrl-csr.ARPA by SRI-NIC.ARPA with TCP; Thu 5 Mar 87 18:06:26-PST Date: Thu, 5 Mar 87 21:07:52 est From: kolacki@nrl-csr (Bob Kolacki) To: tcp-ip@sri-nic Subject: MAILING LIST Return-Path: <@MIT-MULTICS.ARPA:tcp-ip-RELAY@SRI-NIC.ARPA> Message-ID: <8703060207.AA00898@nrl-csr.ARPA> Please put me on your mailing list. I'm currently reviewing the GOSIP document. -------------------- End forwarded message ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MDC-WBD-B02YS%40OFFICE-1] <1987030522020000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: WBD.MDC@OFFICE-1.ARPA (William Daul / McDonnell-Douglas / APD-ASD) Newsgroups: mod.protocols.tcp-ip Subject: US GOVERNMENT OPEN SYSTEMS PROCUREMENT (Open Systems Communication - Feb. 1987, pg. 4) Message-ID: Date: Fri, 6-Mar-87 03:02:00 EST Article-I.D.: OFFICE-1.MDC-WBD-B02YS Posted: Fri Mar 6 03:02:00 1987 Date-Received: Sun, 8-Mar-87 04:06:59 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 89 Approved: tcp-ip@sri-nic.arpa The US Government Open Systems Interconnection User's Committee, which was established by the National Bureau of Standards, is preparing a standard for the procurement of OSI products by Federal Agencies in the US. The draft of this standard, Government Open Systems Interconnection Procurement (GOSIP) Specification for the Fiscal Years 1987 and 1988, is currently being reviewed by government and industry. The purpose of the Government OSI User's Committee is to develop and maintain a Federal Government procurement specification for open systems computer network products. As such, the specification supports the Office of Management and Budget's (OMB) pending policy, "United States Government Computer-Communications Architecture Policy". It is expected that the Administrator of the General Services Administration (GSA) will provide for the implementation of OSI according to the GOSIP specification. The NBS will issue this specification as a Federal Information Processing Standard (FIPS), and the National Communications System (NCS) will issue GOSIP as a Federal Standard. Organizations contributing to the development of the GOSIP specification are as follows: Dept. of Agriculture Dept. of Commerce Dept. of Defense Dept. of Energy Environmental Protection Agency General Services Administration Health and Human Services Dept. of Interior Dept. of Housing and Urban Development Dept. of Justice Labor NASA NSF OMB Dept. of Transporation Dept. of Treasury National Communitations System This specification is based on agreements reached at the NBS workshop for Implementors of OSI. GOSIP is consistent with, and complementary to, the Manufacturing Automation Protocol (MAP) and the Technical and Office Protocols (TOP) specifications developed by industry. GOSIP addresses the need of the Federal Government to move immediately to multivendor interconnectivity without sacrificing essential functionality already implemented in critical networking systems. All capabilities described in the specifications exist as standard products or are close enough to market that they can be implemented by vendors. GOSIP is to be used by all Federal Government agencies when procuring data processing systems of services and communications systems or services. It is mandatory for all new network implementations and should be carefully considered for retrofits. For a period of two years, agencies are permitted to procure alternative interoperable protocols, by they must provide a mechanism for those protocols to interoperate with OSI protocols as well. GOSIP addresses communication and interoperation among end-systems and intermediate systems. It provides specific peer-level, process-to-process, and terminal access functionality between computer systems within and across government agencies. The primary source of protocol specifications used in GOSIP is the Implementation Agreements of Open Systems Interconnection Protocols, which is maintained by the NBS Workshop. Because the Workstation Agreements continue to evolve, GOSIP augments protocol and service specifications for the following sources, ISO Standards and CCITT Recommendations ISO Draft International Standards ISO Draft Proposed Standards Working papers within international standards bodies GOSIP's use of open systems standards minimizes the number of standards used while satisfying the diverse application encompassing government-wide needs. The specification provides a range of protocol choices at different layers. A subset of these protocols may adequately satisfy an individual acquisition requirement, and may be used. At least on lower layer technology must be used (i.e., CSMA/CD, Token Bus, or X.25). The following protocols are mandatory: the connectionless internetwork protocol, Transport Class 4, and Session Layer protocol. Transport Class 0 is to be used only in conjunction with public network messaging. The Presentation Layer protocol and Common Application Service Elements (CASE) are required for all applications except messaging. At least on Application Layer protocol is required to support the intended application. That is, if messaging is required, MHS will be specified; if file transfer is required, FTAM will be specified. The GOSIP specification will be revised annually and will be corrected or amended as needed. The current draft of GOSIP will apply to fiscal years 1987 and 1988. OMNICOM subscribers can obtain a cop[y of the draft (Dec. 18, 1987) GOSIP specification as an OMNICOM File. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).6-Mar-87.06:38:51.VAX.DARPA.MIL] <1987030601385100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL (Dennis G. Perry) Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: Date: Fri, 6-Mar-87 06:38:51 EST Article-I.D.: Posted: Fri Mar 6 06:38:51 1987 Date-Received: Sun, 8-Mar-87 05:34:45 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa I think Rose has a fair interpretation of the GOSIP document, at least according to my understanding of the discussion at the last PSSG meeting. On the other hand, please do get your constructive comments in to Corrigan so that they may properly be relected in the document. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030601385101> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Fri 6 Mar 87 03:40:20-PST Posted-Date: Fri 6 Mar 87 06:38:51-EST Received: by vax.darpa.mil (5.54/5.51) id AA03062; Fri, 6 Mar 87 06:38:55 EST Date: Fri 6 Mar 87 06:38:51-EST From: Dennis G. Perry Subject: Re: GOSIP To: mrose@nrtc-gremlin.arpa Cc: PADLIPSKY@a.isi.edu, postel@bel.isi.edu, TCP-IP@sri-nic.arpa, Corrigan@sri-nic.arpa, Heafner@nbs-vms.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "Marshall Rose " of Tue, 03 Mar 87 07:01:13 -0800 I think Rose has a fair interpretation of the GOSIP document, at least according to my understanding of the discussion at the last PSSG meeting. On the other hand, please do get your constructive comments in to Corrigan so that they may properly be relected in the document. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030601420000> Received: from amadeus.stanford.edu by SRI-NIC.ARPA with TCP; Fri 6 Mar 87 09:40:44-PST Received: by amadeus.stanford.edu; Fri, 6 Mar 87 09:42:02 PST Date: 6 Mar 1987 0942-PST (Friday) From: Glenn Trewitt To: tcp-ip@sri-nic.arpa, Gateway Monitors Cc: Subject: TCP/IP Interoperability Conference -- Birds of a Feather Session This is to announce a birds-of-a-feather session at the TCP/IP conference in Montery, March 16-19. Here is the abstract. Birds of a Feather Session TCP/IP Interoperability Conference Tuesday, March 17, 7-9 pm ISSUES IN GATEWAY MONITORING We will discuss current work that is aimed at developing standard monitoring protocols for the Internet. The scope of this standardization is not limited to gateways, but includes other entities operating at the IP layer. There are many issues here: what data to monitor, data representation, how to request specific data, security, and transport protocols. Security and transport protocols have been discussed at some length on the gateway monitoring mailing list (gwmon-request@sh.cs.net) organized by Craig Partridge. This session will primarily focus on the data-related issues mentioned above. The session will start with several 5-minute presentations from people who are working in this area, describing what they are doing and what their needs are. Following the presentations, we will have round-robin discussion until we stop. If you are interested in giving a presentation, please contact Glenn Trewitt, trewitt@amadeus.stanford.edu. (You will have 5 minutes to talk, followed by questions. There should be an overhead projector available, so you can bring along a slide or two. Also feel free to bring along handouts for people to read.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BSRI-NIC.ARPA%5D.6-Mar-87.05:39:15.STJOHNS] <1987030603390000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Malformed mail header? Message-ID: <[SRI-NIC.ARPA].6-Mar-87.05:39:15.STJOHNS> Date: Fri, 6-Mar-87 08:39:00 EST Article-I.D.: <[SRI-NIC.ARPA].6-Mar-87.05:39:15.STJOHNS> Posted: Fri Mar 6 08:39:00 1987 Date-Received: Sun, 8-Mar-87 08:57:35 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Hmm... according to the host table, thios enclosed message came from a VAX7/50 running UNIX. Doesn't sendmail (or whatever it is) do the translation of nicnames into primary names? I mention this due to the forthcoming removal of nicnames from the host table. Mike Begin forwarded message Received: from MIT-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Fri 6 Mar 87 04:25:45-PST from SRI-NIC.ARPA by MIT-MULTICS.ARPA TCP; 06-Mar-1987 07:19:25-est from nrl-csr.ARPA by SRI-NIC.ARPA with TCP; Thu 5 Mar 87 18:06:26-PST Date: Thu, 5 Mar 87 21:07:52 est From: kolacki@nrl-csr (Bob Kolacki) To: tcp-ip@sri-nic Subject: MAILING LIST Return-Path: <@MIT-MULTICS.ARPA:tcp-ip-RELAY@SRI-NIC.ARPA> Message-ID: <8703060207.AA00898@nrl-csr.ARPA> Please put me on your mailing list. I'm currently reviewing the GOSIP document. -------------------- End forwarded message ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703061755.AA19504%40ucbvax.Berkeley.EDU] <1987030607420000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: trewitt@AMADEUS.STANFORD.EDU (Glenn Trewitt) Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP Interoperability Conference -- Birds of a Feather Session Message-ID: <8703061755.AA19504@ucbvax.Berkeley.EDU> Date: Fri, 6-Mar-87 12:42:00 EST Article-I.D.: ucbvax.8703061755.AA19504 Posted: Fri Mar 6 12:42:00 1987 Date-Received: Sun, 8-Mar-87 06:35:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa This is to announce a birds-of-a-feather session at the TCP/IP conference in Montery, March 16-19. Here is the abstract. Birds of a Feather Session TCP/IP Interoperability Conference Tuesday, March 17, 7-9 pm ISSUES IN GATEWAY MONITORING We will discuss current work that is aimed at developing standard monitoring protocols for the Internet. The scope of this standardization is not limited to gateways, but includes other entities operating at the IP layer. There are many issues here: what data to monitor, data representation, how to request specific data, security, and transport protocols. Security and transport protocols have been discussed at some length on the gateway monitoring mailing list (gwmon-request@sh.cs.net) organized by Craig Partridge. This session will primarily focus on the data-related issues mentioned above. The session will start with several 5-minute presentations from people who are working in this area, describing what they are doing and what their needs are. Following the presentations, we will have round-robin discussion until we stop. If you are interested in giving a presentation, please contact Glenn Trewitt, trewitt@amadeus.stanford.edu. (You will have 5 minutes to talk, followed by questions. There should be an overhead projector available, so you can bring along a slide or two. Also feel free to bring along handouts for people to read.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703062243.AA10033%40well.UUCP] <1987030612434000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: slf@lll-lcc.ARPA@well.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: US GOVERNMENT OPEN SYSTEMS PROCUREMENT (Open Systems Communication - Feb. 1987, pg. 4) Message-ID: <8703062243.AA10033@well.UUCP> Date: Fri, 6-Mar-87 17:43:40 EST Article-I.D.: well.8703062243.AA10033 Posted: Fri Mar 6 17:43:40 1987 Date-Received: Sun, 8-Mar-87 10:28:44 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa Thank you so much for the very detailed explanation. How does one go about getting a copy of this document? And is tha antipathy on Usenet universal, or do most people think it's ok? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703070522.AA25917%40ames-nas.arpa] <1987030619225800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ari@AMES-NAS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: add to mailing list Message-ID: <8703070522.AA25917@ames-nas.arpa> Date: Sat, 7-Mar-87 00:22:58 EST Article-I.D.: ames-nas.8703070522.AA25917 Posted: Sat Mar 7 00:22:58 1987 Date-Received: Sun, 8-Mar-87 11:40:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Please add me to the mod.protocols.tcp-ip list. ari@ames-nas.arpa Thank you, Ari Ollikainen General Electric Company NASA Ames Research Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030706113400> Received: from ucbarpa.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sat 7 Mar 87 22:33:49-PST Received: by ucbarpa.Berkeley.EDU (5.57/1.23) id AA09652; Sat, 7 Mar 87 14:11:34 PST Date: Sat, 7 Mar 87 14:11:34 PST From: jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) Message-Id: <8703072211.AA09652@ucbarpa.Berkeley.EDU> To: tcp-ip@sri-nic.arpa Subject: Re: Malformed mail header? Newsgroups: mod.protocols.tcp-ip In-Reply-To: <[SRI-NIC.ARPA].6-Mar-87.05:39:15.STJOHNS> Organization: Experimental Computer Facility (XCF), UC Berkeley Doesn't sendmail (or whatever it is) do the translation of nicnames into primary names? *sigh* it does, only if you wave the magic wand in the config file. "it should be fixed" /jordan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703080733.AA22325%40ucbvax.Berkeley.EDU] <1987030708510000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BEAME@MCMASTER.BITNET Newsgroups: mod.protocols.tcp-ip Subject: CS/100 Version 12010 software. Message-ID: <8703080733.AA22325@ucbvax.Berkeley.EDU> Date: Sat, 7-Mar-87 13:51:00 EST Article-I.D.: ucbvax.8703080733.AA22325 Posted: Sat Mar 7 13:51:00 1987 Date-Received: Mon, 9-Mar-87 03:13:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 57 Approved: tcp-ip@sri-nic.arpa Hello CS100 users, We installed Version 12010 of the bridge CS/100 TCP/IP software a few weeks ago. I was wondering if anyone else has seen the problem illustrated below ? It seems that the CS/100 is sending invalid IP and TCP packets. This only occurs on sustained output. The invalid packet is retransmitted several times in it's invalid state. After a while, about 1 minute, the packet is retransmitted correctly. CFB/IN - packets arriving at the PC from the CS/100 CFB/OUT - packets from the PC to the CS/100 287 : CFB/IN ether: IP 08-00-02-00-51-23 -> 02-60-8c-19-48-15 88 14755.966 3.297 ip: TCP 01.00000b -> 01.004815 tcp: TELNET -> 7438 ACK tcp: seq: 322186923 ack: 32 win: 104 len: 30 0: 50 1d 2c 7c 3c 50 4c 1d 2c 7d 3c 4d 4f 1d 2c 7c |P.,| 08-00-02-00-51-23 64 14762.347 6.381 ip: TCP 01.004815 -> 01.00000b tcp: 7438 -> TELNET ACK tcp: seq: 32 ack: 322186953 win: 82 len: 0 289 : CFB/IN ether: IP 08-00-02-00-51-23 -> 02-60-8c-19-48-15 80 14799.065 36.718 ip: TCP 01.00000b -> 01.004815 tcp: TELNET -> 7438 PUSH ACK tcp: seq: 322186953 ack: 32 win: 104 len: 22 0: 4f 50 7c 50 50 7b 50 50 4f 7a 4f 4f 4e 4e 4d 7b |OP|PP{PPOzOONNM{| 16: 4d 4d 7c 4c 1d 2c |MM|L., | 290 : CFB/OUT ether: IP 02-60-8c-19-48-15 -> 08-00-02-00-51-23 64 14801.970 2.905 ip: TCP 01.004815 -> 01.00000b tcp: 7438 -> TELNET ACK tcp: seq: 32 ack: 322186975 win: 82 len: 0 291 : CFB/IN ether: IP 08-00-02-00-51-23 -> 02-60-8c-19-48-15 122 14820.583 18.613 ip: TCP 01.00000b -> 01.004815 ip: BAD LENGTH: IHL=20, TL=122, PKT=122 tcp: TELNET -> 7438 ACK tcp: seq: 322186975 ack: 32 win: 104 len: 82 tcp: CKSUM ERROR: received=ac3b, calculated=82dd 0: 7b 3c 4b 4e 1d 2c 7c 3c 4e 4b 1d 2c 7d 3c 4b 4e |{ Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Sat 7 Mar 87 23:16:18-PST Received: from MCMASTER.BITNET by wiscvm.wisc.edu on 03/07/87 at 12:51:19 CST Date: Sat, 7 Mar 87 13:51 EST From: Subject: CS/100 Version 12010 software. To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, BEAME Hello CS100 users, We installed Version 12010 of the bridge CS/100 TCP/IP software a few weeks ago. I was wondering if anyone else has seen the problem illustrated below ? It seems that the CS/100 is sending invalid IP and TCP packets. This only occurs on sustained output. The invalid packet is retransmitted several times in it's invalid state. After a while, about 1 minute, the packet is retransmitted correctly. CFB/IN - packets arriving at the PC from the CS/100 CFB/OUT - packets from the PC to the CS/100 287 : CFB/IN ether: IP 08-00-02-00-51-23 -> 02-60-8c-19-48-15 88 14755.966 3.297 ip: TCP 01.00000b -> 01.004815 tcp: TELNET -> 7438 ACK tcp: seq: 322186923 ack: 32 win: 104 len: 30 0: 50 1d 2c 7c 3c 50 4c 1d 2c 7d 3c 4d 4f 1d 2c 7c |P.,| 08-00-02-00-51-23 64 14762.347 6.381 ip: TCP 01.004815 -> 01.00000b tcp: 7438 -> TELNET ACK tcp: seq: 32 ack: 322186953 win: 82 len: 0 289 : CFB/IN ether: IP 08-00-02-00-51-23 -> 02-60-8c-19-48-15 80 14799.065 36.718 ip: TCP 01.00000b -> 01.004815 tcp: TELNET -> 7438 PUSH ACK tcp: seq: 322186953 ack: 32 win: 104 len: 22 0: 4f 50 7c 50 50 7b 50 50 4f 7a 4f 4f 4e 4e 4d 7b |OP|PP{PPOzOONNM{| 16: 4d 4d 7c 4c 1d 2c |MM|L., | 290 : CFB/OUT ether: IP 02-60-8c-19-48-15 -> 08-00-02-00-51-23 64 14801.970 2.905 ip: TCP 01.004815 -> 01.00000b tcp: 7438 -> TELNET ACK tcp: seq: 32 ack: 322186975 win: 82 len: 0 291 : CFB/IN ether: IP 08-00-02-00-51-23 -> 02-60-8c-19-48-15 122 14820.583 18.613 ip: TCP 01.00000b -> 01.004815 ip: BAD LENGTH: IHL=20, TL=122, PKT=122 tcp: TELNET -> 7438 ACK tcp: seq: 322186975 ack: 32 win: 104 len: 82 tcp: CKSUM ERROR: received=ac3b, calculated=82dd 0: 7b 3c 4b 4e 1d 2c 7c 3c 4e 4b 1d 2c 7d 3c 4b 4e |{ Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: doug@UXC.CSO.UIUC.EDU (Doug Gilmore) Newsgroups: mod.protocols.tcp-ip Subject: Cheap Gateway? Message-ID: <8703080728.AA03629@uxc.cso.uiuc.edu> Date: Sun, 8-Mar-87 02:28:41 EST Article-I.D.: uxc.8703080728.AA03629 Posted: Sun Mar 8 02:28:41 1987 Date-Received: Mon, 9-Mar-87 03:41:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa Though I don't have time to investigate this at the moment, I think its worth noting. As you may have learned from other messages I have sent on the net, I have ported 4.3BSD to the IBM PC-AT. Though the port is far from complete, the network code is fairly solid, thus it would not take too much effort to build reliable gateway machines using this code. In my earlier message, I neglected to mention that kernel has a resident debugger that allows one single step and set breakpoints in the kernel (the user interface is special version of adb that runs on a VAX that communicate with the resident debugger via a serial line). Thus the debugging environment is quite reasonable. Also it may be relatively easy to port the BRL Gateway to the PC-AT using the 4.3BSD code as a basis -- again the kernel debugger would prove very useful here. Send me mail if you would like more information. Doug Gilmore doug@uiucux, doug@uxc.cso.uiuc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12284810947.8.MRC%40PANDA] <1987030810020100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC%PANDA@SUMEX-AIM.STANFORD.EDU (Mark Crispin) Newsgroups: mod.protocols.tcp-ip Subject: ISO controversy Message-ID: <12284810947.8.MRC@PANDA> Date: Sun, 8-Mar-87 15:02:01 EST Article-I.D.: PANDA.12284810947.8.MRC Posted: Sun Mar 8 15:02:01 1987 Date-Received: Mon, 9-Mar-87 04:09:27 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa The single thing about the whole ISO controversy that irritates me the most is the apparent glee in which the ISO groupies (no, I don't mean you, Marshall!) are shoving this mess down our throats. I have heard (and read) truly incredible statements; certain individuals are evidentally getting quite a kick over the trauma the entire DoD Internet will have to go through to migrate to ISO. This is apparently our punishment for developing an internetwork without waiting for ISO to come through. A secondary source of annoyance to me is the lie that various vendors are going to jump in and offer ISO support. The vendor of TOPS-20 isn't going to implement it. Some poor schmuck (probably me) will have to do it. I have this nasty hunch that my friends the Multics hackers will be in the same situation. At least we'll have guaranteed employment for a long time :-). I thought the original intent of the ISO migration issue was to migrate to ISO *only* when it is reasonable to do so. Any migration now is going to cost the US taxpayers BIG bucks. In case the paper- pushers haven't been looking lately, us hackers no longer sell our services cheaply. Has ANYONE done an economic analysis of the impact of an ISO migration on the DoD Internet? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703082116.AA02962%40spam.istc.sri.com] <1987030811345300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jmainini@SPAM.ISTC.SRI.COM (John Mainini) Newsgroups: mod.protocols.tcp-ip Subject: Re: Cheap Gateway? Message-ID: <8703082116.AA02962@spam.istc.sri.com> Date: Sun, 8-Mar-87 16:34:53 EST Article-I.D.: spam.8703082116.AA02962 Posted: Sun Mar 8 16:34:53 1987 Date-Received: Mon, 9-Mar-87 04:09:50 EST References: <8703080728.AA03629@uxc.cso.uiuc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Doug, I have an associate interested in using a PC AT as a gateway between XNS and 3PLUS. I've been told the 2 protocols are very similiar, and personally I can't imagine what 3Com was thinking about when they didn't follow an established standard. Any ideas? Thanks in advance...John Mainini. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703081837.a017969%40Huey.UDEL.EDU] <1987030813372900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: ISO controversy Message-ID: <8703081837.a017969@Huey.UDEL.EDU> Date: Sun, 8-Mar-87 18:37:29 EST Article-I.D.: Huey.8703081837.a017969 Posted: Sun Mar 8 18:37:29 1987 Date-Received: Mon, 9-Mar-87 18:48:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Mark, The gloom spreading on this list about the apparent intent of ISO to overtake and destroy TCP/IP may be premature. When the IAB was briefed on GOSIP recently, it was understood that GOSIP would serve as the guide to selecting conforming ISO protocols, which eventually would be required of all new procurements, in much the same fashion as MAP/TOP. However, there was no explicit requirement that TCP/IP could not be operated and procured indefinately in addition to ISO protocols, just that every procurement must include ISO, even if it isn't actually used. From my own perspective, which I suspect is similar to that of many other players in this band, I am working as hard as I can to assist in the development of an Internet supporting both IP and ISO Connectionless datagrams. Thus, the system could be used for both protocol suites in much the same fashion that DDN Basic and Standard X.25 protocols are used now on ARPANET/MILNET. Then, if our much beloved protocols deserve to die in the long run, they can be accorded a funeral with honor. It is easy to ignite discourse on both sides of the ISO-TCP/IP issue, as seen recently in the newsprint both on and off this list. If in fact the wrong impression was gathered at the IAB briefing and something more sinister is afoot, it would be well to resolve the issue quickly, perhaps in the nature of a DDN Management Bulletin. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703090451.AA06401%40opal.Berkeley.Edu] <1987030818500000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Telnet Option Negotiation to IBMish Hosts Message-ID: <8703090451.AA06401@opal.Berkeley.Edu> Date: Sun, 8-Mar-87 23:50:00 EST Article-I.D.: opal.8703090451.AA06401 Posted: Sun Mar 8 23:50:00 1987 Date-Received: Mon, 9-Mar-87 19:36:48 EST References: <8703051246.AA14918@gjetost.wisc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 56 Approved: tcp-ip@sri-nic.arpa All, First, as to Philip Budne's complaint about 3270 negotiation making it hard to pass the REAL terminal type across the telnet connection - true. But, you have to think about where this all came from. The original intent was that real, live, ibm 327x's, when initiating telnet from their real, live ibm host, should be able to talk to other ibm hosts in a "native" fashion. No one should complain about this - we let vt241 users get their vt241's connected in "native" fashion when talking between two Vax Unix systems. However, the people at Wisconsin, Rice, Berkeley, Yorktown labs, Cornell, and who knows where else have realized that "hey, we can do that from Unix/ms-dos/macintosh-land, too!" Then, there IS a problem. Maybe what we need is "do terminal-type" and also "do charlatan-terminal-type". Anyway, the point is that it WOULD be convenient if we knew we were trying for 3270 emulation; or we could pass both a series of 3270 types and of "real" terminal types. Say you are connecting to a system (any old system) from a PC. The system may have a "preferred" terminal type (VT241, say), and the PC may have a few emulation modes (adm3a, vt100, tvi950, say). So, the system keeps says "send terminal type", and the PC sends them all, and finally indicates end-of-file with "unknown". Now, we have just "lost", since the system might just wish it had been willing to take the best of what had been offered at the time (maybe vt100). This is something like "the price is right" (TV show, for the uncultured). "You may now take this vt100 and run with it, OR you may toss it away in the hopes that what lies hidden behind that door may be better for you". In fact, it may be more complicated than that. Still, I don't think so. So, maybe the ability to "see the list again" would allow for things to work. If so, then the server could see the whole list, keep track of "what seemed best", and then go back and ask for that (so, why not "send terminal LIST", and "SET terminal type"?). (The point is, right, that we are TRYING to learn; not that "we made a mistake!".) As to Marvin Solomon's comments, I doubt I can add much. I do believe that the server could buffer some data, waiting for the end of the terminal type/eor/binary negotiations to happen before committing to either NVT or 3270 mode. The server is probably in error in not accepting even some of the negotiation out of order (but, it isn't the only server with this bug). The bottom line in the Wiscnet case is, probably, people to do the various "small" things. To my knowledge, Wisconsin is no longer getting any IBM money to support (let alone enhance) Wiscnet. I think an RFC would be nice. I think, however, that maybe it needs to address a fairly large amount of issues. Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703092033.AA16134%40ucbvax.Berkeley.EDU] <1987030905240000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NS-DDN@DDN2.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <8703092033.AA16134@ucbvax.Berkeley.EDU> Date: Mon, 9-Mar-87 10:24:00 EST Article-I.D.: ucbvax.8703092033.AA16134 Posted: Mon Mar 9 10:24:00 1987 Date-Received: Tue, 10-Mar-87 05:21:57 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa I am compelled to respond to what I perceive is a rather low opinion of protocol vendors (which would include me, I guess). Granted, it's caveat emptor out there, and the low opinion is deserved IN GENERAL. But there are some vendors who are not money-grubbing capitalists to the extent that customer dissatisfaction is irrelevant. Indeed, all vendors implicitly understand this truth about any marketplace to some degree. The ones who lose sight of the fact that customers buy data flowing between their computers (not software) reap the inevitable consequences. My experience would indicate that a significant number of nodes don't want to employ network protocol experts. They would much rather find a cradle-to-grave network solution (sorry, I couldn't resist) that they can entrust with their data comm requirements. It's easier for managers to beat on one vendor than on one or more employees and one or more vendors. Yes, there is public domain software, but there are learning curves and other hidden costs associated with it, and you still need the hardware. The theory is that more than one vendor springs up to provide these services, each with approximately the same savoir faire and customer commitment. The choices available to the customer cause prices to be competitive. It's lack of alternatives which cause customer gouging. Believe it or not, we do have satisfied customers. And these are obviously my own personal opinions only, too. Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030905240001> Received: from ddn2 by SRI-NIC.ARPA with TCP; Mon 9 Mar 87 12:29:27-PST Date: 9 Mar 87 10:24 EST From: NS-DDN @ DDN2 Subject: Re: GOSIP vs TCP/IP To: karn @ flash.bellcore.com CC: TCP-IP @ SRI-NIC.ARPA I am compelled to respond to what I perceive is a rather low opinion of protocol vendors (which would include me, I guess). Granted, it's caveat emptor out there, and the low opinion is deserved IN GENERAL. But there are some vendors who are not money-grubbing capitalists to the extent that customer dissatisfaction is irrelevant. Indeed, all vendors implicitly understand this truth about any marketplace to some degree. The ones who lose sight of the fact that customers buy data flowing between their computers (not software) reap the inevitable consequences. My experience would indicate that a significant number of nodes don't want to employ network protocol experts. They would much rather find a cradle-to-grave network solution (sorry, I couldn't resist) that they can entrust with their data comm requirements. It's easier for managers to beat on one vendor than on one or more employees and one or more vendors. Yes, there is public domain software, but there are learning curves and other hidden costs associated with it, and you still need the hardware. The theory is that more than one vendor springs up to provide these services, each with approximately the same savoir faire and customer commitment. The choices available to the customer cause prices to be competitive. It's lack of alternatives which cause customer gouging. Believe it or not, we do have satisfied customers. And these are obviously my own personal opinions only, too. Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703091547.AA11289%40ucbvax.Berkeley.EDU] <1987030905361200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ISO controversy Message-ID: <8703091547.AA11289@ucbvax.Berkeley.EDU> Date: Mon, 9-Mar-87 10:36:12 EST Article-I.D.: ucbvax.8703091547.AA11289 Posted: Mon Mar 9 10:36:12 1987 Date-Received: Tue, 10-Mar-87 04:26:15 EST References: <8703081837.a017969@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Dave-- You appear to have fallen into the same trap as Marshall Rose did (and as Dennis Perry did, as witness his recent msg to Marshall, copied to TCP-IP): what they say to you in a meeting is NOT binding; what they publish in a specification IS. See 1.4, Applicability (emphasis added): "GOSIP is to be USED by ALL Federal Government agencies..." and "FOR A PERIOD OF TWO YEARS, agencies are PERMITTED to procure alternative interoperble protocols...." Does that sound like "peaceful coexistence"? Rather than get all pedantic over how much havoc even an "i.e." instead of an "e.g." in a spec can cause, I'll settle for urging you to take whatever action you think appropriate to make the GOSIP spec come out with language supporting the position you heard rather than the position it currently takes. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030905361201> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 9 Mar 87 07:39:54-PST Date: 9 Mar 1987 10:36:12 EST Subject: Re: ISO controversy From: Michael Padlipsky To: Mills@LOUIE.UDEL.EDU cc: Mark Crispin , TCP-IP@SRI-NIC.ARPA In-Reply-To: <8703081837.a017969@Huey.UDEL.EDU> Dave-- You appear to have fallen into the same trap as Marshall Rose did (and as Dennis Perry did, as witness his recent msg to Marshall, copied to TCP-IP): what they say to you in a meeting is NOT binding; what they publish in a specification IS. See 1.4, Applicability (emphasis added): "GOSIP is to be USED by ALL Federal Government agencies..." and "FOR A PERIOD OF TWO YEARS, agencies are PERMITTED to procure alternative interoperble protocols...." Does that sound like "peaceful coexistence"? Rather than get all pedantic over how much havoc even an "i.e." instead of an "e.g." in a spec can cause, I'll settle for urging you to take whatever action you think appropriate to make the GOSIP spec come out with language supporting the position you heard rather than the position it currently takes. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703091741.AA06796%40topaz.Berkeley.Edu] <1987030907410700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ucdla%topaz.Berkeley.EDU@UCBVAX.BERKELEY.EDU (U.C. Div of Library Automa) Newsgroups: mod.protocols.tcp-ip Subject: gosip Message-ID: <8703091741.AA06796@topaz.Berkeley.Edu> Date: Mon, 9-Mar-87 12:41:07 EST Article-I.D.: topaz.8703091741.AA06796 Posted: Mon Mar 9 12:41:07 1987 Date-Received: Tue, 10-Mar-87 23:10:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 2 Approved: tcp-ip@sri-nic.arpa anyone know how to go about getting a copy of the gosip document? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703091845.AA14228%40ACC-SB-UNIX.ARPA] <1987030908453200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kzm@ACC-SB-UNIX.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <8703091845.AA14228@ACC-SB-UNIX.ARPA> Date: Mon, 9-Mar-87 13:45:32 EST Article-I.D.: ACC-SB-U.8703091845.AA14228 Posted: Mon Mar 9 13:45:32 1987 Date-Received: Tue, 10-Mar-87 05:24:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa Mike, I agree with your comments on the GOSIP spec, but not because I am opposed to ISO/OSI. On the contrary, on that future day when it replaces TCP/IP, I think it will be to the benefit of all, since it will encompass a larger audience. This is irrespective of the technical arguments of which is currently better. Here are a few more technical criticisms you might add to your paper : 1. [4.2.4] Packet Voice definitely requires use of other than Transport class 4. 2. [4.2.7.3] says that end systems connected to public data networks must implement TP0, but end systems connected to a private subnetwork must implement TP4 !! This is clearly not inter-operable. 3. [page 19] says "Note that the SNPA is interpreted as decimal digits, even though the AFI of 47 indicates a binary representation" !! Is this following the standards ?? 4. [top of page 20] specifies that the level-3 address must be encoded according to which Level-1 protocol is used (eg. 802.3 is given a NSAP Selector different from 802.4 when both have 802.2 above them). There is already a subnet-id included in the address. Why mix the layers like this ? Cheers, Keith McCloghrie ACC Columbia, Md. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987030922000000> Mail-From: STJOHNS created at 10-Mar-87 06:01:49 Date: 10 Mar 1987 06:00-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: GOSIP From: STJOHNS@SRI-NIC.ARPA To: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]10-Mar-87 06:00:24.STJOHNS> In-Reply-To: <8703091845.AA14228@ACC-SB-UNIX.ARPA> The following is sent on behalf of Mike Corrigan: _____________________________________________________________ A few comments: 1. GOSIP is the Government OSI Protocol Specification. It was prepared by a working group of the Government OSI Users Group, chaired by NBS, which was formed in reaction to what was a pending Office of Management and Budget announcement mandating use of OSI, without benefit of a specification. I don't know the exact status of the OMB announcemnet, but I believe it is still pending. 2. GOSIP is supposed to have been made available for FTPing from the NIC, but I'm not sure it is really there. I will find out and let you know. 3. A specification such as GOSIP consists of two key parts: what it is you hope to buy and when you have to buy it, or, the body of the spec and the applicability statement. If these don't match as well as they might, you get some very peculiar discussions. I think Mike P's discussion makes it clear that the GOSIP spec pulls no punches with respect to what ypu can currently acquire in OSI, and if the applicability statement were not part of the document, it would meet truth in labelling, full disclosure and informed consent concerns a lot better than we have ever managed in the ARPA/DOD protocol standards arena (for example, did anyone ask themselves about guidance or capabilities in the areas of performance, testing, and user interfaces for TCP/IP/SMTP/FTP/TELNET when reading Mike P's comments?). If we had waited for adequacy in these areas in DOD, we would still be waiting. 4. The group responsible for resolving the mismatch between the applicability statement and the spec body in DOD is the protocol standards steering group (actually, it is more complicated than that, but the PSSG invited all the complications to participate with them). At its recent meeting, the issues Mike P. raised were brought to the table by his sponsor, as well as a number of others, and I believe they will be adequately addressed in the DOD comments on the spec, and for the most part will be incorporated in the final spec. I believe that the result will be to place the applicability statement somewhere between the Mike P. reading and the Marshall Rose reading. After the GOSIP is published, there will still need to be guidance prepared by the different agencies for its use in each agency, since different agencies have different plans and concerns. 5. At this point, I believe additional comments would be most useful if they adopted the Marshall Rose interpretation, that is, "If you want to do interoperable OSI, this is how to do it." An additional issue is how OSI should be used by the protocol research community. For really far out research, clearly OSI (or current ARPA/DOD) are minimally relevant. But there is a lot of research in the nearer term which could result in changes to currently planned and operational protocols. Assuming that one believes that the operational protocols for lots of folks are going to be OSI, then the question is how might improvements best be researched. One approach would be to adopt OSI as the research base. This has a lot of apparent advantages: direct applicability and shared terminology for two. A possible difficulty is that the OSI protocols might be a bit "rich" to use when investigating particular points, and a "leaner" protocol suite might be easier to use as the research suite. This approach, however, would have the disadvantage of needing a translation step. (Incidentally, I thought Mike P's protocol to car analogy was less than apt. I would go with OSI is to DOD as Lincoln Town Car is to MGB.) Mike C. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BSRI-NIC.ARPA%5D10-Mar-87.06:00:24.STJOHNS] <1987031004000000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <[SRI-NIC.ARPA]10-Mar-87.06:00:24.STJOHNS> Date: Tue, 10-Mar-87 09:00:00 EST Article-I.D.: <[SRI-NIC.ARPA]10-Mar-87.06:00:24.STJOHNS> Posted: Tue Mar 10 09:00:00 1987 Date-Received: Wed, 11-Mar-87 04:37:47 EST References: <8703091845.AA14228@ACC-SB-UNIX.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 132 Approved: tcp-ip@sri-nic.arpa The following is sent on behalf of Mike Corrigan: _____________________________________________________________ A few comments: 1. GOSIP is the Government OSI Protocol Specification. It was prepared by a working group of the Government OSI Users Group, chaired by NBS, which was formed in reaction to what was a pending Office of Management and Budget announcement mandating use of OSI, without benefit of a specification. I don't know the exact status of the OMB announcemnet, but I believe it is still pending. 2. GOSIP is supposed to have been made available for FTPing from the NIC, but I'm not sure it is really there. I will find out and let you know. 3. A specification such as GOSIP consists of two key parts: what it is you hope to buy and when you have to buy it, or, the body of the spec and the applicability statement. If these don't match as well as they might, you get some very peculiar discussions. I think Mike P's discussion makes it clear that the GOSIP spec pulls no punches with respect to what ypu can currently acquire in OSI, and if the applicability statement were not part of the document, it would meet truth in labelling, full disclosure and informed consent concerns a lot better than we have ever managed in the ARPA/DOD protocol standards arena (for example, did anyone ask themselves about guidance or capabilities in the areas of performance, testing, and user interfaces for TCP/IP/SMTP/FTP/TELNET when reading Mike P's comments?). If we had waited for adequacy in these areas in DOD, we would still be waiting. 4. The group responsible for resolving the mismatch between the applicability statement and the spec body in DOD is the protocol standards steering group (actually, it is more complicated than that, but the PSSG invited all the complications to participate with them). At its recent meeting, the issues Mike P. raised were brought to the table by his sponsor, as well as a number of others, and I believe they will be adequately addressed in the DOD comments on the spec, and for the most part will be incorporated in the final spec. I believe that the result will be to place the applicability statement somewhere between the Mike P. reading and the Marshall Rose reading. After the GOSIP is published, there will still need to be guidance prepared by the different agencies for its use in each agency, since different agencies have different plans and concerns. 5. At this point, I believe additional comments would be most useful if they adopted the Marshall Rose interpretation, that is, "If you want to do interoperable OSI, this is how to do it." An additional issue is how OSI should be used by the protocol research community. For really far out research, clearly OSI (or current ARPA/DOD) are minimally relevant. But there is a lot of research in the nearer term which could result in changes to currently planned and operational protocols. Assuming that one believes that the operational protocols for lots of folks are going to be OSI, then the question is how might improvements best be researched. One approach would be to adopt OSI as the research base. This has a lot of apparent advantages: direct applicability and shared terminology for two. A possible difficulty is that the OSI protocols might be a bit "rich" to use when investigating particular points, and a "leaner" protocol suite might be easier to use as the research suite. This approach, however, would have the disadvantage of needing a translation step. (Incidentally, I thought Mike P's protocol to car analogy was less than apt. I would go with OSI is to DOD as Lincoln Town Car is to MGB.) Mike C. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703120222.AA10926%40ucbvax.Berkeley.EDU] <1987031005200800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: GOSIP (Re)action? Message-ID: <8703120222.AA10926@ucbvax.Berkeley.EDU> Date: Tue, 10-Mar-87 10:20:08 EST Article-I.D.: ucbvax.8703120222.AA10926 Posted: Tue Mar 10 10:20:08 1987 Date-Received: Fri, 13-Mar-87 01:20:33 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa Jon-- Rather than hold fire until everybody who has HEARD things about GOSIP that are rather different from what has been WRITTEN about it manages to catch up with their reading (after all, Marshall has already thrown in the towel and presumably Dave will soon), may I suggest we assume consensus has been reached in the TCP-IP "world" that the GOSIP draft AS CIRCULATED is inappropriate and turn to discussing ways of combatting it? Does it make sense to encourage everybody who has/will come out against it to send hardcopy to Corrigan and Sullivan, seeing that they don't appear to be responding to netmail? Would you like to join me in encouraging Dennis Perry to encourage DARPA to take a formal stand? Should we be suggesting to all interested readers of TCP-IP that they write to Congress? to the GOSIP address you put in your first msg on the topic? to the chaplain? Does anybody out there have any connections with "60 Minutes"? (Not totally facetious, that; they might like one where the DoD has the right end of the stick and it's OMB and/or NBS who are leading to the overexpenditures, if only to balance the one they did the other week about the Bradley Armored Personnel Incinerator--er, uh, Carrier.) I'll be sending my own hardcopy, in compliance with a suggestion Dennis made, but I'd like to think all concerned parties can "do something" in concert. Any ideas? (For that matter, can you publish on the List appropriate p-mail addresses for Sullivan and Corrigan [p=physical], and should the NBS copy go to the attention of Jim Burrows, who was Heafner's boss before he left, perhaps, rather than just to GOSIP?) totally unfacetious cheers, map P.S. As evidence of my seriousness, note that I consciously resisted saying that the hardcopy should be sent Return Receipt Requested. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987031005200801> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 10 Mar 87 07:27:20-PST Date: 10 Mar 1987 10:20:08 EST From: PADLIPSKY@A.ISI.EDU Subject: GOSIP (Re)action? To: postel@A.ISI.EDU cc: tcp-ip@SRI-NIC.ARPA Jon-- Rather than hold fire until everybody who has HEARD things about GOSIP that are rather different from what has been WRITTEN about it manages to catch up with their reading (after all, Marshall has already thrown in the towel and presumably Dave will soon), may I suggest we assume consensus has been reached in the TCP-IP "world" that the GOSIP draft AS CIRCULATED is inappropriate and turn to discussing ways of combatting it? Does it make sense to encourage everybody who has/will come out against it to send hardcopy to Corrigan and Sullivan, seeing that they don't appear to be responding to netmail? Would you like to join me in encouraging Dennis Perry to encourage DARPA to take a formal stand? Should we be suggesting to all interested readers of TCP-IP that they write to Congress? to the GOSIP address you put in your first msg on the topic? to the chaplain? Does anybody out there have any connections with "60 Minutes"? (Not totally facetious, that; they might like one where the DoD has the right end of the stick and it's OMB and/or NBS who are leading to the overexpenditures, if only to balance the one they did the other week about the Bradley Armored Personnel Incinerator--er, uh, Carrier.) I'll be sending my own hardcopy, in compliance with a suggestion Dennis made, but I'd like to think all concerned parties can "do something" in concert. Any ideas? (For that matter, can you publish on the List appropriate p-mail addresses for Sullivan and Corrigan [p=physical], and should the NBS copy go to the attention of Jim Burrows, who was Heafner's boss before he left, perhaps, rather than just to GOSIP?) totally unfacetious cheers, map P.S. As evidence of my seriousness, note that I consciously resisted saying that the hardcopy should be sent Return Receipt Requested. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703101619.AA05494%40ucbvax.Berkeley.EDU] <1987031005312000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <8703101619.AA05494@ucbvax.Berkeley.EDU> Date: Tue, 10-Mar-87 10:31:20 EST Article-I.D.: ucbvax.8703101619.AA05494 Posted: Tue Mar 10 10:31:20 1987 Date-Received: Wed, 11-Mar-87 03:49:55 EST References: <8703060512.AA25993@flash.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Phil-- Your comments on "the Europeans" reminded me that I'd never gotten around to commenting on a msg Jon sent some time back containing a quotation to the effect that the trouble with 5,000- member standards committees is that they spend all their time debating whether to have croissants or doughnuts for breakfast. I'm sure you'll agree that the quotation couldn't have been about ISO or CCITT, since they'd have been debating croissants vs. brioches--doughnuts would give the American vendors too big a headstart. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987031005312001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 10 Mar 87 08:01:09-PST Date: 10 Mar 1987 10:31:20 EST Subject: Re: GOSIP vs TCP/IP From: Michael Padlipsky To: karn@FLASH.BELLCORE.COM (Phil R. Karn) cc: bryan@ACC-SB-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: <8703060512.AA25993@flash.bellcore.com> Phil-- Your comments on "the Europeans" reminded me that I'd never gotten around to commenting on a msg Jon sent some time back containing a quotation to the effect that the trouble with 5,000- member standards committees is that they spend all their time debating whether to have croissants or doughnuts for breakfast. I'm sure you'll agree that the quotation couldn't have been about ISO or CCITT, since they'd have been debating croissants vs. brioches--doughnuts would give the American vendors too big a headstart. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703112213.AA04759%40ucbvax.Berkeley.EDU] <1987031008380000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: andrews@wharton-10.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: schools doing Network research Message-ID: <8703112213.AA04759@ucbvax.Berkeley.EDU> Date: Tue, 10-Mar-87 13:38:00 EST Article-I.D.: ucbvax.8703112213.AA04759 Posted: Tue Mar 10 13:38:00 1987 Date-Received: Fri, 13-Mar-87 02:10:21 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Scott W. Andrews" Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa I'm interested in which schools are doing computer networking design and implementation or protocol design and implementation. I need aplication information for graduate school and would appreciate information on who could I contact at these schools. Thank You Scott W Andrews University of Pennsylvania Philadelphia PA 19104 (215)898-5392 arpa: andrews@wharton-10 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987031008380001> Received: from wharton-10 by SRI-NIC.ARPA with TCP; Wed 11 Mar 87 13:18:00-PST Date: 10 Mar 87 13:38:00 EST From: "Scott W. Andrews" Subject: schools doing Network research To: "tcp-ip" Reply-To: "Scott W. Andrews" I'm interested in which schools are doing computer networking design and implementation or protocol design and implementation. I need aplication information for graduate school and would appreciate information on who could I contact at these schools. Thank You Scott W Andrews University of Pennsylvania Philadelphia PA 19104 (215)898-5392 arpa: andrews@wharton-10 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12285339364.17.PERILLO%40SRI-NIC.ARPA] <1987031010244100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERILLO@SRI-NIC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: GOSIP doc now online at SRI-NIC.ARPA Message-ID: <12285339364.17.PERILLO@SRI-NIC.ARPA> Date: Tue, 10-Mar-87 15:24:41 EST Article-I.D.: SRI-NIC.12285339364.17.PERILLO Posted: Tue Mar 10 15:24:41 1987 Date-Received: Fri, 13-Mar-87 05:11:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa The NIC has received approval from Mike Corrigan to release the GOSIP document online. It may be FTPed from the SRI-NIC.ARPA host using the pathname NETINFO:GOSIP.DOC. It is 50 disk pages long. SRI-NIC.ARPA supports "anonymous" login. -Francine /NIC ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703110409.AA22963%40BORAX.LCS.MIT.EDU] <1987031018095700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jbvb@BORAX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP/IP header question Message-ID: <8703110409.AA22963@BORAX.LCS.MIT.EDU> Date: Tue, 10-Mar-87 23:09:57 EST Article-I.D.: BORAX.8703110409.AA22963 Posted: Tue Mar 10 23:09:57 1987 Date-Received: Fri, 13-Mar-87 02:08:27 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa I don't see any reason to send obsolete information; our implementation updates both ACKs and Window to the values current at the instant the packet is sent. Of course, this does mean we have to re-checksum the packet, but we have to do this anyway if a packet gets partially ack'ed (which you'd better be prepared for...) Note that it *does* seem like a good idea (not mine) to retain the IP 'identification' so that fragments can be assembled from any instance of (re)transmission of a given packet. jbvb@ai.ai.mit.edu James B. VanBokkelen FTP Software, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703110424.AA23018%40BORAX.LCS.MIT.EDU] <1987031018244200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jbvb@BORAX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Thanks to all the TN3270 posters: Message-ID: <8703110424.AA23018@BORAX.LCS.MIT.EDU> Date: Tue, 10-Mar-87 23:24:42 EST Article-I.D.: BORAX.8703110424.AA23018 Posted: Tue Mar 10 23:24:42 1987 Date-Received: Fri, 13-Mar-87 02:09:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa The discussion was very timely: my TN3270 (ancestry: PC/TCP Telnet and Greg Minshall's emulator code, less curses) succeeded in negotiating to BINARY, EOR & terminal type 3278-2 on its second try (against Wiscnet). I don't require EOR to enter 3270 mode, which seems to be de rigeur, given Spartacus's current behavior. I'll test that tomorrow. Anyone out there want to volunteer a UCLA MVS so I can see how well it backs out of 3270? This one will probably get to terminal type 3278-2 with a 4.3 as well, but that seems to be the way the cookie crumbles (if I've read the postings right). jbvb@ai.ai.mit.edu James B. VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703111323.AA12283%40mitre.ARPA] <1987031103231900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <8703111323.AA12283@mitre.ARPA> Date: Wed, 11-Mar-87 08:23:19 EST Article-I.D.: mitre.8703111323.AA12283 Posted: Wed Mar 11 08:23:19 1987 Date-Received: Fri, 13-Mar-87 00:12:09 EST References: <8703060512.AA25993@flash.bellcore.com> Sender: luria@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 48 Approved: tcp-ip@sri-nic.arpa I circulated the note from Phil ("...darker forces at play ...") among several colleagues here at MITRE-Washington; herewith the views of Steve Silverman. -------------------------------------- *** Reply to note of 03/08/87 10:09 From: Steve Silverman Subject: GOSIP vs TCP/IP I would like to reply to your note on TCP/IP and its non-acceptance by the commercial world. First of all, I doubt that there is any connection with the various television standards other than the prevalence of the NIH syndrome. This seems to be fairly prevalent in many places including the DOD. As far as TCP/IP versus ISO, it must be recongnized that there are two ISO suites being developed. One, the Connection-Based (CB), uses TP over X.25. The second one, the Connectionless (CL) suite, uses IP between TP and X.25. The CL suite is a datagram approach in the tradition of the ARPANET. This was used in the first generation packet networks, but has significant costs in comparison with the CB approach used by later generation commercial packet networks. The CL approach means that each packet must contain a larger header (TCP/IP = 40 bytes) than a CB packet (X.25 = 3 bytes). The CL approach requires each switch to make a routing decision on each packet while the CB approach allows transit switches to do a simple table lookup for following packets. Each suite has its benefits; the CL approach is better for tactical networks with very mobile nodes. The CB approach is much more economical for higher data requirements. The public data networks are almost exclusively CB. The design work being done today for future networks by the common carrier network builders is almost exclusively CB based, although the OSI 7 layer model is being downplayed (really discarded). To some of us, the use of a CL stationary packet network is equivalent to forcing all military ground vehicles to be armored and armed. If 495 (our local beltway) were filled with tanks, it would be a major waste of money. It is about time, in my opinion, that the military networkers realized that the commercial data users are not stupid. They demand the same reliability that the DOD requires. The Reconnect feature of X.25 prevents loss of user data when a transit node fails. This has been widely deployed for years. Meanwhile the cost of running the ARPANET is comparable to running the Telenet public network which carries ten times as many user packets. The reluctance of some people to embrace TCP/IP is not just based on NIH. Some of us reject it on technical grounds. Steve Silverman * * Steve :::GOSIP vs TCP/IP R ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12285600801.8.MRC%40PANDA] <1987031110204800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <12285600801.8.MRC@PANDA> Date: Wed, 11-Mar-87 15:20:48 EST Article-I.D.: PANDA.12285600801.8.MRC Posted: Wed Mar 11 15:20:48 1987 Date-Received: Fri, 13-Mar-87 02:07:58 EST References: <[SRI-NIC.ARPA]10-Mar-87.06:00:24.STJOHNS> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa If OSI is to DoD the way a Lincoln Town Car is to an MGB, I guess we'll be running DoD protocols for a long long time to come. As a network programmer, I am delighted at the prospect of full employment for everybody in my field for a very long time, at US government expense. As a taxpayer, I'm outraged, and am starting to make comparisions in my mind with the Sgt. York and the B-1. I am wondering if what we are seeing is OSI having become so large and unmanagable that implementability has become a forgotten goal. I read the FTAM specification and still am not completely sure what FTAM is all about. "Eschew obfuscation" seems to have been forgotten. More to the point; I don't think the US government should be in the business of trying to establish OSI as a standard protocol. The current regime is big on "market" based decisions. If the US government sees itself as a USER of an international standard protocol but is otherwise neutral on what that protocol should be, then the current de facto international standard is TCP/IP. If OSI is so wonderful, then all the other users of network protocols -- industry, research, our foreign allies, the socialist countries(!!) -- will migrate to OSI without US government pressure being brought to bear. If OSI fails to gain such widespread acceptance, then perhaps it was a bad idea to begin with. Nobody is seriously suggesting that TCP/IP should be retained indefinitely; what we ARE saying is that there should not be *any* talk of migration until there is clearly something better available. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).11-Mar-87.17:34:59.VAX.DARPA.MIL] <1987031112345900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP (Re)action? Message-ID: Date: Wed, 11-Mar-87 17:34:59 EST Article-I.D.: Posted: Wed Mar 11 17:34:59 1987 Date-Received: Fri, 13-Mar-87 02:02:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Mike, I have made a very strong request to Corrigan at the PSSG meeting to include something in the GOSIP document to exempt research related procurement. Mick C. agreed to include such suggestion, as I believe he alluded to in his response to the net. DARPA's position is that research should not be hampered by standards, but shoud use them as appropriate to further their research. It may also mean not using them to further their research. The Arpanet is a research network. You can draw your own conclusions from their on my position. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987031112345901> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Wed 11 Mar 87 14:37:23-PST Posted-Date: Wed 11 Mar 87 17:34:59-EST Received: by vax.darpa.mil (5.54/5.51) id AA01889; Wed, 11 Mar 87 17:35:08 EST Date: Wed 11 Mar 87 17:34:59-EST From: Dennis G. Perry Subject: Re: GOSIP (Re)action? To: PADLIPSKY@a.isi.edu Cc: postel@a.isi.edu, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "PADLIPSKY@A.ISI.EDU" of 10 Mar 1987 10:20:08 EST Mike, I have made a very strong request to Corrigan at the PSSG meeting to include something in the GOSIP document to exempt research related procurement. Mick C. agreed to include such suggestion, as I believe he alluded to in his response to the net. DARPA's position is that research should not be hampered by standards, but shoud use them as appropriate to further their research. It may also mean not using them to further their research. The Arpanet is a research network. You can draw your own conclusions from their on my position. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [33:zhuang%40cs.dal.cdn] <1987031117554300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: zhuang@seismo.CSS.GOV@dalcs.UUCP Newsgroups: mod.protocols.tcp-ip Subject: submission Message-ID: <33:zhuang@cs.dal.cdn> Date: Wed, 11-Mar-87 22:55:43 EST Article-I.D.: cs.33:zhuang Posted: Wed Mar 11 22:55:43 1987 Date-Received: Fri, 13-Mar-87 04:46:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 1 Approved: tcp-ip@sri-nic.arpa This is my submission to the list of tcp. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703120441.AA28976%40topaz.rutgers.edu] <1987031118412700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <8703120441.AA28976@topaz.rutgers.edu> Date: Wed, 11-Mar-87 23:41:27 EST Article-I.D.: topaz.8703120441.AA28976 Posted: Wed Mar 11 23:41:27 1987 Date-Received: Fri, 13-Mar-87 04:44:43 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Could you forward this back to Mike Corrigan: My primary concern is that we don't push OSI so fast that we ruin its long-term future. TCP/IP proceeded the way it did because there was no choice. We had to get things out quickly because we needed the facilities. After all, it was originally claimed to be a research vehicle. OSI is supposed to be different. It is supposed to be a second-generation, production system, commerically supported, and all that. I have my own scepticism about this, but the point is that it will accomplish absolutely nothing if we push people into it so fast that we just duplicate the history of TCP/IP. One thing that 4.1 and 4.2 make very clear is how hard it is to get improved software into everybody's hands once large groups of people have started to use something. How many years will it have taken to get subnets in use? (It still isn't finished.) I understand the political pressure to move ahead quickly with OSI, but I think that should be resisted. I think you should be writing specs for pilot implementations, but be suggesting that all production work be done with TCP/IP. The point is that we should give OSI a chance to get some actual use in well-controlled environments, and do lots of testing. When something is offered for general use, that something should be well-tested and the robust. The last thing we should be doing is pressuring vendors to come out with products prematurely, as GOSIP seems sure to do. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987031210480100> Received: from CSL.SRI.COM by SRI-NIC.ARPA with TCP; Fri 13 Mar 87 10:43:50-PST Date: Thu 12 Mar 87 18:48:01-PST From: Karl Auerbach Subject: A defense of GOSIP To: tcp-ip@SRI-NIC.ARPA I think GOSIP is a good idea. I support it. I have read GOSIP. I have read, indeed participated in, the NBS Implementors' workshops. I have read, and believe I understand many, if not most of the ISO and CCITT specifications. I have been implementing one of the larger parts (X.400). 1. As for GOSIP mandating a universal government wide requirement: No matter how one reads the express language of the document, does anyone really think that agencies will abandon SNA? If SNA is an implicit exception why not TCP, XNS, ... ? 2. The entire validity of the ISO protocol suite has been called into question because some of the standards have changed as they progressed through the standardization process. So what? Couldn't the same reasoning be applied to the TCP suite because new RFC's are issued? Yes, the ISO protocols and services are changing. Our own X.400 implementation will be, in part, invalidated due to changes which will be "approved" next year. And is ISO missing important parts? Yes. For instance its protocols for handling routing between intermediate systems ("gateways" in TCP terms) are still being developed. But can one really say that the Internet has done a really good job of inter-gateway routing? Does MAP/TOP contain some really incredibly dumb ideas? Yes. For example, network level addresses (NSAPs) contain the PHYSICAL media addresses (e.g. the 48 bit Ethernet address). This can become a management nightmare, especially as the NSAP is a necessary component of higher level addresses and will be stored by the various application level directory services. But this oddity is NOT a necessary part of ISO, only a temporary expedient reasonably adopted by the MAP folks to defer inventing ARP and routing protocols. GOSIP places a high priority on resolving this issue. And answers are presently being considered, just read for example, RFC 995. Does this mean that one should not "go ISO". Perhaps, if you are measuring costs over a short term. But, if you take a long view, and believe that ISO will, in fact, mature, then perhaps you ought to invest now, grow-up with the technology, and avoid a conversion expense. 3. The ISO protocols and services contain many, many good ideas. They are in many respects superior to TCP services. There has been criticism that the ISO work is bloated. I believe this is a valid objection. But if you look at the Implementors' Agreements you will find many portions of the full ISO specifications which have been chopped off or limited. In addition, as I have worked with ISO my viewpoint has changed. For example, at first I considered most of the session synchronization functions to be questionable. Why should I pay their cost when I am never going to use them? It turns out that they are extremely useful. And, in practice, they don't seem to cost much. I remember similar arguments being raised by assembler language programmers against "the terrible waste of high level languages." --karl-- Karl Auerbach Epilogue Technology Corporation ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703131905.AA28642%40ucbvax.Berkeley.EDU] <1987031216480100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AUERBACH@CSL.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: A defense of GOSIP Message-ID: <8703131905.AA28642@ucbvax.Berkeley.EDU> Date: Thu, 12-Mar-87 21:48:01 EST Article-I.D.: ucbvax.8703131905.AA28642 Posted: Thu Mar 12 21:48:01 1987 Date-Received: Sat, 14-Mar-87 10:23:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 59 Approved: tcp-ip@sri-nic.arpa I think GOSIP is a good idea. I support it. I have read GOSIP. I have read, indeed participated in, the NBS Implementors' workshops. I have read, and believe I understand many, if not most of the ISO and CCITT specifications. I have been implementing one of the larger parts (X.400). 1. As for GOSIP mandating a universal government wide requirement: No matter how one reads the express language of the document, does anyone really think that agencies will abandon SNA? If SNA is an implicit exception why not TCP, XNS, ... ? 2. The entire validity of the ISO protocol suite has been called into question because some of the standards have changed as they progressed through the standardization process. So what? Couldn't the same reasoning be applied to the TCP suite because new RFC's are issued? Yes, the ISO protocols and services are changing. Our own X.400 implementation will be, in part, invalidated due to changes which will be "approved" next year. And is ISO missing important parts? Yes. For instance its protocols for handling routing between intermediate systems ("gateways" in TCP terms) are still being developed. But can one really say that the Internet has done a really good job of inter-gateway routing? Does MAP/TOP contain some really incredibly dumb ideas? Yes. For example, network level addresses (NSAPs) contain the PHYSICAL media addresses (e.g. the 48 bit Ethernet address). This can become a management nightmare, especially as the NSAP is a necessary component of higher level addresses and will be stored by the various application level directory services. But this oddity is NOT a necessary part of ISO, only a temporary expedient reasonably adopted by the MAP folks to defer inventing ARP and routing protocols. GOSIP places a high priority on resolving this issue. And answers are presently being considered, just read for example, RFC 995. Does this mean that one should not "go ISO". Perhaps, if you are measuring costs over a short term. But, if you take a long view, and believe that ISO will, in fact, mature, then perhaps you ought to invest now, grow-up with the technology, and avoid a conversion expense. 3. The ISO protocols and services contain many, many good ideas. They are in many respects superior to TCP services. There has been criticism that the ISO work is bloated. I believe this is a valid objection. But if you look at the Implementors' Agreements you will find many portions of the full ISO specifications which have been chopped off or limited. In addition, as I have worked with ISO my viewpoint has changed. For example, at first I considered most of the session synchronization functions to be questionable. Why should I pay their cost when I am never going to use them? It turns out that they are extremely useful. And, in practice, they don't seem to cost much. I remember similar arguments being raised by assembler language programmers against "the terrible waste of high level languages." --karl-- Karl Auerbach Epilogue Technology Corporation ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987031223204500> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 13 Mar 87 10:08:24-PST Date: 13 Mar 1987 07:20:45 PST From: PADLIPSKY@A.ISI.EDU Subject: Still More Re GOSIP To: tcp-ip@SRI-NIC.ARPA cc: corrigan@SRI-NIC.ARPA, GTSullivan@DOCKMASTER.ARPA [This might be a redundant resend, but the copy I thought was going to the List came back with Message failed for the following: tcp-ip@SRI-NIC.ARPA: Forwarding error: Cannot find indirect file - No such device ------------ so I figured I'd better try again (maybe it's some kind of cosmic compensation for all the ones I thought I'd sent once that have shown up twice). NOTE, by the way, that I've expanded the contents, so even if you think you've seen it before, you haven't really.] [Mainly for Mike C.] Mike-- Glad to hear from you finally. Guess I can save the Government the postage on hardcopy after all. A couple of quick rejoinders: The reason why testing and performance stuff is not relevant to the ARPANET Suite but is relevant to GOSIP (and eventually to OSI--which, it must be realized, must be distinguished from GOSIP) is contained in the final sentence of 1.1, Background (of the GOSIP Draft): "By implementing open systems, the government expects to realize significant savings through reducing duplicate circuits and wiring, training, custom software, work stations, and custom hardware interfaces." Without testing and performance criteria, GOSIP (as it stands) would have to lead to INCREASED costs in "custom software"--to pay for the interoperability-bug fixes and the code tightening, that is. (On a somewhat different, but actually more threatening, tack, another way in which the promise of cost savings from "off-the-shelf"/"standard" software is betrayed lies in the fact that those [DoD] systems which will be using "Blacker" will have to have their X.25 implementations gutted and rehabbed, but let's save the details on that for a venue other than the TCP-IP "bulletin board"/mailing list.) Note, however, that when the ARPANET Suite was being adopted, nobody claimed the advantages of vendor support for it. GOSIP is claiming such advantages and demonstrably won't achieve them, both because of the need for further work on the current stuff and because of the need for further expenditure on the new stuff. A moving target is a moving target. (There's an irony in the fact that now that the ARPANET Suite is enjoying most of the advantages of vendor support after all, we're being asked to chuck it; but let it [the irony, not the Suite] pass.) Re automotive analogies: I'd be inclined to go with your recasting provided you make it a picture of an artist's conception of a "car of the future" model Lincoln vs. an actual MBG. I was trying to be polite by saying GOSIP was a stripped Renault, but if you insist on focusing on what OSI is eventually intended to be, we're in the realm of promises vs. realities. cheers, map P.S. Bravo on getting DARPA not to be considered a Government agency. Here's hoping you can do the same for DoD. (I.e., get it exempted from forced transition; after all, the ARPANET Suite is paid for and could be run in parallel with the OSI Suite when the OSI Suite is really here and really needed to interoperate with, e.g., NATO.) P.P.S. New metaphor: everybody's being told to run as hard as they can to get on this merry-go-round, and when they do they discover the brass ring dispenser's empty. (For those who don't remember such things, if you grabbed the brass ring you'd get a free ride.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703131819.AA27756%40ucbvax.Berkeley.EDU] <1987031305204500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Still More Re GOSIP Message-ID: <8703131819.AA27756@ucbvax.Berkeley.EDU> Date: Fri, 13-Mar-87 10:20:45 EST Article-I.D.: ucbvax.8703131819.AA27756 Posted: Fri Mar 13 10:20:45 1987 Date-Received: Sat, 14-Mar-87 10:23:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 63 Approved: tcp-ip@sri-nic.arpa [This might be a redundant resend, but the copy I thought was going to the List came back with Message failed for the following: tcp-ip@SRI-NIC.ARPA: Forwarding error: Cannot find indirect file - No such device ------------ so I figured I'd better try again (maybe it's some kind of cosmic compensation for all the ones I thought I'd sent once that have shown up twice). NOTE, by the way, that I've expanded the contents, so even if you think you've seen it before, you haven't really.] [Mainly for Mike C.] Mike-- Glad to hear from you finally. Guess I can save the Government the postage on hardcopy after all. A couple of quick rejoinders: The reason why testing and performance stuff is not relevant to the ARPANET Suite but is relevant to GOSIP (and eventually to OSI--which, it must be realized, must be distinguished from GOSIP) is contained in the final sentence of 1.1, Background (of the GOSIP Draft): "By implementing open systems, the government expects to realize significant savings through reducing duplicate circuits and wiring, training, custom software, work stations, and custom hardware interfaces." Without testing and performance criteria, GOSIP (as it stands) would have to lead to INCREASED costs in "custom software"--to pay for the interoperability-bug fixes and the code tightening, that is. (On a somewhat different, but actually more threatening, tack, another way in which the promise of cost savings from "off-the-shelf"/"standard" software is betrayed lies in the fact that those [DoD] systems which will be using "Blacker" will have to have their X.25 implementations gutted and rehabbed, but let's save the details on that for a venue other than the TCP-IP "bulletin board"/mailing list.) Note, however, that when the ARPANET Suite was being adopted, nobody claimed the advantages of vendor support for it. GOSIP is claiming such advantages and demonstrably won't achieve them, both because of the need for further work on the current stuff and because of the need for further expenditure on the new stuff. A moving target is a moving target. (There's an irony in the fact that now that the ARPANET Suite is enjoying most of the advantages of vendor support after all, we're being asked to chuck it; but let it [the irony, not the Suite] pass.) Re automotive analogies: I'd be inclined to go with your recasting provided you make it a picture of an artist's conception of a "car of the future" model Lincoln vs. an actual MBG. I was trying to be polite by saying GOSIP was a stripped Renault, but if you insist on focusing on what OSI is eventually intended to be, we're in the realm of promises vs. realities. cheers, map P.S. Bravo on getting DARPA not to be considered a Government agency. Here's hoping you can do the same for DoD. (I.e., get it exempted from forced transition; after all, the ARPANET Suite is paid for and could be run in parallel with the OSI Suite when the OSI Suite is really here and really needed to interoperate with, e.g., NATO.) P.P.S. New metaphor: everybody's being told to run as hard as they can to get on this merry-go-round, and when they do they discover the brass ring dispenser's empty. (For those who don't remember such things, if you grabbed the brass ring you'd get a free ride.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703131614.AA04222%40THYME.LCS.MIT.EDU] <1987031306141600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: markl@THYME.LCS.MIT.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <8703131614.AA04222@THYME.LCS.MIT.EDU> Date: Fri, 13-Mar-87 11:14:16 EST Article-I.D.: THYME.8703131614.AA04222 Posted: Fri Mar 13 11:14:16 1987 Date-Received: Tue, 17-Mar-87 04:10:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa > If OSI is to DoD the way a Lincoln Town Car is to an MGB, >I guess we'll be running DoD protocols for a long long time to >come. Well *I* have always found MGs to be paragons of reliability... markl Internet: markl@ptt.lcs.mit.edu MIT Laboratory for Computer Science Distributed Systems Group ---------- "When all else fails, pour a pint of Guinness in the gas tank, advance the spark 20 degrees, cry "God Save the Queen!", and pull the starter knob." -- MG "Series MGA" Workshop Manual :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703131812.AA24681%40well.UUCP] <1987031308121300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: slf@well.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP (Re)action? Message-ID: <8703131812.AA24681@well.UUCP> Date: Fri, 13-Mar-87 13:12:13 EST Article-I.D.: well.8703131812.AA24681 Posted: Fri Mar 13 13:12:13 1987 Date-Received: Sat, 14-Mar-87 10:24:12 EST References: <8703120222.AA10926@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: well!slf@lll-lcc.ARPA (Sharon Lynne Fisher) Distribution: world Organization: Whole Earth 'Lectronic Link, Sausalito, CA Lines: 8 Approved: tcp-ip@sri-nic.arpa I'm not 60 Minutes, but I am a computer journalist who has been following this discussion for the past couple of weeks with much interest. I am considering doing an article on this for InfoWorld (I'm the communications editor). To get this past my editors, I have to demonstrate that there is some PC connection; also, I would have to talk to people on 'the other side' (i.e., pro-GOSIP) to get their views as well. Does anybody have any information that can help me? Thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12286252158.8.WANCHO%40SIMTEL20.ARPA] <1987031321584900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: WANCHO@SIMTEL20.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Black Art: sendmail.cf files Message-ID: <12286252158.8.WANCHO@SIMTEL20.ARPA> Date: Sat, 14-Mar-87 02:58:49 EST Article-I.D.: SIMTEL20.12286252158.8.WANCHO Posted: Sat Mar 14 02:58:49 1987 Date-Received: Sat, 14-Mar-87 20:15:24 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa It seems the root of many of the improperly formed message headers, and the reason that many hosts have had difficulty in switching to the domain format host names is poorly constructed sendmail.cf files. This problem will shortly become acute when the NIC will no longer disribute its HOSTS.TXT file containing host alias entries. Therefore, I'd like to propose that a small handful of sendmail wizards get together and produce one proven sendmail.cf file for each of the major environments: Internet only, UUCP only, a combination of the two, and whatever else they deem necessary. Then make the resulting versions available either somewhere on NIC or ucbvax or both, and advertise where they are. Of course, if this has been done already, it would pay to make that information known much more widely, particularly at this time. --Frank ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703142135.AA02579%40braden.isi.edu] <1987031411355600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP/IP header question Message-ID: <8703142135.AA02579@braden.isi.edu> Date: Sat, 14-Mar-87 16:35:56 EST Article-I.D.: braden.8703142135.AA02579 Posted: Sat Mar 14 16:35:56 1987 Date-Received: Sun, 15-Mar-87 04:47:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa If two instances of a given IP datagram contain TCP segments with differing TCP headers, you may be able to reassemble them but it won't do much good... presumably the ----MESSAGE-END---- ----MESSAGE-BEGIN---- [168645.870314.JBVB%40AI.AI.MIT.EDU] <1987031413594500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP/IP header question Message-ID: <168645.870314.JBVB@AI.AI.MIT.EDU> Date: Sat, 14-Mar-87 18:59:45 EST Article-I.D.: AI.168645.870314.JBVB Posted: Sat Mar 14 18:59:45 1987 Date-Received: Sun, 15-Mar-87 07:36:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa Bob, I only got the first few sentences of your message. What I see looks like a point I hadn't thought about. If the TCP header has changed, then using the same IP identification is counter-productive. In conventional implementations, I suppose it is up to the individual designer or tuner to decide whether the fragment reassembly potential is worth the cost of re-sending obsolete Window and Ack. Our current TCP sends the up-to-date information. An idea struck me, though: How about using some sort of checksum of the data passed to IP (perhaps with the protocol and port number appended to prevent aliasing) as the identification? This would seem to be a simple way of getting the reassembly automatically whenever it was possible, without making an arbitrary upper layer concern itself with IP internals. I know, this is easy for me to say, with the processor all to myself, but... jbvb@ai.ai.mit.edu James B. VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703150202.AA25999%40hermes.ai.mit.edu] <1987031416024300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dms@HERMES.AI.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Black Art: sendmail.cf files Message-ID: <8703150202.AA25999@hermes.ai.mit.edu> Date: Sat, 14-Mar-87 21:02:43 EST Article-I.D.: hermes.8703150202.AA25999 Posted: Sat Mar 14 21:02:43 1987 Date-Received: Sun, 15-Mar-87 08:15:12 EST References: <12286252158.8.WANCHO@SIMTEL20.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa I have a sendmail.cf file that works fairly well. It has extra stuff in it for our local chaosnet hosts, and I think it does a few things incorrectly here and there, but it would be a good starting point for someone who might want to tune it up a bit. It uses the domain system and I've stripped out all the Berkeley specific cruft that most people have. It's much less confusing than the standard distribution file. It's in the public ftp area on hermes.ai.mit.edu. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703150317.AA06298%40bu-cs.bu.edu] <1987031417173200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: A defense of GOSIP Message-ID: <8703150317.AA06298@bu-cs.bu.edu> Date: Sat, 14-Mar-87 22:17:32 EST Article-I.D.: bu-cs.8703150317.AA06298 Posted: Sat Mar 14 22:17:32 1987 Date-Received: Sun, 15-Mar-87 13:36:11 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa >Does this mean that one should not "go ISO". Perhaps, if you are >measuring costs over a short term. But, if you take a long view, and >believe that ISO will, in fact, mature, then perhaps you ought to >invest now, grow-up with the technology, and avoid a conversion >expense. Fine, send me implementations for my SUNs, Encores, IBM/3090, Xerox and Symbolics Lisp machines, Vaxes (UNIX and VMS), ATT/3B (SYSV), IBM/PCs and Celerities. I am running some version of Internet protocols on all of those right now and it is critical to our campus' operation, research and educational business. I await the software or list of vendors from you. (maybe we should continue this argument on INFO-OSI which no doubt everyone reads on their X.400/OSI systems anyhow.) -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D15-Mar-87.01:04:54.CERF] <1987031420040000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <[A.ISI.EDU]15-Mar-87.01:04:54.CERF> Date: Sun, 15-Mar-87 01:04:00 EST Article-I.D.: <[A.ISI.EDU]15-Mar-87.01:04:54.CERF> Posted: Sun Mar 15 01:04:00 1987 Date-Received: Sun, 15-Mar-87 13:48:41 EST References: <8703111323.AA12283@mitre.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Please ask Steve what he does about X.25 resets in the absence of an end/end reliable protocol such as TCP or TP4? I thought a significant commercial acceptance of TCP was in evidence from the PC and LAN vendors.? Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987031420040001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sat 14 Mar 87 22:04:51-PST Date: 15 Mar 1987 01:04-EST Sender: CERF@A.ISI.EDU Subject: Re: GOSIP vs TCP/IP From: CERF@A.ISI.EDU To: mckee@MITRE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]15-Mar-87 01:04:54.CERF> In-Reply-To: <8703111323.AA12283@mitre.ARPA> Please ask Steve what he does about X.25 resets in the absence of an end/end reliable protocol such as TCP or TP4? I thought a significant commercial acceptance of TCP was in evidence from the PC and LAN vendors.? Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703151740.AA06099%40mitre-bedford.ARPA] <1987031507404800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sra@MITRE-BEDFORD.ARPA (Stan Ames) Newsgroups: mod.protocols.tcp-ip Subject: ULANA RFP INFO Message-ID: <8703151740.AA06099@mitre-bedford.ARPA> Date: Sun, 15-Mar-87 12:40:48 EST Article-I.D.: mitre-be.8703151740.AA06099 Posted: Sun Mar 15 12:40:48 1987 Date-Received: Mon, 16-Mar-87 04:07:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa The documents related to the upcoming ULANA rfp are again on the host ULANA. To get a copy ftp to ULANA (192.12.120.30) and do a dir The account is guest the passward is anonymous A file called status is also in this account and contains current information. These files are being placed on this host for general info only. Official copies can be had by visiting the ULANA library at ESD. Questions can be sent to ulana at mitre-bedford.arpa Stan Ames ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21718.542829929%40nrtc-gremlin.arpa] <1987031508261500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@NRTC-GREMLIN.ARPA (Marshall Rose) Newsgroups: mod.protocols.tcp-ip Subject: Re: A defense of GOSIP Message-ID: <21718.542829929@nrtc-gremlin.arpa> Date: Sun, 15-Mar-87 13:26:15 EST Article-I.D.: nrtc-gre.21718.542829929 Posted: Sun Mar 15 13:26:15 1987 Date-Received: Mon, 16-Mar-87 04:07:54 EST References: <8703150317.AA06298@bu-cs.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 41 Approved: tcp-ip@sri-nic.arpa > (maybe we should continue this argument on INFO-OSI which no doubt > everyone reads on their X.400/OSI systems anyhow.) Nah. As has been pointed out in the past by Jon, these guys don't even use computers. Seriously, it's the stupidest catch-22 I've ever heard of: you can't start an electronic mail interest group for use by OSI zealots because either: - they don't have working X.400 systems - their systems don't talk to each other yet - they won't agree to use one organization's system for political reasons - they won't use the ARPAnet mailsystem (even though they probably all could get legitimate access) because even though it works it's not OSI and they can't use it 'cause that would be admitting that the ARPAnet stuff works You think I'm kidding, I'm not! This has happened to two or three times to my knowledge, and quite frankly I'm not even tied in that well to the OSI bunch. Of course the gag is that any of these four problems can be "fixed" easily: - you can now get X.400 systems on just about every machine you listed (true!) except perhaps the lisp engines - they could connect up to a common carrier - they could grow up - they could grow up and admit that, for the moment, TCP/IP and the ARPAnet works much better than OSI does. Croissants or donuts? I'd settle for hot water! /mtr ps: I'm out the door for the Monterey conference, so my responses to everyone's flames/cheers will be delayed by a few days... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12286711253.19.CORRIGAN%40SRI-NIC.ARPA] <1987031516004200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CORRIGAN@SRI-NIC.ARPA (Mike Corrigan) Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP Message-ID: <12286711253.19.CORRIGAN@SRI-NIC.ARPA> Date: Sun, 15-Mar-87 21:00:42 EST Article-I.D.: SRI-NIC.12286711253.19.CORRIGAN Posted: Sun Mar 15 21:00:42 1987 Date-Received: Mon, 16-Mar-87 04:52:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 51 Approved: tcp-ip@sri-nic.arpa As I mentioned previously, the concerns which have been raised with respect to the applicability statement will be addressed in DOD comments on GOSIP. I think, however, it may be useful to quote all the relevant portions of the current applicability statement, and give an alternate (I might add, the intended, but as Mike Padlipsky says, you have to read the words) interpretation of what is there now from either of the two views given to date (Mike Padlipsky's and WBD.MDC's). The fact that there can be (at least) three views argues that the current wording is unacceptably ambiguous, but I don't think Marshall Rose, et al. should continue to think they were dreaming when they interpreted it differently. There are three important statements. I will abridge, but not paraphrase (Those who want the missing words can get them from the NIC): "It [GOSIP] is mandatory for all new network implementations..." "Although GOSIP mandates OSI implementations in products, it does not preclude the acquisition of additional (perhaps vendor specific) networking capabilities in that same equipment." "For a period of two years, agencies are permitted to procure alternative interoperable protocols, but they must provide a mechanism for those protocols to interoperate with OSI protocols as well." Statement 1 says that new acquisitions must include GOSIP protocols. Statement 2 says that any additional protocols which are needed may also be acquired. Statement 3 is a partial waiver of statement 1, that is, if an agency already has an interoperable set of protocols (for example, DOD with TCP/IP), then it can buy the current suite in lieu of GOSIP protocols for a period of two years. After this time, GOSIP protocols are mandatory for such agencies as well, but, under statement 2, they can continue to acquire their current set of interoperable protocols indefinitely. Please let me repeat that I agree that other interpretations can easily be made of the current statements, and that even if no other changes were made to the applicability statement, changes to avoid the existing massive ambiguity would be essential. This is why GOSIP is out for comment, but I think there is enough material on this particular point to assist in the rewrite. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703160310.AA09770%40gateway.mitre.org] <1987031517102800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) Newsgroups: mod.protocols.tcp-ip Subject: Re: A defense of GOSIP Message-ID: <8703160310.AA09770@gateway.mitre.org> Date: Sun, 15-Mar-87 22:10:28 EST Article-I.D.: gateway.8703160310.AA09770 Posted: Sun Mar 15 22:10:28 1987 Date-Received: Mon, 16-Mar-87 05:04:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa As per your comments about ISO people and their not using thier own technology for mailing lists. I won't speak for other ISO groups, but the group I'm in (ANSI X3S3.3, aka Transport and Network Layer, the folks that brought you IP (ISO) and TP4) does use the ARPANET and TCP/IP for its mailing. Granted, it's not X.400, but we are more interested in doing our jobs than showing off our own stuff. We are also more that happy to consider what is good (and what is not so good) in the DoD protocol world. By the way, our hot items right now are routing and other management functions, and YES we have looked at EGP and GGP etc., and YES we find some problems there. Also, we are meeting jointly from time to time (actually the first such time will be this April) with the INENG folks (yup, fuzzballs, swamps, etc.). If anyone is interested in getting in on our mailing list, send request to x3s33-interest@mitre-gateway.arpa. (To be honest, I have met many of the folks that give ISO a bad name. But there are SOME good people in standards). Paul Tsuchiya ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).16-Mar-87.06:25:05.VAX.DARPA.MIL] <1987031601250500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL (Dennis G. Perry) Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: Date: Mon, 16-Mar-87 06:25:05 EST Article-I.D.: Posted: Mon Mar 16 06:25:05 1987 Date-Received: Tue, 17-Mar-87 01:50:26 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Steve, you made an interesting statement in your note: "The cost of running the Arpanet is comparable to running the Telenet public network which carries ten times as many user packets." Two questions. (1) How much does it cost to run Telenet? I know how much it cost to run the Arpanet. (2) How many packets does Telenet carry? If you will send me those data, I will put both the Arpanet figures and the Telenet figures on the net. If your statements are true, then it will help us in future designs. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987031601250501> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Mon 16 Mar 87 03:26:02-PST Posted-Date: Mon 16 Mar 87 06:25:05-EST Received: by vax.darpa.mil (5.54/5.51) id AA03280; Mon, 16 Mar 87 06:25:08 EST Date: Mon 16 Mar 87 06:25:05-EST From: Dennis G. Perry Subject: Re: GOSIP vs TCP/IP To: mckee@mitre.arpa Cc: karn@flash.bellcore.com, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "H. Craig McKee " of Wed, 11 Mar 87 08:23:19 EST Steve, you made an interesting statement in your note: "The cost of running the Arpanet is comparable to running the Telenet public network which carries ten times as many user packets." Two questions. (1) How much does it cost to run Telenet? I know how much it cost to run the Arpanet. (2) How many packets does Telenet carry? If you will send me those data, I will put both the Arpanet figures and the Telenet figures on the net. If your statements are true, then it will help us in future designs. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703161253.AA14930%40vlsi-a.mitre.org] <1987031602534900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: scott@GATEWAY.MITRE.ORG Newsgroups: mod.protocols.tcp-ip Subject: GOSIP Message-ID: <8703161253.AA14930@vlsi-a.mitre.org> Date: Mon, 16-Mar-87 07:53:49 EST Article-I.D.: vlsi-a.8703161253.AA14930 Posted: Mon Mar 16 07:53:49 1987 Date-Received: Tue, 17-Mar-87 01:37:43 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa I just read the mail from Mike Corrigan giving the definitive(?) interpretation of GOSIP. I am reminded of when the government had a requirement that all computers acquired after a certain grace period have an ASCII processing mode (exacting when this was I can't remember). This hit alot of computer users hard since they were locked into machines produced by a well known manufacturer that used EBCDIC. This well known manufacturer, seeing his market being yanked away from him, provided machines that had an ASCII mode. No one ever used this mode but it was there in case the bean counters asked. Now I'm not saying that GOSIP is heading down the same road, but if it is this is a good way for software houses to pick up a quick buck for software that may never be used and therefore not that good. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870316100923.9.DCP%40KOYAANISQATSI.S4CC.Symbolics.COM] <1987031605090000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP/IP header question Message-ID: <870316100923.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Mon, 16-Mar-87 10:09:00 EST Article-I.D.: KOYAANIS.870316100923.9.DCP Posted: Mon Mar 16 10:09:00 1987 Date-Received: Tue, 17-Mar-87 02:11:34 EST References: <8703110409.AA22963@BORAX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Date: Tue, 10 Mar 87 23:09:57 est From: jbvb@BORAX.LCS.MIT.EDU (James B. VanBokkelen) I don't see any reason to send obsolete information; our implementation updates both ACKs and Window to the values current at the instant the packet is sent. Of course, this does mean we have to re-checksum the packet, but we have to do this anyway if a packet gets partially ack'ed (which you'd better be prepared for...) Nit: Indeed, you'd better be prepared for it, but you don't have to rechecksum if you don't reshuffle the data around. Not reshuffling is paramount to sending old+new data, which the spec allows. Note that it *does* seem like a good idea (not mine) to retain the IP 'identification' so that fragments can be assembled from any instance of (re)transmission of a given packet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703161624.AA20671%40ucbvax.Berkeley.EDU] <1987031606124500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: mod.protocols.tcp-ip Subject: Re: A defense of GOSIP Message-ID: <8703161624.AA20671@ucbvax.Berkeley.EDU> Date: Mon, 16-Mar-87 11:12:45 EST Article-I.D.: ucbvax.8703161624.AA20671 Posted: Mon Mar 16 11:12:45 1987 Date-Received: Tue, 17-Mar-87 02:12:06 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa The way some people are attracted by picutres of cars-of-the-future makes me wonder whether there isn't a third term to the classic "a pessimist sees the glass as half empty, an optimist sees the glass as half full" routine: what kind of -ist thinks the glass runneth over? (Don't try "futurist," I've got too nasty a retort for that one in storage.) Getting back to what we're supposed to be talking about, however (i.e., the December, 1986 GOSIP Draft, NOT what OSI "will" be), let the record show that I don't even see a half-empty glass, I see a centipede named Achilles. (And I thank the sender of the Subj: msg for exposing a few extra heels.) cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987031606124501> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 16 Mar 87 08:17:03-PST Date: 16 Mar 1987 11:12:45 EST Subject: Re: A defense of GOSIP From: Michael Padlipsky To: Karl Auerbach cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: (Message from "Karl Auerbach " of Thu 12 Mar 87 18:48:01-PST) The way some people are attracted by picutres of cars-of-the-future makes me wonder whether there isn't a third term to the classic "a pessimist sees the glass as half empty, an optimist sees the glass as half full" routine: what kind of -ist thinks the glass runneth over? (Don't try "futurist," I've got too nasty a retort for that one in storage.) Getting back to what we're supposed to be talking about, however (i.e., the December, 1986 GOSIP Draft, NOT what OSI "will" be), let the record show that I don't even see a half-empty glass, I see a centipede named Achilles. (And I thank the sender of the Subj: msg for exposing a few extra heels.) cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703161640.AA20840%40ucbvax.Berkeley.EDU] <1987031606280500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <8703161640.AA20840@ucbvax.Berkeley.EDU> Date: Mon, 16-Mar-87 11:28:05 EST Article-I.D.: ucbvax.8703161640.AA20840 Posted: Mon Mar 16 11:28:05 1987 Date-Received: Tue, 17-Mar-87 02:43:44 EST References: <8703111323.AA12283@mitre.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa It's "apples and eggplants" to compare TCP/IP header sizes with X.25's, as a rudimentary knowledge of Layering should show. Rather than be coy and make Marshall Rose or Mike Corrigan do the explaining, I'll accept the risk that Steve Silverman won't believe me and try to save time by pointing out that X.25 is at the "bottom" of L3 whereas IP is at the "top" of L3 and TCP is L4 (and subsumes some of the functionality of L5). Or, as I'd prefer to express it, X.25 is L I, TCP/IP L II. So any inference that going X.25 saves bits is fallacious (unless the argument is that we should go with the CCITT Suite, which isn't OSI and hence isn't what the argument is about). Aside to Dennis Perry: if you want the ARPANET to carry ten times as many packets as it does at the same (subnet) cost, you could always make the maximum packet size be .1 of what it is and come pretty close, especially if you ban character- at-a-time Telnet. (This one might be artichokes and brussels sprouts, actually, given all the possible differentiae--though maybe not, since it's still in essence attempting to compare the incommensurate.) cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987031606280501> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 16 Mar 87 08:31:52-PST Date: 16 Mar 1987 11:28:05 EST Subject: Re: GOSIP vs TCP/IP From: Michael Padlipsky To: H. Craig McKee cc: karn@FLASH.BELLCORE.COM (Phil R. Karn), tcp-ip@SRI-NIC.ARPA In-Reply-To: <8703111323.AA12283@mitre.ARPA> It's "apples and eggplants" to compare TCP/IP header sizes with X.25's, as a rudimentary knowledge of Layering should show. Rather than be coy and make Marshall Rose or Mike Corrigan do the explaining, I'll accept the risk that Steve Silverman won't believe me and try to save time by pointing out that X.25 is at the "bottom" of L3 whereas IP is at the "top" of L3 and TCP is L4 (and subsumes some of the functionality of L5). Or, as I'd prefer to express it, X.25 is L I, TCP/IP L II. So any inference that going X.25 saves bits is fallacious (unless the argument is that we should go with the CCITT Suite, which isn't OSI and hence isn't what the argument is about). Aside to Dennis Perry: if you want the ARPANET to carry ten times as many packets as it does at the same (subnet) cost, you could always make the maximum packet size be .1 of what it is and come pretty close, especially if you ban character- at-a-time Telnet. (This one might be artichokes and brussels sprouts, actually, given all the possible differentiae--though maybe not, since it's still in essence attempting to compare the incommensurate.) cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703161727.AA15084%40gateway.mitre.org] <1987031607274500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@GATEWAY.MITRE.ORG (Phill Gross) Newsgroups: mod.protocols.tcp-ip Subject: Re: A defense of GOSIP Message-ID: <8703161727.AA15084@gateway.mitre.org> Date: Mon, 16-Mar-87 12:27:45 EST Article-I.D.: gateway.8703161727.AA15084 Posted: Mon Mar 16 12:27:45 1987 Date-Received: Tue, 17-Mar-87 02:45:17 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Marshall, I set up Arpanet mail access for several very appreciative folks on the ANSI X3S3.3 Network Layer Group. I also started a mailing list for their group, which they most definitely use. I've found X3S3.3 to be a very strong technical group which stays tuned into Internet developments, as they should be for their work. In fact, we have scheduled a joint day with S3.3 at the next DARPA Internet Engineering Task Force to discuss our common interests. It doesn't always need to be Us and Them. Phill Gross Mitre ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703161949.AA25990%40jupiter.mitre.org] <1987031609495300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8703161949.AA25990@jupiter.mitre.org> Date: Mon, 16-Mar-87 14:49:53 EST Article-I.D.: jupiter.8703161949.AA25990 Posted: Mon Mar 16 14:49:53 1987 Date-Received: Tue, 17-Mar-87 04:13:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 52 Approved: tcp-ip@sri-nic.arpa Amidst all of the flaming about the scope and applicability statements of GOSIP, I would like to throw in a quick technical suggestion. With regards to the NSAP Address formats. I am concerned that the single format is too narrow. It implies a single type of hierarchy (org.net.net-address) which may or may not reflect organizations real routing structures. For instance, what if an organization is physically seperated into several locations. Then either that organization must have several organization ids (in which case it is no longer an organization id), or they must split up their subnet ID field to reflect the seperate locations. Unfortunately, if manufacturers boxes are not able to parse elements in the subnet ID field................. Also, while GOSIP does let DoD define its own address space, there is still a potential problem with economics. What if 15 vendors decide to implement GOSIP, and 10 of them set up their NSAP parsing code and routing tables to look like what is in GOSIP. Suddenly, if DoD people want their own address format, they must either go to one of the leftover vendors (less "multi-vendor") or have a special development from one or more of the 10 vendors. Both ways cost dollars. The real fear here, though, is future interoperability (what's that, right?). It is concievable to me that static routing could be made to work with dynamic routing if one were very careful how they did things. However, I don't see how it could work if the dynamic routing parsed their NSAP Addresses differently than the static routing (or indeed, if two dynamic routing schemes parsed them differently). What I have in mind is very simple, and is essentially the ARPA subnet-addressing scheme applied to the full address. Have the vendors set up their routing tables, routines, and software that downloads tables into the routers so that every entry in the table has a mask associated with it which says "if the NSAP to be routed matches this routing table entry after the mask is applied, then route this way". There should also be a second mask which tells where the SNPA is imbedded in the NSAP, if there is one. The NSAP structure in GOSIP could even be the default if someone didn't wanted to get involved in defining their own NSAP structure. This is a very easy way to provide a lot of generality at a very low cost. By the way, this idea is very much in line with the ANSI X3S3.3 (network and transport layer) philosophy on addresses and routing. Paul Tsuchiya tsuchiya@mitre-gateway.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703170849.AA08094%40topaz.rutgers.edu] <1987031622494300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8703170849.AA08094@topaz.rutgers.edu> Date: Tue, 17-Mar-87 03:49:43 EST Article-I.D.: topaz.8703170849.AA08094 Posted: Tue Mar 17 03:49:43 1987 Date-Received: Wed, 18-Mar-87 05:38:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa I was surprised by the address structure in GOSIP as well. Some of it could be fixed by changing the commentary, rather than the actual spec. E.g. there are two-byte codes for organization and "subnet". The commentary suggests that the organization will be a Department and the subnet a particular installation. The problem with that is that many installations are large enough to need more than one Ethernet, and therefore they will need subnetting. I have to believe that 32 bits of address is enough. But I think it would be good to suggest that at least part of the subnet should be available for use within large sites. I was also somewhat surprised to see the Ethernet address (in some IEEE incarnation) used as the lowest level piece of the address. I thought there was a concensus that this is a bad idea. Without careful management, changing a bad Ethernet controller card is going to change your protocol address. Yes, I know there are solutions to this, but I think a separate protocol address would be cleaner. I sure hope there is good name server technology behind this proposal. Even if we ignore the prefix that says "this is a U.S. Govt address", we have 10 bytes of address, the last 6 of which are essentially a random number. I sure wouldn't want to have to remember this. I find that I remember the Internet addresses of lots of my machines, and that this is very useful for all sorts of testing and debugging situations. I'm trying to think what the design of the GOSIP version of netwatch is going to look like. Finally, have you given any thought to non-governmental applications? I mean, the whole point of ISO is supposed to be that commercially- supported implementations will exist. So it seems counter-productive to have a standard that doesn't allow for non-governmental uses. As far as I can see, the address format only allows for government agencies. I think you might want to reserve some address space for compatible commercial or educational users, and define a way for allocating it within the GOSIP structure, much as DoD reserved address space for commercial and educational uses within the Internet addressscho'\an ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).17-Mar-87.06:09:21.VAX.DARPA.MIL] <1987031701092100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL (Dennis G. Perry) Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: Date: Tue, 17-Mar-87 06:09:21 EST Article-I.D.: Posted: Tue Mar 17 06:09:21 1987 Date-Received: Wed, 18-Mar-87 06:49:54 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Mike, I like artichokes, but cannot stand brussels sprouts. :-) Actually, aside from the packet size question, which is a real variable left out of many of the off the cuff remarks about performance, I would like to know how the Arpanet compares to commercial offerings. My experience is that it fares well (present limited capacity in the net excepted). dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703171742.AA21857%40.cgcha..uucp] <1987031707422500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: whna@cgcha.UUCP (Heinz Naef) Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8703171742.AA21857@.cgcha..uucp> Date: Tue, 17-Mar-87 12:42:25 EST Article-I.D.: .8703171742.AA21857 Posted: Tue Mar 17 12:42:25 1987 Date-Received: Thu, 19-Mar-87 01:02:21 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Path: cgcha!whna From: whna@cgcha.UUCP (Heinz Naef) Newsgroups: mod.protocols.tcp-ip,comp.dcom.lans Subject: TCP/IP software for HyperChannel II (HyperBus) on IBM mainframes Keywords: TCP/IP, Hyperchannel, Hyperbus, IBM Message-ID: <314@cgcha.UUCP> Date: 17 Mar 87 17:42:23 GMT Organization: CIBA-GEIGY AG, FO/WIRZ/WRZ, CH-4002 Basel, Switzerland Lines: 10 Does anyone know about a TCP/IP protocol package and the appropriate driver for IBM 30xx mainframes to interface to Network Systems Corp.'s HyperChannel II controller/media without using NETEX? As far as we know, this type of attachment exists for Cray's UNICOS operating system and for VME-Bus based systems using the IKON board set. Any hints - via e-mail whna@cgcha.UUCP - will be highly appreciated. Thanks, Heinz. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703172016.AA00515%40jupiter.mitre.org] <1987031710164700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG Newsgroups: mod.protocols.tcp-ip Subject: x3s33 requests Message-ID: <8703172016.AA00515@jupiter.mitre.org> Date: Tue, 17-Mar-87 15:16:47 EST Article-I.D.: jupiter.8703172016.AA00515 Posted: Tue Mar 17 15:16:47 1987 Date-Received: Thu, 19-Mar-87 01:32:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa I made a boo-boo. Would people please send their requests to get on the x3s33-interest list to: x3s33-request@mitre-gateway.arpa. Thanks. PT ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703182124.AA16425%40hoptoad.uucp] <1987031811244600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gnu@hoptoad.UUCP (John Gilmore) Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP and required features that are never used Message-ID: <8703182124.AA16425@hoptoad.uucp> Date: Wed, 18-Mar-87 16:24:46 EST Article-I.D.: hoptoad.8703182124.AA16425 Posted: Wed Mar 18 16:24:46 1987 Date-Received: Fri, 20-Mar-87 02:34:20 EST References: <8703161253.AA14930@vlsi-a.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa scott@GATEWAY.MITRE.ORG writes: > I am reminded of when the government had a requirement that > all computers acquired after a certain grace period have an ASCII processing > mode (exacting when this was I can't remember). This hit alot of computer > users hard since they were locked into machines produced by a well known > manufacturer that used EBCDIC. This well known manufacturer, seeing his market > being yanked away from him, provided machines that had an ASCII mode. No one > ever used this mode but it was there in case the bean counters asked. My memory may be faulty, but I recall that a good part of the reason that Sun started supporting bisync and X.25 and all that other jazz was because many government buyers couldn't buy Suns unless they supported all that stuff, even if they never used it. I have no doubt that the well-intentioned clods pushing GOSIP will have the same effect. More tax money wasted. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703182237.AA14428%40ucbvax.Berkeley.EDU] <1987031812073300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mfidelma@CC5.BBN.COM ("Miles R. Fidelman") Newsgroups: mod.protocols.tcp-ip Subject: ISO ES to IS Info Sought Message-ID: <8703182237.AA14428@ucbvax.Berkeley.EDU> Date: Wed, 18-Mar-87 17:07:33 EST Article-I.D.: ucbvax.8703182237.AA14428 Posted: Wed Mar 18 17:07:33 1987 Date-Received: Fri, 20-Mar-87 02:33:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Does anyone know which working group is working on the End System to Intermediate System protocols, and who a contact would be. For that matter, does anyone know where I can obtain copies of any draft materials? Thanks much, Miles Fidelman BBN Communications Corp. (mfidelman@bbn.com) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987031812073301> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Wed 18 Mar 87 14:16:44-PST To: tcp-ip@sri-nic.ARPA Subject: ISO ES to IS Info Sought Date: 18 Mar 87 17:07:33 EST (Wed) From: "Miles R. Fidelman" Does anyone know which working group is working on the End System to Intermediate System protocols, and who a contact would be. For that matter, does anyone know where I can obtain copies of any draft materials? Thanks much, Miles Fidelman BBN Communications Corp. (mfidelman@bbn.com) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703182353.AA01134%40xanth.cs.odu.edu] <1987031813531100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: john@xanth.cs.odu.EDU (John Owens) Newsgroups: mod.protocols.tcp-ip Subject: Re: Black Art: sendmail.cf files Message-ID: <8703182353.AA01134@xanth.cs.odu.edu> Date: Wed, 18-Mar-87 18:53:11 EST Article-I.D.: xanth.8703182353.AA01134 Posted: Wed Mar 18 18:53:11 1987 Date-Received: Fri, 20-Mar-87 05:22:21 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa [This failed the first time at SRI-NIC: tcp-ip@SRI-NIC.ARPA: Forwarding error: Cannot find indirect file - No such device ?!] > one proven sendmail.cf file for each of the major environments: > Internet only, UUCP only, a combination of the two > --Frank For the combination internet/uucp sendmail.cf file, it would be good if someone could come up with a general, automated, way of sending mail destined for domains primarily under UUCP via UUCP, and others via the Internet. For those that would prefer UUCP when a site is on both, some massaging of the first part of the pathalias output might be in order. I imagine, though, that most Internet sites would prefer Internet, but would rather send mail that will eventually end up on UUCP themselves, rather than forwarding it to seismo. Maybe if the UUCP Project would put out a simple list of the second level domains that are registered with them and not on the Internet or csnet, in the form: ADELIE.COM AMD.COM ATT.COM ... VORTEX.COM it would be usable as a sendmail class.... (This would be especially good for those UUCP Zone domains that don't have an Internet forwarder!) I'd love to help, but as I'm not physically on the Internet.... John Owens Old Dominion University - Norfolk, Virginia, USA john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET +1 804 440 3915 old uucp: {seismo,harvard,sun,hoptoad}!xanth!john ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703190739.AA11616%40gateway.mitre.org] <1987031821392400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@GATEWAY.MITRE.ORG (Phill Gross) Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP and required features that are never used Message-ID: <8703190739.AA11616@gateway.mitre.org> Date: Thu, 19-Mar-87 02:39:24 EST Article-I.D.: gateway.8703190739.AA11616 Posted: Thu Mar 19 02:39:24 1987 Date-Received: Fri, 20-Mar-87 05:52:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa > From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore) > > ... the well-intentioned clods pushing GOSIP ... > I'd appreciate it if the comments on this list remained at a technical level. A well founded technical argument would have no need for this type of personal attack. Phill Gross Mitre Corp. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703192131.AA05404%40oliveb.ATC.OLIVETTI.COM] <1987031911311100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jerry@oliveb.ATC.OLIVETTI.COM (Jerry F Aguirre) Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8703192131.AA05404@oliveb.ATC.OLIVETTI.COM> Date: Thu, 19-Mar-87 16:31:11 EST Article-I.D.: oliveb.8703192131.AA05404 Posted: Thu Mar 19 16:31:11 1987 Date-Received: Sat, 21-Mar-87 07:03:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 66 Approved: tcp-ip@sri-nic.arpa Newsgroups: mod.protocols.tcp-ip Subject: Connecting two ethernet segments References: <8703031250.AA05275@topaz.rutgers.edu> Reply-To: jerry@oliveb.UUCP (Jerry F Aguirre) Distribution: world Organization: Olivetti ATC; Cupertino, Ca In article <8703031250.AA05275@topaz.rutgers.edu> hedrick@seismo.CSS.GOV@topaz.rutgers.edu (Charles Hedrick) writes: >Let us suppose that you have the following configuration: > >--------- network 192.1.1 > | router, with addresses 192.1.1.1 and 192.1.2.2 > | --------- network 192.1.2 > | router, with addresses 192.1.2.1 and 192.1.3.1 > | >--------- network 192.1.3 > >Now suppose you have a 4.2 machine on network 192.1.2, whose own >address is 192.1.2.10. Here is the way I would set up routing. If this is referring to the article about the Bridge GS/3-M then it is wrong. Unlike protocol dependent routers the GS/3-M routes at the ethernet address level. It doesn't know TCP/IP from Decnet and therefor doesn't have an IP network address. Thus you can not specify it in a routing table. Logically the Bridge GS/3-M acts as a repeater allowing you to extend an ethernet beyond the single segment limits. The difference is that it is a selective repeater so it filters out ethernet addresses that don't need to go to the other segment. (It also allows the other segment to be a LOT further away than a standard repeater would.) Segments connected by a repeater are logically on the same network. I spoke to a Bridge representative about this and he said that we would have to re-address the two networks we were planning to connect so that they all had the same network number. He suggested going to a type A address instead of a type C to allow more than 254 hosts/network. Is this a real requirement? Ignoring the Bridge product, suppose that two departments each set up independent ethernets. They properly register their IP addresses so there is no conflict. Later they decide to attach the two segments together either directly or thru a repeater. This seems a common enough occurrence to me. If TCP/IP requires that they renumber all their hosts then this sounds like a significant flaw in the addressing and routing scheme. Would it be enough to specify routing to the network via itself? There is an local entry automatically added that is equivalent to: route add net mynet myhostname Would something like: route add net othernet myhostname be enough to tell it that "othernet" is actually available via the same interface? Someone out there must have had to connect two previously independent ethernet segments. Jerry Aguirre Systems Administration Olivetti ATC ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703191717.a011387%40Huey.UDEL.EDU] <1987031912174700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: ISO ES to IS Info Sought Message-ID: <8703191717.a011387@Huey.UDEL.EDU> Date: Thu, 19-Mar-87 17:17:47 EST Article-I.D.: Huey.8703191717.a011387 Posted: Thu Mar 19 17:17:47 1987 Date-Received: Sat, 21-Mar-87 07:00:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Miles, ANSI X3S3.3 committee. Contact Lyman Chapin (chapin@a.isi.edu). Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703200509.AA15526%40topaz.rutgers.edu] <1987031919095300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8703200509.AA15526@topaz.rutgers.edu> Date: Fri, 20-Mar-87 00:09:53 EST Article-I.D.: topaz.8703200509.AA15526 Posted: Fri Mar 20 00:09:53 1987 Date-Received: Sat, 21-Mar-87 09:11:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa Yes, your theory is correct. You can make any network be treated as local by doing route add 0 (in 4.2. In 4.3 I think there is some minor difference, like omitting the 0.) I thought somebody had explained this before. 4.2 works like this: route-packet (destination-address) lookup destination-address as a host in host routing table [entries that show with "H" in flags field of netstat -r] if that fails, lookup network(destination-address) as a network in network routing table [entries without an "H"] if that fails, look for default route if that fails, say destination unreachable now we have a route. If the metric is 1 or larger [metric is the last field in the "route add" comment. You can tell from the route command because routes with a metric >= 1 will show a "G" in the flags field], this is a normal gateway entry. Send packet to the host listed in the gateway field. If the metric is 0 [route add command ended in zero, or in some versions, the metric was omitted. netstat -r does not show "G" in the flags field], this is a "route to the interface". Send packet out the interface listed in the interface column. If interface is an Ethernet, use ARP. Note that the gateway address (gateway field in netstat -r) is irrelevant in the case of a route to the interface. The route add command uses that address only to figure out which interface to associate with the route. So when setting up a route to an interface, the simplest approach is to use your own address on that network. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703201433.AA02131%40gateway.mitre.org] <1987032004332100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG.UUCP Newsgroups: mod.protocols.tcp-ip Subject: routing and bridges Message-ID: <8703201433.AA02131@gateway.mitre.org> Date: Fri, 20-Mar-87 09:33:21 EST Article-I.D.: gateway.8703201433.AA02131 Posted: Fri Mar 20 09:33:21 1987 Date-Received: Sun, 22-Mar-87 21:05:01 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa Per you query about connecting two ethernet segments with different IP network numbers with bridges which route on ethernet address.... It seems you have two problems. First, getting your own IP-level gateways to know about the other net, and second, getting other boxes in the world to know that both nets are available through one interface. If you can solve the first problem, then the second problem is easy because you can address both nets via EGP (maybe I shouldn't assume EGP here, but I am guessing that RIP et al. can also do this). In solving the first problem, I would first ask whether the Bridges pass on broadcast ethernet addresses. If they do, then ARP can be used by the IP-level gateway to pass messages on to hosts irregardless of the IP-network number. If not, then somehow the IP-gateway has to have a local list of ethernet-address/IP-address tuples. Either way, the problem is a local one, and shouldn't REQUIRE both ethernets to have different network addresses (REQUIRE in the sense that the IP routing architecture breaks if you don't have one address). Also, if you want more that 254 hosts, to to a type B rather than a type A address. Type B will give you 65534 addresses. Type A network numbers are reserved for those REALLY BIG networks. Paul F. Tsuchiya ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703201606.AA11905%40spam.istc.sri.com] <1987032006061900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gds@SPAM.ISTC.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: breakdown of SMTP traffic Message-ID: <8703201606.AA11905@spam.istc.sri.com> Date: Fri, 20-Mar-87 11:06:19 EST Article-I.D.: spam.8703201606.AA11905 Posted: Fri Mar 20 11:06:19 1987 Date-Received: Sun, 22-Mar-87 21:06:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa I'm sorry to interrupt this useful discussion of GOSIP, but I have a brief question regarding arpanet/milnet congestion. Does anyone have any figures (even ballpark figures) for: * the % of TCP packets that are SMTP packets that cross the arpanet/milnet * the % of those packets which are going to arpanet list-of-lists mailing list recipients, or to the list itself * the % of those packets which are going to non list-of-lists mailing lists which have sizable readerships (e.g. egp-people, gwmon) * the % of those packets which are "conversational" (ie. don't fall into the previous two categories) I am assuming that the last two categories are contributing to congestion to a larger degree than the second category. --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12287918755.13.AI.CLIVE%40MCC.COM] <1987032006334200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AI.CLIVE@MCC.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Is it just me, or... Message-ID: <12287918755.13.AI.CLIVE@MCC.COM> Date: Fri, 20-Mar-87 11:33:42 EST Article-I.D.: MCC.12287918755.13.AI.CLIVE Posted: Fri Mar 20 11:33:42 1987 Date-Received: Sun, 22-Mar-87 21:06:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa ... are other people getting two copies of many of the messages to TCP-IP? Is there a problem with a mailer somewhere? Sounds like the classic case of a fatal error aborting delivery midway through the list, and the mailer starting over without eliminating the addresses that were already successful. Clive ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703201653.AA12382%40spam.istc.sri.com] <1987032007154500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jmainini@SPAM.ISTC.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8703201653.AA12382@spam.istc.sri.com> Date: Fri, 20-Mar-87 12:15:45 EST Article-I.D.: spam.8703201653.AA12382 Posted: Fri Mar 20 12:15:45 1987 Date-Received: Sun, 22-Mar-87 21:08:27 EST References: <8703192131.AA05404@oliveb.ATC.OLIVETTI.COM> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Jerry, Here at SRI on our floor we have 4 DEC LAN 100's. They cost around 8K, and build thier own routing tables. You don't have to renumber any nets, as they don't care. They just know who is on either side and will send where ever is appropriate. They are a store, filter, and forward device that will pass any protocol or net number if that node exists on the other side. We have had these bridges around a year, and havn't had any trouble so far. John Mainini ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703201752.AA18400%40oddjob.uchicago.edu] <1987032007523900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: matt@ODDJOB.UCHICAGO.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: (none) Message-ID: <8703201752.AA18400@oddjob.uchicago.edu> Date: Fri, 20-Mar-87 12:52:39 EST Article-I.D.: oddjob.8703201752.AA18400 Posted: Fri Mar 20 12:52:39 1987 Date-Received: Sat, 28-Mar-87 06:21:43 EST References: <8703192131.AA05404@oliveb.ATC.OLIVETTI.COM> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: matt@oddjob.uchicago.edu (Matt Crawford) Distribution: world Organization: Very Little Lines: 51 Approved: tcp-ip@sri-nic.arpa jerry@oliveb.ATC.OLIVETTI.COM (Jerry F Aguirre) writes: ) ... Ignoring the Bridge product, suppose that ) two departments each set up independent ethernets. They properly ) register their IP addresses so there is no conflict. Later they decide ) to attach the two segments together either directly or thru a repeater. ) ... ) Would it be enough to specify routing to the network via itself? ) Would something like: ) ) route add net othernet myhostname ) ) be enough to tell it that "othernet" is actually available via the same ) interface? Someone out there must have had to connect two previously ) independent ethernet segments. You bet someone has. As I told Charles in private ail, the "USAN" satellite network links many networks around the country using Bridge/Vitalink filtering forwarders. It does suffice in 4.2 and 4.3 to do route add othernet myname 0 where the final number, commonly believed to be a hopcount, is actually for the flags field. Zero means "not a route to a gateway". Trouble comes, however, if there is a host on othernet that you want to use as a gateway to some more distant destination. The kernel cannot be convinced that the gateway is reachable, even though it can communicate with the gateway. If, as Charles pointed out in his replies to me, the gateway will do promiscuous arp, or if some other host on the net will do proxy arp for the gateways, the day is saved and you can make a default route to your own interface with route add default myname 0 An alternative which I used in the early days of USAN was to add a pseudo-interface driver for each net reachable by bridges. This driver just put its output packets on the queue of the real eternet interface, while serving as a marker to the routing ioctl code that gateways on those nets were indeed reachable. Because of the net hassle of trying to solve this problem all around the country, the final answer wound up being to connect each bridge to a stub ethernet that linked it only with an IP level forwarder. ________________________________________________________ Matt University matt@oddjob.uchicago.edu Crawford of Chicago {astrovax,ihnp4}!oddjob!matt ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703202035.AA01617%40braden.isi.edu] <1987032010354000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Garden Implements Message-ID: <8703202035.AA01617@braden.isi.edu> Date: Fri, 20-Mar-87 15:35:40 EST Article-I.D.: braden.8703202035.AA01617 Posted: Fri Mar 20 15:35:40 1987 Date-Received: Sun, 22-Mar-87 17:03:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa Is this a real requirement? Ignoring the Bridge product, suppose that two departments each set up independent ethernets. They properly register their IP addresses so there is no conflict. Later they decide to attach the two segments together either directly or thru a repeater. This seems a common enough occurrence to me. If TCP/IP requires that they renumber all their hosts then this sounds like a significant flaw in the addressing and routing scheme. Is it a flaw in the design of a rake that it does not perform very well as a shovel?? The Internet architecture includes gateways to connect different networks. One of the essential advantages of a gateway over a level-2 bridge is the separation of address spaces. If you need a rake, buy a rake, don;t complain that your shovel cannot be adapted. Perhaps the moral is... beware of the glib tongues of shovel salesmen. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703202122.AA03862%40hoquiam] <1987032011220700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: don@SRI-LEWIS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Is it just me, or... Message-ID: <8703202122.AA03862@hoquiam> Date: Fri, 20-Mar-87 16:22:07 EST Article-I.D.: hoquiam.8703202122.AA03862 Posted: Fri Mar 20 16:22:07 1987 Date-Received: Sun, 22-Mar-87 17:07:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa > ... are other people getting two copies of many of the messages > to TCP-IP? Is there a problem with a mailer somewhere? Sounds > like the classic case of a fatal error aborting delivery midway > through the list, and the mailer starting over without eliminating > the addresses that were already successful. > Clive >------- I am also receiving multiple copies, as are many of my office mates here! Don Holman SRI International ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703202137.AA16093%40spam.istc.sri.com] <1987032012284300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: robert@SPAM.ISTC.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Is it just me, or... Message-ID: <8703202137.AA16093@spam.istc.sri.com> Date: Fri, 20-Mar-87 17:28:43 EST Article-I.D.: spam.8703202137.AA16093 Posted: Fri Mar 20 17:28:43 1987 Date-Received: Sun, 22-Mar-87 17:04:21 EST References: <12287918755.13.AI.CLIVE@MCC.COM> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa To quote a recently heard personage "Me too! Me too!" You bet I am getting duplicate messages. I think it is one (or more) particular mailer(s) which is/are doing it, but so far I have no hard facts. I'm keeping an eye on it though, so I can get some hard facts and get the problem fixed. Robert Allen, robert@spam.istc.sri.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12288041852.6.VAF%40C.CS.CMU.EDU] <1987032017495400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Vince.Fuller@C.CS.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: DEC LANbridge query... Message-ID: <12288041852.6.VAF@C.CS.CMU.EDU> Date: Fri, 20-Mar-87 22:49:54 EST Article-I.D.: C.12288041852.6.VAF Posted: Fri Mar 20 22:49:54 1987 Date-Received: Sun, 22-Mar-87 18:16:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Has anyone managed to decode the protocol used to talk to these things to the point of being able to write a program to query them? We are using them to tie together the various segments of our departmental network and would like to be able to query them to help locate errant hosts. We have the RBMS software for VMS but really need to develop some application code of our own. Unfortunately, the (DEC Proprietary) documentation we have is worse than useless, since our observations of the LANbridge control packets look almost nothing like what the documentation claims. The documentation claims that the "Bridge Management Protocol" is built on top of the Maintenance Operations Protocol (MOP), but no where in the DEC/DNA MOP documentation can I find an obvious place where this might be wedged in (and observations of the control packets again bear show little resemblance to any MOP packets). Has anyone else been down this path or can suggest documentation I might reference? We'd like to find out what all of these funny packet values actually mean, rather than just brute-force using the binary values in our monitoring programs. Thanks in advance, Vince Fuller, CMU-CSD ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703211727.AA16149%40ucbvax.Berkeley.EDU] <1987032107280900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jon@CS.UCL.AC.UK.UUCP Newsgroups: mod.protocols.tcp-ip Subject: talking of and to gateways and bridges Message-ID: <8703211727.AA16149@ucbvax.Berkeley.EDU> Date: Sat, 21-Mar-87 12:28:09 EST Article-I.D.: ucbvax.8703211727.AA16149 Posted: Sat Mar 21 12:28:09 1987 Date-Received: Sun, 22-Mar-87 21:38:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 36 Approved: tcp-ip@sri-nic.arpa We at UCL witness an interesting problem. Because it is regarded as AOK for gateways to talk to each other using unreliable IP, and gateways don't reassemble, only a minimal amount of info can get between gateways at any one go. The internet has got so large now, that when a reasonable percentage of sites are up, we disappear off the end of routing updates, and go unreachable. Why not get the gateways to reassemble packets destined for them (ie when they are acting as hosts/end points after all), I hear you cry? Nope, cos thats just a short term fix til there are more than (say) 1500 bytes worth of update. Why not use a transport protocol between IP and EGP/GGP/IGP/RIP etc? Yes, but which one. Well, there's TCP/RDP/ and who knows how many transaction protocols out there waiting to pounce. [This may also make your routing algorithms cleaner.] Well, use the same one as you use for talking management to your gateway from your hosts for now, like TCP. Surely it's not beyond the wit of gatewayfarers to put TCP into their boxes, since half of them build TCP terminal concentrators already. Our attitude to manageing MAC Bridges ~like~ the DEC LAN Bridge 100, is to put a separate management network (eg V24 or V35/ RS422 lines or whatever) in the ether/coax/fibre bundle, and use that to talk telnet/tcp blah into the Bridge. That's no solace to people with proprietry stuff in the Bridge, but I think it's the way things will go. Next years answer is: use ECMA ROS over REX, because it's gonna be a standard, and I am a biased European. Jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032113540000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Sat 21 Mar 87 20:58:27-PST Received: from UKANVAX.BITNET by wiscvm.wisc.edu on 03/21/87 at 19:52:28 CST Date: Sat, 21 Mar 87 19:54 CST From: Subject: addition to mailing list To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, CONLEY Please add me to your mailing list. If possible, I would prefer that digests be sent to "csvax1@ukanvax.bitnet". Thanks, Dennis R. Conley Systems Programmer Computer Science Dept University of Kansas CSNET: conley@csvax.cs.ukans.edu BITNET: conley@ukanvax ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703220511.AA23686%40ucbvax.Berkeley.EDU] <1987032115540000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CONLEY@UKANVAX.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: addition to mailing list Message-ID: <8703220511.AA23686@ucbvax.Berkeley.EDU> Date: Sat, 21-Mar-87 20:54:00 EST Article-I.D.: ucbvax.8703220511.AA23686 Posted: Sat Mar 21 20:54:00 1987 Date-Received: Sun, 22-Mar-87 16:42:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Please add me to your mailing list. If possible, I would prefer that digests be sent to "csvax1@ukanvax.bitnet". Thanks, Dennis R. Conley Systems Programmer Computer Science Dept University of Kansas CSNET: conley@csvax.cs.ukans.edu BITNET: conley@ukanvax ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032117122900> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Sat 21 Mar 87 09:21:30-PST Received: from ucl-cs-pyr1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa05585; 21 Mar 87 17:17 WET To: tcp-ip@sri-nic.arpa Subject: talking of and to gateways and bridges Date: Sat, 21 Mar 87 17:12:29 +0000 From: Jon Crowcroft We at UCL witness an interesting problem. Because it is regarded as AOK for gateways to talk to each other using unreliable IP, and gateways don't reassemble, only a minimal amount of info can get between gateways at any one go. The internet has got so large now, that when a reasonable percentage of sites are up, we disappear off the end of routing updates, and go unreachable. Why not get the gateways to reassemble packets destined for them (ie when they are acting as hosts/end points after all), I hear you cry? Nope, cos thats just a short term fix til there are more than (say) 1500 bytes worth of update. Why not use a transport protocol between IP and EGP/GGP/IGP/RIP etc? Yes, but which one. Well, there's TCP/RDP/ and who knows how many transaction protocols out there waiting to pounce. [This may also make your routing algorithms cleaner.] Well, use the same one as you use for talking management to your gateway from your hosts for now, like TCP. Surely it's not beyond the wit of gatewayfarers to put TCP into their boxes, since half of them build TCP terminal concentrators already. Our attitude to manageing MAC Bridges ~like~ the DEC LAN Bridge 100, is to put a separate management network (eg V24 or V35/ RS422 lines or whatever) in the ether/coax/fibre bundle, and use that to talk telnet/tcp blah into the Bridge. That's no solace to people with proprietry stuff in the Bridge, but I think it's the way things will go. Next years answer is: use ECMA ROS over REX, because it's gonna be a standard, and I am a biased European. Jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703220422.AA13307%40buita.bu.edu] <1987032118220200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jsol@buit1.bu.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story] Message-ID: <8703220422.AA13307@buita.bu.edu> Date: Sat, 21-Mar-87 23:22:02 EST Article-I.D.: buita.8703220422.AA13307 Posted: Sat Mar 21 23:22:02 1987 Date-Received: Sun, 22-Mar-87 16:41:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 43 Approved: tcp-ip@sri-nic.arpa This won't be news to any of you who are bitnet people, but I think it will be to some others. Bitnet has a routing system based on static lookup tables (hey, IBM software rules!). Updated versions of these tables are generated once a month and sent all over bitnet... One problem with this is that the huge amount of data swamps several major network links (like PSUVM<->OHSTVMA). Recent mail from our fearless leaders at BITNIC follows: From LINKFAIL@BITNIC.BITNET Tue Mar 17 09:23:08 1987 Received: by psuvax1.UUCP (4.12/4.7) id AA18551; Tue, 17 Mar 87 09:22:57 est Message-Id: <8703171422.AA18551@psuvax1.UUCP> Received: From bitnic.bitnet By psuvax1.bitnet ; 17 Mar 87 14:22:37 GMT Received: by BITNIC (Mailer X1.23b) id 6139; Tue, 17 Mar 87 09:08:23 EST Date: Tue, 17 Mar 87 09:01:39 EST Reply-To: Scott Earley Sender: BITNIC LINKFAIL List From: Scott Earley Subject: "March" routing tables To: "Dave Eckhardt (Penn SU Comp Sci VLSI Dev" What were once known as the "March routing tables" have been twice delayed from delivery -- both irregular circumstances. The proposed solution to the immediate dilemma is as follows: Tables for all sites on the Penn State side of the PSU-Ohio link will be sent through the UCBCMSA--CUNYVM link as usual. Tables for all sites on the Ohio side of the PSU-Ohio link will be put on tape and mailed overnight to a pre-appointed individual who will reintroduce them into the network from there. This will eliminate sending about 200 tables through the PSUVM--OHSTVMA link. In the future, those tables will be generated by a site on the far side, as a more permanent solution. ... That's right. Mag tape. --Daemon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703220951.aa03730%40SEM.BRL.ARPA] <1987032204514500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dpk@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP (Re)action? Message-ID: <8703220951.aa03730@SEM.BRL.ARPA> Date: Sun, 22-Mar-87 09:51:45 EST Article-I.D.: SEM.8703220951.aa03730 Posted: Sun Mar 22 09:51:45 1987 Date-Received: Mon, 23-Mar-87 01:46:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 92 Approved: tcp-ip@sri-nic.arpa [Disclaimer: The following represent my personal professional opinion and does not necessarily represent the opinions of BRL or the DoD.] Concerning Connections between TCP/IP and PC's ---------------------------------------------- There are several possible connections between TCP/IP and PC's. There are several implementations of the DOD protocol suite for PC, both public domain (MIT & by Phil Karn for HAM packet radio) and vendor supported (FTP Software in Mass., maybe others as well, check with the NIC's vendor list). In addition there is TCP/IP support for PC's by means of smart interface cards that put TCP/IP into firmware. I believe there are several of these as well, 3Com being the one that comes immediately to mind. More details can be be dragged out of the NIC and the industry magazines. Try looking at Ungerman-Bass, Micom/Interlan, CMC, Network Solutions? PC's are now fairly easily tied into a network of Super-Mini's to Supercomputers using TCP/IP from any of these sources. This can even include true remote file systems using the Sun Microsystems NFS software for the PC (it uses the 3Com hardware as a base). A variety of vendors now make TCP/IP virtual terminal servers which provide a means to easily access other hosts via RS232 as a terminal. While this does not make a PC a real host on the network, it can be a cheap way for several PC's to access the network by sharing a terminal server and using it much like a modem. UNIX is becoming the second operating system of the PC and most versions of UNIX already support the TCP/IP protocol suite. Opinion and Caveat ------------------ [in the following read "ISO" to mean protocols referenced in the GOSIP] My position on this is a pragmatic one. I feel there is undoubtedly potential benefit to migration to (a possibly modified or amended) ISO protocol suite in the future. However, now is not the time to be purchasing ISO protocols for production use as the GOSIP is indicating. There is at least a decade of research in the TCP/IP protocol suite. This includes not only the investigation of the architectural features, but also the algorithms used in the actual operation of a large internet. These are lessons that are not necessarily transferable to the ISO protocol suite due to differences in design. These kinds of lessons can only be learned over time with controlled introduction, first into an experienced research community and then into larger communities as the specifications and unspecified algorithms solidify. You must keep the initial communities small because there will changes necessary, and you need fast turnaround between recommendation and implementation. I work in a research lab, and I expect us to start experimentation and testing of the ISO protocols to start this year at our institution. I don't expect them to work or to be complete. My gut feeling is that five years from now is the earliest time to expect reasonably robust and complete ISO protocol suite implementations. The government cannot afford to turn itself into an alpha or beta test site which is what would undoubtedly happen. As any consumer can tell you there is always a danger in buying the first units of a new product. If you are interested in reliability and predictable performance, you wait for the second printing, the next model year, or the later revision of the product. In short, I am not anti-ISO, but adoption of ISO on large scale at this time is a costly mistake. It will prove to be buggy, incomplete, and there will be unforseen incompatablities, and since its never been used on a large scale it will have scaling problems as systems are interconnected for the first time. The government should hold off widespread usage in production usage until the ISO suite has had a chance to mature, stabilize, and "prove itself" in the R&D community. I would be happy to talk to you further by phone or mail, and to help review your article for correctness regarding the TCP/IP suite. I feel its critical that people get the correct information about this. Cheers, -Doug- (301)-278-6678 AV 298-6678 FTS 939-6678 Internet: Postal: Douglas P. Kingston III Advanced Computer Systems Team Systems Engineering and Concepts Analysis Division U.S. Army Ballistic Research Laboratory Attn: SLCBR-SECAD (Kingston) APG, MD 21005 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703221542.AA29364%40ucbvax.Berkeley.EDU] <1987032205365100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story] Message-ID: <8703221542.AA29364@ucbvax.Berkeley.EDU> Date: Sun, 22-Mar-87 10:36:51 EST Article-I.D.: ucbvax.8703221542.AA29364 Posted: Sun Mar 22 10:36:51 1987 Date-Received: Mon, 23-Mar-87 01:48:45 EST References: <8703220422.AA13307@buita.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa "on the far side" conjures up visions of Gary Larson's delightful creatures manipulating that huge database in the sky. Actually the folks in BITNET are experiencing a wonderful thing: success. They pay for it by having to mail magtapes around once in a while. The Arpanauts also have success and pay for it by byzantine dynamic behavior. The pain we all go through to get network services must be worth the gain, eh? We all need more money and bright ideas to make the networks work better. A dose of money could help to give our brains a rest... Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032205365101> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 22 Mar 87 07:39:02-PST Date: 22 Mar 1987 10:36:51 EST Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story] From: Dan Lynch To: TCP-IP@SRI-NIC.ARPA In-Reply-To: <8703220422.AA13307@buita.bu.edu> "on the far side" conjures up visions of Gary Larson's delightful creatures manipulating that huge database in the sky. Actually the folks in BITNET are experiencing a wonderful thing: success. They pay for it by having to mail magtapes around once in a while. The Arpanauts also have success and pay for it by byzantine dynamic behavior. The pain we all go through to get network services must be worth the gain, eh? We all need more money and bright ideas to make the networks work better. A dose of money could help to give our brains a rest... Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).22-Mar-87.16:07:25.VAX.DARPA.MIL] <1987032211072500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL (Dennis G. Perry) Newsgroups: mod.protocols.tcp-ip Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story] Message-ID: Date: Sun, 22-Mar-87 16:07:25 EST Article-I.D.: Posted: Sun Mar 22 16:07:25 1987 Date-Received: Tue, 24-Mar-87 01:43:39 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa I would like to counter Dan's suggestion that money is a solution. In fact I think we have too much money chasing too few brains. If we would use our brains to figure out what is 'right', we could probably do with the money we have. Unfortunately, as is often the case in economics, it it not the amount of money available, it is the improper distribution of same. Brains and money have at least one thing in common, they should both be put to work, and if left idle, will both lead to mischief! dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032211072501> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Sun 22 Mar 87 13:57:14-PST Posted-Date: Sun 22 Mar 87 16:07:25-EST Received: by vax.darpa.mil (5.54/5.51) id AA00886; Sun, 22 Mar 87 16:07:29 EST Date: Sun 22 Mar 87 16:07:25-EST From: Dennis G. Perry Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story] To: LYNCH@a.isi.edu Cc: TCP-IP@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "Dan Lynch " of 22 Mar 1987 10:36:51 EST I would like to counter Dan's suggestion that money is a solution. In fact I think we have too much money chasing too few brains. If we would use our brains to figure out what is 'right', we could probably do with the money we have. Unfortunately, as is often the case in economics, it it not the amount of money available, it is the improper distribution of same. Brains and money have at least one thing in common, they should both be put to work, and if left idle, will both lead to mischief! dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703222256.AA03443%40ucbvax.Berkeley.EDU] <1987032212400300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hinden@ccv.bbn.COM (Robert Hinden) Newsgroups: mod.protocols.tcp-ip Subject: Re: talking of and to gateways and bridges Message-ID: <8703222256.AA03443@ucbvax.Berkeley.EDU> Date: Sun, 22-Mar-87 17:40:03 EST Article-I.D.: ucbvax.8703222256.AA03443 Posted: Sun Mar 22 17:40:03 1987 Date-Received: Tue, 24-Mar-87 01:29:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Jon, I don't think it OK for gateways to not do IP reassembly. They should be able to reassemble datagrams addressed directly to them. We are currently working to add this to the Butterfly and LSI-11 gateways. In principal I agree with you that we should think about using a transport protocol to carry our routing data. The problem I see is that most of our current protocols try very hard to deliver the old data before the new data. This is less than optimum for routing data, where it is important the deliver the new data and forget about delivering the old data. I hope we will never get to the point where we send our routing around by magtape like BITNET. Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032212400301> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Sun 22 Mar 87 14:46:57-PST To: Jon Crowcroft cc: tcp-ip@sri-nic.ARPA, hinden@ccv.bbn.com Subject: Re: talking of and to gateways and bridges In-reply-to: Your message of Sat, 21 Mar 87 17:12:29 +0000. Date: 22 Mar 87 17:40:03 EST (Sun) From: Robert Hinden Jon, I don't think it OK for gateways to not do IP reassembly. They should be able to reassemble datagrams addressed directly to them. We are currently working to add this to the Butterfly and LSI-11 gateways. In principal I agree with you that we should think about using a transport protocol to carry our routing data. The problem I see is that most of our current protocols try very hard to deliver the old data before the new data. This is less than optimum for routing data, where it is important the deliver the new data and forget about delivering the old data. I hope we will never get to the point where we send our routing around by magtape like BITNET. Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703230041.AA04545%40ucbvax.Berkeley.EDU] <1987032214253000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: mod.protocols.tcp-ip Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story] Message-ID: <8703230041.AA04545@ucbvax.Berkeley.EDU> Date: Sun, 22-Mar-87 19:25:30 EST Article-I.D.: ucbvax.8703230041.AA04545 Posted: Sun Mar 22 19:25:30 1987 Date-Received: Tue, 24-Mar-87 01:38:07 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Dennis, My (unspoken) use for the money was not for more research, but for more simple capacity. As a matter of fact, depending on what your goal is, you should be able to create a model of allocating your dollar budget that maximizes "happiness" by giving some to research and some to capacity. When you see lots of good research ideas you fund research, else just pump the money into capacity. If that is the model you have been implementing inthe past then there must have been a lot of great research going on in the past few years... Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032214253001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 22 Mar 87 16:27:46-PST Date: 22 Mar 1987 19:25:30 EST Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story] From: Dan Lynch To: Dennis G. Perry cc: LYNCH@A.ISI.EDU, TCP-IP@SRI-NIC.ARPA In-Reply-To: Dennis, My (unspoken) use for the money was not for more research, but for more simple capacity. As a matter of fact, depending on what your goal is, you should be able to create a model of allocating your dollar budget that maximizes "happiness" by giving some to research and some to capacity. When you see lots of good research ideas you fund research, else just pump the money into capacity. If that is the model you have been implementing inthe past then there must have been a lot of great research going on in the past few years... Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).23-Mar-87.07:15:18.VAX.DARPA.MIL] <1987032302151800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story] Message-ID: Date: Mon, 23-Mar-87 07:15:18 EST Article-I.D.: Posted: Mon Mar 23 07:15:18 1987 Date-Received: Wed, 25-Mar-87 03:44:59 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa Dan, not sure there has been any model, or any great research either. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032302151801> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Mon 23 Mar 87 04:16:01-PST Posted-Date: Mon 23 Mar 87 07:15:18-EST Received: by vax.darpa.mil (5.54/5.51) id AA01929; Mon, 23 Mar 87 07:15:21 EST Date: Mon 23 Mar 87 07:15:18-EST From: Dennis G. Perry Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story] To: LYNCH@a.isi.edu Cc: PERRY@vax.darpa.mil, TCP-IP@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "Dan Lynch " of 22 Mar 1987 19:25:30 EST Dan, not sure there has been any model, or any great research either. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703231941.AA09022%40flash.bellcore.com] <1987032309413000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP (Re)action? Message-ID: <8703231941.AA09022@flash.bellcore.com> Date: Mon, 23-Mar-87 14:41:30 EST Article-I.D.: flash.8703231941.AA09022 Posted: Mon Mar 23 14:41:30 1987 Date-Received: Wed, 25-Mar-87 04:38:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa A correction: my TCP/IP code for the IBM PC is NOT in the public domain; I have copyrighted it. However, I grant blanket permission for NONprofit, NONcommercial, NONgovernmental, NONmilitary copying and use ONLY. Amateur radio, educational and public service applications (e.g., Red Cross) are fine. (I really got a kick out of taking something originally developed for the military and subverting and perverting it for constructive purposes... :-) Otherwise I agree with Doug's posting. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703232218.AA11722%40mnetor.UUCP] <1987032312182100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: henry@utzoo.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP cookbook? Message-ID: <8703232218.AA11722@mnetor.UUCP> Date: Mon, 23-Mar-87 17:18:21 EST Article-I.D.: mnetor.8703232218.AA11722 Posted: Mon Mar 23 17:18:21 1987 Date-Received: Wed, 25-Mar-87 02:25:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Does anybody know of a good book on the nitty-gritty of implementing TCP/IP? (If there's an obvious choice, sorry about that, I'm a relative newcomer to this stuff.) I'm not after history and philosophy, which I gather is the main thrust of Padlipsky's book (which I haven't had a chance to read yet), and I want something deeper than a ten-page paper. I'm aware of the Protocol Handbook, and have it on order, but my impression is that it's more of a collection of standards than a unified discussion. I have Comer's book "Internetworking with XINU", but it leaves too many things out (and worse, doesn't tell you that it's doing so). Suggestions? Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703232221.AA13270%40devvax.TN.CORNELL.EDU] <1987032312210700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: swb@DEVVAX.TN.CORNELL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: HP9000/550 Message-ID: <8703232221.AA13270@devvax.TN.CORNELL.EDU> Date: Mon, 23-Mar-87 17:21:07 EST Article-I.D.: devvax.8703232221.AA13270 Posted: Mon Mar 23 17:21:07 1987 Date-Received: Wed, 25-Mar-87 01:02:57 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa Wollongong is the only vendor listed in the Vendors List as supplying TCP/IP for an HP9000 model 550. Does anyone know of any others? Thanks ... Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032312431800> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Tue 24 Mar 87 04:03:36-PST Received: from relay2.cs.net by RELAY.CS.NET id aa20583; 24 Mar 87 6:57 EST Received: from pitt by RELAY.CS.NET id af16784; 24 Mar 87 6:50 EST Received: by pitt (5.51/4.7) id AA27312; Mon, 23 Mar 87 17:43:18 EST Date: Mon, 23 Mar 87 17:43:18 EST From: Bob Hoffman Newsgroups: mod.protocols.tcp-ip Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story] Summary: Expires: References: <8703220422.AA13307@buita.bu.edu> Sender: Reply-To: Bob Hoffman Followup-To: Distribution: world Organization: Univ. of Pittsburgh Computer Science Keywords: Apparently-To: tcp-ip@sri-nic.arpa In article <8703220422.AA13307@buita.bu.edu> jsol@buit1.bu.EDU writes: > From: Scott Earley > > ... Tables > for all sites on the Ohio side of the PSU-Ohio link will be put > on tape and mailed overnight to a pre-appointed individual who > will reintroduce them into the network from there. > ... > >That's right. Mag tape. > >--Daemon Never underestimate the bandwidth of a station wagon full of magtapes! -- Bob Hoffman, N3CVL {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman Pitt Computer Science hoffman%pitt@relay.cs.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).23-Mar-87.18:09:59.VAX.DARPA.MIL] <1987032313095900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP (Re)action? Message-ID: Date: Mon, 23-Mar-87 18:09:59 EST Article-I.D.: Posted: Mon Mar 23 18:09:59 1987 Date-Received: Wed, 25-Mar-87 00:56:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Seems to me you are taking good advantage also of the Arpanet, which was developed for militray purposes, why do you deny your obligations to it. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032313095901> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Mon 23 Mar 87 15:12:08-PST Posted-Date: Mon 23 Mar 87 18:09:59-EST Received: by vax.darpa.mil (5.54/5.51) id AA03961; Mon, 23 Mar 87 18:10:04 EST Date: Mon 23 Mar 87 18:09:59-EST From: Dennis G. Perry Subject: Re: GOSIP (Re)action? To: karn@flash.bellcore.com Cc: dpk@brl.arpa, well!slf@lll-lcc.arpa, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "karn@flash.bellcore.com (Phil R. Karn)" of Mon, 23 Mar 87 14:41:30 est Seems to me you are taking good advantage also of the Arpanet, which was developed for militray purposes, why do you deny your obligations to it. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703232326.AA18131%40seismo.CSS.GOV] <1987032313511000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: michael@labtam.OZ.AU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: PC LANs, NETBIOS and UNIX Message-ID: <8703232326.AA18131@seismo.CSS.GOV> Date: Mon, 23-Mar-87 18:51:10 EST Article-I.D.: seismo.8703232326.AA18131 Posted: Mon Mar 23 18:51:10 1987 Date-Received: Wed, 25-Mar-87 03:08:10 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Could someone let be know the status of the NETBIOS over TCP/IP working group, and how to contact them? I last saw a reference to this group late last year. Also has anyone linked a decent PC LAN, such as Novell Netware, to a Unix computer as a file-server, or know of any such planned links? All that I have heard so far suggests that the Novell and 3Com software can co-exist with TCP/IP for TELNET and FTP but thats it. Is there nothing better and more integrated out there? thanks ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703240511.AA27920%40ucbvax.Berkeley.EDU] <1987032318550100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: PC LANs, NETBIOS and UNIX Message-ID: <8703240511.AA27920@ucbvax.Berkeley.EDU> Date: Mon, 23-Mar-87 23:55:01 EST Article-I.D.: ucbvax.8703240511.AA27920 Posted: Mon Mar 23 23:55:01 1987 Date-Received: Wed, 25-Mar-87 05:53:32 EST References: <8703232326.AA18131@seismo.CSS.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Michael, Perhaps the best way to get in touch with the NETBIOS activity is to contact Lee LeBarre at Mitre. (CEL@mitre-bedford.arpa) Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032318550101> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 23 Mar 87 21:01:15-PST Date: 23 Mar 1987 23:55:01 EST Subject: Re: PC LANs, NETBIOS and UNIX From: Dan Lynch To: Michael Podhorodecki cc: tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU, cel@MITRE-BEDFORD.ARPA In-Reply-To: <8703232326.AA18131@seismo.CSS.GOV> Michael, Perhaps the best way to get in touch with the NETBIOS activity is to contact Lee LeBarre at Mitre. (CEL@mitre-bedford.arpa) Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703241224.AA03823%40ucbvax.Berkeley.EDU] <1987032400105200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jon@CS.UCL.AC.UK.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.E Message-ID: <8703241224.AA03823@ucbvax.Berkeley.EDU> Date: Tue, 24-Mar-87 05:10:52 EST Article-I.D.: ucbvax.8703241224.AA03823 Posted: Tue Mar 24 05:10:52 1987 Date-Received: Thu, 26-Mar-87 01:15:43 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 45 Approved: tcp-ip@sri-nic.arpa /* Written 2:08 pm Mar 23, 1987 by tcp-ip@pyr1 in pyr1:tcp-ip */ /* ---------- "Re: [dae%psuvax1.bitnet@jade.Berkeley.E" ---------- */ Received: from ucl-cs-nss by pyr1.Cs.Ucl.AC.UK with SMTP id aa16134; 23 Mar 87 14:06 WET Received: from sri-nic.arpa by mv1.Cs.Ucl.AC.UK via Satnet with SMTP id aa05875; 23 Mar 87 14:00 WET Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Mon 23 Mar 87 04:16:01-PST Posted-Date: Mon 23 Mar 87 07:15:18-EST Received: by vax.darpa.mil (5.54/5.51) id AA01929; Mon, 23 Mar 87 07:15:21 EST Date: Mon 23 Mar 87 07:15:18-EST From: "Dennis G. Perry" Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story] To: LYNCH@edu.isi.a Cc: PERRY@mil.darpa.vax, TCP-IP@arpa.sri-nic, perry@mil.darpa.vax Message-Id: In-Reply-To: Message from "Dan Lynch " of 22 Mar 1987 19:25:30 EST Dan, not sure there has been any model, or any great research either. dennis ------- /* End of text from pyr1:tcp-ip */ If you look at the original Internet design issues, the idea of fate sharing and a tactical network, and so on, determined gateway/routers were connectionless. A bit like the old CSMA versus token arguments, in a WAN context, the consequence of this design decision is that (without resource reservation a la X.25) you HAVE to over-engineer for bandwidth and delay, or it just doesn't work. Witness the UK Academic X.25 network availability under extreme load is 99% plus, with MTTR in the minutes, and MTBFs in the days range, compared with the Internet under extreme load, where we were seeing availabilities of 20-30% and MTTRs of hours and MTBFs in the hour range. I look forward to seeing some intermediate scheme ("connectionish networks") for the tactical+low-congestion internet. Jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D24-Mar-87.08:37:09.CERF] <1987032403370000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: PC LANs, NETBIOS and UNIX Message-ID: <[A.ISI.EDU]24-Mar-87.08:37:09.CERF> Date: Tue, 24-Mar-87 08:37:00 EST Article-I.D.: <[A.ISI.EDU]24-Mar-87.08:37:09.CERF> Posted: Tue Mar 24 08:37:00 1987 Date-Received: Thu, 26-Mar-87 05:24:00 EST References: <8703232326.AA18131@seismo.CSS.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa NETBIOS group has completed its work and produced two RFCs (1001 and 1002) which are available from the NIC or by FTP (I think). Stan Ames was the stimulus for this group's founding. sra@Mitre-bedford.arpa Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032403370001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 24 Mar 87 05:38:31-PST Date: 24 Mar 1987 08:37-EST Sender: CERF@A.ISI.EDU Subject: Re: PC LANs, NETBIOS and UNIX From: CERF@A.ISI.EDU To: munnari!labtam.oz!michael@SEISMO.CSS.GOV Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]24-Mar-87 08:37:09.CERF> In-Reply-To: <8703232326.AA18131@seismo.CSS.GOV> NETBIOS group has completed its work and produced two RFCs (1001 and 1002) which are available from the NIC or by FTP (I think). Stan Ames was the stimulus for this group's founding. sra@Mitre-bedford.arpa Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D24-Mar-87.08:39:32.CERF] <1987032403390000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP/IP cookbook? Message-ID: <[A.ISI.EDU]24-Mar-87.08:39:32.CERF> Date: Tue, 24-Mar-87 08:39:00 EST Article-I.D.: <[A.ISI.EDU]24-Mar-87.08:39:32.CERF> Posted: Tue Mar 24 08:39:00 1987 Date-Received: Thu, 26-Mar-87 07:18:37 EST References: <8703232218.AA11722@mnetor.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Henry, there isn't a book of the type you desire, so far as I know. there is an opportunity for some author out there... Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032403390001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 24 Mar 87 05:40:55-PST Date: 24 Mar 1987 08:39-EST Sender: CERF@A.ISI.EDU Subject: Re: TCP/IP cookbook? From: CERF@A.ISI.EDU To: mnetor!utzoo!henry@SEISMO.CSS.GOV Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]24-Mar-87 08:39:32.CERF> In-Reply-To: <8703232218.AA11722@mnetor.UUCP> Henry, there isn't a book of the type you desire, so far as I know. there is an opportunity for some author out there... Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703241353.AA07652%40mitre.ARPA] <1987032403530600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <8703241353.AA07652@mitre.ARPA> Date: Tue, 24-Mar-87 08:53:06 EST Article-I.D.: mitre.8703241353.AA07652 Posted: Tue Mar 24 08:53:06 1987 Date-Received: Thu, 26-Mar-87 06:28:28 EST References: <[A.ISI.EDU]15-Mar-87.01:04:54.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 11 Approved: tcp-ip@sri-nic.arpa The reply from Steve Silverman to Vint Cerf concerning X.25 resets follows: *** Reply to note of 03/22/87 12:25 From: Steve Silverman Subject: Re: GOSIP vs TCP/IP Re: X.25 reset: If the endpoint processor running one side of the X.25 session fails, then info is lost. The same is true if the processor running TCP or TP -4 fails. Hopefully, the user is notified in either case. Steve. * * Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703241359.AA07821%40mitre.ARPA] <1987032403595000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <8703241359.AA07821@mitre.ARPA> Date: Tue, 24-Mar-87 08:59:50 EST Article-I.D.: mitre.8703241359.AA07821 Posted: Tue Mar 24 08:59:50 1987 Date-Received: Thu, 26-Mar-87 07:44:23 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 17 Approved: tcp-ip@sri-nic.arpa The reply from Steve Silverman to Dennis Perry concerning the cost of, and traffic over, Telenet follows: *** Reply to note of 03/22/87 12:28 From: Steve Silverman Subject: Re: GOSIP vs TCP/IP Response to Dennis Perry: In 1983 the Telenet public network cost in the neighborhood of 85 - 100 million dollars/year. This included development, PAD support, and interest on debt. About a year ago the Telenet public net handled about 1.5 billion user data packets /month. This does not include layer 3RR packets, which would be the equivalent of TCP acknowledgments, retransmittals of dropped packets, or network maintenance (GGP packets). * * Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032404060000> Received: from eglin-vax by SRI-NIC.ARPA with TCP; Tue 24 Mar 87 08:40:43-PST Date: 24 Mar 87 10:06:00 CST From: "CALVIN R GEORGE" Subject: Need Info on SMTP To: "tcp-ip" Reply-To: "CALVIN R GEORGE" E G L I N A F B I N T E R O F F I C E M E M O R A N D U M Date: 24-Mar-1987 09:30am CST From: CALVIN R GEORGE GEORGE Dept: Tel No: 882-5498 TO: _MAILER! ( _DDN[TCP-IP@SRI-NIC] ) CC: FRANK M WOODALL ( WOODALL ) CC: BRIAN C. BRAZIEL ( BRAZIEL ) CC: BARBARA J LINN ( LINN ) CC: HERBERT SPIES ( SPIES ) Subject: Need Info on SMTP Is there a Public Domain version of SMTP ( both Client and Server ) available? As you can tell by the headers on this message, we are using DEC's ALL-IN-1 and Wollongong's WIN/VX. The interface between ALL-IN-1 and WIN/VX is a local mod to an ALL-IN-1 script. All of the ALL-IN-1 mail features such as FORWARD, AUTOANSWER, READ RECEIPT, etc. are not supported, or should I say, do not work. After some investigation, we have decided that the best way to provide these services is to write SMTP servers/clients that know about ALL-IN-1. Has any work been done in this area? Any knowledge/source for SMTP code would at least prevent us from having to write SMTP code from scratch. Please reply to me directly. I will provide any responses to interested parties upon request. Calvin George AD/KRSSD Eglin AFB, FL ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703241434.AA29530%40unix.macc.wisc.edu] <1987032404345700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dorl@uwmacc.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8703241434.AA29530@unix.macc.wisc.edu> Date: Tue, 24-Mar-87 09:34:57 EST Article-I.D.: unix.8703241434.AA29530 Posted: Tue Mar 24 09:34:57 1987 Date-Received: Thu, 26-Mar-87 07:44:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Path: uwmacc!dorl From: dorl@uwmacc.UUCP (Michael Dorl) Newsgroups: mod.protocols.tcp-ip,comp.dcom.lans Subject: Bruknet Protocols Message-ID: <1282@uwmacc.UUCP> Date: 24 Mar 87 14:34:56 GMT Organization: UWisconsin-Madison Academic Comp Center Lines: 14 I have a Ethernet supporting both the TCP/IP and DECNet protocols. A user in Biochemistry wishes to attach some German machinery using something called Bruknet to this network. The manual seems to indicate that it coexists with DECNet. It appears to use Ethernet type 10-10 or 4112 (base 10). This type number does not conflict with IP but its not listed in the Assigned Numbers section of the DDN Protocol Handbook. Has anyone used this product? Is it known to coexist with both DECNet and TCP/IP? Michael Dorl dorl@unix.macc.wisc.edu dorl@wiscmacc.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D24-Mar-87.10:07:04.CERF] <1987032405070000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <[A.ISI.EDU]24-Mar-87.10:07:04.CERF> Date: Tue, 24-Mar-87 10:07:00 EST Article-I.D.: <[A.ISI.EDU]24-Mar-87.10:07:04.CERF> Posted: Tue Mar 24 10:07:00 1987 Date-Received: Thu, 26-Mar-87 07:18:55 EST References: <8703241353.AA07652@mitre.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Steve (Silverman), Thanks for the reply on X.25 resets. My experiences with public or private data nets using X.25 is that under congestion conditions, X.25 does NOT recover from the problems causing resets while TCP and other end/end transport protocols often do recover. Consequently, most inter-computer applications use some kind of end/end protocol with retransmission (and, of course duplicate detection) above X.25. I took the earlier comments on X.25 to imply that raw X.25 is sufficient. I would have to say that my experience has been otherwise, except for terminal to host applications in which the user recovers from problems by re-typing his input (which behavior is also appropriate for noisy, unprotected dial-up access to PADs...). Do we have a difference of opinion? Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032405070001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 24 Mar 87 07:10:05-PST Date: 24 Mar 1987 10:07-EST Sender: CERF@A.ISI.EDU Subject: Re: GOSIP vs TCP/IP From: CERF@A.ISI.EDU To: mckee@MITRE.ARPA Cc: tcp-ip@SRI-NIC.ARPA, m15368%mwvm@MITRE.ARPA Message-ID: <[A.ISI.EDU]24-Mar-87 10:07:04.CERF> In-Reply-To: <8703241353.AA07652@mitre.ARPA> Steve (Silverman), Thanks for the reply on X.25 resets. My experiences with public or private data nets using X.25 is that under congestion conditions, X.25 does NOT recover from the problems causing resets while TCP and other end/end transport protocols often do recover. Consequently, most inter-computer applications use some kind of end/end protocol with retransmission (and, of course duplicate detection) above X.25. I took the earlier comments on X.25 to imply that raw X.25 is sufficient. I would have to say that my experience has been otherwise, except for terminal to host applications in which the user recovers from problems by re-typing his input (which behavior is also appropriate for noisy, unprotected dial-up access to PADs...). Do we have a difference of opinion? Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D24-Mar-87.10:10:18.CERF] <1987032405100000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <[A.ISI.EDU]24-Mar-87.10:10:18.CERF> Date: Tue, 24-Mar-87 10:10:00 EST Article-I.D.: <[A.ISI.EDU]24-Mar-87.10:10:18.CERF> Posted: Tue Mar 24 10:10:00 1987 Date-Received: Thu, 26-Mar-87 07:19:24 EST References: <8703241359.AA07821@mitre.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Seems to me that the Telenet costs are comparable to ARPANET costs since there is a factor of 10 difference in traffic and costs in both systems. Several years ago, we estimated that the PRICE of telenet service would be something like 3 times higher than the cost of ARPANET service. It would be very interesting to make the comparison again. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032405100001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 24 Mar 87 07:11:35-PST Date: 24 Mar 1987 10:10-EST Sender: CERF@A.ISI.EDU Subject: Re: GOSIP vs TCP/IP From: CERF@A.ISI.EDU To: mckee@MITRE.ARPA Cc: PERRY@VAX.DARPA.MIL, m15368%mwvm@MITRE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]24-Mar-87 10:10:18.CERF> In-Reply-To: <8703241359.AA07821@mitre.ARPA> Seems to me that the Telenet costs are comparable to ARPANET costs since there is a factor of 10 difference in traffic and costs in both systems. Several years ago, we estimated that the PRICE of telenet service would be something like 3 times higher than the cost of ARPANET service. It would be very interesting to make the comparison again. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703241658.AA06751%40ucbvax.Berkeley.EDU] <1987032406060000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: george@EGLIN-VAX.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Need Info on SMTP Message-ID: <8703241658.AA06751@ucbvax.Berkeley.EDU> Date: Tue, 24-Mar-87 11:06:00 EST Article-I.D.: ucbvax.8703241658.AA06751 Posted: Tue Mar 24 11:06:00 1987 Date-Received: Thu, 26-Mar-87 05:09:13 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "CALVIN R GEORGE" Distribution: world Organization: The ARPA Internet Lines: 43 Approved: tcp-ip@sri-nic.arpa E G L I N A F B I N T E R O F F I C E M E M O R A N D U M Date: 24-Mar-1987 09:30am CST From: CALVIN R GEORGE GEORGE Dept: Tel No: 882-5498 TO: _MAILER! ( _DDN[TCP-IP@SRI-NIC] ) CC: FRANK M WOODALL ( WOODALL ) CC: BRIAN C. BRAZIEL ( BRAZIEL ) CC: BARBARA J LINN ( LINN ) CC: HERBERT SPIES ( SPIES ) Subject: Need Info on SMTP Is there a Public Domain version of SMTP ( both Client and Server ) available? As you can tell by the headers on this message, we are using DEC's ALL-IN-1 and Wollongong's WIN/VX. The interface between ALL-IN-1 and WIN/VX is a local mod to an ALL-IN-1 script. All of the ALL-IN-1 mail features such as FORWARD, AUTOANSWER, READ RECEIPT, etc. are not supported, or should I say, do not work. After some investigation, we have decided that the best way to provide these services is to write SMTP servers/clients that know about ALL-IN-1. Has any work been done in this area? Any knowledge/source for SMTP code would at least prevent us from having to write SMTP code from scratch. Please reply to me directly. I will provide any responses to interested parties upon request. Calvin George AD/KRSSD Eglin AFB, FL ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032406323900> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Tue 24 Mar 87 10:36:18-PST Date: 24 Mar 1987 12:32:39 CST Subject: Fact or fiction From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Comments (especially corrections) welcome, DDN X.25 has always been a source of confusion to a lot of people. I want to get the record straight for once. There are two types of X.25 service in DDN; Basic and Standard. I don't want to get into the details of X.25, except where the DDN does interesting things. Basic X.25---This is the easy one. Hosts can use the DDN as if it was PDN. The D-bit, Q-bit, and M-bit are passed transparently through the network. The PSN End-to-end modules set up the the internal End-to-end connection to establish the X.25 virtual circuit. Each X.25 packet is viewed as a "meesage" by the End-to-End module. Multiple virtual circuits are allowed between a given host pair. What I would like to know is: Does the End-to-End module set up multiple End-to-End connections? If not, how does End-to-End sort which "messages" go with which virtual circuit. Standard X.25---This is the interesting one, available in PSN 6.0 initially. I assume here that if you use the Standard Service facilities field then the node "assumes" you to be placing an interoperable call and "all" the packets get passed to the IOP module. The IOP mudule is a logical 1822 host created in software. The user data is extracted from X.25 packets and used to form 1822 messages which are then passed to the End-to-End module for transmission through the network. The Q-bit and D-bit are not passed through the network. All X.25 acks are only locally significant. Each packet, or complete packet sequence is assumed to be an IP datagram. Therefore the M-bit is used locally to send a datagram larger than 1 packet as a complete packet sequence. The user data portions of the complete packet sequence are agregated into a single "message" which is then passed to the End-to-End module. A datagram, sent as a single packet or a complete sequence, cannot be longer than the 1822 maximum message length. Only one End-to- End connection can be established between any two host pairs at a given precedence level (let's leave precedence out now). Question: What will the node do if you try to set up a second virtual circuit between a host pair already having one End-to-End connection established? Will the node simply clear the call? A related IOP question: The 1822 spec call for the hardware to pad messages out to specific length boundaries (16 or 32 bits, I don't remember at the moment). If an 1822 host sends a message to another 1822 host, the hardware on the receiving end strips the padding. What happens if an 1822 host sends a message to a Standard X.25 host. The padding added by the hardware of the sending host is added to the user data in the X.25 packet (or sequence) that gets sent to the receiving host. The IP module of that host will then be passed a buffer of data as a datagram that's longer than the length field in the IP header says it should really be. This shouldn't be a problem, but I know of one host that got confused by this. It took the guy debugging the interface a couple of days to figure out the problem. Is all this really accurate or have I glitched a bit somewhere? A lot of this stuff will change with the advent of PSN 7.0. Anybody know exactly what's gonna change? Darrel B. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12288977750.61.AI.CLIVE%40MCC.COM] <1987032407305600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AI.CLIVE@MCC.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Duplicate messages Message-ID: <12288977750.61.AI.CLIVE@MCC.COM> Date: Tue, 24-Mar-87 12:30:56 EST Article-I.D.: MCC.12288977750.61.AI.CLIVE Posted: Tue Mar 24 12:30:56 1987 Date-Received: Thu, 26-Mar-87 07:25:01 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 51 Approved: tcp-ip@sri-nic.arpa Judging from the number of repsonses I received, I'm certainly not the only one receiving multiple copies of TCP-IP messages. I believe the problem can be isolated to SRI-NIC's mailer. Header info seems to indicate that SRI-NIC is receiving a single copy of each message, but for unknown reasons transmits two. This situation has existed for the better part of a year, at least. It is ironic that the mailing list which is most used to discuss the current state of net congestion is a contributor to it as well. Clive P.S. For the benefit of anybody who might (please!) be able to look into this, here is one recent example: Message 1 -- ************************ Return-Path: Received: from SRI-NIC.ARPA by MCC.COM with TCP; Mon 23 Mar 87 23:24:58-CST Received: from seismo.CSS.GOV by SRI-NIC.ARPA with TCP; Mon 23 Mar 87 15:27:27-PST Received: from munnari.oz by seismo.CSS.GOV (5.54/1.14) with UUCP id AA18131; Mon, 23 Mar 87 18:26:22 EST Message-Id: <8703232326.AA18131@seismo.CSS.GOV> Received: from labtam (via mulga) by munnari with SunIII (5.5) id AA03707; Tue, 24 Mar 87 00:54:01 EST Received: by labtam (4.12/1.7) id AA07943; Mon, 23 Mar 87 23:55:31 +1000 Date: Mon, 23 Mar 87 23:55:31 +1000 From: Michael Podhorodecki To: tcp-ip@sri-nic.arpa Subject: PC LANs, NETBIOS and UNIX ... Message 2 -- ************************ Return-Path: Received: from SRI-NIC.ARPA by MCC.COM with TCP; Tue 24 Mar 87 02:04:22-CST Received: from seismo.CSS.GOV by SRI-NIC.ARPA with TCP; Mon 23 Mar 87 15:27:27-PST Received: from munnari.oz by seismo.CSS.GOV (5.54/1.14) with UUCP id AA18131; Mon, 23 Mar 87 18:26:22 EST Message-Id: <8703232326.AA18131@seismo.CSS.GOV> Received: from labtam (via mulga) by munnari with SunIII (5.5) id AA03707; Tue, 24 Mar 87 00:54:01 EST Received: by labtam (4.12/1.7) id AA07943; Mon, 23 Mar 87 23:55:31 +1000 Date: Mon, 23 Mar 87 23:55:31 +1000 From: Michael Podhorodecki To: tcp-ip@sri-nic.arpa Subject: PC LANs, NETBIOS and UNIX ... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703241855.AA09116%40ucbvax.Berkeley.EDU] <1987032408323900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Fact or fiction Message-ID: <8703241855.AA09116@ucbvax.Berkeley.EDU> Date: Tue, 24-Mar-87 13:32:39 EST Article-I.D.: ucbvax.8703241855.AA09116 Posted: Tue Mar 24 13:32:39 1987 Date-Received: Thu, 26-Mar-87 01:59:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 54 Approved: tcp-ip@sri-nic.arpa Comments (especially corrections) welcome, DDN X.25 has always been a source of confusion to a lot of people. I want to get the record straight for once. There are two types of X.25 service in DDN; Basic and Standard. I don't want to get into the details of X.25, except where the DDN does interesting things. Basic X.25---This is the easy one. Hosts can use the DDN as if it was PDN. The D-bit, Q-bit, and M-bit are passed transparently through the network. The PSN End-to-end modules set up the the internal End-to-end connection to establish the X.25 virtual circuit. Each X.25 packet is viewed as a "meesage" by the End-to-End module. Multiple virtual circuits are allowed between a given host pair. What I would like to know is: Does the End-to-End module set up multiple End-to-End connections? If not, how does End-to-End sort which "messages" go with which virtual circuit. Standard X.25---This is the interesting one, available in PSN 6.0 initially. I assume here that if you use the Standard Service facilities field then the node "assumes" you to be placing an interoperable call and "all" the packets get passed to the IOP module. The IOP mudule is a logical 1822 host created in software. The user data is extracted from X.25 packets and used to form 1822 messages which are then passed to the End-to-End module for transmission through the network. The Q-bit and D-bit are not passed through the network. All X.25 acks are only locally significant. Each packet, or complete packet sequence is assumed to be an IP datagram. Therefore the M-bit is used locally to send a datagram larger than 1 packet as a complete packet sequence. The user data portions of the complete packet sequence are agregated into a single "message" which is then passed to the End-to-End module. A datagram, sent as a single packet or a complete sequence, cannot be longer than the 1822 maximum message length. Only one End-to- End connection can be established between any two host pairs at a given precedence level (let's leave precedence out now). Question: What will the node do if you try to set up a second virtual circuit between a host pair already having one End-to-End connection established? Will the node simply clear the call? A related IOP question: The 1822 spec call for the hardware to pad messages out to specific length boundaries (16 or 32 bits, I don't remember at the moment). If an 1822 host sends a message to another 1822 host, the hardware on the receiving end strips the padding. What happens if an 1822 host sends a message to a Standard X.25 host. The padding added by the hardware of the sending host is added to the user data in the X.25 packet (or sequence) that gets sent to the receiving host. The IP module of that host will then be passed a buffer of data as a datagram that's longer than the length field in the IP header says it should really be. This shouldn't be a problem, but I know of one host that got confused by this. It took the guy debugging the interface a couple of days to figure out the problem. Is all this really accurate or have I glitched a bit somewhere? A lot of this stuff will change with the advent of PSN 7.0. Anybody know exactly what's gonna change? Darrel B. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703241852.AA20403%40flash.bellcore.com] <1987032408521000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: network horror stories Message-ID: <8703241852.AA20403@flash.bellcore.com> Date: Tue, 24-Mar-87 13:52:10 EST Article-I.D.: flash.8703241852.AA20403 Posted: Tue Mar 24 13:52:10 1987 Date-Received: Thu, 26-Mar-87 02:01:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 40 Approved: tcp-ip@sri-nic.arpa Anyone who believes that connection-oriented networks are inherently immune to congestion should consider one of the following events: 1. The US phone network on the night of the Carter-Reagan debates in 1980. AT&T conducted their first large-scale trial of their 900 DIAL-IT service which was used to poll viewers on their opinions regarding the debate. Although AT&T placed strict limits on the number of long distance trunks that could be used for 900 service, there were so many people attempting to call it that in most places in the country there were delays of at least 2 minutes in getting dial tone from the local office. 2. The phone system in the state of Arizona the day the Tucson Amateur Packet Radio group decided to take phone orders (one day only!) for their new packet radio controller box. They only had one phone line. Not only was Tucson cut off from the rest of the world for several hours, but most of the rest of the state as well. 3. The ticket-buying frenzy accompanying any Bruce Springsteen concert. The problem isn't connectionless vs connection-oriented, it's that the network is a shared resource. If there aren't enough facilities to go around in times of peak demand, some people are going to be denied service. The only difference is in the details of how that's done. The real issue when trying to assure network stability is how the users react to being denied service. If they use Demon Dialers to hammer away at the phone network, you're going to have trouble. The Internet is in trouble because there are so many broken TCPs out there that do the equivalent thing when the network load picks up. I wouldn't be surprised if a few nodes could bring down an X.25 network pretty easily by just pummeling it with CALL REQUEST packets to unreachable addresses. The solution is more likely economic than technical. Since failed attempts still use network resources, one answer is to charge for them. I suspect charging for failed phone calls would put a stop to the abuse of demon dialers. Since the Internet doesn't charge for each packet, the solution here would be to require certification of a host's TCP retransmission behavior before it attached to the network in the same way that a radio transmitter has to be type certified before it can be placed in operation. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703242139.AA00170%40apolling.imagen.uucp] <1987032411390600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@apolling.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Station wagon full of bits Message-ID: <8703242139.AA00170@apolling.imagen.uucp> Date: Tue, 24-Mar-87 16:39:06 EST Article-I.D.: apolling.8703242139.AA00170 Posted: Tue Mar 24 16:39:06 1987 Date-Received: Thu, 26-Mar-87 02:42:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa > In article <8703220422.AA13307@buita.bu.edu> jsol@buit1.bu.EDU writes: > > From: Scott Earley > > > > ... Tables > > for all sites on the Ohio side of the PSU-Ohio link will be put > > on tape and mailed overnight to a pre-appointed individual who > > will reintroduce them into the network from there. > > ... > > > >That's right. Mag tape. > > > >--Daemon > > Never underestimate the bandwidth of a station wagon full of magtapes! > Well, we can't resist this, can we. Back of the envelope calculations for a station wagon full of bits transmitted from the east coast to the west coast follow. Apologies for any naivitee about magtapes -- I don't use them often and never learned all the sordid details. Station wagon: 5' X 5' X 3' trunk Transit time: 4 days = 345 600 s (might add a day on each side to copy the data to & from tape) Data: 1 magtape, 12"X1" reel, 1000' of tape, 9600 bpi, 9 tracks => 12*1000*9600*9 = 129.6 E 6 bits 5*5*36 = 875 magtapes in trunk => 875*129.6 = 113.4 E 9 bits Throughput: 113.4e9 b / 345600 s = 328,125 b/s Hmm.... better than the arpanet.... how much does a station wagon cost these days, anyway... Corrections welcome (they might as well be, I'm sure there will be some!), - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032411514400> Received: from CSL.SRI.COM by SRI-NIC.ARPA with TCP; Tue 24 Mar 87 21:53:21-PST Date: Tue 24 Mar 87 19:51:44-PST From: Karl Auerbach Subject: Re: PC LANs, NETBIOS and UNIX To: munnari!labtam.oz!michael@SEISMO.CSS.GOV cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "Michael Podhorodecki " of Mon 23 Mar 87 23:59:00-PST The NetBIOS-over-TCP group is alive and well. Two RFCs have been written. RFC 1001 is an overview of the operation of the protocols. RFC 1002 describes the packet representations and gives pseudo-code for the various protocol engines. I have not yet seen the notice announcing that the documents are available on the NIC. The protocols were expressly designed so that one could implement them on a Un*x system without kernel mods. The "SMB" protocol is the most common NetBIOS-based application for doing remote virtual disks and printers. This is what the IBM PC network program uses. Hearsay has it that Novell does not conform to either NetBIOS or SMB, based on an assertion that NetBIOS or SMB would lead to sub-optimal performance. There ARE SMB server products available for Un*x. Unfortunately, I can't remember the vendors. Until images are posted to the NIC, copies may be a bit hard to come by. I believe you can get a paper copy from Amatzia Ben-Artzi at Sytek. When you do get a copy, please read it and send comments to either the editor (me) or the chairman, as listed in the RFCs. --karl-- (Karl Auerbach, Epilogue Technology Corp.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032412105200> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Tue 24 Mar 87 04:11:36-PST Received: from ucl-cs-pyr1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa05027; 24 Mar 87 12:11 WET Date: Tue, 24 Mar 87 12:10:52 WET From: jon@Cs.Ucl.AC.UK Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.E To: tcp-ip@Cs.Ucl.AC.UK /* Written 2:08 pm Mar 23, 1987 by tcp-ip@pyr1 in pyr1:tcp-ip */ /* ---------- "Re: [dae%psuvax1.bitnet@jade.Berkeley.E" ---------- */ Received: from ucl-cs-nss by pyr1.Cs.Ucl.AC.UK with SMTP id aa16134; 23 Mar 87 14:06 WET Received: from sri-nic.arpa by mv1.Cs.Ucl.AC.UK via Satnet with SMTP id aa05875; 23 Mar 87 14:00 WET Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Mon 23 Mar 87 04:16:01-PST Posted-Date: Mon 23 Mar 87 07:15:18-EST Received: by vax.darpa.mil (5.54/5.51) id AA01929; Mon, 23 Mar 87 07:15:21 EST Date: Mon 23 Mar 87 07:15:18-EST From: "Dennis G. Perry" Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story] To: LYNCH@edu.isi.a Cc: PERRY@mil.darpa.vax, TCP-IP@arpa.sri-nic, perry@mil.darpa.vax Message-Id: In-Reply-To: Message from "Dan Lynch " of 22 Mar 1987 19:25:30 EST Dan, not sure there has been any model, or any great research either. dennis ------- /* End of text from pyr1:tcp-ip */ If you look at the original Internet design issues, the idea of fate sharing and a tactical network, and so on, determined gateway/routers were connectionless. A bit like the old CSMA versus token arguments, in a WAN context, the consequence of this design decision is that (without resource reservation a la X.25) you HAVE to over-engineer for bandwidth and delay, or it just doesn't work. Witness the UK Academic X.25 network availability under extreme load is 99% plus, with MTTR in the minutes, and MTBFs in the days range, compared with the Internet under extreme load, where we were seeing availabilities of 20-30% and MTTRs of hours and MTBFs in the hour range. I look forward to seeing some intermediate scheme ("connectionish networks") for the tactical+low-congestion internet. Jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703250201.AA06443%40flash.bellcore.com] <1987032416015700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <8703250201.AA06443@flash.bellcore.com> Date: Tue, 24-Mar-87 21:01:57 EST Article-I.D.: flash.8703250201.AA06443 Posted: Tue Mar 24 21:01:57 1987 Date-Received: Thu, 26-Mar-87 03:40:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa This is misleading. In "unlayered virtual circuit" networks, connection state information is kept not only in the end-point switches, but also in every intermediate switch along the path. For example, I understand that each GTE Telenet node speaks X.75 to its neighbors, making it an unlayered VC network. Because of this, a node or link failure ANYWHERE along the connection path causes an X.25 VC reset, not just failures at the end nodes. Only in "layered VC" networks such as the DDN (where datagrams are used internally) can intermediate node and link failures occur without resetting virtual circuits. Since it is my understanding that the DDN is used almost exclusively for passing Internet datagrams around, I never could understand the reason for forcing IP gateways to deal with the gratuitous complexity of X.25. I can only speculate that the reasons were political and not technical. However, I am thankful that we will be able to come up on the ARPANET with HDH instead of X.25. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [0UNp%3Diy00UoJyeY2t%3D%40andrew.cmu.edu] <1987032417455000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ddp#@ANDREW.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: danger of bridges Message-ID: <0UNp=iy00UoJyeY2t=@andrew.cmu.edu> Date: Tue, 24-Mar-87 22:45:50 EST Article-I.D.: andrew.0UNp=iy00UoJyeY2t= Posted: Tue Mar 24 22:45:50 1987 Date-Received: Thu, 26-Mar-87 07:30:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 54 Approved: tcp-ip@sri-nic.arpa I've been hearing alot about people creating large networks using level 2 bridges (i.e. the DEC LANBridge). People are talking about connecting 1000's of hosts' to ethernet's connected via them. In Monterey I even heard about a 3 university consortium planning on using them to connect all their nets together! This is extremely dangerous! It really scares me. DEC, IBM and other companies promoting these boxes are being incredibly short sighted and are leading their customers down a dead-end road! These boxes are just great for small networks and connecting multiple nets together where repeaters won't work, but for large net's (greater than 100's of hosts) they are not efficient. The reason is because of broadcasts and multicasts which are passed through the boxes, as they must be. For example, ARP request broadcasts are passed through all bridges on the network so that they reach all hosts on all connected nets. If you have 1000's of hosts on your network that tend to talk to a large number of other hosts, you wind up with an incredible amount of arp traffic. For example, the CMU network is composed of >2000 hosts and >50 networks. Some of these nets are connected using LANBridges, but most of them are connected via CMU routers (gateways) which operate on a scheme similar to the extended arp black boxes propsed by John Postel in RFC 925 (although we had it first :-)). This scheme effectively operates as a level 2 bridge system for ARP packets but as a level 3 gateway for IP packets. I.e. routing is done via arp, sort of like as in "promiscuous arp" or the "arp hack". I say similar because we've put a lot of additional work into this scheme in order to suppress the number of arps. According to our statistics, we do limit a significant amount of arp to a single network rather than being forwarded through all connected nets. However, we still have an average rate of 20 arp's per second on all nets in the system! Yes, I typed that right, twenty. And of course every time someone's program goes crazy you wind up with even higher rates. Once a student hacking on a UNIX system wrote a program to send a UDP datagram to every host in the host table (since only setuid programs can send broadcasts in 4.2). It was truly amazing seeing 100 arp's/sec... That's the price paid for not having subnet's and level 3 routing with IP. We are definitely not going to reach our goal of 7000 hosts this way... And then there's DECnet. I won't claim to be a DECnet expert, but from my observations it appears to me that all Phase IV DECnet hosts connected to an ethernet transmit HELLO multicast messages every 15 seconds. These of course all pass through the bridge or else intra-area routing wouldn't work. We have somewhere around 100 DECnet hosts connected to our backbone ethernet system. Dividing these two numbers I expect to see about 6 HELLO's a second on the net. Using PCIP NETWATCH I indeed measured 5 per second. Of course, this is with only 100 hosts. Doing the same calculation with 1000 hosts one would see 66 HELLO's/sec. 2000 hosts would yield 133/sec, 4000 hosts would give 266/sec. Can you imagine EVERY DECnet machine on a network processing 266 routing packets/sec? I sure wouldn't want to try to get work done on such a machine. To summarize, level 2 bridges are very useful, but you have realize that they are not the perfect solution. You have to keep their limitations in mind. There are very good reasons for having level 3 routing. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703250610.AA20384%40ucbvax.Berkeley.EDU] <1987032417514400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AUERBACH@CSL.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: PC LANs, NETBIOS and UNIX Message-ID: <8703250610.AA20384@ucbvax.Berkeley.EDU> Date: Tue, 24-Mar-87 22:51:44 EST Article-I.D.: ucbvax.8703250610.AA20384 Posted: Tue Mar 24 22:51:44 1987 Date-Received: Thu, 26-Mar-87 05:37:58 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa The NetBIOS-over-TCP group is alive and well. Two RFCs have been written. RFC 1001 is an overview of the operation of the protocols. RFC 1002 describes the packet representations and gives pseudo-code for the various protocol engines. I have not yet seen the notice announcing that the documents are available on the NIC. The protocols were expressly designed so that one could implement them on a Un*x system without kernel mods. The "SMB" protocol is the most common NetBIOS-based application for doing remote virtual disks and printers. This is what the IBM PC network program uses. Hearsay has it that Novell does not conform to either NetBIOS or SMB, based on an assertion that NetBIOS or SMB would lead to sub-optimal performance. There ARE SMB server products available for Un*x. Unfortunately, I can't remember the vendors. Until images are posted to the NIC, copies may be a bit hard to come by. I believe you can get a paper copy from Amatzia Ben-Artzi at Sytek. When you do get a copy, please read it and send comments to either the editor (me) or the chairman, as listed in the RFCs. --karl-- (Karl Auerbach, Epilogue Technology Corp.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703251140.AA24968%40ucbvax.Berkeley.EDU] <1987032501410700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jon@CS.UCL.AC.UK.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: network horror stories Message-ID: <8703251140.AA24968@ucbvax.Berkeley.EDU> Date: Wed, 25-Mar-87 06:41:07 EST Article-I.D.: ucbvax.8703251140.AA24968 Posted: Wed Mar 25 06:41:07 1987 Date-Received: Fri, 27-Mar-87 00:53:12 EST References: <8703241852.AA20403@flash.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa Exactly my point. TCP can be made to work fine. IP can be made to work fine, but currently has no (workable) mechanism for congestion control. If the internet is overengineered in terms of bandwidth, this works OK. If some congestion control mechanism is put in the gateways, it can be made to work better. Just fixing everyone's TCP does not fix things, because they can not make optimal use of the paths. X.25 networks give you a (one particular kind of) handle to control the hop by hop congestion control if you implement it right, whilst TP4/TCP (especially with selacks) buys you efficient end to end control. JANET happens to do this, which is why it works well. The resource reservation explicit in X.25 means you don't get hit by misbehaving end points - it's fair. A DTE that floods the DCE with CALL REQUEST packets just gets ignored by any reasonable DCE, and does not impinge on the network at all, after all X.25 is an interface spec more than a protocol. Asking people to certify TCPs before attaching to a research network like the internet is like asking your friend to certify that the car he's selling you cheap is going to run trouble free. We can't prove programs yet. jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D25-Mar-87.08:08:34.CERF] <1987032503080000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <[A.ISI.EDU]25-Mar-87.08:08:34.CERF> Date: Wed, 25-Mar-87 08:08:00 EST Article-I.D.: <[A.ISI.EDU]25-Mar-87.08:08:34.CERF> Posted: Wed Mar 25 08:08:00 1987 Date-Received: Fri, 27-Mar-87 01:44:02 EST References: <8703242139.AA00170@apolling.imagen.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa Never confuse bandwidth with timeliness and utility. For example, take the highest density storage medium you can think of - say the 10**10 bits per square inch optical storage disks, put a stack of them in a knapsack. Walk from east coast to west coast: The 14" disk has about pi*(5)**2 sq inches and you can put about 100 of these disks into the sack (at 1/2 pound each that would be a reasonable 50 lbs). At an average speed of 3 mph for 10 hours a day, it would take 100 days or 100*86,400 seconds. So you have roughly: (22/7)*25*10**10 bits per disk = 7.86 * 10**10 bits per disk 100 disks = 7.8 * 10**12 bits At 3 mph for 10 hrs/day it takes 100 days to go 3000 miles. 100 days at 86,400 seconds/24 hr day = 8.6 * 10**6 seconds So the coast to coast data rate for Johnny Appleseed is: 7.8/8.6 * 10**5 = about .9 * 10**5 = 90 kb/s which is about double the bandwidth you can get out of an unloaded ARPANET with today's 56 kb/s backbone. But few applications can deal with 100 day transmisstion/propagation delay. If people want to pursue this line of reasoning, I suggest that we invent a new unit of transmission: Appleseeds which are measured in Megabytes per Fortnight. Since a Megabyte per Fortnight is about a Megabyte in 14 days which works out to close to 1 byte per second, it is easy to see that the optical disk/Adidas method yields roughly 90 kiloAppleseeds. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032503080001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 25 Mar 87 05:09:25-PST Date: 25 Mar 1987 08:08-EST Sender: CERF@A.ISI.EDU Subject: Re: Station wagon full of bits From: CERF@A.ISI.EDU To: imagen!apolling!geof@DECWRL.DEC.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]25-Mar-87 08:08:34.CERF> In-Reply-To: <8703242139.AA00170@apolling.imagen.uucp> Never confuse bandwidth with timeliness and utility. For example, take the highest density storage medium you can think of - say the 10**10 bits per square inch optical storage disks, put a stack of them in a knapsack. Walk from east coast to west coast: The 14" disk has about pi*(5)**2 sq inches and you can put about 100 of these disks into the sack (at 1/2 pound each that would be a reasonable 50 lbs). At an average speed of 3 mph for 10 hours a day, it would take 100 days or 100*86,400 seconds. So you have roughly: (22/7)*25*10**10 bits per disk = 7.86 * 10**10 bits per disk 100 disks = 7.8 * 10**12 bits At 3 mph for 10 hrs/day it takes 100 days to go 3000 miles. 100 days at 86,400 seconds/24 hr day = 8.6 * 10**6 seconds So the coast to coast data rate for Johnny Appleseed is: 7.8/8.6 * 10**5 = about .9 * 10**5 = 90 kb/s which is about double the bandwidth you can get out of an unloaded ARPANET with today's 56 kb/s backbone. But few applications can deal with 100 day transmisstion/propagation delay. If people want to pursue this line of reasoning, I suggest that we invent a new unit of transmission: Appleseeds which are measured in Megabytes per Fortnight. Since a Megabyte per Fortnight is about a Megabyte in 14 days which works out to close to 1 byte per second, it is easy to see that the optical disk/Adidas method yields roughly 90 kiloAppleseeds. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D25-Mar-87.08:25:30.CERF] <1987032503250000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <[A.ISI.EDU]25-Mar-87.08:25:30.CERF> Date: Wed, 25-Mar-87 08:25:00 EST Article-I.D.: <[A.ISI.EDU]25-Mar-87.08:25:30.CERF> Posted: Wed Mar 25 08:25:00 1987 Date-Received: Sat, 28-Mar-87 06:55:45 EST References: <8703250201.AA06443@flash.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa The X.25 interface to DDN was pursued for at least two reasons: First, there are more X.25 interfaces available commercially than 1822 or just pure HDLC. Second, these interfaces can be used on public data nets which gives the potential for commercial back-up in case of emergencies. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032503250001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 25 Mar 87 06:31:14-PST Date: 25 Mar 1987 08:25-EST Sender: CERF@A.ISI.EDU Subject: Re: GOSIP vs TCP/IP From: CERF@A.ISI.EDU To: karn@FLASH.BELLCORE.COM Cc: mckee@MITRE.ARPA, m15368%mwvm@MITRE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]25-Mar-87 08:25:30.CERF> In-Reply-To: <8703250201.AA06443@flash.bellcore.com> The X.25 interface to DDN was pursued for at least two reasons: First, there are more X.25 interfaces available commercially than 1822 or just pure HDLC. Second, these interfaces can be used on public data nets which gives the potential for commercial back-up in case of emergencies. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D25-Mar-87.08:45:08.CERF] <1987032503450000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <[A.ISI.EDU]25-Mar-87.08:45:08.CERF> Date: Wed, 25-Mar-87 08:45:00 EST Article-I.D.: <[A.ISI.EDU]25-Mar-87.08:45:08.CERF> Posted: Wed Mar 25 08:45:00 1987 Date-Received: Fri, 27-Mar-87 01:44:15 EST References: <[A.ISI.EDU]25-Mar-87.08:08:34.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa OOPS. The Appleseed is 1 MB/1.2 Msec = 8 Mb/1.2 Msec = 6.7 bps So 90 Kbps is about 13.5 K Appleseeds Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032503450001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 25 Mar 87 05:47:37-PST Date: 25 Mar 1987 08:45-EST Sender: CERF@A.ISI.EDU Subject: Re: Station wagon full of bits From: CERF@A.ISI.EDU To: CERF@A.ISI.EDU Cc: imagen!apolling!geof@DECWRL.DEC.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]25-Mar-87 08:45:08.CERF> In-Reply-To: <[A.ISI.EDU]25-Mar-87 08:08:34.CERF> OOPS. The Appleseed is 1 MB/1.2 Msec = 8 Mb/1.2 Msec = 6.7 bps So 90 Kbps is about 13.5 K Appleseeds Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703251425.AA26729%40ucbvax.Berkeley.EDU] <1987032504062800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hinden@CCV.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703251425.AA26729@ucbvax.Berkeley.EDU> Date: Wed, 25-Mar-87 09:06:28 EST Article-I.D.: ucbvax.8703251425.AA26729 Posted: Wed Mar 25 09:06:28 1987 Date-Received: Fri, 27-Mar-87 01:48:06 EST References: <8703242139.AA00170@apolling.imagen.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Geof, Just think of the bandwidth of a 747 full of magtapes! Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032504062801> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Wed 25 Mar 87 06:16:39-PST To: Geof Cooper cc: tcp-ip@sri-nic.ARPA Subject: Re: Station wagon full of bits In-reply-to: Your message of Tue, 24 Mar 87 13:39:06 pst. <8703242139.AA00170@apolling.imagen.uucp> Date: 25 Mar 87 09:06:28 EST (Wed) From: Robert Hinden Geof, Just think of the bandwidth of a 747 full of magtapes! Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703251525.AA27297%40ucbvax.Berkeley.EDU] <1987032504234100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ahill@CC7.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703251525.AA27297@ucbvax.Berkeley.EDU> Date: Wed, 25-Mar-87 09:23:41 EST Article-I.D.: ucbvax.8703251525.AA27297 Posted: Wed Mar 25 09:23:41 1987 Date-Received: Fri, 27-Mar-87 02:04:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Back in the early 70's when the ARPANET was a little zippier than it is today, SDAC tried to send full 1600bpi 9 track tape contents from Virginia to UCLA using a very highly tuned block transfer FTP that got roughly 18KB continuous across the network. We needed to transfer six tapes a day and rapidly learned (the hard way) that the US Snail could outperform the network in bandwidth and cost. I don't suggest that the network is not efficient or useful but it easy to misuse particularly with bulk data transfers. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032504234101> Received: from cc7.bbn.com by SRI-NIC.ARPA with TCP; Wed 25 Mar 87 07:08:45-PST Date: Wed, 25 Mar 87 9:23:41 EST From: "Alan R. Hill" Subject: Re: Station wagon full of bits In-Reply-To: Your message of Tue, 24 Mar 87 13:39:06 pst To: imagen!apolling!geof@decwrl.dec.com Cc: tcp-ip@sri-nic.arpa Back in the early 70's when the ARPANET was a little zippier than it is today, SDAC tried to send full 1600bpi 9 track tape contents from Virginia to UCLA using a very highly tuned block transfer FTP that got roughly 18KB continuous across the network. We needed to transfer six tapes a day and rapidly learned (the hard way) that the US Snail could outperform the network in bandwidth and cost. I don't suggest that the network is not efficient or useful but it easy to misuse particularly with bulk data transfers. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12289238285.24.OLE%40SRI-NIC.ARPA] <1987032507220600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: OLE@SRI-NIC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: PC LANs, NETBIOS and UNIX Message-ID: <12289238285.24.OLE@SRI-NIC.ARPA> Date: Wed, 25-Mar-87 12:22:06 EST Article-I.D.: SRI-NIC.12289238285.24.OLE Posted: Wed Mar 25 12:22:06 1987 Date-Received: Fri, 27-Mar-87 02:12:38 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa I got the RFC announcement yesterday and just checked now: RFC 1001 and RFC 1002 are now online at the NIC, go get 'em! Ole ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703251601.a014585%40Huey.UDEL.EDU] <1987032511010300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Fact or fiction Message-ID: <8703251601.a014585@Huey.UDEL.EDU> Date: Wed, 25-Mar-87 16:01:03 EST Article-I.D.: Huey.8703251601.a014585 Posted: Wed Mar 25 16:01:03 1987 Date-Received: Fri, 27-Mar-87 04:14:06 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Darrel, While I can't speak to all the points in your message, I can confirm that the tailing bits you impute to the 1822-X.25 message occur on ordinary 1822-1822 messages as well. It is well known that the padding bits will always add up to 16 bits to the length of the message. I would suspect, so far unverified, that this can happen on a Standard X.25-X.25 message as well. From an implementor's point of view, this bug seldom bites more than once. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032511260900> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Wed 25 Mar 87 03:34:47-PST Received: from ucl-cs-pyr1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa05457; 25 Mar 87 11:26 WET To: "Phil R. Karn" cc: tcp-ip@sri-nic.arpa, jon@Cs.Ucl.AC.UK Subject: Re: network horror stories In-reply-to: Your message of Tue, 24 Mar 87 13:52:10 -0500. <8703241852.AA20403@flash.bellcore.com> Date: Wed, 25 Mar 87 11:26:09 +0000 From: Jon Crowcroft Exactly my point. TCP can be made to work fine. IP can be made to work fine, but currently has no (workable) mechanism for congestion control. If the internet is overengineered in terms of bandwidth, this works OK. If some congestion control mechanism is put in the gateways, it can be made to work better. Just fixing everyone's TCP does not fix things, because they can not make optimal use of the paths. X.25 networks give you a (one particular kind of) handle to control the hop by hop congestion control if you implement it right, whilst TP4/TCP (especially with selacks) buys you efficient end to end control. JANET happens to do this, which is why it works well. The resource reservation explicit in X.25 means you don't get hit by misbehaving end points - it's fair. A DTE that floods the DCE with CALL REQUEST packets just gets ignored by any reasonable DCE, and does not impinge on the network at all, after all X.25 is an interface spec more than a protocol. Asking people to certify TCPs before attaching to a research network like the internet is like asking your friend to certify that the car he's selling you cheap is going to run trouble free. We can't prove programs yet. jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).25-Mar-87.20:55:50.VAX.DARPA.MIL] <1987032515555000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: Date: Wed, 25-Mar-87 20:55:50 EST Article-I.D.: Posted: Wed Mar 25 20:55:50 1987 Date-Received: Fri, 27-Mar-87 07:19:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Geof, suggest you use 2400 feet for a standard mag tape. At about 40 Mbytes per tape or 320 E 6 bits instead of 129.6 E 6 bits. Gives you roughly a factor of 3 better thru put. Last time I checked a station wagon cost about a fouth the cost of a butterfly gateway. Or about four months of 56 kbit/s cross country line from ATT. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032515555001> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Wed 25 Mar 87 17:59:52-PST Posted-Date: Wed 25 Mar 87 20:55:50-EST Received: by vax.darpa.mil (5.54/5.51) id AA01941; Wed, 25 Mar 87 20:55:57 EST Date: Wed 25 Mar 87 20:55:50-EST From: Dennis G. Perry Subject: Re: Station wagon full of bits To: imagen!apolling!geof@decwrl.dec.com Cc: tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "imagen!apolling!geof@decwrl.DEC.COM (Geof Cooper)" of Tue, 24 Mar 87 13:39:06 pst Geof, suggest you use 2400 feet for a standard mag tape. At about 40 Mbytes per tape or 320 E 6 bits instead of 129.6 E 6 bits. Gives you roughly a factor of 3 better thru put. Last time I checked a station wagon cost about a fouth the cost of a butterfly gateway. Or about four months of 56 kbit/s cross country line from ATT. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703260316.AA23501%40flash.bellcore.com] <1987032517162900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@flash.bellcore.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703260316.AA23501@flash.bellcore.com> Date: Wed, 25-Mar-87 22:16:29 EST Article-I.D.: flash.8703260316.AA23501 Posted: Wed Mar 25 22:16:29 1987 Date-Received: Fri, 27-Mar-87 06:19:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 45 Approved: tcp-ip@sri-nic.arpa You really should update this old idea to use more up-to-date technologies. To wit: What is the bandwidth of a B-747 (DC-10, L-1011, A-300) loaded with Compact Discs or CD Roms? (To be fair, we should compare this to a fiber link covering the same path.) With fiber, the economies of scale in transmission are enormous. However, the ARPANET has been around a long time. Its internal routing algorithms were built to squeeze the most out of the slow and expensive leased lines available in 1969. Its internal protocols and congestion control techniques were designed to squeeze the most out of the expensive, memory-poor computers available in 1969. It was an excellent computer network -- for 1969. Unfortunately, much of this simply can't scale in its present form to where it can effectively utilize the new economies of scale in transmission. Making decisions about the future of networking by comparing the "operating costs" of ARPANET and MILNET to GTE Telenet is dangerous. For one thing, Telenet was also built on 1970's technology and protocols. Also, its users pay *real money* depending on how much traffic they send. Unlike the ARPANET/MILNET, Telenet's primary use is as a nationwide "remote terminal concentrator", with the vast majority of users dialing into X.3/28/29 PADs with dumb terminals and connecting to timesharing hosts. Their only alternative is to dial a direct long distance call using AT&T or MCI or whatever, and Telenet is well aware of this; they price their service accordingly. Anyone who tries to use it for computer-to-computer internetworking (as we do through CSNET/X.25NET) finds out VERY quickly just how expensive this can be. The circuit-switched mentality is deeply ingrained in Telenet's internal design; at least with the DDN, X.25 is kept on the edges, making it at least theoretically possible to escape its braindamage. In deciding where to spend future bucks, I think it would make a lot more sense to look at newer technologies. Because the transmission guys have leapfrogged so far over the switching guys, a radical change in mindset is in order. It simply doesn't pay anymore to worry about efficient PSN buffer utilization, 100% delivery reliability, packet header overhead, finding the most optimal routes, or load splitting if doing so takes so much CPU time that you can't drive fast links at full speed. At present, only link-level bridges like the Vitalink Translan III seem able to switch packets quickly enough to drive a T-1 link to 100% utilization on small packets; if somebody can do this with an X.25 switch or IP gateway I would like to know about it. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703252309.a019065%40Huey.UDEL.EDU] <1987032518095300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703252309.a019065@Huey.UDEL.EDU> Date: Wed, 25-Mar-87 23:09:53 EST Article-I.D.: Huey.8703252309.a019065 Posted: Wed Mar 25 23:09:53 1987 Date-Received: Fri, 27-Mar-87 06:08:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Geof, Recalculate using compact-disk ROMs and Federal Express. The ARPAfolks calculated back in the late sixties that it would be cheaper to send a pagefull of text via the ARPANET than as a first-class letter. On the other hand, for bulk data larger than a megabit, the cheapest way was an airmailed magtape. Maybe one of the original Buzzards might certify and maybe update my recollections. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703260614.AA08543%40BORAX.LCS.MIT.EDU] <1987032520142400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jbvb@BORAX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: UCLA TN3270 negotiation Message-ID: <8703260614.AA08543@BORAX.LCS.MIT.EDU> Date: Thu, 26-Mar-87 01:14:24 EST Article-I.D.: BORAX.8703260614.AA08543 Posted: Thu Mar 26 01:14:24 1987 Date-Received: Sat, 28-Mar-87 01:01:06 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Could someone familiar with the UCLA ACP tell me at what point in the connection/login sequence it first negotiates 3270 mode (Term Type, EOR and Binary)? I have tried connecting to an UCLA MVS Arpanet machine, but negotiation didn't seem to take place on connection open (unlike WISCNET), and I didn't have an account, so I haven't been able to proceed further. Is my code broken, or do I have to log in to really test it? jbvb@ai.ai.mit.edu James B. VanBokkelen FTP Software Inc. (617) 868-4878 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032603545400> Received: from gateway.mitre.org by SRI-NIC.ARPA with TCP; Thu 26 Mar 87 06:14:02-PST Return-Path: Received: by gateway.mitre.org (5.54/SMI-2.2) id AA12557; Thu, 26 Mar 87 08:55:22 EST Full-Name: Paul Tsuchiya Received: by jupiter.mitre.org (1.1/SMI-3.0DEV3) id AA01431; Thu, 26 Mar 87 08:54:54 EST Date: Thu, 26 Mar 87 08:54:54 EST From: tsuchiya@mitre-gateway.arpa Message-Id: <8703261354.AA01431@jupiter.mitre.org> To: ddp#@andrew.cmu.edu, tcp-ip@sri-nic.arpa Subject: Re: danger of bridges Cc: x3s33-interest > Date: Tue, 24 Mar 87 22:45:50 est > From: ddp#@andrew.cmu.edu (Drew Daniel Perkins) > To: tcp-ip@sri-nic.arpa > Subject: danger of bridges > Status: R > > > > And then there's DECnet. I won't claim to be a DECnet expert, but from my > observations it appears to me that all Phase IV DECnet hosts connected to an > ethernet transmit HELLO multicast messages every 15 seconds. These of course > all pass through the bridge or else intra-area routing wouldn't work. We > have somewhere around 100 DECnet hosts connected to our backbone ethernet > system. Dividing these two numbers I expect to see about 6 HELLO's a second > on the net. Using PCIP NETWATCH I indeed measured 5 per second. Of course, > this is with only 100 hosts. Doing the same calculation with 1000 hosts one > would see 66 HELLO's/sec. 2000 hosts would yield 133/sec, 4000 hosts would > give 266/sec. Can you imagine EVERY DECnet machine on a network processing > 266 routing packets/sec? I sure wouldn't want to try to get work done on > such a machine. > > To summarize, level 2 bridges are very useful, but you have realize that they > are not the perfect solution. You have to keep their limitations in mind. > There are very good reasons for having level 3 routing. > > Drew > > > I should hope that the situation is not this bad, especially since x3s33 ES-IS (host-gateway) routing protocol uses a similar HELLO scheme. Although I am also not a DECNET expert (or even novice, for that matter), I'm would be EXTREMELY suprized if the HELLO timer was not settable, meaning that for crowded networks, it could and I assume normally would be set to greater than 15 seconds. Second, host HELLO's typically go to gateways, not other hosts, so every host doesn't need to process every host HELLO, just gateway HELLO's. There should be much fewer gateways than hosts. Paul (no I don't work for DEC) Tsuchiya ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).26-Mar-87.10:51:09.VAX.DARPA.MIL] <1987032605510900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: mod.protocols.tcp-ip Subject: appelseeds/fortnight Message-ID: Date: Thu, 26-Mar-87 10:51:09 EST Article-I.D.: Posted: Thu Mar 26 10:51:09 1987 Date-Received: Sat, 28-Mar-87 06:33:49 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa Marvelous!! dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032605510901> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Thu 26 Mar 87 09:51:19-PST Posted-Date: Thu 26 Mar 87 10:51:09-EST Received: by vax.darpa.mil (5.54/5.51) id AA00683; Thu, 26 Mar 87 10:51:13 EST Date: Thu 26 Mar 87 10:51:09-EST From: Dennis G. Perry Subject: appelseeds/fortnight To: CERF@a.isi.edu Cc: imagen!apolling!geof@decwrl.dec.com, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "CERF@A.ISI.EDU" of 25 Mar 1987 08:08-EST Marvelous!! dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1987.3.26.16.1.37.Rudy.Nedved%40h.cs.cmu.edu] <1987032606391700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Rudy.Nedved@H.CS.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: network horror stories Message-ID: <1987.3.26.16.1.37.Rudy.Nedved@h.cs.cmu.edu> Date: Thu, 26-Mar-87 11:39:17 EST Article-I.D.: h.1987.3.26.16.1.37.Rudy.Nedved Posted: Thu Mar 26 11:39:17 1987 Date-Received: Sat, 28-Mar-87 05:01:14 EST References: <8703241852.AA20403@flash.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 40 Approved: tcp-ip@sri-nic.arpa Phil, I agree with your points alas certification seems to be something like program verification, it only works on small test cases. With comments from things like Jan 1987 ACM SIGOPS section on MIT Project Athena, "Firewalls in gateways are neccessary" and my own experiences, I believe it is up to the routers, bridges and gateways to control congestion and ignore brain damaged hosts. I would suggest that an implementation be beat on for some type of certification before being released but experience has shown that the imagination of the attackers/testers is more conservative then the ever changing network enviroment....something always shows up later. Therefore, the two prong approach of doing constructive/definitive tests and putting firewalls into gateways is the way to go. For firewalls, adding hysteresis to gateways, bridges and routers tied in with the volume of datagrams from a host or network should help even though it would penalize highly used paths...these paths are having severe problems as it is...this will encourage more efficient use of those paths....especially if every relaying agent does it. For relay agents on "dedicated" networks the hysteresis would be very heavy for datagrams not to or from dedicated network clients. When congestion occurs, the clients that want to send the once and a while important message would succeed but the clients that generally send lots of communication in an inefficient manner would be penalized....this is a more desirable behaviour then everyone who tries gets penalized. Lastly, communicating back to entry gateways that some client is being nasty and should be ignore would reduce gateway to gateway congestion just like most of the telephone companies have the prefix for remote areas stored locally to reduce trunk line usage from wrong numbers...if you dial 412 333 XXXX in 201 area then 201 area will not even try the connection, it will indicate that number is incorrect and a telephone book should be consulted. Alas, propagation of this information has the same problems as propagating routing information....sigh. Cheers, -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703261719.AA12871%40crys.wisc.edu] <1987032607192400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: solomon@CRYS.WISC.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8703261719.AA12871@crys.wisc.edu> Date: Thu, 26-Mar-87 12:19:24 EST Article-I.D.: crys.8703261719.AA12871 Posted: Thu Mar 26 12:19:24 1987 Date-Received: Sat, 28-Mar-87 05:11:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa Path: crystal!solomon From: solomon@crys.WISC.EDU (Marvin Solomon) Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Summary: There's more to data communication than bits/second. Message-ID: <291@crys.WISC.EDU> Date: 26 Mar 87 17:19:24 GMT References: Organization: U of Wisconsin CS Dept Lines: 31 Vint Cerf has pointed out one pitfall in trying to use a single number to compare very different technologies: One must consider not only bandwidth, but also latency. But all the discussion on this topic so far has failed to note that the information-carrying capacity of a station wagon full of tapes (or a knapsack full of CS's, or whatever) and a 56Kbps leased line have different dimensions! Vint's "Johnny Appleseed" has units capacity*velocity = bits*length/time, whereas a communications line is measured in bits/time. Thus, to compare the two, one has to mention the distance. The problem we are considering was posed by Jon Bentley in his delightful Programming Pearls column, "The Back of the Envelope" in the March 1984 issue of "Communications of the ACM": At what distances can a courier on a bicycle with a reel of magnetic tape be a more rapid carrier of information than a 56-kilobaud [sic] telephone line? Than a 1200-baud line? [op cit, p. 182] The answers (based on considerably more realistic estimates about magnetic tape than have been bandied about in this forum, by the way) are, respectively, 20 miles and the distance the cyclist can travel in a week. The point is that a communication line can beat ANY bulk transfer over sufficiently long distances. Of course, we can effectively cut off discussion at (say) the diameter of the earth. To summarize: The advantages of networking are both low latency and distance-independence. -- Marvin Solomon Computer Sciences Department University of Wisconsin, Madison WI solomon@gjetost.wisc.edu or seismo!uwvax!solomon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703261229.a027287%40Huey.UDEL.EDU] <1987032607294100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703261229.a027287@Huey.UDEL.EDU> Date: Thu, 26-Mar-87 12:29:41 EST Article-I.D.: Huey.8703261229.a027287 Posted: Thu Mar 26 12:29:41 1987 Date-Received: Sat, 28-Mar-87 05:10:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa Vint, Yeah, that's the kind of model I was fishing for. But, now you have to consider the energy input to the system, which depends on the weight of the knapsack. Ordinarily, we don't worry about that in the ARPANET, since the total energy input (watts and bucks?) is first-order independent of the bits carried. Therefore, I submit a more relevant measure might be microjoules/appleseed. At least Johnny left some trees in his wake. A long time ago while working my way through school as a disk jockey, I tossed off a calculation on the total length of the record grooves played throughout the day (about 100 miles). The station manager liked it so much he asked me to work the idea into a promo spot, which I did. The idea caught on and was copied by other local stations as well. It seems the issues can often be exposed effectively by outrageous changes in the assumptions and then working through the logic anyway to see if it all fits. Okay, I promise to shut up. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12289526116.32.GROSSMAN%40Sierra.Stanford.EDU] <1987032609431200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GROSSMAN@SIERRA.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <12289526116.32.GROSSMAN@Sierra.Stanford.EDU> Date: Thu, 26-Mar-87 14:43:12 EST Article-I.D.: Sierra.12289526116.32.GROSSMAN Posted: Thu Mar 26 14:43:12 1987 Date-Received: Sat, 28-Mar-87 05:34:10 EST References: <[A.ISI.EDU]25-Mar-87.08:08:34.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa I did a few calculations of the bandwidth of Wagonnet, and heres what I came up with: The most readily available magtape technology happens to be 2400' reels. These have a common maximum density of 6250 bytes/inch. This results in a value of 6250*12 = 75000 bytes/foot, and therefore we get 75000*2400*8 = 1.44e9 bits/tape. Now, your average 2400 foot reel is about 10.75 inches in diameter by 1 inch high, so (squaring off the corners) you get a volume of 115.6 cu inches/tape, and therefore you can get 12^3/115.6 = 14.98 tapes per cubic foot. This amounts to (rounding up to whole magtapes) 15*1.44e9= 21.6e9 bits/cu ft. Now, your typical station wagon holds anywhere from 30 to 65 cubic feet of stuff. I'll presume that this station wagon is large, since it has to deal with Bitnet. Therefore it holds 65*21.6e9= 1.404e12 bits/station wagon. Now, at a rate of 55 mph (I don't want to break the law), this station wagon can get across the country in 3000/55 * 3600 +10% = 216000 seconds. The 10% is for dealing with changing drivers, food amd gas stops, etc.... This results in a baud rate of 1.404e12/216000 = 6.5e6 bits/sec. This is comparable to typical Ethernet thoughput with a good controller and few collisions. Of course, this network has the advantage that congestion doesn't make it lose data. It just gets there kinda slowly. However, the RTTs are rather long (on the order of 216000*2= 5 days. But despair not, there's some hope! If congress raises the speed limit to 65mph, then the typical RTT will be reduced to a mere 3.8 days. You could probably convince congress that it would be in the best interests of national defense to do this! Note that a speed limit of 216 million mph would result in a much more reasonable RTT on the order of .1 seconds! Stu Grossman ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703261951.AA00664%40gateway.mitre.org] <1987032609513600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@GATEWAY.MITRE.ORG.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703261951.AA00664@gateway.mitre.org> Date: Thu, 26-Mar-87 14:51:36 EST Article-I.D.: gateway.8703261951.AA00664 Posted: Thu Mar 26 14:51:36 1987 Date-Received: Sat, 28-Mar-87 03:55:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Bob, You've been scooped. There has already been a proposal involving a 747. Naturally, it's called.... Jumbo-net. Phill ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703262020.AA27749%40flash.bellcore.com] <1987032610202600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Response to anti-bridge comments Message-ID: <8703262020.AA27749@flash.bellcore.com> Date: Thu, 26-Mar-87 15:20:26 EST Article-I.D.: flash.8703262020.AA27749 Posted: Thu Mar 26 15:20:26 1987 Date-Received: Sat, 28-Mar-87 03:59:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 92 Approved: tcp-ip@sri-nic.arpa As one who has just helped construct a "large" bridged network, I think a few comments based on actual experience might be useful. First, a description. Bellcore has five major locations in north central New Jersey. We lease T1 circuits organized as a star with the hub at Piscataway, the geographically central location. These circuits are divided down with synchronous multiplexors into various sized channels for things like Micom terminal switch trunks and IBM RJE links. At the moment, 256 kbps of this capacity connects a set of five Vitalink Translan IIIs as a star with the hub at Piscataway. Each of these boxes also connects to the building-wide backbone Ethernet at its location, thus bridging the locations together at the link level. Within each location almost all of our Ethernets are bridged with DEC LanBridge 100s, with the fiber version interconnecting multiple buildings at a location. At last count, the routing tables on the Translans showed something like 600 active hosts. Virtually all of these hosts speak DoD IP; most are 4.2BSD derivatives. A few Symbolics machines speak Chaosnet. As far as I'm aware we have no DECNET or XNS traffic, other than that spoken by the Translans and LanBridges themselves. And it all works, and works well! I hardly ever look at the boxes anymore. We had one infant mortality after we installed them in late December: a power supply died after 24 hours in operation. Vitalink immediately shipped out a replacement which arrived a day later, and the boxes have all been solid since. Two other outages were due to people kicking out Ethernet cables, but this is a generic Ethernet problem and isn't Vitalink's fault (I do hope they'll come out with screw-on connectors, though). With our switch to bridging, the reliability and availability of intra-company networking has improved enormously over what it was when we used general purpose UNIX machines (VAXes and Sun fileservers) as IP gateways. True, it's a bit unfair to compare standalone boxes with general purpose systems with disks that must also do other things. But there were enough RIP/routed screwups that once I seriously considered running everything with static routing. Even now our remaining IP routers get screwed up occasionally and they have to be restarted. But at least when this happens it doesn't affect our intra-company communications, which are most important. And nobody has to renumber their hosts when they move from one physical cable to another, which is an ENORMOUS practical advantage in a place as big as this one. All this is not to say we haven't had our problems. I do monitor the ARP broadcast traffic from time to time. We generally see 1-2 per second, which is expected and entirely acceptable. If you see 20 per second, then you've got something wrong somewhere. I've found that bursts of ARP requests are usually caused by hosts who respond inappropriately to UDP broadcasts to bogus IP addresses. The trigger is generally a Microvax, since Ultrix 1.2 allows you to set the net mask and the broadcast address, thereby allowing you to get it wrong. (I just can't wait until Sun also supports subnetting and broadcast address selection). Although the problem clearly gets worse as you build larger bridged networks, YOU CAN'T BLAME IT ON BRIDGING!!! If there weren't so many broken TCP/IP implementations out there the problem wouldn't exist in the first place. Nevertheless, my usual tactic has been to place an entry in the appropriate Translan to isolate the offending host until the user can fix it; this "twit listing" feature is very helpful. You discover other interesting things when you build a large bridged network. For example: 1. It seems that every CCI Power 6 machine as shipped comes with the same Ethernet address. We didn't notice until we started bridging networks together, but you can't exactly blame it on the use of bridging. 2. Some older 4.2 machines seem to respond inappropriately with wrong answers to RARPs from Sun workstations, keeping them from booting. 3. We made an aggressive effort to turn off rwho daemons, bringing UDP broadcasting to an acceptable level. (Many people find this necessary even when bridges aren't used). With fewer IP gateways, the amount of RIP traffic has stayed fairly modest. 4. Pyramids seem to respond to every ARP request they hear, regardless of whether they were the target or not. Fortunately they respond with correct (but irrelevant) information, so this is just a minor annoyance. You can just as easily have antisocial machines with these problems on the same physical cable; the solution is to FIX them, not throw up your hands and say "bridges are terrible" because they force you to confront the software vendors. Overall, our experience with bridging has been quite positive. There are some valid arguments against large-scale bridging, but they have to do more with vulnerability to spoofing than with any inherent technical weaknesses in a "friendly" environment such as ours. Even in a heterogeneous environment, though, Vitalink boxes are useful as simple, fast packet switches because they can be configured to filter out broadcasts and to use static routing tables. I understand that NASA Ames uses them in this way. I'm a big believer in TCP/IP. IP does the job of interconnecting dissimilar networks so well that some people forget that there are easier ways to connect networks of the same type. The Internet has grown so large that the job needs to be broken down hierarchically into more manageable pieces; you can't (and shouldn't try to) do EVERYTHING with IP gateways. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703270059.AA17951%40spam.istc.sri.com] <1987032615255700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gds@SPAM.ISTC.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703270059.AA17951@spam.istc.sri.com> Date: Thu, 26-Mar-87 20:25:57 EST Article-I.D.: spam.8703270059.AA17951 Posted: Thu Mar 26 20:25:57 1987 Date-Received: Sat, 28-Mar-87 07:24:20 EST References: <12289526116.32.GROSSMAN@Sierra.Stanford.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Instead of using wagons, why not contract a moving company (e.g. Allied, NorthAmerican) to do this? We might be able to get cheaper rates with the moving companies than to contract out a set of drivers and their wagons. I would imagine the lifetimes of these wagons would be small relative to the lifetimes of moving vans (not many cars last through extensive heavy moving). Plus, the routes the van lines use are already set up, and probably parallel the cross-country trunks. We will be able to get much better bandwidth (I'm assuming the capacity of a moving van to be at least 10 times that of a station wagon), less overhead involved in switching drivers (they make a living out of doing this so they know how to switch with minimum delay), more bits/driver (they are trained so they need less sleep). Let's use planes to fly the transcontinental links. They're not quite so good for transmission within a continent (case in point: you can't land one at an imp :-). --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703270131.AA06172%40HECTOR.MIT.EDU] <1987032615313500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martillo@ATHENA.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: X.25, X.31 vs Q.921/Q.921 and Networking Style in General Message-ID: <8703270131.AA06172@HECTOR.MIT.EDU> Date: Thu, 26-Mar-87 20:31:35 EST Article-I.D.: HECTOR.8703270131.AA06172 Posted: Thu Mar 26 20:31:35 1987 Date-Received: Sat, 28-Mar-87 06:49:59 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 261 Approved: tcp-ip@sri-nic.arpa I have received a suggestion to move a discussion from a UUCP netnews to this mailing list. I am also not on this mailing list and would like to be added. Path: bacchus!martillo From: martillo@athena.mit.edu (Yakim Martillo) Newsgroups: comp.dcom.lans,comp.dcom.modems Subject: X.25, X.31 vs Q.921/Q.921 and Networking Style in General Message-ID: <363@bacchus.MIT.EDU> Date: 23 Mar 87 02:00:13 GMT Sender: daemon@bacchus.MIT.EDU Reply-To: martillo@athena.mit.edu (Yakim Martillo) Distribution: net Organization: MIT Project Athena Lines: 136 Xref: bacchus comp.dcom.lans:180 comp.dcom.modems:269 I am working on getting a proprietary data communications system to work over ISDN primary and basic rate interfaces. The system was originally designed to use only PSDN (PDNs) as the communications subnet. An end to end protocol was never designed so that individual applications have their own end to end protocols. Eventually, the developers put the communications system over a proprietary token ring and ethernet, as well as point to point leased lines. Since they wanted to modify the networking software as little as possible, they basically used a slightly modified version of X.25 level 2 for the token ring (running on top of the token rings datagram protocol) and ran X.25 level 3 on top of it. On ethernet they substituted 802.3 for X.25 level 2 and ran X.25 level 3 on top of that. And for point to point leased lines they run straight X.25. Of course, they had some sort of procedure whereby one party becomes the DCE and the other party becomes the DTE. Thus X.25 has basically become the end to end transport protocol in the network unless a PSDN is the communications subnet. Now they want to put their network over ISDN using LAPD, LAPB, X.25 level 3, X.31 with Q.931/Q.921 signaling and I see problems with how people use the X.25 family of protocols and what Q.931/Q.921 seems to provide. Full Q.931 seems to allow for "hold" (via hold, suspend resume signaling messages) on a given CSC (Circuit-Switched Circuit), and in fact I think I really want to do this because I could easily see an individual user using 3 CSCs or more for a given session (e.g. remote terminal session from A to B, while on B doing a remote copy from C to B -- the user could easily be taking up 3 CSCs). With an average of 40 users on the machine with a full-blown remote file system and RPCs (Remote procedure calls), I think it is fairly easy for even a PRI to get fully loaded really fast, and I would want the PBX to send indication of incoming calls even when there are no available channels, so that the controller could put one call on-hold and then accept the new call. For outgoing, if there are no channels available I would like to put one call on hold and then place the new outgoing call, and then round-robin (with prioritization for calls which have outgoing data) the calls on the available channels. In the case of a (2B+D or 1B+D) BRI on a workstation, the scenario described above becomes even more problematic. The problem comes in with X.25 restart and rest procedures as outlined in the redbook and as typically implemented. Deasington says in X.25 Explained (p.52) says: The restart procedure is used to ensure that both the DCE and DTE consider that all the PVCs and SVCs are in a known state. A restart causes all PVCs to be reset and all SVCs to be cleared and free to be used. The Network level will need to be restarted if the Link level has failed for some reason, for example the line between the DTE and DCE was disconnected. If the Link level has timed out and has been restarted by the exchange of SABM, UA, etc., as previously described, the Network level will be restarted by the DCE sending to the DTE a Network level Restart Indication frame; in PSS the Restart Indication frame will be sent to the DTE at intervals of six seconds until a Restart Confirmation is received. The DTE may at any time transmit a Restart Indication to the DCE if it needs to restart the Network level completely, for example if it has completely lost track of the state of the active SVCs. According to the X.25 specification, resets should be generated on VCs if data has been lost or a protocol error has occurred. I have no problems with either restart or reset procedures as long as disconnection of level 2 is not considered a protocol error because I don't intend for my hosts to loose data in this case and I can set up the following scenario: 1) non-alien host (i.e one of my hosts which form a part of my contractee's proprietary network) connects to non-alien host. 2) calling party exchanges XID with called party, establishes calling party as DCE and establishes automatic call-back in the event of disconnections while VCs are still active (sometimes CSCs just drop). 3) Level 2 gets connected. DCE does a network level restart. 4) VCs get started and normal data communications proceeds. 5) Called or calling party interface fills and incoming call arrives, Called or calling party interface selects channel to put on-hold (probably least-recently used algorithm), and stat muxes the active calls among physical channels. 6) Possibly, the level 2 of one of the calls on hold times out and becomes disconnected, when the call goes off-hold. Now from the above in Deasington, apparently many PSPDNs automatically restart the interface upon disconnection of the logical link under the assumption this means the foreign interface had been turned off. I think in the case of hold this should be utterly unnecessary and the level 2 should just be reconnected transparently to the level 3. 6) Alternatively, the call drops for unspecified reason, the DCE replaces the call, reconnects the link-layer, but does not restart the network interface. 7) Eventually the number of VCs on the link goes to zero. Level three on both hosts requests to controller to disconnect the logical level 2 and then to disconnect the call. In the case of alien hosts who do not understand the proprietary protocols, the alien host is always the DTE and the non-alien host is always the DCE. Hold and auto-redial could be negotiated in the XID but I would tend to make the default to disallow hold and neither expect nor perform auto-redial in case of disconnect but rather inform level 3 of termination of level 2 so that the VCs could be abnormally terminated from the host point of view. When one of my hosts calls a PSDN or is called by a PSDN, the PSDN would of course be the DCE while my (non-alien) host would be the DCE. Procedures about hold and auto-redial would be negotiated with the PSDN at subscription time and could be exchanged in the XID. To me this all seems like a perfectly reasonable way to do data communications via ISDN (I mean real resource sharing not kermit) however all the network "experts" at my employer totally freaked at my suggest and scenarios. I would like opinions. If you comment, I would be interested in your background and experience because I guess I am conducting a survey and I would like to have some sort of guide to weight opinions. If you prefer, you may send your comments to me by private mail at martillo@athena.mit.edu ..!ihnp4!mit-eddie!athena!martillo If there is desire, I can post the results to the net. Yaqim Martillo Path: bacchus!mit-eddie!rutgers!ames!ucbcad!ucbvax!ucbarpa.Berkeley.EDU!fair From: fair@ucbarpa.Berkeley.EDU (Erik E. Fair) Newsgroups: comp.dcom.lans,comp.dcom.modems Subject: Re: X.25, X.31 vs Q.921/Q.921 and Networking Style in General Message-ID: <17977@ucbvax.BERKELEY.EDU> Date: 23 Mar 87 13:20:42 GMT References: <363@bacchus.MIT.EDU> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Michael A. Padlipsky Fan Club Lines: 6 Xref: bacchus comp.dcom.lans:182 comp.dcom.modems:270 Do the obvious thing: chuck it all and use the DoD Internet Protocol suite for this application. It is certainly clear that you need some sort of transport that makes no assumption about the reliability of the data link layers, and the X.* stuff doesn't seem to qualify. Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu Path: bacchus!martillo From: martillo@athena.mit.edu (Yakim Martillo) Newsgroups: comp.dcom.lans,comp.dcom.modems Subject: Re: X.25, X.31 vs Q.921/Q.921 and Networking Style in General Message-ID: <366@bacchus.MIT.EDU> Date: 25 Mar 87 02:40:13 GMT References: <363@bacchus.MIT.EDU> <17977@ucbvax.BERKELEY.EDU> Sender: daemon@bacchus.MIT.EDU Reply-To: martillo@athena.mit.edu (Yaqim Martillo) Organization: MIT Project Athena Lines: 77 Xref: bacchus comp.dcom.lans:189 comp.dcom.modems:277 In article <17977@ucbvax.BERKELEY.EDU> fair@ucbarpa.Berkeley.EDU (Erik E. Fair) writes: >Do the obvious thing: chuck it all and use the DoD Internet Protocol >suite for this application. It is certainly clear that you need some >sort of transport that makes no assumption about the reliability of >the data link layers, and the X.* stuff doesn't seem to qualify. While I have enjoy Padlipsky's writing, you have missed the point (or I have accidentally mislead you), the X.25, X.31, LAPD, Q.921/Q.931 suite of protocols is not comparable to TCP/IP but is rather comparable to 1822. The ISDN switch is basically comparable to an IMP (or PSN nowadays I guess). One might argue about the virtual circuit orientation of the X.25 but in fact an ISDN switch is much more complicated than an IMP and you really need something more complex than 1822. As for the circuit orientation, from personal experience in dealing with the FCC, I believe tariffing a reliable virtual circuit access protocol in which the remote end point is specified is much easier than tariffing an access protocol like 1822. Of course, the existence of a level 3 reset is relatively stupid in a virtual circuit oriented access protocol, but the level 3 reset was *demanded* by the PDNs because of the limitations of their switches. Running TCP/IP on top of X.25 is just as reasonable as running TCP/IP on top of 1822 but as far as the PTTs and the private long distance carriers are concerned, they have no interest in an internetting layer or a transport layer built on top of it. A true internetting layer makes tail-end-hop-off (popping in and out between public and private networks where the two end point are accessing the catenet via public phone lines in order to decrease phone bills) and such a specification will never come out of CCITT. Now the proprietary network on which I am working was developed before the modern TCP/IP based Arpanet came into existence. As I understand it the pre-TCP/IP Arpanet basically used a predecessor of 1822 as an end to end protocol, so that my contractee's decision to go with X.25 as the network communications protocol was not unreasonable especially given that the major portion of their business is overseas where until recently no one did TCP/IP. Of course not learning anything from the Arpanet experience is pretty close to criminal but the company is being punished in its sales, so justice is being served. Granted, there is no real reason to run X.25 on an unrestricted digital 64kbps CSC bearer channel except that the CSC may equally probably be going to a PSDN as to one of the proprietary network hosts where one of the network hosts is acting as the DCE and pretends to be a PSDN. This is reasonable because if some other manufacturer supports some service via a PSDN, my contractee can directly offer that service to the other manufacturer's equipment because my contractee's equipment can pretend to be a PSDN. But my contractee is also trying to sell real data communications via a ISDN-PBX-LAN and my feeling is that while the network hosts can pretend to be PSDNs, among friends (non-alien hosts), the host that pretends to be a DCE does not have to imitate the non-obligatory procedures which PSDNs use like VC reset, some of the network-level restarts, the various worthless level 3 DCE timers. If they do complete imitation of the PSDN non-obligatory procedures, a CSC based ISDN-PBX-LAN running the proprietary data communications network should quite quickly become fragmented into topologically disconnected islands of network connectivity with evil consequences like dead-lock, loss of network services and inability to use to use some of the niftier features of Q.921/Q.931 [of course maybe they are trying to prevent the ultimate convergence of phone and computer hacking :)]. I would really like some genuine X.25/PSDN expert to tell me my suggestion is perfectly reasonable and is in fact the right way to do data communications in the environment of a CSC based ISDN-PBX-LAN using the X.25 suite of protocols. Of course, if I am wrong I would like to be told and be told why. The network-expert at my contractee's has yet to show any understanding of data communications at a level more sophisticated than that of a PAD. Yaqim Martillo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703270733.AA22168%40amdcad.AMD.COM] <1987032621332300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rpw3@amdcad.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703270733.AA22168@amdcad.AMD.COM> Date: Fri, 27-Mar-87 02:33:23 EST Article-I.D.: amdcad.8703270733.AA22168 Posted: Fri Mar 27 02:33:23 1987 Date-Received: Sat, 28-Mar-87 11:01:37 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: amdcad!rpw3@decwrl.DEC.COM (Rob Warnock) Distribution: world Organization: [Consultant] San Mateo, CA Lines: 18 Approved: tcp-ip@sri-nic.arpa Summary: Use 6250bpi If you use 6250 fci, 2400' tape, and long records, you can get about 80% use of the tape, or 144 Mbytes. Adds ANOTHER factor of 3, so the original posting was about an order of magnitude low. Incidently, given the volume of stuff that is seen on USENET (over 1 Mbyte/day, now), and the size of some of the phone bills, the typical transport delay, and the fact that priority (2-day) mail is fairly cheap, mailed magtapes (small ones) or floppies really SHOULD be considered as a way of distributing netnews! Rob Warnock Consultant UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3 ATT: attmail!rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703271338.AA06455%40ucbvax.Berkeley.EDU] <1987032703240800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DYOUNG@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP/IBM/Pronet Message-ID: <8703271338.AA06455@ucbvax.Berkeley.EDU> Date: Fri, 27-Mar-87 08:24:08 EST Article-I.D.: ucbvax.8703271338.AA06455 Posted: Fri Mar 27 08:24:08 1987 Date-Received: Sat, 28-Mar-87 13:07:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Does anyone have any experience using TCP/IP on an IBM 4381 connected to a Proteon ProNET? Any pointers would be useful. David ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032703240801> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 27 Mar 87 05:31:07-PST Date: 27 Mar 1987 08:24:08 EST Subject: TCP/IP/IBM/Pronet From: C. David Young To: tcp-ip@SRI-NIC.ARPA cc: DYOUNG@A.ISI.EDU Does anyone have any experience using TCP/IP on an IBM 4381 connected to a Proteon ProNET? Any pointers would be useful. David ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703271619.AA08142%40ucbvax.Berkeley.EDU] <1987032705561100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ahill@CC7.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Fact or fiction Message-ID: <8703271619.AA08142@ucbvax.Berkeley.EDU> Date: Fri, 27-Mar-87 10:56:11 EST Article-I.D.: ucbvax.8703271619.AA08142 Posted: Fri Mar 27 10:56:11 1987 Date-Received: Sat, 28-Mar-87 13:41:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Darrel, I'll take a crack at answering your knowledgable inquiries. Basic X.25 allows multiple VCs between a given host pair. Each VC gets its own connection at level 3. X.25 traffic is encapslated in 1822 and delivered to the subnet. The traffic is subject to 1822 restrictions. All traffic between host pairs is on one dynamic subnet connection. X.25 acts like a software host so 1822 delivers the encapslated data to X.25 which handles the L3 connection control. Your understanding of Standard X.25 is correct. The answer to your question is Yes. IOP strives to do the reasonable thing about hardware padding on messages. BBN believes that there was a problem during the early days of IOP but the software has been corrected. If this is not the case I hope people will speak up and let us know. PSN 7.0 will make significant changes in the way X.25 traffic is handled as well as major modifications to the subnet E-E. X.25 and AHIP (1822) will be handled as peer protocols thus elimnating the need for IOP and significantly improving X.25 performance. RFC978 might help you understand some of the features of PSN 7.0. Regards, Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032705561101> Received: from cc7.bbn.com by SRI-NIC.ARPA with TCP; Fri 27 Mar 87 08:13:13-PST Date: Fri, 27 Mar 87 10:56:11 EST From: "Alan R. Hill" Subject: Re: Fact or fiction In-Reply-To: Your message of 24 Mar 1987 12:32:39 CST To: AFDDN.TCP-IP@gunter-adam.arpa Cc: tcp-ip@sri-nic.arpa Darrel, I'll take a crack at answering your knowledgable inquiries. Basic X.25 allows multiple VCs between a given host pair. Each VC gets its own connection at level 3. X.25 traffic is encapslated in 1822 and delivered to the subnet. The traffic is subject to 1822 restrictions. All traffic between host pairs is on one dynamic subnet connection. X.25 acts like a software host so 1822 delivers the encapslated data to X.25 which handles the L3 connection control. Your understanding of Standard X.25 is correct. The answer to your question is Yes. IOP strives to do the reasonable thing about hardware padding on messages. BBN believes that there was a problem during the early days of IOP but the software has been corrected. If this is not the case I hope people will speak up and let us know. PSN 7.0 will make significant changes in the way X.25 traffic is handled as well as major modifications to the subnet E-E. X.25 and AHIP (1822) will be handled as peer protocols thus elimnating the need for IOP and significantly improving X.25 performance. RFC978 might help you understand some of the features of PSN 7.0. Regards, Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [YUOegJy00UgcotI0B1%40andrew.cmu.edu] <1987032706384500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ms6b#@ANDREW.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: Date: Fri, 27-Mar-87 11:38:45 EST Article-I.D.: andrew.YUOegJy00UgcotI0B1 Posted: Fri Mar 27 11:38:45 1987 Date-Received: Sat, 28-Mar-87 14:46:48 EST References: <8703252309.a019065@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa In their classic article published in 1970*, Roberts and Wessler compare the cost per megabit for a variety of transmission media including mailing an IBM tape. (Which was lower by an order of magnitude than any other medium.) *"Computer network development of achive resource sharing," Proceedings of the AFIPS Spring Joint Computer Conference, vol 36, May 5-7, 1970 pp. 543-549. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703271736.AA02854%40braden.isi.edu] <1987032707361200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: UCLA TN3270 negotiation Message-ID: <8703271736.AA02854@braden.isi.edu> Date: Fri, 27-Mar-87 12:36:12 EST Article-I.D.: braden.8703271736.AA02854 Posted: Fri Mar 27 12:36:12 1987 Date-Received: Sat, 28-Mar-87 14:47:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 33 Approved: tcp-ip@sri-nic.arpa Could someone familiar with the UCLA ACP tell me at what point in the connection/login sequence it first negotiates 3270 mode (Term Type, EOR and Binary)? I have tried connecting to an UCLA MVS Arpanet machine, but negotiation didn't seem to take place on connection open (unlike WISCNET), and I didn't have an account, so I haven't been able to proceed further. Is my code broken, or do I have to log in to really test it? James, Well, yes, I can tell you. Too bad you did not go to the TCP/IP Interoperability Workshop in Monterey last week; Greg Minshall gave a whole session on IBM 3270 support, and I described the rules for negotiation into fullscreen mode. Basically, VM uses a less-than-general approach to fullscreen negotiation because of restrictions in that operating system's virtual terminal machinery. If you simply connect to a UCLA MVS system with a normal Telnet NVT, you will understand the problem. It does not negotiate fullscreen mode until it is able to determine that the particular service subsystem of the host to which you actually want to talk handles fullscreen mode. EG, if you "logon" to TSO, it will then try to negotiate full screen; when you logoff TSO, it will return you to NVT mode, etc. Since this topic is probably not of general interest, and has been somewhat beaten to death in the past, I suggest we take any further discussion on this off the mailing list. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12289768346.39.SUE%40SRI-NIC.ARPA] <1987032707534900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HOSTMASTER@SRI-NIC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Wollongong VMS V4.2 Message-ID: <12289768346.39.SUE@SRI-NIC.ARPA> Date: Fri, 27-Mar-87 12:53:49 EST Article-I.D.: SRI-NIC.12289768346.39.SUE Posted: Fri Mar 27 12:53:49 1987 Date-Received: Sat, 28-Mar-87 14:45:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: HOSTMASTER@SRI-NIC.ARPA Distribution: world Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa To all those running Wollongong VMS V4.2 which does not handle domain-style naming: All customers under support can get a copy of the fixed mailer (tape) from Wollongong. The product manager at Wollongong has said that all DDN customers have been "automatically identified." TCP/IP customers should have or will get a letter from Wollongong about the fixed mailer. If you are not under support, have not been notified either by letter or other means, and need to get a copy of the tape, please call (415) 962-7140 for assistance. This number is the Wollongong support line. -NIC hostmaster ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703271845.AA29686%40mitre.ARPA] <1987032708451000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703271845.AA29686@mitre.ARPA> Date: Fri, 27-Mar-87 13:45:10 EST Article-I.D.: mitre.8703271845.AA29686 Posted: Fri Mar 27 13:45:10 1987 Date-Received: Sat, 28-Mar-87 14:36:26 EST References: <8703260316.AA23501@flash.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 37 Approved: tcp-ip@sri-nic.arpa This note is from Steve Silverman "m15368%mwvm@mitre.arpa" He's not on the tcp-ip mailing list. We have some kind of weird lash-up here at MITRE with a curious lack of transitivity: Steve can send to me; you and I can send to Steve, but Steve can't send to you. Anyway ..... ________________________________ To: KARN%FLASH.BELLCORE.COM From: Steve Silverman Subject: future networks I just received a copy of your message of 3/25 on future nets. I agree with you and the current direction of network evolution as developing in T1D1 and SG XVIII supports what you said. Frame relay uses LAPD on each end with the transit switches just relaying the frames. This allows very low transit delay and high capacity switches. AT&T is supposedly testing a megapacket/second switch. The Bellcore contingent at T1D1 is fairly active in this. Do you know Kaj Tesink? (I don't know how to spell his name but I think he works for Joan LaBanca.) (Kaj rhymes with sky.) Frame Relay is a complete violation of the OSI model but nobody wants to admit it. In my view, the fiber-optic explosion has invalidated the details of the OSI model. The FO error rate is low enough that it no longer pays to do error checking and retransmission on a link by link basis. I think that the deployment of ISDN equipment in the 88-91 timeframe will will be a major shock to the current networking world. Running layer 2 end to end will make layer 3 redundant. (Except we are moving some of the layer 3 functionality into Q.931 (the call control protocol).) Most of the data networking world is oblivious to ISDN. I still hear statements that it won't happen until the next century. I think that by 1990, ISDN will be in serious use in many places. Steve Silverman ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703272120.AA00114%40utah-gr.ARPA] <1987032711205800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haas%utah-gr@UTAH-CS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <8703272120.AA00114@utah-gr.ARPA> Date: Fri, 27-Mar-87 16:20:58 EST Article-I.D.: utah-gr.8703272120.AA00114 Posted: Fri Mar 27 16:20:58 1987 Date-Received: Sat, 28-Mar-87 15:38:55 EST References: <8703250201.AA06443@flash.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa In article <8703250201.AA06443@flash.bellcore.com>, karn@FLASH.BELLCORE.COM (Phil R. Karn) writes: > ... I understand that > each GTE Telenet node speaks X.75 to its neighbors, making it an unlayered > VC network. Because of this, a node or link failure ANYWHERE along the > connection path causes an X.25 VC reset, not just failures at the end nodes. Not entirely correct. The interface protocol X.25 is not affected if an intermediate TCO fails, since the endpoint TCOs will reestablish the VC (if possible) via an alternative route. The hosts will see a VC reset only if one of the two endpoint TCOs fails. Tymnet does the same thing by a similar mechanism. Cheers -- Walt ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703272138.AA00475%40utah-gr.ARPA] <1987032711383800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haas%utah-gr@UTAH-CS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: network horror stories Message-ID: <8703272138.AA00475@utah-gr.ARPA> Date: Fri, 27-Mar-87 16:38:38 EST Article-I.D.: utah-gr.8703272138.AA00475 Posted: Fri Mar 27 16:38:38 1987 Date-Received: Sat, 28-Mar-87 16:36:27 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa One of the more interesting but little-discussed events in the history of network engineering occured when Telenet converted from unreliable-datagram internal architecture to VC internally. For a good discussion of the whys and wherefores of Telenet internal architecture see a paper entitled "An X.75 Based Network Architecture" by D. F Weir, J. B. Holmblad and A. C. Rothberg published in the "Proceedings of the Fifth International Conference on Computer Communications", 1980. If you don't feel like chasing the Proceedings around the library Telenet will probably give you a free copy of the paper. The justification for ripping out the datagram code and replacing it with VC code was economic. There is less waste and better management of the resource in a VC network. I quote from the cited paper: "... in the late 70's it became economically attractive to incur additional processing and storage costs in order to reduce communications costs... ... By establishing fixed paths, virtual circuit routing can better balance load as compared with routing in a datagram based network ... congestion at a transit point in a virtual circuit network can be reflected back to the endpoint nodes to restrict flow into the network. This capability results from access to the virtual circuit at transit nodes using the logical channel number. In a datagram network, knowledge of virtual calls does not exist at transit nodes and flow control cannot easily be applied to the virtual circuits at the endpoints." Cheers -- Walt ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703272058.a020394%40Huey.UDEL.EDU] <1987032715585600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: network horror stories Message-ID: <8703272058.a020394@Huey.UDEL.EDU> Date: Fri, 27-Mar-87 20:58:56 EST Article-I.D.: Huey.8703272058.a020394 Posted: Fri Mar 27 20:58:56 1987 Date-Received: Sat, 28-Mar-87 17:45:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa Rudy, You are referring to what are called "hard-to-reach" (HTR) numbers. Clever switches remember HTR prefixes in order to back congestion up towards the source. Now consider doing the same thing in an IP gateway. All it has to do is wiretap ICMP messages on the way back to the sender and cache the information for awhile. You may remember the general reaction (horror) in response to this suggestion some time back. Many consider wiretapping ICMP messages something only a little less sinful than forwarding redirects across gateways. Considering the almost universal practice of ignoring ICMP error messages, perhaps your comment may spark a minor change in that thinking. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).27-Mar-87.23:21:51.VAX.DARPA.MIL] <1987032718215100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Need Info on SMTP Message-ID: Date: Fri, 27-Mar-87 23:21:51 EST Article-I.D.: Posted: Fri Mar 27 23:21:51 1987 Date-Received: Sat, 28-Mar-87 17:15:30 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Calvin, you might check with Los Alamos. They have an All-in-one connection to unix mail which seems to work. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032718215101> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Fri 27 Mar 87 20:22:51-PST Posted-Date: Fri 27 Mar 87 23:21:51-EST Received: by vax.darpa.mil (5.54/5.51) id AA02033; Fri, 27 Mar 87 23:21:55 EST Date: Fri 27 Mar 87 23:21:51-EST From: Dennis G. Perry Subject: Re: Need Info on SMTP To: george@eglin-vax.arpa Cc: tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from ""CALVIN R GEORGE" " of 24 Mar 87 10:06:00 CST Calvin, you might check with Los Alamos. They have an All-in-one connection to unix mail which seems to work. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703281522.AA26822%40ucbvax.Berkeley.EDU] <1987032805081100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hinden@CCV.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703281522.AA26822@ucbvax.Berkeley.EDU> Date: Sat, 28-Mar-87 10:08:11 EST Article-I.D.: ucbvax.8703281522.AA26822 Posted: Sat Mar 28 10:08:11 1987 Date-Received: Sun, 29-Mar-87 08:56:04 EST References: <12289526116.32.GROSSMAN@Sierra.Stanford.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Stu, A collision in Wagonnet is, of course, much more serious than on an Ethernet. Retransmissions might be more difficult to arrange. You do have all of your "bits" in one "Wagon" :-). Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032805081101> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Sat 28 Mar 87 07:14:13-PST To: Stu Grossman cc: tcp-ip@sri-nic.ARPA Subject: Re: Station wagon full of bits In-reply-to: Your message of Thu 26 Mar 87 11:43:12-PST. <12289526116.32.GROSSMAN@Sierra.Stanford.EDU> Date: 28 Mar 87 10:08:11 EST (Sat) From: Robert Hinden Stu, A collision in Wagonnet is, of course, much more serious than on an Ethernet. Retransmissions might be more difficult to arrange. You do have all of your "bits" in one "Wagon" :-). Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703281707.AA27706%40ucbvax.Berkeley.EDU] <1987032806013500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MAB@CORNELLC.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703281707.AA27706@ucbvax.Berkeley.EDU> Date: Sat, 28-Mar-87 11:01:35 EST Article-I.D.: ucbvax.8703281707.AA27706 Posted: Sat Mar 28 11:01:35 1987 Date-Received: Sun, 29-Mar-87 12:10:38 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Stu, in comparing Wagonnet with Ethernet, you mentioned that for Wagonnet, congestion is not as much of a problem. What you neglected to mention, though, is that for our now well-discussed station wagon, collisions are much more serious! (Sorry, couldn't resist. :-) Mark Bodenstein ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032806013501> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Sat 28 Mar 87 09:00:09-PST Received: from CORNELLC.BITNET by wiscvm.wisc.edu on 03/28/87 at 10:17:11 CST Received: by CORNELLC (Mailer X1.23b) id 0604; Sat, 28 Mar 87 11:14:50 EST Date: Sat, 28 Mar 87 11:01:35 EST From: Mark Bodenstein Subject: Re: Station wagon full of bits To: Stu Grossman cc: TCP-IP@sri-nic.arpa In-Reply-To: Your message of Thu 26 Mar 87 11:43:12-PST Stu, in comparing Wagonnet with Ethernet, you mentioned that for Wagonnet, congestion is not as much of a problem. What you neglected to mention, though, is that for our now well-discussed station wagon, collisions are much more serious! (Sorry, couldn't resist. :-) Mark Bodenstein ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703281227.a027209%40Huey.UDEL.EDU] <1987032807273900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Routing hold-downs Message-ID: <8703281227.a027209@Huey.UDEL.EDU> Date: Sat, 28-Mar-87 12:27:39 EST Article-I.D.: Huey.8703281227.a027209 Posted: Sat Mar 28 12:27:39 1987 Date-Received: Sun, 29-Mar-87 10:47:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 78 Approved: tcp-ip@sri-nic.arpa Folks, Yesterday I happened to watch the EGP tables in one gateway just after another gateway crashed. The intent was to see how long old information about nets serviced by that gateway persisted and whether naughty things might be happening as it dissipated in the various caches. The old information persisted well over an hour. Shocked out of my socks, I started digging further. The gateway that crashed represented the only path to two innocent networks; however, reachability was being advertised via EGP to the core and also along a different path to the NSFNET swamps, a situation typical of many universities these days. Therefore, I looked for route loops, cache relatches and other phenomena characteristic of the algorithms used on these wetlands. I can't speak for all implementations and in fact can speak authoritatively only for the ones used by the fuzzballs, which are scattered all over the swamps. The routing algorithms used by the fuzzballs (sometimes called "hello") are very careful about dissipating old information and avoiding loops, at least between neighbors. A two-minute hold-down interval is enforced once a previously reachable path goes down, during which reachability claims are ignored. This mechanism, used at various times in other algorthms, including ARPANET, is designed to avoid re-introduction of old, now bogus information. The interval is selected to be at leat as long as the maximum time to spread routing information throughout the system, which can be a pretty long time. Obviously, in the present case we have to look beyond the fuzzballs to find where the old information is being stashed. Note that this can happen anywhere in the world and it only takes one rogue who innocently may have a funny idea how long this information should live in its cache and then re-introduce it into the system, finding its way back to the fuzzballs, core gateways or whatever, and start the whole process all over again. Why should we care about the problem? It is typical of such phenomena that route loops form; thus, traffic to the now-unreachable destinations must circulate somewhere until the TTL fields expire. The key indicator of that is the ICMP Time Exceeded message. If these are popping up at your host, the problem is also yours. My observations might suggest a hold- down should be in the order of an hour, but I don't think this is the case. More likely one or more implementations have no hold-down at all. Lessons learned: Operations people (this includes both the INOC, NSF and related monitoring centers) must do more than react to reported problems and go out looking for them. This comment is not meant in any way to detract from their excellent service and prompt response given for a long time, but might suggest additional, specialized staff might be necessary. The lookers might start by periodically rummaging over the data bases at strategic spots looking for excessive "churn" (entries changing very often) and inconsistencies. Occasional tests should be done involving a net being turned off, watching the systemic response and so forth. I've been doing thee things informally for some years now and occasionally reporting the results to this list. Now the system has grown to big for me to do that. The important implementor's lesson is that a coordinated hold-down (or equivalent) is absolutely necessary. My guess is that two minutes is not enough and maybe twice that is more appropriate. We also need to examine those cases where, for various reasons, information must be cached for much longer than this interval, such as when public networks are involved. One rule might be that, if you have to cache something for longer than the hold-down interval, you can't ever tell anybody else about it. And so forth. As hinted recently, it might be time to re-examine the "wiretapping" issue, where a gateway observing an ICMP error message wandering by to a host on one of its connected networks is examined for possible hints that might be useful in its forwarding and routing functions. A sufficient number of these for the same destination within some time should be grounds to declare the destination unreachable, thus avoiding needless congestion, looping and other antisocial behavior. Yes, I know the layer violations implicit in the above may drive many up the wall. Please show this message to them the next time their TCP/TELNET connection times out. At least two readers of this list will notice this could be the first toenail in the "fair-queueing" closet. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703282014.AA09837%40bu-cs.bu.edu] <1987032810145600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703282014.AA09837@bu-cs.bu.edu> Date: Sat, 28-Mar-87 15:14:56 EST Article-I.D.: bu-cs.8703282014.AA09837 Posted: Sat Mar 28 15:14:56 1987 Date-Received: Sun, 29-Mar-87 11:58:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa While at Harvard in the mid-70's we in fact used a similar method of transferring things. We had a research group in Ohio and occasionally the (semi-portable home-brewed) computer broke down. We simply ran to the airport with a spare, bought it a seat on the next flight and had someone meet it at the airport gate at the other end (a similar method is often used to transfer children around the country.) We did the same sort of thing with (large) boxes of floppies occasionally to start up data analysis, it worked well enough (plus or minus traffic jams at Logan Airport.) The broken computer was returned similarly. The cost was very reasonable compared to other options, we were under heavy time pressure to keep the data collection rolling. While we're on the subject of using planes, why not rockets laden with CDs and launched in parabolic arcs, much faster. We can refer to it as the Strategic Data Initiative, perhaps a proposal is in order. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703291921.AA12554%40ucbvax.Berkeley.EDU] <1987032903484200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Tcp/Ip vs a store & forward network Message-ID: <8703291921.AA12554@ucbvax.Berkeley.EDU> Date: Sun, 29-Mar-87 08:48:42 EST Article-I.D.: ucbvax.8703291921.AA12554 Posted: Sun Mar 29 08:48:42 1987 Date-Received: Sun, 29-Mar-87 23:46:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa All the calculations about the bandwidth of a station wagon got me thinking. Why was Tcp/Ip not designed as a store and forward network (in addition to the protocols it does support)? Let me explain why I am asking this. In Bitnet, you might have as many as 20 9.6Kb lines separating you from the place you wish to send a file to. The probably that all 20 lines are working and that all 20 intermediate machines are up (yup - no IMPs) simaltaneously becomes quite small. (Imagine if the probability of any machine being up and working is 98% and that the probablility that any leased phone line is working is 99.5% - after 10 machines - 77.7% successful connection). Well you can say alternate paths and better reliability make the connection rate closer to 95%. I would perhaps doubt that when the two nodes are separated by a number of physical links and that the data has to pass thru a couple of hardware boxes that will not work if there is a power outage in the building or other "things" that can cause a hardware box to not respond. So, a S&F network would alleviate much of the problem. Try to get the data as close to the destination node and then spool it. Instead SMTP makes a valiant attempt to emulate S&F by spooling the mail locally and occassionally trying to establish a connection to the destination. After 'n' of days SMTP gives up and sends mail to the sender. I think it would have been nicer that SMTP try to get it as close to the down node as possible and then let that node try polling the down node for 'n' number of days. But FTP is even worse. FTP is basically an interactive process. You want a file you gotta establish a connection and suck it off or slap it into place. Transferring files should really be a batch orientated feat - you say what file you want to store or retrieve and you type in all the necessary options and parameters and you don't hear about it until it completes (with appropriate return codes of course). Bitnet uses BSMTP (Batch SMTP). Is there such a thing as BFTP (Batch FTP)? Is there a very strong technical reason why S&F was not part of the design of Tcp/Ip?? I have a lot of questions but very few answers. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703291428.AA29318%40brillig.umd.edu] <1987032904285000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: steve@BRILLIG.UMD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ICMP message caching Message-ID: <8703291428.AA29318@brillig.umd.edu> Date: Sun, 29-Mar-87 09:28:50 EST Article-I.D.: brillig.8703291428.AA29318 Posted: Sun Mar 29 09:28:50 1987 Date-Received: Sun, 29-Mar-87 23:42:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa Recently, I've been considering wedging some code into the 4.3 kernel that would let me do some ICMP message caching both in individual hosts and in gateways. It seems to me that intelligent use of such a feature could cut down on extra packet sends, especially in terms of behavior like the recent mess with ISIB and domain name serving. After all, if one "connection" discovers that a host is down, there is no need for everything else to find that information out for itself. This would also fix the problems with getting errors back on unconnected UDP sockets; a packet to a down site would elicit an unreachability message which would not be reported to the user, but the next send to that site would result in an immediate error without ever going to the net. It also seems to me that doing this sort of caching in a gateway might not be a bad idea, but Dave Mills' recent message seems to indicate that people think this is an evil idea. It was suggested to me that ICMP messages should get delivered (via raw ICMP socket, perhaps) to a user-level process, which has more smarts to it than the kernel can reasonably have and which uses ioctls to stick information into the kernel's cache. That way, it's relatively easy to change policies to ignore, for example, single ICMP errors (a single ICMP unreachability error might be due to routing changes, perhaps), but to add entries to the cache if it sees the same error a number of times. Also, it might be possible to associate error information with routes so that a host trying to reach another host and which has two different ways to get there can take note of the error and try to send via a different route. It seems that this issue has been discussed before, and while I don't remember what brought this idea to mind, I doubt that it is at all original. If this has been beaten to death publicly and someone could give me some pointers to RFCs or into the archives, I would appreciate it. Otherwise, maybe we can discuss it here. -Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870329202736.635670%40MIT-MULTICS.ARPA] <1987032910270000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Kodinsky@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Telnet Option Negotiation to IBMish Hosts Message-ID: <870329202736.635670@MIT-MULTICS.ARPA> Date: Sun, 29-Mar-87 15:27:00 EST Article-I.D.: MIT-MULT.870329202736.635670 Posted: Sun Mar 29 15:27:00 1987 Date-Received: Tue, 31-Mar-87 01:02:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa I wish to first apologize for not reading and responding to this note earlier. It obviously has great importance to the KNET telnet programs (both client and server). The KNET telnet client and server operate almost identically to the procedure laid out in Marvin's note (at least that is the way they should operate). There are a few exceptions - FIRST: we will renegotiate the terminal type at any time - though in ] the "No change" mode. As a matter of fact, if the terminal type were to be changed (within telnet server storage) there would be no effect - the logical device already exists. SECOND: we do not, as best as I can tell, require an EOR option to be negotiated. If we are in "3270" mode then we automatically assume that EOR is going to be understood by the other end. I think that an RFC would be a good thing for this. It should address two issues: the details of 3270 telnet AND (more importantly) the issues involved in tying together interdependent options (as Marvin Pointed out). We at Spartacus would be glad to work with the community on this RFC. We do not feel that we can take a lead in this effort since we have been on the net for only a few months. Regards, Frank Kastenholz - Manager KNET/VM Development - Spartacus/Fibronics ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703292331.AA28741%40bu-cs.bu.edu] <1987032913311500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Tcp/Ip vs a store & forward network Message-ID: <8703292331.AA28741@bu-cs.bu.edu> Date: Sun, 29-Mar-87 18:31:15 EST Article-I.D.: bu-cs.8703292331.AA28741 Posted: Sun Mar 29 18:31:15 1987 Date-Received: Tue, 31-Mar-87 01:09:45 EST References: <8703292254.AA28103@bu-cs.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 54 Approved: tcp-ip@sri-nic.arpa Hank, Your questions mostly focus on design trade-offs. Trying to get the data as close to to the destination node and then spooling might not be defineable in many cases. What does closer mean when routing can be changed? The very notion implies that a route calculated at transmission time remains static (perhaps for days) as the file moves from host to host through the network. This is not always a reasonable assumption. I do think a Batch FTP is a fine idea, many people accomplish this anyhow by backgrounding transfer jobs, others by sending files through the mail networks. One major issue, of course is security. FTP is designed to demand a password before a file transfer begins. Not sure how this is accomplished in batch mode without sending passwords around the net (store and forward exacerbates this problem as passwords may lie on intermediate hosts for long periods of time.) Bitnet basically takes the attitude that it is similar to mail and files are simply put on a spool for a target user, no password to send a file is required. How *does* a user fetch a file within the Bitnet sendfile paradigm? Other than specialized servers for certain files, of course. Another problem with S&F networks at the higher (that is file or mail message) level are the failure modes presented. Clogging of hosts' disks receiving these as intermediaries becomes a problem (I believe WISCVM fell as much as 3 weeks behind in file transfers recently due to this type of clogging? correct me if I'm wrong, I mean no malice.) Packets are much more ephemeral things. There, of course, is also the problem of getting an error or success back to the originator from an intermediate node who decides the file's fate has been sealed. For another extreme, try MAIL-11 on VMS in a DECNET network. You can't send a message unless it is immediately deliverable, very annoying to me to end a message (typically a reply) and have it immediately rejected because the host happens to be down at the moment. This is a place where some kind of store and forward seems essential, I hate "busy signals" in mail networks. I think my conclusion is that it would probably be interesting to see someone propose and design a store and forward file transfer protocol and get it accepted by the community. There are several design problems but I don't think the concept is flawed, why have a human sit and wait on a slow link? Or not be able to initiate a transfer just because a host is down at the moment? I don't think, however, Bitnet is a great model for this at all layers if for no other reason than the fact that the routing is so well defined in Bitnet for where to store and where to forward while in the Internet things get a bit more nebulous. But, hey, that's what the designer will have to solve. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703300117.AA15165%40gwen.cs.purdue.edu] <1987032915165800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: narten@PURDUE.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <8703300117.AA15165@gwen.cs.purdue.edu> Date: Sun, 29-Mar-87 20:16:58 EST Article-I.D.: gwen.8703300117.AA15165 Posted: Sun Mar 29 20:16:58 1987 Date-Received: Tue, 31-Mar-87 01:49:32 EST References: <8703300006.AA19177@arthur.cs.purdue.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa One big problem with S&F networks is the lack of end-to-end acks. Once you drop a "transaction" (e.g. batch ftp or piece of mail) in the queue of one of the intermediate nodes, it is out of your hands. You don't know where it is, and you can't find out. How many times have you sent mail into a black hole? It happens much more often in store and forward networks than in the TCP world. Based on my experience, when I send mail over TCP to a user, I feel very confident that it gets to them. If the mail gets lost, its almost always because the mail subsystem at the receiving site is messed up. Sending mail through mail lists (which puts in an extra S&F hop) is also pretty reliably, though not as much. On the other hand, when mailing via one of the S&F networks, my confidence falls rapidly as the number of hops increases. You might argue that the reliability of S&F networks could be improved. No matter how reliable you make them, you will still be left with a system where everything you drop in disappears, and there is no way of finding out where it is until it comes out at the other end (if it does). Not too good when you just sent an important message. Thomas ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12290411719.278.SY.KEN%40CU20B.COLUMBIA.EDU] <1987032918475800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sy.Ken@CU20B.COLUMBIA.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <12290411719.278.SY.KEN@CU20B.COLUMBIA.EDU> Date: Sun, 29-Mar-87 23:47:58 EST Article-I.D.: CU20B.12290411719.278.SY.KEN Posted: Sun Mar 29 23:47:58 1987 Date-Received: Tue, 31-Mar-87 01:11:27 EST References: <8703291731.AA04028@columbia.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Stu, in comparing Wagonnet with Ethernet, you mentioned that for Wagonnet, congestion is not as much of a problem. What you neglected to mention, though, is that for our now well-discussed station wagon, collisions are much more serious! (Sorry, couldn't resist. :-) I would also hope that the driver would not "back off and retry"... :-) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703300458.AA02844%40ka9q.bellcore.com] <1987032918584200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@KA9Q.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Tcp/Ip vs a store & forward network Message-ID: <8703300458.AA02844@ka9q.bellcore.com> Date: Sun, 29-Mar-87 23:58:42 EST Article-I.D.: ka9q.8703300458.AA02844 Posted: Sun Mar 29 23:58:42 1987 Date-Received: Tue, 31-Mar-87 01:13:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 48 Approved: tcp-ip@sri-nic.arpa Actually, I thought the Internet WAS a store-and-forward network. Gateways store up packets as they are received and forward them after a queueing delay. I think you really meant "message switching" as opposed to "packet switching". But even this distinction is rather artificial. One of the most popular message switching networks is UUCP. Like the Internet, each UUCP node also stores up a block of information, makes a routing decision (sometimes specified in a source route) and sends it on its way. The only real differences are quantitative, i.e., the maximum allowable message size and the typical end-to-end delivery delay, although admittedly they heavily influence the way end-user nodes make use of the service. You *could* run TCP on top of UUCP (encapsulating one segment per message) as long as it is prepared to deal with RTTs of several days. On the other hand UDP query-response applications use the Internet as though it were a message switching network, since messages fit neatly into Internet datagrams. Perhaps the only real qualitative distinction is whether the network is useful for "real time" communications, however you define them. Nobody runs SMTP/TCP/IP on UUCP because few are willing to wait several days for a TCP 3-way handshake to complete. Instead UUCP mail consists of single, large, self-contained "datagrams" with no end-to-end protocol other than the implicit human-to-human one. Of course this means you have no real guarantee that the message will get there, so everyone puts in lots of low-level reliability enhancing mechanisms. I prefer SMTP across the Internet over UUCP whenever available, not only because it's usually faster, but because I *want* that end-to-end reliability provided by TCP. Assuming a fully connected Internet, I can feel pretty confident that if my mail disappears from the spool then it has safely reached its destination and isn't stuck in some unknown place halfway across the path. I think the distinction between message and packet switching will blur further as very high speed transmission facilities become available and RAMs get even cheaper. You can allow very large packets on a high speed fiber link without sacrificing "real time" performance. Chopping up a data stream into tiny packets will no longer be necessary or even desirable: the packet rate would get completely out of hand. For example, if each packet could hold an entire NTSC video frame, real time packet video would only be 30 packets per second, well within the capability of even a Z-80 as long as data paths are kept separate. An interesting project would be to see just how applications might make use of "megapackets". Interactive timesharing probably can't make use of much more than a few K (a screenful of text) but clearly file transfers could use much more. (Think of an entire magtape occupying a single packet. At gigabit rates it would still only take a second or so to transmit). Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987032919184200> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Sun 29 Mar 87 11:12:01-PST Received: from BARILVM.BITNET by wiscvm.wisc.edu on 03/29/87 at 13:10:30 CST Received: by BARILVM (Mailer X1.23b) id 1130; Sun, 29 Mar 87 16:22:53 O Date: Sun, 29 Mar 87 15:48:42 O From: Henry Nussbacher Subject: Tcp/Ip vs a store & forward network To: tcp-ip@sri-nic.ARPA All the calculations about the bandwidth of a station wagon got me thinking. Why was Tcp/Ip not designed as a store and forward network (in addition to the protocols it does support)? Let me explain why I am asking this. In Bitnet, you might have as many as 20 9.6Kb lines separating you from the place you wish to send a file to. The probably that all 20 lines are working and that all 20 intermediate machines are up (yup - no IMPs) simaltaneously becomes quite small. (Imagine if the probability of any machine being up and working is 98% and that the probablility that any leased phone line is working is 99.5% - after 10 machines - 77.7% successful connection). Well you can say alternate paths and better reliability make the connection rate closer to 95%. I would perhaps doubt that when the two nodes are separated by a number of physical links and that the data has to pass thru a couple of hardware boxes that will not work if there is a power outage in the building or other "things" that can cause a hardware box to not respond. So, a S&F network would alleviate much of the problem. Try to get the data as close to the destination node and then spool it. Instead SMTP makes a valiant attempt to emulate S&F by spooling the mail locally and occassionally trying to establish a connection to the destination. After 'n' of days SMTP gives up and sends mail to the sender. I think it would have been nicer that SMTP try to get it as close to the down node as possible and then let that node try polling the down node for 'n' number of days. But FTP is even worse. FTP is basically an interactive process. You want a file you gotta establish a connection and suck it off or slap it into place. Transferring files should really be a batch orientated feat - you say what file you want to store or retrieve and you type in all the necessary options and parameters and you don't hear about it until it completes (with appropriate return codes of course). Bitnet uses BSMTP (Batch SMTP). Is there such a thing as BFTP (Batch FTP)? Is there a very strong technical reason why S&F was not part of the design of Tcp/Ip?? I have a lot of questions but very few answers. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703301251.AA25896%40ucbvax.Berkeley.EDU] <1987033002322800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <8703301251.AA25896@ucbvax.Berkeley.EDU> Date: Mon, 30-Mar-87 07:32:28 EST Article-I.D.: ucbvax.8703301251.AA25896 Posted: Mon Mar 30 07:32:28 1987 Date-Received: Tue, 31-Mar-87 05:57:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Barry, Which brings me to something I would like to get created: FTP to spool so that no pswds need to make their way around the network. If Bitnet can transfer files to/from Unix, VMS, VM, MVS, CDC, etc machines - WITHOUT passwords then Tcp/Ip should be able to send files around to local spool systems so that the entire concept of FTP pswds can be eliminated. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703301321.AA26219%40ucbvax.Berkeley.EDU] <1987033003052700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TcpIp vs S&F Message-ID: <8703301321.AA26219@ucbvax.Berkeley.EDU> Date: Mon, 30-Mar-87 08:05:27 EST Article-I.D.: ucbvax.8703301321.AA26219 Posted: Mon Mar 30 08:05:27 1987 Date-Received: Tue, 31-Mar-87 06:11:21 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa I am more than well aware of all the drawbacks of S&F and what RSCS can't do (by the way - there is a PVM version that was developed at U of Maine that piggybacks on RSCS). It leaves a lot to be desired and that is why I want to see if Tcp/Ip can do the same type of functions that RSCS does (i.e. send a file to someone w/o transmitting a password). Thanks for all the replies. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703300928.aa22515%40SEM.BRL.ARPA] <1987033004280700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703300928.aa22515@SEM.BRL.ARPA> Date: Mon, 30-Mar-87 09:28:07 EST Article-I.D.: SEM.8703300928.aa22515 Posted: Mon Mar 30 09:28:07 1987 Date-Received: Tue, 31-Mar-87 05:48:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa A friend of mine who formerly worked at CCI implemented their network by running around the building with an armful of floppy disks...coined "Adidas Net" -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703301458.AA18974%40HECTOR.MIT.EDU] <1987033004580700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martillo@ATHENA.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Station wagon full of bits (Frame-Relay) Message-ID: <8703301458.AA18974@HECTOR.MIT.EDU> Date: Mon, 30-Mar-87 09:58:07 EST Article-I.D.: HECTOR.8703301458.AA18974 Posted: Mon Mar 30 09:58:07 1987 Date-Received: Tue, 31-Mar-87 05:48:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa I confess to not having thought about it too much, but my impression is frame relay simply permits the passage of level 2 packets on the basis of level 2 address through the switch to some place in the phone network where full level 2 processing can be handled. This means that the switch can basically concentrate on tdm switching problems while the level 2 termination point can concentrate statistical muxing switching problems. Such a division makes sense as a way to optimise CSC switch or packet switch performance. In the asynchronous world LAPD could per passed on a 64 KBPS unrestricted data circuit to a terminal concentrator and each LAPD virtual level 2 could correspond to an asynchronous terminal. While I consider asynchronous terminal concentrators a backward-looking technology, in the business world lots of firm want such devices. Obviously this is not an OSI application, but the separation of the problem into a physical channel, multiple virtual level 2s, and a flow control layer on top of this has clearly been influenced by concepts of layering, and LAPD terminal multiplexing seems more sensible than the PAD protocols. Yaqim Martillo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703301511.AA22345%40mitre.ARPA] <1987033005113100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <8703301511.AA22345@mitre.ARPA> Date: Mon, 30-Mar-87 10:11:31 EST Article-I.D.: mitre.8703301511.AA22345 Posted: Mon Mar 30 10:11:31 1987 Date-Received: Tue, 31-Mar-87 06:15:29 EST References: <8703300117.AA15165@gwen.cs.purdue.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 19 Approved: tcp-ip@sri-nic.arpa You were concerned about the reliability of S&F. There are a variety of tradeoffs to consider. The DoD has an ancient but vigorous system called AUTODIN. It has the following characteristics: - It is a message switching system; messages are limited to 40,000 characters; each message may have as many as 500 addresses. - The "switching" part of the system is fairly small; there are 8 AUTODIN Switching Centers in the US, and a few more in Europe and the Far East. - AUTODIN is EXTREMELY reliable; however, duplicate messages may occur during recovery from a failure. The AUTODIN design philosophy is that it is better to send several messages twice than to drop any message once. - Also, during failure recovery, delivery transposition may occur; i.e., an older message will be delivered before a newer message. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703301648.AA24168%40mitre.ARPA] <1987033006482600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <8703301648.AA24168@mitre.ARPA> Date: Mon, 30-Mar-87 11:48:26 EST Article-I.D.: mitre.8703301648.AA24168 Posted: Mon Mar 30 11:48:26 1987 Date-Received: Tue, 31-Mar-87 06:23:17 EST References: <8703260316.AA23501@flash.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 14 Approved: tcp-ip@sri-nic.arpa Phil asked, "What is the bandwidth of a 747 ..." I talked to the Boeing folks here in DC. A B747-200F (cargo config.) has: gross take-off wt. 416 tons operating wt. 171 the difference being fuel and cargo wt. 245 Allowing 45 tons of fuel for 6 hours enroute plus reserve leaves 200 tons of compact disks. According to Cerf, 100 disks equals 50 pounds equals 7.8*10**12 bits; therefore, multiplying by 8,000, 800,000 disks - 200 tons - 6.2*10**16 bits dividing by (6*3600) 21,600 seconds equals 2.9*10**12 bps. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703301826.AA00363%40ucbvax.Berkeley.EDU] <1987033008030000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NS-DDN@DDN3.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <8703301826.AA00363@ucbvax.Berkeley.EDU> Date: Mon, 30-Mar-87 13:03:00 EST Article-I.D.: ucbvax.8703301826.AA00363 Posted: Mon Mar 30 13:03:00 1987 Date-Received: Tue, 31-Mar-87 07:33:38 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa But, Hank, that is already provided for in the FTP specs. The PASS command is not a required command (for that matter, neither is USER). The possibilities are: USER, Reply 2xx USER, Reply 331, PASS, Reply 2xx USER, Reply 332, ACNT, Reply 2xx USER, Reply 331, PASS, Reply 332, ACNT, Reply 2xx If you want to use SPOOL for a USER name which requires no password, but does need a user id via the ACNT command, then that "user" (service, really) can simply DISK DUMP the resultant file into the target virtual machine's reader queue. If a USER name convention is used throughout the net, it will greatly simplify the "interactive" script to permit brainless automatons to manage the process. Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033008030001> Received: from ddn3 by SRI-NIC.ARPA with TCP; Mon 30 Mar 87 10:20:34-PST Date: 30 Mar 87 13:03 EST From: NS-DDN @ DDN3.arpa Subject: Subject: Re: Tcp/Ip vs a store & forward network To: To: HANK%BARILVM.BITNET @ WISCVM.WISC.EDU, tcp-ip @ SRI-NIC.ARPA CC: But, Hank, that is already provided for in the FTP specs. The PASS command is not a required command (for that matter, neither is USER). The possibilities are: USER, Reply 2xx USER, Reply 331, PASS, Reply 2xx USER, Reply 332, ACNT, Reply 2xx USER, Reply 331, PASS, Reply 332, ACNT, Reply 2xx If you want to use SPOOL for a USER name which requires no password, but does need a user id via the ACNT command, then that "user" (service, really) can simply DISK DUMP the resultant file into the target virtual machine's reader queue. If a USER name convention is used throughout the net, it will greatly simplify the "interactive" script to permit brainless automatons to manage the process. Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703301826.AA14541%40bu-cs.bu.edu] <1987033008261100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Tcp/Ip vs a store & forward network Message-ID: <8703301826.AA14541@bu-cs.bu.edu> Date: Mon, 30-Mar-87 13:26:11 EST Article-I.D.: bu-cs.8703301826.AA14541 Posted: Mon Mar 30 13:26:11 1987 Date-Received: Wed, 1-Apr-87 00:56:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 46 Approved: tcp-ip@sri-nic.arpa >Barry, > >Which brings me to something I would like to get created: FTP to spool so that >no pswds need to make their way around the network. If Bitnet can transfer >files to/from Unix, VMS, VM, MVS, CDC, etc machines - WITHOUT passwords >then Tcp/Ip should be able to send files around to local spool systems so >that the entire concept of FTP pswds can be eliminated. >Hank I'm not sure there's much difference between bitnet's SENDFILE and just sending a file via mail. Most of the differences between SENDFILE and Bitnet/Mail (and, actually, SMTP) are simply to accommodate spool record length restrictions within IBM's filing system. This is not particularly a problem when an heterogeneous environment is accounted for and files have to be in some "reasonable" ASCII text format anyhow. Even record length restrictions and binary images can be transferred in more generic ways (eg. UUENCODE/UUDECODE which I've ported to my 3090) than DISKDUMP formats which appear to be limited in function and very much designed with IBM's filing system in mind. I suppose VMS's jnet (bitnet) product accommodates this, but I assume only by being subservient to IBM file formats (and a very, very limited subset at that, as far as I know there is still no way to send, eg, a PDS between even two IBM systems via Bitnet without some user hackery.) The other half of the difference would be accomplished by adopting some convention that files are sent to, say, user-fxfr@host so it appears in a different spool or just marking the header so mail user agents could pluck out "file transfers" from the mail when they start up. I think this is a minor need, the Subject: line can get you 98% of the way there without changing anything. The "entire concept" of FTP passwords is useful in that it allows a user to get at files either destructively (in a positive sense) or past normal security (that is, files not publicly readable.) I don't think getting rid of this feature is a step forward. There are already passwordless protocols in use (eg. TFTP in the internet world and transferring via uucppublic in the UUCP world.) For obvious reasons they seem to have limited acceptance when FTP is available. They're mostly a security botch, especially when fetching of files is needed. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703301829.AA06404%40hplnmk] <1987033008291300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kincl%hplnmk@HPLABS.HP.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Response to anti-bridge comments Message-ID: <8703301829.AA06404@hplnmk> Date: Mon, 30-Mar-87 13:29:13 EST Article-I.D.: hplnmk.8703301829.AA06404 Posted: Mon Mar 30 13:29:13 1987 Date-Received: Wed, 1-Apr-87 01:16:40 EST References: <8703262020.AA27749@flash.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 45 Approved: tcp-ip@sri-nic.arpa At the moment, 256 kbps of this capacity connects a set of five Vitalink Translan IIIs as a star with the hub at Piscataway. Each of these boxes also connects to the building-wide backbone Ethernet at its location, thus bridging the locations together at the link level. Within each location almost all of our Ethernets are bridged with DEC LanBridge 100s, with the fiber version interconnecting multiple buildings at a location. At last count, the routing tables on the Translans showed something like 600 active hosts. Question: How well would all this work if you decided that you need redundant routes or if you decided that you do not want a start topology but have an arbitrary topology? Can you have a configuration like the following: ---------------Ethernet----------------- | | | | Bridge Bridge | | | | ---------------Ethernet----------------- | | | | Bridge Bridge | | | | ---------------Ethernet----------------- We currently have about 40-50 Ethernets connected with about 20 IP gateway boxes. The gateways are connected via Ethernet, Broadband, 56Kb land lines, 9.6Kb land lines, and soon T1 and 64Kb satelite links. The gateways we use (cisco Systems) are both fast (we have measured them at 1000 large packets per second between Ethernets) as well as have reasonable routing algorithms (though they will speak RIP they talk amongst themselves with IGRP). We have not seen any problems with the routing (or anything else related to the gateways). You are right---it is unfair to compare standalone level 2 bridges with general purpose systems (especially when they are runing RIP). -Norm Kincl HP Labs ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033008292400> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Tue 31 Mar 87 07:31:18-PST Received: from relay2.cs.net by RELAY.CS.NET id aa08436; 31 Mar 87 10:27 EST Received: from ub.com by RELAY.CS.NET id af03522; 31 Mar 87 10:19 EST Date: Mon, 30 Mar 87 16:29:24 PST From: Dave Crocker To: tcp-ip@SRI-NIC.ARPA Subject: NetBios over TCP Organization: Ungermann-Bass, Inc., Santa Clara, CA In article <8703232326.AA18131@seismo.CSS.GOV> michael@labtam.OZ.AU (Michael Podhorodecki) writes: > > Could someone let be know the status of the NETBIOS over TCP/IP... I am slowly working my way through some backlog messages and others may already have responded. But your query seemed important enough to be worth a redundant response... The NetBios/TCP effort has produced an initial specification which is documented as two Arpa Internet RFC (Requests for Comments): Protocol Standard for a NetBios Service on a TCP/UDP Transport: Concepts and Methods; RFC #1001 Protocol Standard for a NetBios Service on a TCP/UDP Transport: Detailed Specifications; RFC #1002 They are available for distribution from the Network Information Center, at SRI International. You may order them by calling 800-235-3155. The text is about 150 pages, combined, so you can have many hours of fun reading, understanding, commenting upon it. The spec cites online and postal address to which you may send comments. You might also consider sending online comments to netbios@mitre-bedford.arpa Good luck. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703301830.AA00030%40apolling.imagen.uucp] <1987033008303800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@imagen.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: Tcp/Ip vs a store & forward network Message-ID: <8703301830.AA00030@apolling.imagen.uucp> Date: Mon, 30-Mar-87 13:30:38 EST Article-I.D.: apolling.8703301830.AA00030 Posted: Mon Mar 30 13:30:38 1987 Date-Received: Wed, 1-Apr-87 01:28:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.DEC.COM Distribution: world Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa > Which brings me to something I would like to get created: FTP to spool so that > no pswds need to make their way around the network. [sorry for not answering directly, I don't have a reliable path from USENET to bitnet -- my packets always go into a black hole :-] I think that you are arguing for new conventions, not new protocols. Queuing of FTP requests is something you can program on your local machine. As pointed out, in the internet, a host has no concept of "closer", so it is impossible for a store and forward FTP to do anything other than what SMTP does now. Unless you do manual routing. Augh. Similarly, who says that Arpanet mail has end-to-end ACKs? It just depends on where you put the "end." I put it at the user, and I want to see explicit acks from users, too (well, I flame so much that it actually doesn't matter to me if some of my typed jewels drop on the floor -- but when I care, I ask for an explicit response). For example, I recently looked over the shoulder of another user, and discovered that he didn't realize that MM would only show him the messages as "NEW" once -- after that they were only marked UNSEEN. About three weeks before he had been cut off by a bad phone connection, and thus missed reading 2 important messages for three weeks - until I showed him that MM still had those messages marked UNSEEN (he didn't know what the U was for). So what good was Arpanet's ~100% reliable delivery there! On USENET it is normal to keep a copy of a sent message until you receive an ACK for it, manually sent by the recipient. It is reasonable etiquette to ACK a message when you receive it (unless you want to be able to claim that you didn't receive it :-)) with a small message that says "I got your message" or even just "ack". My opinion is that mail reading software should encourage this behavior by suggesting such a reply and having an automatic way of generating it. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703301843.AA24737%40flash.bellcore.com] <1987033008432200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Response to anti-bridge comments Message-ID: <8703301843.AA24737@flash.bellcore.com> Date: Mon, 30-Mar-87 13:43:22 EST Article-I.D.: flash.8703301843.AA24737 Posted: Mon Mar 30 13:43:22 1987 Date-Received: Wed, 1-Apr-87 01:17:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa DEC LanBridge 100's have a loop detection algorithm. When a bridge is turned on, it sends out test packets on each interface and checks if they come back in on the other side. If so, the bridge will remain offline and not forward traffic. An offline bridge will continue to test the path and will go online within a few seconds should the existing path fail. It is my understanding that while the Vitalink Translans have a similar loop detection algorithm, not every combination of DEC and Vitalink bridges will do what you want. If there are parallel paths via LanBridges and Translans, it's possible to have a LanBridge go offline in favor of a Translan, which is decidedly suboptimal. I understand Vitalink is working on a new software release that will "do the right things" in combination with LanBridge 100s. Fortunately the situation is rather rare (it doesn't occur in our network). For further info you should call Vitalink. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033009150300> Received: from po5.andrew.cmu.edu by SRI-NIC.ARPA with TCP; Mon 30 Mar 87 11:15:20-PST Received: by po5.andrew.cmu.edu (5.54/3.15) id for tcp-ip@sri-nic.arpa; Mon, 30 Mar 87 14:16:49 EST Received: via switchmail; Mon, 30 Mar 87 14:16:45 est Received: FROM liberty VIA queuemail ID ; Mon, 30 Mar 87 14:15:18 est Message-Id: Date: Mon, 30 Mar 87 14:15:03 est From: ms6b#@andrew.cmu.edu (Marvin Sirbu) To: karn@flash.bellcore.com (Phil R. Karn), Rudy.Nedved@h.cs.cmu.edu Subject: Re: network horror stories Cc: tcp-ip@sri-nic.arpa >most of the telephone companies have the prefix for remote areas stored locally to >reduce trunk line usage from wrong numbers...if you dial 412 333 XXXX in 201 >area then 201 area will not even try the connection, it will indicate that >number is incorrect and a telephone book should be consulted. Alas, >propagation of this information has the same problems as propagating routing >information....sigh. When CMU's exchange code was changed last year (to 268= CMU) that fact was not properly propogated to the CCSA switches used by the FTS network. As a consequence, for two days after the change, no one at NSF, DoD, etc. could call CMU over the FTS network! They were told 268 was not a working exchange. Marvin Sirbu CMU ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3476.544130860%40UK.AC.UCL.CS] <1987033009592200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Steve.Kille@CS.UCL.AC.UK.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <3476.544130860@UK.AC.UCL.CS> Date: Mon, 30-Mar-87 14:59:22 EST Article-I.D.: UK.3476.544130860 Posted: Mon Mar 30 14:59:22 1987 Date-Received: Wed, 1-Apr-87 01:27:12 EST References: <[A.ISI.EDU]15-Mar-87.01:04:54.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa >From: CERF@edu.isi.a >Subject: Re: GOSIP vs TCP/IP >Date: 15 Mar 1987 01:04-EST >Please ask Steve what he does about X.25 resets in the absence of >an end/end reliable protocol such as TCP or TP4? Well, I'm the wrong Steve, but will comment anyhow! The TCP Implementor's conference has made it very clear to me that the X.25 oriented solutions are very poorly understood in the TCP/IP community. There are two basic ways of handling resets. The first is at the application level, and will certainly be done by those applications which need to handle large quantities of data, and do not wish to incur the cost of retransmission. This can be done by use of CCR (Comit Concurrency + Recovery) for FTAM and JTM (Job Transfer and Manipulation). For X.400, the RTS (Reliable Transfer Service) resumption mechanisms can be used. In many cases, these will be sufficient, and so a very lightweight transport (viz TP0) is sensible to make best utilisation of the X.25. However, for some applications (e.g. Terminal Access) it would be very desirable to have resumption over the same transport connection. Therfore, TP1 (viz error recovery class) is a sensible choice. There is absolutely no need for the heavyweight overkill of TP4. X.25 will keep data in sequence, and prevent data corruption. Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1987.3.30.21.34.46.Rudy.Nedved%40h.cs.cmu.edu] <1987033011394900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Rudy.Nedved@H.CS.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: network horror stories Message-ID: <1987.3.30.21.34.46.Rudy.Nedved@h.cs.cmu.edu> Date: Mon, 30-Mar-87 16:39:49 EST Article-I.D.: h.1987.3.30.21.34.46.Rudy.Nedved Posted: Mon Mar 30 16:39:49 1987 Date-Received: Wed, 1-Apr-87 01:46:28 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa I am not aware of the details behind the transition from one exchange to another...maybe it could have been done over a longer time period with some type of exchange forwarding at the local TelCo... As far as I know, the major users were not affected only private and small telephone companies. This is a problem in the ARPA Internet and is an issue of managerial inertia not a technical problem. If you don't play the game correctly then what can you do. Anyhow, two days once every few years is not a major reason to not do what they do. -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703302132.AA15796%40spam.istc.sri.com] <1987033012150300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gds@SPAM.ISTC.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <8703302132.AA15796@spam.istc.sri.com> Date: Mon, 30-Mar-87 17:15:03 EST Article-I.D.: spam.8703302132.AA15796 Posted: Mon Mar 30 17:15:03 1987 Date-Received: Wed, 1-Apr-87 01:55:11 EST References: <8703301251.AA25896@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa Summary: no passwords? Which brings me to something I would like to get created: FTP to spool so that no pswds need to make their way around the network. If Bitnet can transfer files to/from Unix, VMS, VM, MVS, CDC, etc machines - WITHOUT passwords then Tcp/Ip should be able to send files around to local spool systems so that the entire concept of FTP pswds can be eliminated. Hank I would like to know what sorts of access controls are used in Bitnet to allow or deny a user access to * a remote file they own * a remote file they don't own, but is not protected * a remote file they don't own, but is protected and how such users are prevented from sabotaging remote disks ... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703311541.AA20353%40ucbvax.Berkeley.EDU] <1987033014292400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dcrocker@engr.ub.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: NetBios over TCP Message-ID: <8703311541.AA20353@ucbvax.Berkeley.EDU> Date: Mon, 30-Mar-87 19:29:24 EST Article-I.D.: ucbvax.8703311541.AA20353 Posted: Mon Mar 30 19:29:24 1987 Date-Received: Thu, 2-Apr-87 07:07:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: Ungermann-Bass, Inc., Santa Clara, CA Lines: 31 Approved: tcp-ip@sri-nic.arpa In article <8703232326.AA18131@seismo.CSS.GOV> michael@labtam.OZ.AU (Michael Podhorodecki) writes: > > Could someone let be know the status of the NETBIOS over TCP/IP... I am slowly working my way through some backlog messages and others may already have responded. But your query seemed important enough to be worth a redundant response... The NetBios/TCP effort has produced an initial specification which is documented as two Arpa Internet RFC (Requests for Comments): Protocol Standard for a NetBios Service on a TCP/UDP Transport: Concepts and Methods; RFC #1001 Protocol Standard for a NetBios Service on a TCP/UDP Transport: Detailed Specifications; RFC #1002 They are available for distribution from the Network Information Center, at SRI International. You may order them by calling 800-235-3155. The text is about 150 pages, combined, so you can have many hours of fun reading, understanding, commenting upon it. The spec cites online and postal address to which you may send comments. You might also consider sending online comments to netbios@mitre-bedford.arpa Good luck. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3170%40burdvax.PRC.Unisys.COM] <1987033015181800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: starner@burdvax.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: FTP and 4.3BSD Message-ID: <3170@burdvax.PRC.Unisys.COM> Date: Mon, 30-Mar-87 20:18:18 EST Article-I.D.: burdvax.3170 Posted: Mon Mar 30 20:18:18 1987 Date-Received: Wed, 1-Apr-87 05:09:11 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: Unisys/Paoli Research Center, Paoli, PA Lines: 51 Keywords: parcvax, timeouts Approved: tcp-ip@sri-nic.arpa Since converting to 4.3BSD I have been having problems using ftp to parcvax.xerox.com (i have discovered this problem at no other sites, yet). I can connect to the site fine, login anonymous, ls works -- but "dir" and the "*get" functions hang, finally timeout with the message "connection reset by peer". This behaviour is exhibited on all hosts on our internal network also. Here is a sample: 101% ftp parcvax.xerox.com Connected to parcvax.xerox.com. 220 parcvax.xerox.com FTP server (Version 4.105 Mon Jun 2 17:55:28 PDT 1986) ready. Name (parcvax.xerox.com:starner): anonym,ous mous 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. ftp> ls 200 PORT command successful. 150 Opening data connection for /bin/ls (10.5.0.96,1133) (0 bytes). .cshrc .login .plan . . . xns 226 Transfer complete. 143 bytes received in 1.9 seconds (0.072 Kbytes/s) ftp> dir 200 PORT command successful. 150 Opening data connection for /bin/ls (10.5.0.96,1134) (0 bytes). netin: Connection reset by peer 226 Transfer complete. ftp> quit 221 Goodbye. 102% Does this problem seem familiar to anyone? I can ftp to other 4.3 sites, 4.2 sites, TENEX, etc.... with no problem. Also, I can get files using a Xerox 1109 using TCP/IP from parcvax. But not from any of my unix hosts on my network. Any hints anyone can give would be appreciated. -- Mark Starner starner@burdvax.prc.unisys.com Unisys Corporation/Paoli Research Center {seismo,sdcrdcf}!burdvax!starner Paoli, PA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033018022800> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 30 Mar 87 04:38:12-PST Received: from BARILVM.BITNET by wiscvm.wisc.edu on 03/30/87 at 06:36:38 CST Received: by BARILVM (Mailer X1.23b) id 1847; Mon, 30 Mar 87 14:35:51 O Date: Mon, 30 Mar 87 14:32:28 O From: Henry Nussbacher Subject: Re: Tcp/Ip vs a store & forward network To: Barry Shein cc: tcp-ip@sri-nic.ARPA In-Reply-To: Your message of Sun, 29 Mar 87 18:31:15 EST Barry, Which brings me to something I would like to get created: FTP to spool so that no pswds need to make their way around the network. If Bitnet can transfer files to/from Unix, VMS, VM, MVS, CDC, etc machines - WITHOUT passwords then Tcp/Ip should be able to send files around to local spool systems so that the entire concept of FTP pswds can be eliminated. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703310416.AA22724%40HECTOR.MIT.EDU] <1987033018160200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martillo@ATHENA.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Station wagon full of bits Message-ID: <8703310416.AA22724@HECTOR.MIT.EDU> Date: Mon, 30-Mar-87 23:16:02 EST Article-I.D.: HECTOR.8703310416.AA22724 Posted: Mon Mar 30 23:16:02 1987 Date-Received: Wed, 1-Apr-87 05:39:59 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Is frame-forwarding really more of a violation of the OSI model than an ethernet bridge. A frame-forwarding switch does not strike me as a great deal different in concept or functionality than an ethernet bridge. Yakim Martillo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033018352700> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 30 Mar 87 05:09:09-PST Received: from BARILVM.BITNET by wiscvm.wisc.edu on 03/30/87 at 07:07:41 CST Received: by BARILVM (Mailer X1.23b) id 1873; Mon, 30 Mar 87 15:09:38 O Date: Mon, 30 Mar 87 15:05:27 O From: Henry Nussbacher Subject: TcpIp vs S&F To: tcp-ip@sri-nic.ARPA I am more than well aware of all the drawbacks of S&F and what RSCS can't do (by the way - there is a PVM version that was developed at U of Maine that piggybacks on RSCS). It leaves a lot to be desired and that is why I want to see if Tcp/Ip can do the same type of functions that RSCS does (i.e. send a file to someone w/o transmitting a password). Thanks for all the replies. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [kUPpCLy00UoJgMY1GH%40andrew.cmu.edu] <1987033019264700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ddp#@ANDREW.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: danger of bridges Message-ID: Date: Tue, 31-Mar-87 00:26:47 EST Article-I.D.: andrew.kUPpCLy00UoJgMY1GH Posted: Tue Mar 31 00:26:47 1987 Date-Received: Wed, 1-Apr-87 06:08:36 EST References: <8703261354.AA01431@jupiter.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa >I should hope that the situation is not this bad, especially since x3s33 >ES-IS (host-gateway) routing protocol uses a similar HELLO scheme. Although >I am also not a DECNET expert (or even novice, for that matter), I'm would >be EXTREMELY suprized if the HELLO timer was not settable, meaning that >for crowded networks, it could and I assume normally would be set >to greater than 15 seconds. I've asked a local DECnet wizard who tells me that the timer is indeed settable (almost everything is in DECnet). Of course the problem is that it must be set on every host and we don't have direct control over them all... >Second, host HELLO's typically go to gateways, >not other hosts, so every host doesn't need to process every host >HELLO, just gateway HELLO's. There should be much fewer gateways than >hosts. In DECnet atleast, the HELLO is just a multicast and therefore goes to all hosts receiving on that multicast address. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4UPpoUy00UoJoMY1Sd%40andrew.cmu.edu] <1987033020072800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ddp#@ANDREW.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Response to anti-bridge comments Message-ID: <4UPpoUy00UoJoMY1Sd@andrew.cmu.edu> Date: Tue, 31-Mar-87 01:07:28 EST Article-I.D.: andrew.4UPpoUy00UoJoMY1Sd Posted: Tue Mar 31 01:07:28 1987 Date-Received: Wed, 1-Apr-87 06:09:37 EST References: <8703262020.AA27749@flash.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 56 Approved: tcp-ip@sri-nic.arpa >At last count, the routing tables on the Translans showed something like 600 active hosts. I'm not sure this is quite a large enough net for my statements to apply. It's probably the case that your's is a network where level 2 bridges are appropriate for your current needs. I wouldn't agree that they will be appropriate for future needs though. >We generally see 1-2 per second, which is expected and entirely acceptable. The arp rate a particular net sees is probably going to be quite dependent on the type of applications being used on it. Over 60% of the IP traffic on our network is from the Andrew distributed file system (something like NFS in functionality). Each workstation on the network regularly communicates with quite a few different servers and other hosts. I would suspect that the ARP rate from distributed applications like this is much higher from networks with your basic telnets, ftp's and smtps. >If you see 20 per second, then you've got something wrong somewhere. >I've found that bursts of ARP requests are usually caused by hosts who >respond inappropriately to UDP broadcasts to bogus IP addresses. Luckily I think we have the bad UDP broadcast problem under control. That definitely is not what causes the majority of our ARP's. There's nothing really wrong (that we've been able to find) besides the problems with 4.2 UNIX itself. Actually most of our arps seem to be from hosts that relentlessly try to open connections to machines which are down. It especially get's bad when an important server goes down. When 500 hosts are trying to talk to a file server that has been down for a while... Luckily the file system knows about exponential backoff. One of the problems we found a while ago is that the default size of an arp cache in 4.2 is not at all appropriate for a server machine which communicates with LOTS of machines. The default is for a cache of 5x19 entries, i.e. there are 19 possible hash values and only 5 hosts can hash to each one. In the worst case, if you are trying to communicate sequentially with 6 hosts which all hash to the same value, you can end up sending one ARP req packet per IP packet/transaction. For our file servers which regularly communicate with 300 hosts in a 10 minute period this is definitely not appropriate... I think we made the cache 10x99 instead. The crux of the problem though is that with level 2 biridges, your arp rate (or any kind of multicast/broadcast) rises LINEARLY with the number of hosts connected on ANY subnet of the network. However using level 3 routers, the rate only rises linearly with the number of hosts connected to your particular subnet. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033023143300> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Tue 31 Mar 87 07:31:37-PST Received: from relay2.cs.net by RELAY.CS.NET id ab08436; 31 Mar 87 10:27 EST Received: from ub.com by RELAY.CS.NET id ag03522; 31 Mar 87 10:19 EST Date: Tue, 31 Mar 87 7:14:33 PST From: Dave Crocker To: tcp-ip@SRI-NIC.ARPA Subject: Packet network reliability Organization: Ungermann-Bass, Inc., Santa Clara, CA In article <8703250201.AA06443@flash.bellcore.com> karn@FLASH.BELLCORE.COM (Phil R. Karn) writes: >... In "unlayered virtual circuit" networks, connection >state information is kept not only in the end-point switches, but also in >every intermediate switch along the path. >... Because of this, a node or link failure ANYWHERE along the >connection path causes an X.25 VC reset, not just failures at the end nodes. > >Only in "layered VC" networks such as the DDN (where datagrams are used >internally) can intermediate node and link failures occur without resetting >virtual circuits. ... Don't know how much this will contribute to the discussion, but you pushed one of my buttons: There are two issues often treated as one: Virtual Circuit vs. Datagram underlying architecture, and Robust vs. Fragile handling of major network anomolies. It is common for VC-oriented nets to be relatively more Fragile than the DG-oriented ones, but that definitely is not necessary. It has more to do with certain economies that are perceived by the implementors. X.25 vendors are excellent examples of the VC/Fragile orientation. By virtue of being very cost-conscious, they pay very close attention to such things as packet-handling "efficiencies" and buffer management. The handling efficiency question walks them down the path of internal VC orientation. (Common belief: The processing overhead to forward a packet in a VC-oriented system is lower than in a DG-oriented one.) The buffer management question makes them give up a buffer as soon as the "next" hop has acknowledged it. That is, the only copy of the data exists at the latest node to have accepted it. If that node goes down, the copy is lost. Your note used the term "end to end reliability". That is exactly the issue. The sending node must hold onto a copy of the data until the receiving node acknowledges deliverying it to the destination host. If it does this, than an internal X.25 Reset (for example) could be transparently recovered from, by re-routing the circuit automatically. A few years ago, I tried to get Databit (Siemens) to modify their X.25 packet switches to permit holding on to the packet at the sending node, until a final ack was received. They were not willing to consume buffers for that long. By the same token, BBN could modify their switches NOT to hold on to packets at the source PSN. At that point, a number of problems internal to the net would become highly visible to users. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703311211.AA18259%40ucbvax.Berkeley.EDU] <1987033100012200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jon@CS.UCL.AC.UK.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Response to anti-bridge comment Message-ID: <8703311211.AA18259@ucbvax.Berkeley.EDU> Date: Tue, 31-Mar-87 05:01:22 EST Article-I.D.: ucbvax.8703311211.AA18259 Posted: Tue Mar 31 05:01:22 1987 Date-Received: Thu, 2-Apr-87 01:06:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 85 Approved: tcp-ip@sri-nic.arpa /* Written 8:22 am Mar 31, 1987 by kincl%hplnmk@com.hp.hplabs in pyr1:tcp-ip */ /* ---------- "Re: Response to anti-bridge comment" ---------- */ Received: from ucl-cs-nss by pyr1.Cs.Ucl.AC.UK with SMTP id aa05565; 31 Mar 87 8:21 WET Received: from sri-nic.arpa by mv1.Cs.Ucl.AC.UK via Satnet with SMTP id aa05190; 31 Mar 87 8:20 WET Received: from hplabs.HP.COM by SRI-NIC.ARPA with TCP; Mon 30 Mar 87 10:27:05-PST Received: from hplms1 by hplabs.HP.COM with TCP ; Mon, 30 Mar 87 10:25:06 pst Received: from hplnmk (hplnmk) by hplms1; Mon, 30 Mar 87 10:24:38 pst Return-Path: Received: from hplnmk.hpl.hp.com by hplnmk ; Mon, 30 Mar 87 10:29:16 pst Message-Id: <8703301829.AA06404@hplnmk> To: "Phil R. Karn" Cc: tcp-ip@arpa.sri-nic Subject: Re: Response to anti-bridge comments In-Reply-To: Your message of Thu, 26 Mar 87 15:20:26 -0500. <8703262020.AA27749@flash.bellcore.com> Date: Mon, 30 Mar 87 10:29:13 PST Question: How well would all this work if you decided that you need redundant routes or if you decided that you do not want a start topology but have an arbitrary topology? Can you have a configuration like the following: ---------------Ethernet----------------- | | | | Bridge Bridge | | | | ---------------Ethernet----------------- | | | | Bridge Bridge | | | | ---------------Ethernet----------------- Yes, but. At UCL we run a mini internet with 5 sites interconnected by Megastream (thats 2.Mbps not T1) lines. We also run a lot of LAN technology, mostly ethernet. We reckon that it's swings and roundabouts whether we use MAC Bridges or Network Level relays (to use ISO jargon). TYhere is an emerging (ISO!) standard for MAC bridges, and the only thing it is waiting on is how to do loop resolution and access control (ie the things most people think are network level things, but ISO are beginning to concede are different in a LAN/MAN context). Anyway, its down to 1. performance 2. functionality a) traffic control b) Fault Isolation c) routing/loop resolution d) access control e) management of all this. There's absolutely no reason to get layerist about this. if the addressing and protocols can stand it, there's nothing to choose between MAC bridges and network lewvel relays if they happen to do the same job as well. broadcast/multicast limiting can be done if you use distributed nameservers (and arp klugery is not a hack, it can be managed properly as a ditributed multicast system in MAC bridges if you implement it). two asides: 1. MAC bridges also buy you more trustworthy access control, since it's harder to spoof physical address without being spotted than to spoof IP/network level address, specially if you dont buy the wrong LAN. 2. MAC bridges usually perform, better - eg NFS works through them - you have to kludge the silly numbers in the mount table to get it to go even through a cisco box - one of the better IP gateways around. We use network level relays (IP gateways) between sites over the megastream, and predominantly MAC bridges within sites. The choice seems to have made sense in terms of managing the system, but I suspect that we just got good hardware and software, and that's what counts in the end. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703311326.AA18899%40ucbvax.Berkeley.EDU] <1987033101052900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jon@CS.UCL.AC.UK.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Tcp/Ip vs a store & forward network Message-ID: <8703311326.AA18899@ucbvax.Berkeley.EDU> Date: Tue, 31-Mar-87 06:05:29 EST Article-I.D.: ucbvax.8703311326.AA18899 Posted: Tue Mar 31 06:05:29 1987 Date-Received: Thu, 2-Apr-87 03:11:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Actually, I thought the Internet WAS a store-and-forward network. Gateways store up packets as they are received and forward them after a queueing delay. I think you really meant "message switching" as opposed to "packet switching". Yep. In the UK we use a spooled FTP system called NIFTP (Network independant file transfer protocol). This works over anything and we have it on 11/44s on Cambridge rings, vaxen and pyramid, TCP/IP over ethernet. The spec says you can checkpoint files, so it will work over junk networks without having to break large files down yourself. It also does binary etc, and it does some sorts of run-length encoding, for people with 30bps packet radio nets! It also has sensible authentication, unlike ftp which seems happy to send LOGIN passwords around on networks without encryption (try and sell that to a commercial company with ethernet). The spec may be got from the Joint Network Team in the UK. Implementations for ?NIXs exist. Why reinvent the wheel, when you can get a halftrack for free - or you could wait for FTAM. jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703311356.AA19171%40ucbvax.Berkeley.EDU] <1987033102150000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: computer manuals vs books Message-ID: <8703311356.AA19171@ucbvax.Berkeley.EDU> Date: Tue, 31-Mar-87 07:15:00 EST Article-I.D.: ucbvax.8703311356.AA19171 Posted: Tue Mar 31 07:15:00 1987 Date-Received: Thu, 2-Apr-87 03:16:15 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 46 Approved: tcp-ip@sri-nic.arpa I recently had occasion to order from DEC the data link layer and physical layer specs for the ethernet. What I received was your basic standard computer company type manual. Last year I ordered some documents from the NTIS* on computer security. Some of what I received from them was similar to the above but the rest looks very much like 3 rd generation copier material. For the price I paid for the NTIS documents I would have expected better. I recently ordered, from the IEEE, the 802.2 and 802.3 standards. What I paid was in line with the rest of the manuals I am talking about here or maybe just a bit higher but not much. What I received floored me completely. The IEEE sent me BOOKS. They sent me REAL BOOKS. These aren't computer manuals and they certainly are NOT 3 rd generation copies. These are hard cover, very solid BOOKS. Worth every penny just to see a real book again, never mind the content. They were done with proper type-setting, an eye catching use of bold type, and clean diagrams in general. I wasn't at all ready for this. The IEEE got Wiley & Sons to do the publishing. I guess that helped. If I were king, I think I would tell the computer companies AND the NTIS to either cut there prices or start printing better material. If the IEEE can do it then so can they. (Yes I understand about replacement pages, the time value of information, and other things like that. Many documents can be well published however.) HOORAY for the IEEE! Just thought you might like to know that somebody seems to do something right. NTIS: National Technical Information Service. USnail: Chris Johnson Academic Computer Services Northeastern University 39RI 360 Huntington Ave. Boston, MA. U.S.A. 02115 AT&T: (617) 437-2335 CSNET: johnson@nuhub.acs.northeastern.edu ARPANET: johnson%nuhub.acs.northeastern.edu@relay.cs.net BITNET: johnson%nuhub.acs.northeastern.edu@csnet-relay ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033102150001> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Tue 31 Mar 87 05:41:19-PST Received: from relay2.cs.net by RELAY.CS.NET id aa03861; 31 Mar 87 8:37 EST Received: from northeastern.edu by RELAY.CS.NET id aa02834; 31 Mar 87 8:29 EST Date: Tue, 31 Mar 87 07:15 EST From: "I am only an egg." To: tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA Subject: computer manuals vs books X-VMS-To: TCP-IP,INFO-VAX I recently had occasion to order from DEC the data link layer and physical layer specs for the ethernet. What I received was your basic standard computer company type manual. Last year I ordered some documents from the NTIS* on computer security. Some of what I received from them was similar to the above but the rest looks very much like 3 rd generation copier material. For the price I paid for the NTIS documents I would have expected better. I recently ordered, from the IEEE, the 802.2 and 802.3 standards. What I paid was in line with the rest of the manuals I am talking about here or maybe just a bit higher but not much. What I received floored me completely. The IEEE sent me BOOKS. They sent me REAL BOOKS. These aren't computer manuals and they certainly are NOT 3 rd generation copies. These are hard cover, very solid BOOKS. Worth every penny just to see a real book again, never mind the content. They were done with proper type-setting, an eye catching use of bold type, and clean diagrams in general. I wasn't at all ready for this. The IEEE got Wiley & Sons to do the publishing. I guess that helped. If I were king, I think I would tell the computer companies AND the NTIS to either cut there prices or start printing better material. If the IEEE can do it then so can they. (Yes I understand about replacement pages, the time value of information, and other things like that. Many documents can be well published however.) HOORAY for the IEEE! Just thought you might like to know that somebody seems to do something right. NTIS: National Technical Information Service. USnail: Chris Johnson Academic Computer Services Northeastern University 39RI 360 Huntington Ave. Boston, MA. U.S.A. 02115 AT&T: (617) 437-2335 CSNET: johnson@nuhub.acs.northeastern.edu ARPANET: johnson%nuhub.acs.northeastern.edu@relay.cs.net BITNET: johnson%nuhub.acs.northeastern.edu@csnet-relay ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703311435.AA11791%40gwen.cs.purdue.edu] <1987033104351600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: narten@PURDUE.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <8703311435.AA11791@gwen.cs.purdue.edu> Date: Tue, 31-Mar-87 09:35:16 EST Article-I.D.: gwen.8703311435.AA11791 Posted: Tue Mar 31 09:35:16 1987 Date-Received: Thu, 2-Apr-87 06:56:17 EST References: <8703301830.AA00030@apolling.imagen.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 40 Approved: tcp-ip@sri-nic.arpa Geof, >Similarly, who says that Arpanet mail has end-to-end ACKs? It just depends >on where you put the "end." I put it at the user, and I want to see explicit >acks from users, too True, there will never be real end-to-end ACKs if you take things far enough. An ack for a mail message to some would mean "mail has been received and READ (and understood :-))". A reasonable compromise would be a confirmation that the message has been placed in the recipients mailbox. Presumably, as domain names get extended, we will be able to do that. Any mail you send to a user can go directly to the machine where the his/her mailbox resides. No forwarding at the site would be needed. >On USENET it is normal to keep a copy of a sent message until you receive >an ACK for it, manually sent by the recipient. It is reasonable etiquette >to ACK a message when you receive it I don't find that acceptable as a *general* way of doing business. This puts the burden on reliable delivery on the sender and the recipient. That works for some cases, but requires voluntary compliance of all users (some who know nothing about mail and networks). Each user has to think about things such as "Is it time to send the mail again? I don't have an ACK yet." It is unworkable when mailing to lists (for which mail needs to be just as reliable), when the receiver is out of town, etc. etc. It is especially a burden for those that send and receive large quantities of mail. >My opinion is that mail reading software should encourage this >behavior by suggesting such a reply and having an automatic way of >generating it. This just confirms that most people want reliable mail delivery. Hence, the burden should be shifted from the user to the software used for the delivery of mail. It is much easier to do this with a transport level protocol that connects directly with the destination machine than over an S&F message switching system. Thomas ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703311555.AA20531%40ucbvax.Berkeley.EDU] <1987033105143300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dcrocker@engr.ub.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Packet network reliability Message-ID: <8703311555.AA20531@ucbvax.Berkeley.EDU> Date: Tue, 31-Mar-87 10:14:33 EST Article-I.D.: ucbvax.8703311555.AA20531 Posted: Tue Mar 31 10:14:33 1987 Date-Received: Thu, 2-Apr-87 05:00:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: Ungermann-Bass, Inc., Santa Clara, CA Lines: 52 Approved: tcp-ip@sri-nic.arpa In article <8703250201.AA06443@flash.bellcore.com> karn@FLASH.BELLCORE.COM (Phil R. Karn) writes: >... In "unlayered virtual circuit" networks, connection >state information is kept not only in the end-point switches, but also in >every intermediate switch along the path. >... Because of this, a node or link failure ANYWHERE along the >connection path causes an X.25 VC reset, not just failures at the end nodes. > >Only in "layered VC" networks such as the DDN (where datagrams are used >internally) can intermediate node and link failures occur without resetting >virtual circuits. ... Don't know how much this will contribute to the discussion, but you pushed one of my buttons: There are two issues often treated as one: Virtual Circuit vs. Datagram underlying architecture, and Robust vs. Fragile handling of major network anomolies. It is common for VC-oriented nets to be relatively more Fragile than the DG-oriented ones, but that definitely is not necessary. It has more to do with certain economies that are perceived by the implementors. X.25 vendors are excellent examples of the VC/Fragile orientation. By virtue of being very cost-conscious, they pay very close attention to such things as packet-handling "efficiencies" and buffer management. The handling efficiency question walks them down the path of internal VC orientation. (Common belief: The processing overhead to forward a packet in a VC-oriented system is lower than in a DG-oriented one.) The buffer management question makes them give up a buffer as soon as the "next" hop has acknowledged it. That is, the only copy of the data exists at the latest node to have accepted it. If that node goes down, the copy is lost. Your note used the term "end to end reliability". That is exactly the issue. The sending node must hold onto a copy of the data until the receiving node acknowledges deliverying it to the destination host. If it does this, than an internal X.25 Reset (for example) could be transparently recovered from, by re-routing the circuit automatically. A few years ago, I tried to get Databit (Siemens) to modify their X.25 packet switches to permit holding on to the packet at the sending node, until a final ack was received. They were not willing to consume buffers for that long. By the same token, BBN could modify their switches NOT to hold on to packets at the source PSN. At that point, a number of problems internal to the net would become highly visible to users. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D31-Mar-87.11:00:17.GBELING] <1987033106000000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GBELING@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: tp4 on sun Message-ID: <[A.ISI.EDU]31-Mar-87.11:00:17.GBELING> Date: Tue, 31-Mar-87 11:00:00 EST Article-I.D.: <[A.ISI.EDU]31-Mar-87.11:00:17.GBELING> Posted: Tue Mar 31 11:00:00 1987 Date-Received: Fri, 3-Apr-87 04:05:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa hello, maybe someone can help us* we are implementing an OSI-transport protocol tp4 under unix systems. so far it worked well on a vax 750 under 4.2 bsd. now we try to do the same on a sun 2/50 under os 3.2 (there equivalent of 4.2 bsd). we encountered problems when trying to access the IP raw socket on this sun, especially using the system calls: SENDTO and RECEIVEFROM which seem not to work. has anyone ever tried to use the raw IP socket and encountered a similar problem ?????? thanks gerd beling FGAN west-germany ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033106000001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 31 Mar 87 08:01:38-PST Date: 31 Mar 1987 11:00-EST Sender: GBELING@A.ISI.EDU Subject: tp4 on sun From: GBELING@A.ISI.EDU To: paal@NTA-VAX.ARPA, tcp-ip@SRI-NIC.ARPA Cc: GBELING@A.ISI.EDU Message-ID: <[A.ISI.EDU]31-Mar-87 11:00:17.GBELING> hello, maybe someone can help us* we are implementing an OSI-transport protocol tp4 under unix systems. so far it worked well on a vax 750 under 4.2 bsd. now we try to do the same on a sun 2/50 under os 3.2 (there equivalent of 4.2 bsd). we encountered problems when trying to access the IP raw socket on this sun, especially using the system calls: SENDTO and RECEIVEFROM which seem not to work. has anyone ever tried to use the raw IP socket and encountered a similar problem ?????? thanks gerd beling FGAN west-germany ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033106194600> Received: from Sierra.Stanford.EDU by SRI-NIC.ARPA with TCP; Tue 31 Mar 87 14:30:08-PST Date: Tue 31 Mar 87 14:19:46-PST From: Stu Grossman Subject: Re: danger of bridges To: tsuchiya@GATEWAY.MITRE.ORG cc: ddp#@[128.2.11.131], tcp-ip@SRI-NIC.ARPA, x3s33-interest@GATEWAY.MITRE.ORG In-Reply-To: Message of Sun 29 Mar 87 20:46:36-PST Message-ID: <12290865337.25.GROSSMAN@Sierra.Stanford.EDU> Regarding DECnet HELLOs: 1) You are correct regarding the settability of the DECnet hello timers. These (by default) are 15 seconds, but can be set to any value, as timer value is sent out over the network for each host. 2) The hellos are sent to a multicast address that is only enabled by DECnet 'routers'. Non-routers (known as 'endnodes') do not receive these messages. Yes, these messages do eat up some Ethernet bandwidth, but intelligent controllers pitch them if the host isn't interested. I think the real issue here is really "how often do I have to wait to acquire the Ethernet?" DEC controllers keep track of this information in a counter known as "Deferred transmits". My experience with a cable segment with over 400 DECnet nodes, a bunch of LAT boxes and some TCP/IP traffic is that this counter was quite low (well under 1% of all the transmits from the node in question**). It would be really interesting to find out the values of things like deferred transmits, single collision transmits, and multi-collision transmits vs. total transmits for various host and gateway interfaces. Stu Grossman ** Actual mileage may vary. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033108010200> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Tue 31 Mar 87 12:00:34-PST Date: 31 Mar 1987 14:01:02 CST Subject: Re: Packet network reliability From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To: Dave Crocker , tcp-ip@SRI-NIC.ARPA In-Reply-To: (Message from "Dave Crocker " of Tue, 31 Mar 87 7:14:33 PST) I'm in the same boat with Dave; VC versus datagram is one of my buttons. I'm much more familiar with the BBN way of doing things than with PDNs. I can see where PDNs would want to have very tight control over everything going on in the network. Tightly binding resources in a single virtual path through the network does let you know what resources are going where and for how long. I think it also tends to stabilize network delays around some median which might be nice. You can also establish stable (fixed) routing. Some nets I believe have a single route source that has global knowledge of the network and returns routes to the net nodes for every connection request. The disadvantage I see is that every VC will use up a given amount of net resources whether data is actually being transmitted across the VC or not. In the cases where static routing is downloaded from a central site, the survivability of the network as a whole is only as good as that of the central site. BBN gets around these two disadvantages at a cost. The Milnet for instance is gettingvery large, very fast. I don't know the formula for computing the amount of bandwidth required for the internal routing updates, but I would suspect it would go up exponentially with the number of nodes(and connectivity of them). If anybody knows the numbers I'd like to have them. The current limit of 256 nodes on one network has already been reached for Milnet. They nodes aren't installed and operational yet, but the addresses have been allocated to future nodes. And even with the size of the backbone, there are nodes with 12-18 hosts connected or slated for connection. Maybe we need "butter" switches? Darrel B. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703312012.AA25019%40ucbvax.Berkeley.EDU] <1987033110010200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Packet network reliability Message-ID: <8703312012.AA25019@ucbvax.Berkeley.EDU> Date: Tue, 31-Mar-87 15:01:02 EST Article-I.D.: ucbvax.8703312012.AA25019 Posted: Tue Mar 31 15:01:02 1987 Date-Received: Thu, 2-Apr-87 06:11:56 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa I'm in the same boat with Dave; VC versus datagram is one of my buttons. I'm much more familiar with the BBN way of doing things than with PDNs. I can see where PDNs would want to have very tight control over everything going on in the network. Tightly binding resources in a single virtual path through the network does let you know what resources are going where and for how long. I think it also tends to stabilize network delays around some median which might be nice. You can also establish stable (fixed) routing. Some nets I believe have a single route source that has global knowledge of the network and returns routes to the net nodes for every connection request. The disadvantage I see is that every VC will use up a given amount of net resources whether data is actually being transmitted across the VC or not. In the cases where static routing is downloaded from a central site, the survivability of the network as a whole is only as good as that of the central site. BBN gets around these two disadvantages at a cost. The Milnet for instance is gettingvery large, very fast. I don't know the formula for computing the amount of bandwidth required for the internal routing updates, but I would suspect it would go up exponentially with the number of nodes(and connectivity of them). If anybody knows the numbers I'd like to have them. The current limit of 256 nodes on one network has already been reached for Milnet. They nodes aren't installed and operational yet, but the addresses have been allocated to future nodes. And even with the size of the backbone, there are nodes with 12-18 hosts connected or slated for connection. Maybe we need "butter" switches? Darrel B. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703312033.AA26906%40monk.proteon.com] <1987033110332900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Response to anti-bridge comments Message-ID: <8703312033.AA26906@monk.proteon.com> Date: Tue, 31-Mar-87 15:33:29 EST Article-I.D.: monk.8703312033.AA26906 Posted: Tue Mar 31 15:33:29 1987 Date-Received: Thu, 2-Apr-87 01:45:24 EST References: <8703301843.AA24737@flash.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Phil, your message does not exactly answer Norman's question. Most (not all) bridge vendors have loop detection algorithms that allow you to have hot-standby bridges. However, they are only hot-standby bridges. The very nature of bridges prevents you from doing load sharing (unless you manually program the filtering/forwarding databases, giving up the advantages of adaptive bridges). Gateways with multipath internal routing algorithms can do load sharing, look at BBN's PSN software using SPF on the ARPANET and MILNET. Sooner or later, a network gets big enough and complicated enough that one migrates from bridges to routers. What the advocates are arguing about is where the line between bridges and routers is. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033112012200> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Tue 31 Mar 87 04:04:22-PST Received: from ucl-cs-pyr1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa00868; 31 Mar 87 11:56 WET Date: Tue, 31 Mar 87 12:01:22 WET From: jon@Cs.Ucl.AC.UK Subject: Re: Response to anti-bridge comment To: tcp-ip@sri-nic.arpa /* Written 8:22 am Mar 31, 1987 by kincl%hplnmk@com.hp.hplabs in pyr1:tcp-ip */ /* ---------- "Re: Response to anti-bridge comment" ---------- */ Received: from ucl-cs-nss by pyr1.Cs.Ucl.AC.UK with SMTP id aa05565; 31 Mar 87 8:21 WET Received: from sri-nic.arpa by mv1.Cs.Ucl.AC.UK via Satnet with SMTP id aa05190; 31 Mar 87 8:20 WET Received: from hplabs.HP.COM by SRI-NIC.ARPA with TCP; Mon 30 Mar 87 10:27:05-PST Received: from hplms1 by hplabs.HP.COM with TCP ; Mon, 30 Mar 87 10:25:06 pst Received: from hplnmk (hplnmk) by hplms1; Mon, 30 Mar 87 10:24:38 pst Return-Path: Received: from hplnmk.hpl.hp.com by hplnmk ; Mon, 30 Mar 87 10:29:16 pst Message-Id: <8703301829.AA06404@hplnmk> To: "Phil R. Karn" Cc: tcp-ip@arpa.sri-nic Subject: Re: Response to anti-bridge comments In-Reply-To: Your message of Thu, 26 Mar 87 15:20:26 -0500. <8703262020.AA27749@flash.bellcore.com> Date: Mon, 30 Mar 87 10:29:13 PST Question: How well would all this work if you decided that you need redundant routes or if you decided that you do not want a start topology but have an arbitrary topology? Can you have a configuration like the following: ---------------Ethernet----------------- | | | | Bridge Bridge | | | | ---------------Ethernet----------------- | | | | Bridge Bridge | | | | ---------------Ethernet----------------- Yes, but. At UCL we run a mini internet with 5 sites interconnected by Megastream (thats 2.Mbps not T1) lines. We also run a lot of LAN technology, mostly ethernet. We reckon that it's swings and roundabouts whether we use MAC Bridges or Network Level relays (to use ISO jargon). TYhere is an emerging (ISO!) standard for MAC bridges, and the only thing it is waiting on is how to do loop resolution and access control (ie the things most people think are network level things, but ISO are beginning to concede are different in a LAN/MAN context). Anyway, its down to 1. performance 2. functionality a) traffic control b) Fault Isolation c) routing/loop resolution d) access control e) management of all this. There's absolutely no reason to get layerist about this. if the addressing and protocols can stand it, there's nothing to choose between MAC bridges and network lewvel relays if they happen to do the same job as well. broadcast/multicast limiting can be done if you use distributed nameservers (and arp klugery is not a hack, it can be managed properly as a ditributed multicast system in MAC bridges if you implement it). two asides: 1. MAC bridges also buy you more trustworthy access control, since it's harder to spoof physical address without being spotted than to spoof IP/network level address, specially if you dont buy the wrong LAN. 2. MAC bridges usually perform, better - eg NFS works through them - you have to kludge the silly numbers in the mount table to get it to go even through a cisco box - one of the better IP gateways around. We use network level relays (IP gateways) between sites over the megastream, and predominantly MAC bridges within sites. The choice seems to have made sense in terms of managing the system, but I suspect that we just got good hardware and software, and that's what counts in the end. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033112040000> Received: from citi.umich.edu by SRI-NIC.ARPA with TCP; Tue 31 Mar 87 14:13:16-PST From: anon@citi.umich.edu To: tcp-ip@sri-nic.arpa Date: Tue 31 Mar EST 1987 17:04 Subject: overloaded station wagon Forgive my inexperience at these things. I was just under the impression that such conversations are usually carried on elsewhere. I am being forced to filter my mail, to distill other more useful information on TCP/IP. This reminds me of my real mailbox, often stuffed with 5-cent ground beef coupons. Again, forgive my ignorance. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12290865264.25.GROSSMAN%40Sierra.Stanford.EDU] <1987033112192200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GROSSMAN@SIERRA.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: danger of bridges Message-ID: <12290865264.25.GROSSMAN@Sierra.Stanford.EDU> Date: Tue, 31-Mar-87 17:19:22 EST Article-I.D.: Sierra.12290865264.25.GROSSMAN Posted: Tue Mar 31 17:19:22 1987 Date-Received: Thu, 2-Apr-87 02:16:50 EST References: <8703261354.AA01431@jupiter.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Regarding DECnet HELLOs: 1) You are correct regarding the settability of the DECnet hello timers. These (by default) are 15 seconds, but can be set to any value, as timer value is sent out over the network for each host. 2) The hellos are sent to a multicast address that is only enabled by DECnet 'routers'. Non-routers (known as 'endnodes') do not receive these messages. Yes, these messages do eat up some Ethernet bandwidth, but intelligent controllers pitch them if the host isn't interested. I think the real issue here is really "how often do I have to wait to acquire the Ethernet?" DEC controllers keep track of this information in a counter known as "Deferred transmits". My experience with a cable segment with over 400 DECnet nodes, a bunch of LAT boxes and some TCP/IP traffic is that this counter was quite low (well under 1% of all the transmits from the node in question**). It would be really interesting to find out the values of things like deferred transmits, single collision transmits, and multi-collision transmits vs. total transmits for various host and gateway interfaces. Stu Grossman ** Actual mileage may vary. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703312227.AA27273%40ucbvax.Berkeley.EDU] <1987033112291400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: anon@CITI.UMICH.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: overloaded station wagon Message-ID: <8703312227.AA27273@ucbvax.Berkeley.EDU> Date: Tue, 31-Mar-87 17:29:14 EST Article-I.D.: ucbvax.8703312227.AA27273 Posted: Tue Mar 31 17:29:14 1987 Date-Received: Thu, 2-Apr-87 02:10:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Forgive my inexperience at these things. I was just under the impression that such conversations are usually carried on elsewhere. I am being forced to filter my mail, to distill other more useful information on TCP/IP. This reminds me of my real mailbox, often stuffed with 5-cent ground beef coupons. Again, forgive my ignorance. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704010011.AA29397%40ucbvax.Berkeley.EDU] <1987033112440000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: honey@CITI.UMICH.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <8704010011.AA29397@ucbvax.Berkeley.EDU> Date: Tue, 31-Mar-87 17:44:00 EST Article-I.D.: ucbvax.8704010011.AA29397 Posted: Tue Mar 31 17:44:00 1987 Date-Received: Thu, 2-Apr-87 02:37:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa a man after my own heart -- reinventing uucp. i'm with you, bro'. peter ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033112440001> Received: from citi.umich.edu by SRI-NIC.ARPA with TCP; Tue 31 Mar 87 15:52:15-PST From: honey@citi.umich.edu To: HANK@BARILVM.BITNET, tcp-ip@sri-nic.ARPA Date: 31 Mar 1987 17:44 EST Subject: Re: Tcp/Ip vs a store & forward network a man after my own heart -- reinventing uucp. i'm with you, bro'. peter ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987033113052900> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Tue 31 Mar 87 05:07:08-PST Received: from ucl-cs-pyr1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa03543; 31 Mar 87 12:59 WET Date: Tue, 31 Mar 87 13:05:29 WET From: jon@Cs.Ucl.AC.UK Subject: Tcp/Ip vs a store & forward network To: tcp-ip@sri-nic.arpa Actually, I thought the Internet WAS a store-and-forward network. Gateways store up packets as they are received and forward them after a queueing delay. I think you really meant "message switching" as opposed to "packet switching". Yep. In the UK we use a spooled FTP system called NIFTP (Network independant file transfer protocol). This works over anything and we have it on 11/44s on Cambridge rings, vaxen and pyramid, TCP/IP over ethernet. The spec says you can checkpoint files, so it will work over junk networks without having to break large files down yourself. It also does binary etc, and it does some sorts of run-length encoding, for people with 30bps packet radio nets! It also has sensible authentication, unlike ftp which seems happy to send LOGIN passwords around on networks without encryption (try and sell that to a commercial company with ethernet). The spec may be got from the Joint Network Team in the UK. Implementations for ?NIXs exist. Why reinvent the wheel, when you can get a halftrack for free - or you could wait for FTAM. jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [QUQ54dy00UoJIlg0cw%40andrew.cmu.edu] <1987033113284100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ddp#@ANDREW.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: danger of bridges Message-ID: Date: Tue, 31-Mar-87 18:28:41 EST Article-I.D.: andrew.QUQ54dy00UoJIlg0cw Posted: Tue Mar 31 18:28:41 1987 Date-Received: Thu, 2-Apr-87 02:35:58 EST References: <12290865337.25.GROSSMAN@Sierra.Stanford.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Well that is certainly good news, but I have a question... If DECnet endnodes don't enable listening to Hello's, then how do two endnodes communicate on a network consisting only of themselves? Seems like they'd have to be listening on some sort of routing multicast address. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704010008.AA05567%40utah-gr.ARPA] <1987033114082800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haas%utah-gr@CS.UTAH.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Packet network reliability Message-ID: <8704010008.AA05567@utah-gr.ARPA> Date: Tue, 31-Mar-87 19:08:28 EST Article-I.D.: utah-gr.8704010008.AA05567 Posted: Tue Mar 31 19:08:28 1987 Date-Received: Fri, 3-Apr-87 01:34:01 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 36 Approved: tcp-ip@sri-nic.arpa In article <8703312012.AA25019@ucbvax.Berkeley.EDU>, AFDDN.TCP-IP@GUNTER-ADAM.ARPA writes: > Tightly binding resources in a single virtual path through the > network does let you know what resources are going where and for how long... True, this was a major motivation for Telenet's conversion to VC internals. > Some nets I believe have a single route source that has global knowledge of > the network and returns routes to the net nodes for every connection > request. The earliest version of Tymnet used something like this. The system did not scale up, not so much because of the reliability problem but because of the enormous amount of traffic to and from the Master User Directory. This approach is no longer used. > The disadvantage I see is that every VC will use up a given amount of net > resources whether data is actually being transmitted across the VC or not. Only a small table entry is used. This is in practice less costly than the communications resources used to convey a complete address in every packet. > In the cases where static routing is downloaded from a central site, the > survivability of the network as a whole is only as good as that of the > central site. True. Tymnet went to four regional sites for routing information, which helps with robustness and distributes the traffic a little more evenly. Telenet assigns net addresses geographically, and each TCO routes based on the implicit geographic information in the Call Request packet. Thus each TCO can make routing decisions independently of any central source of routing information. This is very robust. Cheers -- Walt ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12290893946.25.GROSSMAN%40Sierra.Stanford.EDU] <1987033114565500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GROSSMAN@SIERRA.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: danger of bridges Message-ID: <12290893946.25.GROSSMAN@Sierra.Stanford.EDU> Date: Tue, 31-Mar-87 19:56:55 EST Article-I.D.: Sierra.12290893946.25.GROSSMAN Posted: Tue Mar 31 19:56:55 1987 Date-Received: Fri, 3-Apr-87 04:15:53 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa Good guesswork! Endnodes do indeed listen to a special multicast address. A breif explanation: When a DECnet endnode wants to send a datagram, it sends it to a DECnet node known as the 'Designated Router'. The designated router is known by the endnode because he periodically emits a special hello message to say who he is. Now, theres a little bit more glue and filler to deal with getting the endnode to use a more direct route if possible (such as if the dest node is on the same ethernet), and cacheing of the next hop (ie: best gateway) to get to a specified node. Just to throw another monkey into the wrenchworks, there is the added feature that the designated router can move around! There's a little bit of protocol and stuff that arbitrates who gets the honor, but theres no special setup needed to establish the DR. Oh yeah, just one more thing, just in case there is NO DR at all, the endnode can still talk to other systems on the same wire, it just computes the Ethernet address from the DECnet address, and sends the datagram! Stu Grossman ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704010105.AA25464%40nrl-mpm.ARPA] <1987033115051500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mullen@NRL-MPM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: obnoxious broadcast messages Message-ID: <8704010105.AA25464@nrl-mpm.ARPA> Date: Tue, 31-Mar-87 20:05:15 EST Article-I.D.: nrl-mpm.8704010105.AA25464 Posted: Tue Mar 31 20:05:15 1987 Date-Received: Fri, 3-Apr-87 01:20:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa > broadcast message from temp!root: This is a test of area coverage. Please send me a nasty indignant flame > if you get this broadcast. > > Jordan (jkh@violet.berkeley.edu) I have gotten several of these broadcast messages (equivalent to a "wall") today on various Unix systems on my local network. 1. Who is this person, jkh@violet.berkeley.edu? 2. Why are we being bothered with these messages? 3. How is it being done? 4. How can we stop this nuisance? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12290940173.15.ROMKEY%40XX.LCS.MIT.EDU] <1987033119105100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROMKEY@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: interesting new product I ran across Message-ID: <12290940173.15.ROMKEY@XX.LCS.MIT.EDU> Date: Wed, 1-Apr-87 00:10:51 EST Article-I.D.: XX.12290940173.15.ROMKEY Posted: Wed Apr 1 00:10:51 1987 Date-Received: Fri, 3-Apr-87 03:43:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 58 Approved: tcp-ip@sri-nic.arpa This crossed my desk today and I thought some people out there might have some interest in it. I don't mean to advertise on the net, I mean, after all, *I* certainly have no connection with "FTAM Hardware, Inc.". - john romkey FTP Software, Inc. FTAM Hardware, Inc Product Announcement PA0000 The Illudium Q-2 Explosive Network Demodulator The Illudium Q-2 Explosive Network Demodulator is a must for all network installations. It eliminates dangerous modulations from your network. It features a 100Hz low pass filter; now all your hosts will show the same performance on network operations! Standard features include Ethernet, IEEE, ARPANET, SATNET, ProNET-10 and synchronous and asynchronous serial line compatability. TCP/IP, DECnet, XNS, Chaosnet, SNA and ISO modes available. NETBIOS interface standard, and the Network Demodulator will attempt to negotiate into 3270 emulation mode when possible. Supports Berkeley Unix protocols. Converts trailers into Recreational Vehicles. Microwave, infrared and fiberoptic options are available, though the standard kit works with phone lines. The Illudium Q-2 Explosive Network Demodulator includes a network monitoring feature, with, as a standard feature, a command that will monitor the network to tell you your choice of Jon Postel's, Vint Cerf's, Dave Mills' or Richard M. Stallman's password (special hardware support provided for the latter). Also has facilities for seeing who IBM, DEC and AT&T are sending packets to, now that they're all connected to the same network. Tempest certified. One size fits all. Fully compliant with the ULANA and GOSIP specifications. Implements full source-routing and security features. Available in green, red, blue and plaid cases. Requires GNU Emacs Version 78.90 or later, and 200Mb physical memory (188 for Emacs, 12 for the Illudium Q-2 Explosive Network Demodulator). (The Illudium Q-2 Explosive Network Demodulator is also useful for for handling obstacles which obstruct your satellite link to Venus.) Order by midnight tonight and receive these free gifts: The Ginzu ethernet splicer! The TJ Watson memorial EBCDIC decoder ring! and the Vint Cerf Programmable Calculator which takes as input a data storage medium and a mode of transportation and calculates your bit rate! ("where's the kaboom? there's supposed to be a network-shattering kaboom!") ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704010458.AA01350%40spam.istc.sri.com] <1987033119171200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gds@SPAM.ISTC.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <8704010458.AA01350@spam.istc.sri.com> Date: Wed, 1-Apr-87 00:17:12 EST Article-I.D.: spam.8704010458.AA01350 Posted: Wed Apr 1 00:17:12 1987 Date-Received: Fri, 3-Apr-87 03:41:50 EST References: <8703311435.AA11791@gwen.cs.purdue.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 33 Approved: tcp-ip@sri-nic.arpa A reasonable compromise would be a confirmation that the message has been placed in the recipients mailbox. If you'll allow that the message has been placed in the user's maildrop (/usr/spool/mail/user), sendmail has a feature such that if it receives mail with the header Return-Receipt-To:, it will generate an ack to the address listed there. (The address must be replyable from the receiver's context, so it must contain a full reverse path for a reliable ack.) You are pretty much guaranteed that the mail has been committed to stable storage (if not the maildrop, the sendmail spool). Presumably, as domain names get extended, we will be able to do that. Any mail you send to a user can go directly to the machine where the his/her mailbox resides. No forwarding at the site would be needed. I'm not sure what you mean by this. In the ARPA Internet, mail goes directly from the sender's site to the recipient's site unless forwarding is specified. UUCP requires forwarding at intermediate nodes. Even if the UUCP namespace were entirely mapped out, you couldn't have mail going directly from sender machine to recipient machine unless everyone called everyone else, which will never happen. I think we're mixing concepts here a bit. "reliable delivery" to gds@spam.istc.sri.com is accomplished when something has been delivered to a process on spam.istc.sri.com which will leave the mail where "gds" can access it. "reliable delivery" to the human Greg Skinner requires that he read it. I think it would be asking too much to modify mail software to require acks, not to mention a problem for sites which don't have source. --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704011429.AA11823%40ucbvax.Berkeley.EDU] <1987033122314100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Remote access in Bitnet Message-ID: <8704011429.AA11823@ucbvax.Berkeley.EDU> Date: Wed, 1-Apr-87 03:31:41 EST Article-I.D.: ucbvax.8704011429.AA11823 Posted: Wed Apr 1 03:31:41 1987 Date-Received: Sat, 4-Apr-87 06:10:00 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 62 Approved: tcp-ip@sri-nic.arpa (Caveat - This description is primarily for people who have no idea how Bitnet works.) Greg, The concept of remote access doesn't exist in Bitnet. The protocols in Bitnet are as follows: 1) One-way File Transfer - any user is allowed to send a file to any other user. Since the file ends up in the destination users spool system (or some emulation thereof) there is no problem with access control. 2) Interactive Message - any user can send a one line message (max 160 characters) to any other user. All you need to know is the destination user and node. If the user is not logged on or a link is down you are told so. Based on these two primitives - Bitnet has built various other pseudo-protocols. From #1 above - we are able to do mail, list explosion, computer conferencing, general file transfer. From #2 above, Bitnet has developed a CB (Chat) system. By combined both of the basic primitives above, a file server can be set up at any node that will trap incoming 'Interactive Messages' - which contain a command and process the command and send the results back to the user via the 'One-Way File Transfer' mechanism. This method allows users to sit at their machine and issue commands like DIR or LIST to some remote file server and then issue some SEND commands to retrieve the files they want. There is no need in that case to do any sort of remote connect (anonymous FTP). Most servers (200+) in Bitnet also accept transactions via files or RFC822 mail. Lately, various servers in Arpanet have decided that is also a 'clever' thing to have, so we have things like archive-request@simtel20.arpa and service@sri-nic.arpa popping up (I expect more before the end of th year). So to answer your question: > a remote file they own They cannot access it. Yup would be nice and that is just one reason why Bitnet should convert to Tcp/Ip. Incidentally, there is a program I distribute in Bitnet that allows this remote access to a file the person owns but it is a private convention. The program runs as a task (and therefore must be running when the remote user wants access to his/her files). and the user needs to set up a remote access password. It uses the Interactive Message Primitive to send and receive data, and each command you want executed on the remote host must be prefixed with your remote pswd. Not as elegent as TELNET but when the entire concept of TELNET doesn't exist it is the best one can do. > a remote file they don't own, but is not protected Only if the file is available via a remote file server can they access it. > a remote file they don't own, but is protected They can't access it. Hope this helps. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704010943.AA08745%40ucbvax.Berkeley.EDU] <1987033123445900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jon@CS.UCL.AC.UK.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: talking of and to gateways and bridges Message-ID: <8704010943.AA08745@ucbvax.Berkeley.EDU> Date: Wed, 1-Apr-87 04:44:59 EST Article-I.D.: ucbvax.8704010943.AA08745 Posted: Wed Apr 1 04:44:59 1987 Date-Received: Sat, 4-Apr-87 06:21:37 EST References: <8703312141.AA25608@bert.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa Chris, ROS stands for Remote OperationS, and REX stands for Remote EXexcution. They are part of the ECMA (European Computer Manufacturers Association) input to draft standards work on distributed computing. REX is a Birrel & Nelson type 'minimum packet' transaction transport protocol, whilst ROS uses ASN (Abstract Sysntax Notation) as a presentation layer to to define call/reply/error messages and parameters and to provide machine independance of call and reply parameter representation. The ANSA (Advanced Network Systems Architecture) research group have put a lot of work into their design. The goal is to provide a system where code for client/server model interactions may be generated automatically (RPC type work), but to allow for other types of interaction too. jon ----MESSAGE-END----