----MESSAGE-BEGIN---- [8509031953.AA02698%40UCB-VAX.ARPA] <1985090311543500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: mills@DCN6.ARPA Newsgroups: fa.tcp-ip Subject: Timetelling (continued) Message-ID: <8509031953.AA02698@UCB-VAX.ARPA> Date: Tue, 3-Sep-85 15:54:35 EDT Article-I.D.: UCB-VAX.8509031953.AA02698 Posted: Tue Sep 3 15:54:35 1985 Date-Received: Wed, 4-Sep-85 07:14:16 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.berkeley.edu Organization: The ARPA Internet Lines: 104 Folks, You might be interested in the following survey of Internet timetellers, the results of which provide an interesting insight into the things that can break in such a service. The section that follows was extracted from a research report that may become an RFC. The original (promise not to redistribute it) is in the file SYNCH.DOC in the MILLS directory at ISID. A3. Comparison of UDP and ICMP Time The third experiment was designed to assess the accuracies produced by the various host implementations of the UDP Time protocol and ICMP Timestamp messages. For each of the hosts responding to the UDP Time protocol in the first experiment a separate test was conducted using both UDP and ICMP in the same test, so as to minimize the effect of clock drift. Of the 162 hosts responding to UDP requests, 45 also responded to ICMP requests with apparently correct time, but the remainder either responded with unknown or nonstandard ICMP time (29) or failed to respond to ICMP requests at all (88). Table A8 shows both the UDP time (seconds) and ICMP time (milliseconds) returned by each of the 45 hosts responding to both UDP and ICMP requests. The data are ordered first by indicated UDP offset and then by indicated ICMP offset. The seven hosts at the top of the table are continuously synchronized, directly or indirectly to a radio clock, as described earlier under the first experiment. It is probable, but not confirmed, that those hosts below showing discrepancies of a second or less are synchronized on occasion to one of these hosts. Host UDP time ICMP time ------------------------------------------------- DCN6.ARPA 0 sec 0 msec DCN7.ARPA 0 0 DCN1.ARPA 0 -6 DCN5.ARPA 0 -7 UMD1.ARPA 0 8 UMICH1.ARPA 0 -21 FORD1.ARPA 0 31 TESLA.EE.CORNELL.EDU 0 132 SEISMO.CSS.GOV 0 174 UT-SALLY.ARPA -1 -240 CU-ARPA.CS.CORNELL.EDU -1 -514 UCI-ICSE.ARPA -1 -1896 UCI-ICSC.ARPA 1 2000 DCN9.ARPA -7 -6610 TRANTOR.ARPA 10 10232 COLUMBIA.ARPA 11 12402 GVAX.CS.CORNELL.EDU -12 -11988 UCI-CIP5.ARPA -15 -17450 RADC-MULTICS.ARPA -16 -16600 SU-WHITNEY.ARPA 17 17480 UCI-ICSD.ARPA -20 -20045 SU-COYOTE.ARPA 21 21642 MIT-MULTICS.ARPA 27 28265 BBNA.ARPA -34 -34199 UCI-ICSA.ARPA -37 -36804 ROCHESTER.ARPA -42 -41542 SU-AIMVAX.ARPA -50 -49575 UCI-CIP4.ARPA -57 -57060 SU-SAFE.ARPA -59 -59212 SU-PSYCH.ARPA -59 -58421 UDEL-MICRO.ARPA 62 63214 UIUCDCSB.ARPA 63 63865 BELLCORE-CS-GW.ARPA 71 71402 USGS2-MULTICS.ARPA 76 77018 BBNG.ARPA 81 81439 UDEL-DEWEY.ARPA 89 89283 UCI-CIP3.ARPA -102 -102148 UIUC.ARPA 105 105843 UCI-CIP2.ARPA -185 -185250 UCI-CIP.ARPA -576 -576386 OSLO-VAX.ARPA 3738 3739395 DEVVAX.TN.CORNELL.EDU 3657 3657026 PATCH.ARPA -86380 20411 IPTO-FAX.ARPA -86402 -1693 NETWOLF.ARPA 10651435 -62164450 Table A8. Comparison of UDP and ICMP Host Clock Offsets Allowing for various degrees of truncation and roundoff abuse in the various implmentations, discrepancies of up to a second could be expected between UDP and ICMP time. While the results for most hosts confirm this, some discrepancies are far greater, which may indicate defective implementations, excessive swapping delays and so forth. For instance, the ICMP time indicated by UCI-CIP5.ARPA is almost 2.5 seconds less than the UDP time. Even though the UDP and ICMP times indicated by OSLO-VAX.ARPA and DEVVAX.TN.CORNELL.EDU agree within nominals, the fact that they are within a couple of minutes or so of exactly one hour early (3600 seconds) lends weight to the conclusion they were incorrectly set, probably by an operator who confused local summer and standard time. Something is clearly broken in the case of PATCH.ARPA, IPTO-FAX.ARPA and NETWOLF.ARPA. Investigation of the PATCH.ARPA and IPTO-FAX.ARPA reveals that these hosts were set by hand accidently one day late (-86400 seconds), but otherwise close to the correct time-of-day. Since the ICMP time rolls over at 2400 UT, the ICMP offset was within nominals. No explanation is available for the obviously defective UDP and ICMP times indicated by NETWOLF.ARPA, although it was operating within nominals at least in the first experiment. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985090318091300> Received: from DCN7.ARPA by SRI-NIC.ARPA with TCP; Tue 3 Sep 85 11:16:45-PDT Date: 03-Sep-85 18:09:13-UT From: mills@dcn6.arpa Subject: Timetelling (continued) To: tcp-ip@sri-nic.arpa Folks, You might be interested in the following survey of Internet timetellers, the results of which provide an interesting insight into the things that can break in such a service. The section that follows was extracted from a research report that may become an RFC. The original (promise not to redistribute it) is in the file SYNCH.DOC in the MILLS directory at ISID. A3. Comparison of UDP and ICMP Time The third experiment was designed to assess the accuracies produced by the various host implementations of the UDP Time protocol and ICMP Timestamp messages. For each of the hosts responding to the UDP Time protocol in the first experiment a separate test was conducted using both UDP and ICMP in the same test, so as to minimize the effect of clock drift. Of the 162 hosts responding to UDP requests, 45 also responded to ICMP requests with apparently correct time, but the remainder either responded with unknown or nonstandard ICMP time (29) or failed to respond to ICMP requests at all (88). Table A8 shows both the UDP time (seconds) and ICMP time (milliseconds) returned by each of the 45 hosts responding to both UDP and ICMP requests. The data are ordered first by indicated UDP offset and then by indicated ICMP offset. The seven hosts at the top of the table are continuously synchronized, directly or indirectly to a radio clock, as described earlier under the first experiment. It is probable, but not confirmed, that those hosts below showing discrepancies of a second or less are synchronized on occasion to one of these hosts. Host UDP time ICMP time ------------------------------------------------- DCN6.ARPA 0 sec 0 msec DCN7.ARPA 0 0 DCN1.ARPA 0 -6 DCN5.ARPA 0 -7 UMD1.ARPA 0 8 UMICH1.ARPA 0 -21 FORD1.ARPA 0 31 TESLA.EE.CORNELL.EDU 0 132 SEISMO.CSS.GOV 0 174 UT-SALLY.ARPA -1 -240 CU-ARPA.CS.CORNELL.EDU -1 -514 UCI-ICSE.ARPA -1 -1896 UCI-ICSC.ARPA 1 2000 DCN9.ARPA -7 -6610 TRANTOR.ARPA 10 10232 COLUMBIA.ARPA 11 12402 GVAX.CS.CORNELL.EDU -12 -11988 UCI-CIP5.ARPA -15 -17450 RADC-MULTICS.ARPA -16 -16600 SU-WHITNEY.ARPA 17 17480 UCI-ICSD.ARPA -20 -20045 SU-COYOTE.ARPA 21 21642 MIT-MULTICS.ARPA 27 28265 BBNA.ARPA -34 -34199 UCI-ICSA.ARPA -37 -36804 ROCHESTER.ARPA -42 -41542 SU-AIMVAX.ARPA -50 -49575 UCI-CIP4.ARPA -57 -57060 SU-SAFE.ARPA -59 -59212 SU-PSYCH.ARPA -59 -58421 UDEL-MICRO.ARPA 62 63214 UIUCDCSB.ARPA 63 63865 BELLCORE-CS-GW.ARPA 71 71402 USGS2-MULTICS.ARPA 76 77018 BBNG.ARPA 81 81439 UDEL-DEWEY.ARPA 89 89283 UCI-CIP3.ARPA -102 -102148 UIUC.ARPA 105 105843 UCI-CIP2.ARPA -185 -185250 UCI-CIP.ARPA -576 -576386 OSLO-VAX.ARPA 3738 3739395 DEVVAX.TN.CORNELL.EDU 3657 3657026 PATCH.ARPA -86380 20411 IPTO-FAX.ARPA -86402 -1693 NETWOLF.ARPA 10651435 -62164450 Table A8. Comparison of UDP and ICMP Host Clock Offsets Allowing for various degrees of truncation and roundoff abuse in the various implmentations, discrepancies of up to a second could be expected between UDP and ICMP time. While the results for most hosts confirm this, some discrepancies are far greater, which may indicate defective implementations, excessive swapping delays and so forth. For instance, the ICMP time indicated by UCI-CIP5.ARPA is almost 2.5 seconds less than the UDP time. Even though the UDP and ICMP times indicated by OSLO-VAX.ARPA and DEVVAX.TN.CORNELL.EDU agree within nominals, the fact that they are within a couple of minutes or so of exactly one hour early (3600 seconds) lends weight to the conclusion they were incorrectly set, probably by an operator who confused local summer and standard time. Something is clearly broken in the case of PATCH.ARPA, IPTO-FAX.ARPA and NETWOLF.ARPA. Investigation of the PATCH.ARPA and IPTO-FAX.ARPA reveals that these hosts were set by hand accidently one day late (-86400 seconds), but otherwise close to the correct time-of-day. Since the ICMP time rolls over at 2400 UT, the ICMP offset was within nominals. No explanation is available for the obviously defective UDP and ICMP times indicated by NETWOLF.ARPA, although it was operating within nominals at least in the first experiment. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985090503200000> Received: from mitre-bedford by SRI-NIC.ARPA with TCP; Thu 5 Sep 85 04:25:38-PDT Date: Thursday, 5 Sep 1985 07:20-EDT From: sra@mitre-bedford.ARPA To: tcp-ip@sri-nic Cc: sra@mitre-bedford.ARPA Subject: TCP Performance and Compatibility Mitre-Bedford is about to commence and an operational experiment of interconnecting as many hosts and TCP implementations that we can gain access to in an effort to demonstrate and test vendor compatibility and performance of various implementation strageties. The interconnection will be over Ethernet (Broadband, Baseband and Fiber segments) tied together by Applitek bridges. I am soliciting suggestions as to the types of tests the TCP/IP community would like to see run as well as performance benchmark or compatibility tests that may already exist that we can have. Thanks Stan Ames sra at Mitre-Bedford ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509051347.AA18013%40UCB-VAX.ARPA] <1985090504365100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: mckenzie@BBNH.ARPA (Alex McKenzie) Newsgroups: fa.tcp-ip Subject: Seeking Info about Ethernet BRIDGES Message-ID: <8509051347.AA18013@UCB-VAX.ARPA> Date: Thu, 5-Sep-85 08:36:51 EDT Article-I.D.: UCB-VAX.8509051347.AA18013 Posted: Thu Sep 5 08:36:51 1985 Date-Received: Fri, 6-Sep-85 05:34:16 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.berkeley.edu Organization: The ARPA Internet Lines: 13 I've recently seen messages from NASA Ames, Rutgers, and Mitre Bedford about use of Applitek bridges. BBN is considering use of a substantial number of bridges locally, and I'm very interested to hear about experience with the Applitek bridges. Are there any other sites where these devices are currently in use? For that matter, does anyone out there have any experience with bridges made by companies other than AppliteK which are intended to provide LOCAL interconnection of Ethernets (i.e, I'm not interested in the Vitalink device, nor in repeaters, nor in gateways). Thanks in advance for any pointers, Alex McKenzie BBN 617/497-2962 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985090504365101> Received: from bbnh by SRI-NIC.ARPA with TCP; Thu 5 Sep 85 05:46:25-PDT Date: Thu, 5 Sep 85 8:36:51 EDT From: Alex McKenzie Subject: Seeking Info about Ethernet BRIDGES To: tcp-ip@sri-nic.arpa Cc: mckenzie@BBNH.ARPA I've recently seen messages from NASA Ames, Rutgers, and Mitre Bedford about use of Applitek bridges. BBN is considering use of a substantial number of bridges locally, and I'm very interested to hear about experience with the Applitek bridges. Are there any other sites where these devices are currently in use? For that matter, does anyone out there have any experience with bridges made by companies other than AppliteK which are intended to provide LOCAL interconnection of Ethernets (i.e, I'm not interested in the Vitalink device, nor in repeaters, nor in gateways). Thanks in advance for any pointers, Alex McKenzie BBN 617/497-2962 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509051618.AA20147%40UCB-VAX.ARPA] <1985090507010900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: MILLS@USC-ISID.ARPA Newsgroups: fa.tcp-ip Subject: Re: TCP Performance and Compatibility Message-ID: <8509051618.AA20147@UCB-VAX.ARPA> Date: Thu, 5-Sep-85 11:01:09 EDT Article-I.D.: UCB-VAX.8509051618.AA20147 Posted: Thu Sep 5 11:01:09 1985 Date-Received: Fri, 6-Sep-85 05:34:29 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.berkeley.edu Organization: The ARPA Internet Lines: 13 In response to the message sent Thursday, 5 Sep 1985 07:20-EDT from sra@mitre-bedford.ARPA Stan, Your tests appear similar to those within the scope of the Protocol Testing Lab at DCEC. You may also discover friends in the Testing Task Force, chaired by Ed Cain (cain@edn-unix). Compatibility tests via Ethernet and Applitek bridges may be an excellent test of Ethernet technology, but they inspire little confidence that cranky TCP implementations find joy in each other via real Internet paths. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [850905154233.2.NFEP%40NEPONSET.SCRC.Symbolics.COM] <1985090511420000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: DCP@SCRC-QUABBIN.ARPA (David C. Plummer in disguise) Newsgroups: fa.tcp-ip Subject: TCP Performance and Compatibility Message-ID: <850905154233.2.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Thu, 5-Sep-85 15:42:00 EDT Article-I.D.: NEPONSET.850905154233.2.NFEP Posted: Thu Sep 5 15:42:00 1985 Date-Received: Sat, 7-Sep-85 04:17:58 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.berkeley.edu Organization: The ARPA Internet Lines: 9 For performance, I suggest not using many of the standard protocols. This is because most of them have to do character set translation or at least double scanning. TELNET is one example, and I think ASCII mode of TCP/FTP is another. Specifically, it has to scan the data making sure the whatever the system's newline sequence is gets converted into or out-of NVT-NEWLINE and that raw CRs get NULLs appended to them. TCP/FTP binary mode would probably be OK. For raw performance, SINK, ECHO and SOURCE servers would be best, though I don't know off hand if they are a standard port that people are expected to implement. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509061000.AA10226%40UCB-VAX.ARPA] <1985090600310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: vshank%weizmann.BITNET@WISCVM.ARPA (Henry Nussbacher) Newsgroups: fa.tcp-ip Subject: VMS and TCP/IP Message-ID: <8509061000.AA10226@UCB-VAX.ARPA> Date: Fri, 6-Sep-85 04:31:00 EDT Article-I.D.: UCB-VAX.8509061000.AA10226 Posted: Fri Sep 6 04:31:00 1985 Date-Received: Sat, 7-Sep-85 07:09:34 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.berkeley.edu Organization: The ARPA Internet Lines: 11 I am new to this forum, so please forgive me if this has been covered. Can someone send me a list of the vendors or available public domain software for TCP/IP on VMS? If you can, include vendors address and estimated price. Next, can someone also fill me in on PC/IP? Thanks, Hank P.S. Reply directly to me so as not to clutter up the forum with this. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985090605000000> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 6 Sep 85 12:01:53-PDT Date: 6 Sep 1985 12:00-PDT Sender: WESTINE@USC-ISIB.ARPA Subject: Performance and Compatibilty From: Jon Postel To: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISIB.ARPA] 6-Sep-85 12:00:07.WESTINE> Try the Echo Protocol (RFC 862) on port 7, the Discard Protocol (RFC 863) on port 9, and the Character Generator Protocol (RFC 864) on port 19. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985090606152600> Received: from RED.RUTGERS.EDU by SRI-NIC.ARPA with TCP; Fri 6 Sep 85 07:17:19-PDT Date: 6 Sep 85 10:15:26 EDT From: Charles Subject: MIT TCP-PC Source code? To: tcp-ip@SRI-NIC.ARPA Hello, A while back we obtained the MIT TCP implimentation for IBM PCs (with a 3Com board), and the source code for it and the 8086 & 68000 cross-compilers. Low and behold, one of the include libraries on the 8086 cross-compiler tape got zapped. I called MIT and it turns out that the version they have on their machine is also munged (which is how the tape wound up bad). Now, I have asked them to please get the library restored so we can get it, but I was hoping someone out there might have it available now and let us ftp it (since they have to search back n backup tapes and find it). The directory is: .../lib86/include/sys ... can anyone help me/us? Charles ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985090614010000> Received: from WISCVM.ARPA by SRI-NIC.ARPA with TCP; Fri 6 Sep 85 02:17:22-PDT Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 09/06/85 at 04:16:33 CDT Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 3317; Fri, 06 Sep 85 10:34:33 O Date: Fri, 6 Sep 85 10:31 O From: Henry Nussbacher Subject: VMS and TCP/IP To: I am new to this forum, so please forgive me if this has been covered. Can someone send me a list of the vendors or available public domain software for TCP/IP on VMS? If you can, include vendors address and estimated price. Next, can someone also fill me in on PC/IP? Thanks, Hank P.S. Reply directly to me so as not to clutter up the forum with this. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [850906214445.8.NFEP%40NEPONSET.SCRC.Symbolics.COM] <1985090617440000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: DCP@SCRC-QUABBIN.ARPA ("David C. Plummer in disguise") Newsgroups: fa.tcp-ip Subject: Performance and Compatibilty Message-ID: <850906214445.8.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Fri, 6-Sep-85 21:44:00 EDT Article-I.D.: NEPONSET.850906214445.8.NFEP Posted: Fri Sep 6 21:44:00 1985 Date-Received: Sun, 8-Sep-85 16:13:28 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.berkeley.edu Organization: The ARPA Internet Lines: 14 Date: 6 Sep 1985 12:00-PDT From: Jon Postel Try the Echo Protocol (RFC 862) on port 7, the Discard Protocol (RFC 863) on port 9, and the Character Generator Protocol (RFC 864) on port 19. Ah, such things do exist with assigned numbers. I just checked and Symbolics does in fact implement all of these. I feared we didn't. Is a TCP implementation considered complete without these? My point is, they aren't generally useful except for debugging and performace, and many people may not have bothered. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509091729.AA01305%40UCB-VAX.ARPA] <1985090909303700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: mills@DCN6.ARPA Newsgroups: fa.tcp-ip Subject: Proposed Network Time Protocol (NTP) Message-ID: <8509091729.AA01305@UCB-VAX.ARPA> Date: Mon, 9-Sep-85 13:30:37 EDT Article-I.D.: UCB-VAX.8509091729.AA01305 Posted: Mon Sep 9 13:30:37 1985 Date-Received: Tue, 10-Sep-85 05:09:50 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 33 Folks, I am proposing a new protocol for distributing network time. It is called the Network Time Protocol (NTP) and described in a document suitable for distribution as an RFC. The document is in TIMPRO.DOC in the MILLS directory at ISID. Background information, along with experimental data and algorithm designs, is in two companion documents TIME.DOC and SYNCH.DOC. I have implemented prototype servers and testing programs, which are running now on DCN1.ARPA (WWVB clock), DCN6.ARPA (WWV clock), FORD1.ARPA (GOES clock) and IPTO-FAX.ARPA (line-frequency clock). NTP specifies data formats and message-transfer procedures only. It does not specify the local timekeeping or network distribution algorithms. Accurate timetelling to fractions of a second requires carefully managed timekeeping mechanisms such as described in TIME.DOC and RFC-889. The interesting area remaining is the network distribution algorithms appropriate for a large, hierarchical community of hosts to maintain and distribute accurate time, in spite of some timetellers that are less accurate than others and even some that might refuse, lie or die. Suggested algorithms to filter unreliable or noisy data are included in SYNCH.DOC, while an outline for a distributed algorithm for network management is included in TIMPRO.DOC. This note is to invite discussion and comment in the relevant task forces and message groups before the paint dries on the the protocol document and it is generally distributed. My hope is to do this while continuing to experiment and define the distribution algorithm, so I would like to keep the discussion period short. I have found this area a useful model for studying and experimenting with robust, distributed protocols while keeping implementation overheads low. Comments and suggestions to this mailbox (mills@dcn6.arpa) would be appreciated and will be combined for redistribution. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985090916051700> Received: from DCN7.ARPA by SRI-NIC.ARPA with TCP; Mon 9 Sep 85 09:11:24-PDT Date: 09-Sep-85 16:05:17-UT From: mills@dcn6.arpa Subject: Proposed Network Time Protocol (NTP) To: tcp-ip@sri-nic.arpa Folks, I am proposing a new protocol for distributing network time. It is called the Network Time Protocol (NTP) and described in a document suitable for distribution as an RFC. The document is in TIMPRO.DOC in the MILLS directory at ISID. Background information, along with experimental data and algorithm designs, is in two companion documents TIME.DOC and SYNCH.DOC. I have implemented prototype servers and testing programs, which are running now on DCN1.ARPA (WWVB clock), DCN6.ARPA (WWV clock), FORD1.ARPA (GOES clock) and IPTO-FAX.ARPA (line-frequency clock). NTP specifies data formats and message-transfer procedures only. It does not specify the local timekeeping or network distribution algorithms. Accurate timetelling to fractions of a second requires carefully managed timekeeping mechanisms such as described in TIME.DOC and RFC-889. The interesting area remaining is the network distribution algorithms appropriate for a large, hierarchical community of hosts to maintain and distribute accurate time, in spite of some timetellers that are less accurate than others and even some that might refuse, lie or die. Suggested algorithms to filter unreliable or noisy data are included in SYNCH.DOC, while an outline for a distributed algorithm for network management is included in TIMPRO.DOC. This note is to invite discussion and comment in the relevant task forces and message groups before the paint dries on the the protocol document and it is generally distributed. My hope is to do this while continuing to experiment and define the distribution algorithm, so I would like to keep the discussion period short. I have found this area a useful model for studying and experimenting with robust, distributed protocols while keeping implementation overheads low. Comments and suggestions to this mailbox (mills@dcn6.arpa) would be appreciated and will be combined for redistribution. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509101836.AA01625%40UCB-VAX.ARPA] <1985091004024500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: klute%gatech.csnet@CSNET-RELAY.ARPA (Gregory Kenley) Newsgroups: fa.tcp-ip Subject: Re: Proposed Network Time Protocol (NTP) Message-ID: <8509101836.AA01625@UCB-VAX.ARPA> Date: Tue, 10-Sep-85 08:02:45 EDT Article-I.D.: UCB-VAX.8509101836.AA01625 Posted: Tue Sep 10 08:02:45 1985 Date-Received: Wed, 11-Sep-85 07:57:35 EDT References: <8509091729.AA01305@UCB-VAX.ARPA> Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 6 Dave, I am very interested in your latest posting. However since I don't have ARPA access I cannot get at these documents. Would you please send the sources to me as mail? I would appreciate it a lot. I would very much like to see what you have done. Thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509110541.AA09758%40UCB-VAX.ARPA] <1985091021415400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: mills@DCN6.ARPA Newsgroups: fa.tcp-ip Subject: Ticking and tocking Message-ID: <8509110541.AA09758@UCB-VAX.ARPA> Date: Wed, 11-Sep-85 01:41:54 EDT Article-I.D.: UCB-VAX.8509110541.AA09758 Posted: Wed Sep 11 01:41:54 1985 Date-Received: Fri, 13-Sep-85 00:19:02 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 17 Folks, You may be bored with my continuing saga; on the other hand you may find it hilarious. Awesome jolts due electrical storms zapped various parts of our local-net anatomy on Friday, Sunday and Tuesday evenings, laying waste fuzzballs, clocks, Ethernets and anything else that writhed in the Washington, DC, area. The lesson never to rely on radio clocks in the same geographical area deja-vued all over again, since both our WWVB and WWV clocks got lobotomized and only the FORDnet GOES clock in Dearborn, MI, saved our timekeeping souls, and that only after manual intervention. I once again apologize for all those errant DCN1 timestamps our comrades use to stamp their files, bombs and bills. If you believe a protocol similar to the one I proposed in my recent message and document will cure what hurts, please send comments, advice or money. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091104063900> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Tue 10 Sep 85 21:43:43-PDT Date: 11-Sep-85 04:06:39-UT From: mills@dcn6.arpa Subject: Ticking and tocking To: tcp-ip@sri-nic.arpa Folks, You may be bored with my continuing saga; on the other hand you may find it hilarious. Awesome jolts due electrical storms zapped various parts of our local-net anatomy on Friday, Sunday and Tuesday evenings, laying waste fuzzballs, clocks, Ethernets and anything else that writhed in the Washington, DC, area. The lesson never to rely on radio clocks in the same geographical area deja-vued all over again, since both our WWVB and WWV clocks got lobotomized and only the FORDnet GOES clock in Dearborn, MI, saved our timekeeping souls, and that only after manual intervention. I once again apologize for all those errant DCN1 timestamps our comrades use to stamp their files, bombs and bills. If you believe a protocol similar to the one I proposed in my recent message and document will cure what hurts, please send comments, advice or money. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509120331.AA04231%40UCB-VAX.ARPA] <1985091118165600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: walsh@BBN-LABS-B.ARPA (Bob Walsh) Newsgroups: fa.tcp-ip Subject: re: BBN networking code in 4.3BSD Message-ID: <8509120331.AA04231@UCB-VAX.ARPA> Date: Wed, 11-Sep-85 22:16:56 EDT Article-I.D.: UCB-VAX.8509120331.AA04231 Posted: Wed Sep 11 22:16:56 1985 Date-Received: Thu, 12-Sep-85 11:37:09 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 64 > From: mckusick@ucbvax.ARPA (Kirk Mckusick) > Subject: Status of 4.3BSD > Date: 6 Sep 85 00:23:29 GMT > Keywords: 4.3BSD > To: unix-wizards@brl-tgr.arpa > > At the June Usenix conference we announced that we expected to begin > shipping production 4.3BSD systems in mid to late August. Two weeks > after the Usenix meeting we shipped what we then thought was our beta > distribution tape. The following week our primary funding agency, DARPA, > informed us that we were required to replace our version of TCP/IP > with that supplied by BBN. After a great deal of discussion, we > agreed to include both implementations and let individual sites > choose which version they wanted to configure their kernels to use. > BBN delivered their implementation to us on August 30th. We must now > put together another beta tape with the new kernel and restart the > beta testing (in particular we must give BBN time to work on their > networking code, as it does not interface to many of the utilities). > Assuming that we are not required to make any further changes to the > distribution, we now anticipate that full distribution will begin > before the end of the year. ... > Kirk McKusick > CSRG ? work on the networking code and interface it to utilities? The BBN code for 4.2 UNIX could almost be dropped right in. The exceptional programs were those that knew about implementation specific information (/etc/route because the ioctl to install a route encoded the size of a routing structure and the routing structure was augmented with additional information, netstat so that it could interpret protocol connection state data structures...) Standard utilities like rwho, ftp, telnet, rlogin... required neither change nor recompilation. With the 4.3 distribution, I modified netstat to be smart enough to determine which implementation was in use and to examine the state information accordingly. Programs like route that know about kernel data structures are being distributed knowing about data structure definitions that meet both implementation's requirements. So, with 4.3 BSD one could switch back and forth at will by just changing a line in the system configuration. If I am wrong, please correct me and let the people at BBN know. Though I am entering graduate school this fall, I will be reading my mail and advising Karen Lam, my successor at BBN. For system managers, I should say that the two systems do provide networking support within UNIX. Both 4.3 systems work well. One can succesfully telnet, ftp, rcp, rsh, and all the rest. Many sites will not notice which they run. The goal is to support those sites which would notice. One should not have the impression that this code is wet behind the ears, though parts of it are new. When Berkeley distributed 4.1BSD, one could get a networking tape from BBN and provide themselves with a networking system. The BBN 4.2 code was not widely distributed because BBN did not want to get into the UNIX license verification business. However, it was used at Internet sites that required some of its extra functionality and more reliable performance over SATNET. Though similar in that they provide a transport layer, they do not always share the same algorithms or external properties. But that is a topic for a longer message. bob walsh ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091118165601> Received: from BBN-LABS-B.ARPA by SRI-NIC.ARPA with TCP; Wed 11 Sep 85 19:20:08-PDT Date: Wed, 11 Sep 85 22:16:56 EDT From: Bob Walsh To: unix-wizards@brl-tgr.ARPA cc: tcp-ip@sri-nic.ARPA, gurwitz@BBN-LABS-B.ARPA, lam@BBN-LABS-B.ARPA Subject: re: BBN networking code in 4.3BSD > From: mckusick@ucbvax.ARPA (Kirk Mckusick) > Subject: Status of 4.3BSD > Date: 6 Sep 85 00:23:29 GMT > Keywords: 4.3BSD > To: unix-wizards@brl-tgr.arpa > > At the June Usenix conference we announced that we expected to begin > shipping production 4.3BSD systems in mid to late August. Two weeks > after the Usenix meeting we shipped what we then thought was our beta > distribution tape. The following week our primary funding agency, DARPA, > informed us that we were required to replace our version of TCP/IP > with that supplied by BBN. After a great deal of discussion, we > agreed to include both implementations and let individual sites > choose which version they wanted to configure their kernels to use. > BBN delivered their implementation to us on August 30th. We must now > put together another beta tape with the new kernel and restart the > beta testing (in particular we must give BBN time to work on their > networking code, as it does not interface to many of the utilities). > Assuming that we are not required to make any further changes to the > distribution, we now anticipate that full distribution will begin > before the end of the year. ... > Kirk McKusick > CSRG ? work on the networking code and interface it to utilities? The BBN code for 4.2 UNIX could almost be dropped right in. The exceptional programs were those that knew about implementation specific information (/etc/route because the ioctl to install a route encoded the size of a routing structure and the routing structure was augmented with additional information, netstat so that it could interpret protocol connection state data structures...) Standard utilities like rwho, ftp, telnet, rlogin... required neither change nor recompilation. With the 4.3 distribution, I modified netstat to be smart enough to determine which implementation was in use and to examine the state information accordingly. Programs like route that know about kernel data structures are being distributed knowing about data structure definitions that meet both implementation's requirements. So, with 4.3 BSD one could switch back and forth at will by just changing a line in the system configuration. If I am wrong, please correct me and let the people at BBN know. Though I am entering graduate school this fall, I will be reading my mail and advising Karen Lam, my successor at BBN. For system managers, I should say that the two systems do provide networking support within UNIX. Both 4.3 systems work well. One can succesfully telnet, ftp, rcp, rsh, and all the rest. Many sites will not notice which they run. The goal is to support those sites which would notice. One should not have the impression that this code is wet behind the ears, though parts of it are new. When Berkeley distributed 4.1BSD, one could get a networking tape from BBN and provide themselves with a networking system. The BBN 4.2 code was not widely distributed because BBN did not want to get into the UNIX license verification business. However, it was used at Internet sites that required some of its extra functionality and more reliable performance over SATNET. Though similar in that they provide a transport layer, they do not always share the same algorithms or external properties. But that is a topic for a longer message. bob walsh ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091307460000> Received: from STL-HOST1.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Sep 85 10:47:25-PDT Date: 13 Sep 1985 12:46-CDT Sender: SNELSON@STL-HOST1.ARPA Subject: FIBER INSTEAD OF COAX From: SNELSON@STL-HOST1.ARPA To: TCP-IP@SRI-NIC.ARPA Message-ID: <[STL-HOST1.ARPA]13-Sep-85 12:46:41.SNELSON> IS ANYONE AWARE OF A FIBER OPTIC CABLE REPLACEMENT FOR COAX FROM AND IBM 3274 TYPE CONTROLLER TO A DISPLAY STATION AND/OR PRINTER? STEVE ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091309303900> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Sep 85 16:34:27-PDT Date: 13 Sep 1985 16:30:39 PDT From: POSTEL@USC-ISIB.ARPA Subject: re: Class B networks vs. Class C networks To: TCP-IP@SRI-NIC.ARPA Jon Solomon: Please consider the subnetting procedure described in RFC 950. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091310560000> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Sep 85 14:20:03-PDT Received: from bostonu by csnet-relay.csnet id ak20384; 13 Sep 85 16:50 EDT Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7) id AA23491; Fri, 13 Sep 85 14:58:13 edt Date: Fri, 13 Sep 1985 14:56 EDT Message-Id: <[BUCS20].JSOL.13-Sep-85 14:56:16> From: Jon Solomon To: tcp-ip@sri-nic.csnet Subject: Class B networks Vs. Class C networks Phase-Of-The-Moon: LQ+6D.21H.16M.3S. We are about to ask for our first network number(s) here at BU. We have a couple of questions that have been touched upon in this list and perhaps one that hasn't been touched upon. We currently have an Ethernet and a BroadBand network. Will a class B network traverse both of these networks? What additional hardware do we need to purchase to make this a reality? Currently we use one (or two) of our timesharing machines to gateway between two (imaginary -- made up) class A networks, one for the broadband net and one for the ethernet. Can we continue to use this configuration? Will UNIX, TOPS-20, and VMS stand being dually homed on the same network (but different subnets)? One thought just occurred. Can we treat our class B network (if we ask for one) as separate class-C networks and use the unix systems as gateways? Given the growth in computing at BU, I am strongly in favor of a class B network. Is this possible in our situation? Intuitively I think this could work. Practically -- has anyone used similar configurations??? Cheers, --JSol ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509140043.AA07658%40UCB-VAX.ARPA] <1985091315303900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: POSTEL@USC-ISIB.ARPA Newsgroups: fa.tcp-ip Subject: re: Class B networks vs. Class C networks Message-ID: <8509140043.AA07658@UCB-VAX.ARPA> Date: Fri, 13-Sep-85 19:30:39 EDT Article-I.D.: UCB-VAX.8509140043.AA07658 Posted: Fri Sep 13 19:30:39 1985 Date-Received: Sat, 14-Sep-85 08:16:40 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 7 Jon Solomon: Please consider the subnetting procedure described in RFC 950. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091601542600> Received: from ALMSA-1 by SRI-NIC.ARPA with TCP; Mon 16 Sep 85 16:36:36-PDT Received: by ALMSA-1 via avd; 16 Sep 85 9:04 CDT Date: 16 Sep 85 6:54:26-CDT (Mon) From: Morence@Avd-Plexus01 To: tcp-ip@Sri-Nic Subject: [Morence: MY MAILBOX] ----- Forwarded message # 1: Received: by ALMSA-1 via avd; 13 Sep 85 13:02 CDT Date: 13 Sep 85 12:57:59-CDT (Fri) From: Morence@Avd-Plexus01 To: tcp.ip@Sri-Nic cc: morence@ALMSA-1 Subject: MY MAILBOX Via: ALMSA-1; 13 Sep 85 14:36-EDT To whom it may concern: My mailbox: MORENCE at ALMSA-1 is back in business. ALMSA-1 will pass my mail to AVD-PLEXUS01 which will deliver it to me. Regards, Jerry ----- End of forwarded messages ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509170044.AA01234%40UCB-VAX.ARPA] <1985091603542600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: Morence@AVD-PLEXUS01 Newsgroups: fa.tcp-ip Subject: [Morence: MY MAILBOX] Message-ID: <8509170044.AA01234@UCB-VAX.ARPA> Date: Mon, 16-Sep-85 07:54:26 EDT Article-I.D.: UCB-VAX.8509170044.AA01234 Posted: Mon Sep 16 07:54:26 1985 Date-Received: Wed, 18-Sep-85 03:09:51 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 21 ----- Forwarded message # 1: Received: by ALMSA-1 via avd; 13 Sep 85 13:02 CDT Date: 13 Sep 85 12:57:59-CDT (Fri) From: Morence@Avd-Plexus01 To: tcp.ip@Sri-Nic cc: morence@ALMSA-1 Subject: MY MAILBOX Via: ALMSA-1; 13 Sep 85 14:36-EDT To whom it may concern: My mailbox: MORENCE at ALMSA-1 is back in business. ALMSA-1 will pass my mail to AVD-PLEXUS01 which will deliver it to me. Regards, Jerry ----- End of forwarded messages ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091610260000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Mon 16 Sep 85 18:28:09-PDT Date: 16 Sep 1985 18:26 PST From: Art Berggreen Subject: ACC IF-11/HDH To: tcp-ip@sri-nic Reply-To: ART@ACC.ARPA Anyone running an ACC IF-11/HDH interface under BSD UNIX or VMS using TWG software should make sure that they are running version 1.2 of the HDH firmware on the boards. A few recent boards may have been shipped with an older version. "Art Berggreen" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509182342.AA06166%40UCB-VAX.ARPA] <1985091618260000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: ART@ACC.ARPA (Art Berggreen) Newsgroups: fa.tcp-ip Subject: ACC IF-11/HDH Message-ID: <8509182342.AA06166@UCB-VAX.ARPA> Date: Mon, 16-Sep-85 22:26:00 EDT Article-I.D.: UCB-VAX.8509182342.AA06166 Posted: Mon Sep 16 22:26:00 1985 Date-Received: Fri, 20-Sep-85 03:45:29 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 9 Anyone running an ACC IF-11/HDH interface under BSD UNIX or VMS using TWG software should make sure that they are running version 1.2 of the HDH firmware on the boards. A few recent boards may have been shipped with an older version. "Art Berggreen" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509170824.AA13758%40lll-crg.ARPA] <1985091700244200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: matt@LLL-CRG.ARPA (Matt Thomas) Newsgroups: fa.tcp-ip Subject: ARP & IP and numbers Message-ID: <8509170824.AA13758@lll-crg.ARPA> Date: Tue, 17-Sep-85 04:24:42 EDT Article-I.D.: lll-crg.8509170824.AA13758 Posted: Tue Sep 17 04:24:42 1985 Date-Received: Fri, 20-Sep-85 05:17:49 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 7 Does anybody know the protocol number and multicast address for the Address Resolution Protocol (RFC826) on Ethernet? Also which protocol number is used for transmitting IP datagrams over Ethernets? Thanks in advance matt thomas ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091706033900> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 17 Sep 85 13:05:33-PDT Date: 17 Sep 1985 13:03:39 PDT From: POSTEL@USC-ISIB.ARPA Subject: re: ARP & IP anf numbers To: TCP-IP@SRI-NIC.ARPA Matt Thomas: Please see page 22 of the current Assigned Numbers document (RFC-943). ARP is 2054 (0806 hex), IP is 2048 (0800 hex). --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509171949.AA29970%40hao.NCAR] <1985091711494500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: dougm@ico.UUCP Newsgroups: fa.tcp-ip Subject: X.25 board driver wanted Message-ID: <8509171949.AA29970@hao.NCAR> Date: Tue, 17-Sep-85 15:49:45 EDT Article-I.D.: hao.8509171949.AA29970 Posted: Tue Sep 17 15:49:45 1985 Date-Received: Thu, 19-Sep-85 06:55:59 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 9 I am in need of a driver for an ACC UMC X.25 controller for 4.2BSD UNIX or Ultrix. I would like to be able to use it as an interface to TCP/IP as well as a normal X.25 connection to Telenet. The board I have is actually an Interactive Systems INcard version of the ACC controller if that matters. Does anyone have or know of one and it's availability? Thanks, Doug McCallum ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509182344.AA06237%40UCB-VAX.ARPA] <1985091712033900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: POSTEL@USC-ISIB.ARPA Newsgroups: fa.tcp-ip Subject: re: ARP & IP anf numbers Message-ID: <8509182344.AA06237@UCB-VAX.ARPA> Date: Tue, 17-Sep-85 16:03:39 EDT Article-I.D.: UCB-VAX.8509182344.AA06237 Posted: Tue Sep 17 16:03:39 1985 Date-Received: Fri, 20-Sep-85 03:45:42 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 8 Matt Thomas: Please see page 22 of the current Assigned Numbers document (RFC-943). ARP is 2054 (0806 hex), IP is 2048 (0800 hex). --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091800310000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Wed 18 Sep 85 08:41:28-PDT Date: 18 Sep 1985 08:31 PST From: Gary Krall Subject: X.25 drivers To: TCP-IP@SRI-NIC Reply-To: GARY@ACC.ARPA ACC has a device driver for its ACP 625 X.25 interface card which will run under Ultrix and 4.2 and will interface to IP. However, this interface currently only supports DDN related applications. Some folks at CSnet are looking at making the driver more general purpose to allow it to run over PDN's (see rfc877 and Douglas Comer and John Korb's paper entitled: "CSnet Protocol Software: The IP-to-X.25 Interface") and use IP services. This implementation will be posted to this net when available. Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509182348.AA06328%40UCB-VAX.ARPA] <1985091803532900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: ddaly%xls-plexus01.amc@AMC-HQ.ARPA (DUSTY) Newsgroups: fa.tcp-ip Subject: name removal Message-ID: <8509182348.AA06328@UCB-VAX.ARPA> Date: Wed, 18-Sep-85 07:53:29 EDT Article-I.D.: UCB-VAX.8509182348.AA06328 Posted: Wed Sep 18 07:53:29 1985 Date-Received: Fri, 20-Sep-85 04:47:08 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 4 Please remove the following name from your mailing list as my activity already receives several copies. ddaly at amc-hq ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091803532901> Received: from AMC-HQ by SRI-NIC.ARPA with TCP; Wed 18 Sep 85 05:48:26-PDT Received: by AMC-HQ via hq1; 18 Sep 85 8:33 EDT Date: 18 Sep 85 7:53:29-EDT (Wed) From: DUSTY To: info-unix%brl.arpa@AMC-HQ.ARPA, tcp-ip%sri-nic.arpa@AMC-HQ.ARPA Subject: name removal Via: xls-plexus02; 18 Sep 85 7:59-EDT Via: xls-plexus01; 18 Sep 85 8:12-EDT Please remove the following name from your mailing list as my activity already receives several copies. ddaly at amc-hq ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091804433200> Received: from su-shasta.arpa by SRI-NIC.ARPA with TCP; Wed 25 Sep 85 10:01:19-PDT Received: by su-shasta.arpa with TCP; Wed, 25 Sep 85 10:00:27 pdt Received: by imagen.UUCP; Wed, 18 Sep 85 11:44:05 pdt To: Matt Thomas Cc: shasta!tcp-ip@sri-nic Reply-To: imagen!geof@shasta Phone: (408) 986-9400 (work) Postal-Address: IMAGEN, 2650 San Thomas Expressway, Santa Clara, CA 95052 Subject: Re: ARP & IP and numbers In-Reply-To: Your message of Tue, 17 Sep 85 01:24:42 pdt. <8509170824.AA13758@lll-crg.ARPA> Date: 18 Sep 85 11:43:32 PDT (Wed) From: Geoffrey H. Cooper ARP's Ethernet number is 0x806 (806 hex). 2054 for you decimal fans. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091806150000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Wed 18 Sep 85 14:19:28-PDT Date: 18 Sep 1985 14:15 PST From: Gary Krall Subject: a footnote To: TCP-IP@SRI-NIC Reply-To: GARY@ACC.ARPA The INcard from Interactive Systems uses the same hardware (ie the UMC) however it is an entirely different set of firmware and host interface. It is not a easy matter to use ACC's firmware on the INcard. The recommendation would be to monitor the CSnet work for standard ip-x25 on PDN's or if your requirement is for DDN contact me as we have a solution today. Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509182351.AA06410%40UCB-VAX.ARPA] <1985091808310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: GARY@ACC.ARPA (Gary Krall) Newsgroups: fa.tcp-ip Subject: X.25 drivers Message-ID: <8509182351.AA06410@UCB-VAX.ARPA> Date: Wed, 18-Sep-85 12:31:00 EDT Article-I.D.: UCB-VAX.8509182351.AA06410 Posted: Wed Sep 18 12:31:00 1985 Date-Received: Fri, 20-Sep-85 04:47:48 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 13 ACC has a device driver for its ACP 625 X.25 interface card which will run under Ultrix and 4.2 and will interface to IP. However, this interface currently only supports DDN related applications. Some folks at CSnet are looking at making the driver more general purpose to allow it to run over PDN's (see rfc877 and Douglas Comer and John Korb's paper entitled: "CSnet Protocol Software: The IP-to-X.25 Interface") and use IP services. This implementation will be posted to this net when available. Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509181905.AA00608%40UCB-VAX.ARPA] <1985091809345600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: ron@BRL.ARPA (Ron Natalie) Newsgroups: fa.tcp-ip Subject: Re: X.25 board driver wanted Message-ID: <8509181905.AA00608@UCB-VAX.ARPA> Date: Wed, 18-Sep-85 13:34:56 EDT Article-I.D.: UCB-VAX.8509181905.AA00608 Posted: Wed Sep 18 13:34:56 1985 Date-Received: Thu, 19-Sep-85 07:14:11 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 6 Cough, if that is the same version of the board we have, it is utterly unusable on a macne with a UNIBUS map such as a VAX or an 11/44 or 70. Your best bet would be to inquire of ACC of new firmware for the card. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091809345601> Received: from BRL-TGR.ARPA by SRI-NIC.ARPA with TCP; Wed 18 Sep 85 10:40:46-PDT Date: Wed, 18 Sep 85 13:34:56 EDT From: Ron Natalie To: Doug McCallum cc: TCP-IP@SRI-NIC.ARPA Subject: Re: X.25 board driver wanted Cough, if that is the same version of the board we have, it is utterly unusable on a macne with a UNIBUS map such as a VAX or an 11/44 or 70. Your best bet would be to inquire of ACC of new firmware for the card. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509182009.AB00592%40UCB-VAX.ARPA] <1985091810033600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: sdyer@BBNCC5.ARPA Newsgroups: fa.tcp-ip Subject: Re: X.25 board driver wanted Message-ID: <8509182009.AB00592@UCB-VAX.ARPA> Date: Wed, 18-Sep-85 14:03:36 EDT Article-I.D.: UCB-VAX.8509182009.AB00592 Posted: Wed Sep 18 14:03:36 1985 Date-Received: Fri, 20-Sep-85 05:01:01 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 3 The INCard (ACC's UMC-Z80 with Interactive firmware) works fine on VAXes, as evidenced by its recommendation by CSNET to connect VAXes together over Telenet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509252049.AA03599%40UCB-VAX.ARPA] <1985091810433200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: geof@imagen.UUCP Newsgroups: fa.tcp-ip Subject: Re: ARP & IP and numbers Message-ID: <8509252049.AA03599@UCB-VAX.ARPA> Date: Wed, 18-Sep-85 14:43:32 EDT Article-I.D.: UCB-VAX.8509252049.AA03599 Posted: Wed Sep 18 14:43:32 1985 Date-Received: Fri, 27-Sep-85 03:55:33 EDT References: <8509170824.AA13758@lll-crg.ARPA> Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 4 ARP's Ethernet number is 0x806 (806 hex). 2054 for you decimal fans. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509182323.AA05605%40UCB-VAX.ARPA] <1985091813583700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: ron@BRL.ARPA (Ron Natalie) Newsgroups: fa.tcp-ip Subject: Re: X.25 board driver wanted Message-ID: <8509182323.AA05605@UCB-VAX.ARPA> Date: Wed, 18-Sep-85 17:58:37 EDT Article-I.D.: UCB-VAX.8509182323.AA05605 Posted: Wed Sep 18 17:58:37 1985 Date-Received: Thu, 19-Sep-85 06:58:47 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 6 Either the INCard has different firmware other than the MCX that came with ours, or you use only a very small number of logical channels. Our board is such that each logical channel burns a mapping register in each direction. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985091813583701> Received: from BRL-TGR.ARPA by SRI-NIC.ARPA with TCP; Wed 18 Sep 85 15:07:06-PDT Date: Wed, 18 Sep 85 17:58:37 EDT From: Ron Natalie To: sdyer@BBNCC5.ARPA cc: Ron Natalie , Doug McCallum , TCP-IP@SRI-NIC.ARPA Subject: Re: X.25 board driver wanted Either the INCard has different firmware other than the MCX that came with ours, or you use only a very small number of logical channels. Our board is such that each logical channel burns a mapping register in each direction. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509190013.AA06811%40UCB-VAX.ARPA] <1985091814150000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: GARY@ACC.ARPA (Gary Krall) Newsgroups: fa.tcp-ip Subject: a footnote Message-ID: <8509190013.AA06811@UCB-VAX.ARPA> Date: Wed, 18-Sep-85 18:15:00 EDT Article-I.D.: UCB-VAX.8509190013.AA06811 Posted: Wed Sep 18 18:15:00 1985 Date-Received: Fri, 20-Sep-85 03:45:56 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 10 The INcard from Interactive Systems uses the same hardware (ie the UMC) however it is an entirely different set of firmware and host interface. It is not a easy matter to use ACC's firmware on the INcard. The recommendation would be to monitor the CSnet work for standard ip-x25 on PDN's or if your requirement is for DDN contact me as we have a solution today. Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509202015.AA04680%40hao.NCAR] <1985092012155200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: dougm@ico.UUCP Newsgroups: fa.tcp-ip Subject: Re: x.25 board driver wanted Message-ID: <8509202015.AA04680@hao.NCAR> Date: Fri, 20-Sep-85 16:15:52 EDT Article-I.D.: hao.8509202015.AA04680 Posted: Fri Sep 20 16:15:52 1985 Date-Received: Sun, 22-Sep-85 05:40:21 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 6 I want to thank everyone for their input. I got the answer I expected. CSNET has a driver for the Interactive INcard for 4.2 BSD for CSNET members. Unfortunately we are not a CSNET member. Thanks anyway Doug McCallum ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985092108111700> Received: from Dewey.UDEL.EDU by SRI-NIC.ARPA with TCP; Mon 23 Sep 85 07:02:11-PDT Date: Sat, 21 Sep 85 12:11:17 EDT From: Boots Cassel To: tcp-ip@dewey.udel.EDU cc: cassel@dewey.udel.EDU Subject: bibliography I am compiling an annotated bibliography in the general area of local area networks, with some concentration on measurement and evaluation. Any suggestions as to material others have found useful would be gratefully received. I would be glad to hear from anyone interested in seeing the results of the effort also. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985092311441500> Received: from DEC-MARLBORO.ARPA by SRI-NIC.ARPA with TCP; Mon 23 Sep 85 12:48:19-PDT Date: Mon 23 Sep 85 15:44:15-EDT From: Kevin Paetzold Subject: NRC Fusion Code To: tcp-ip@SRI-NIC.ARPA Has anyone out there had experience with the TCP/IP software provided by Network Research Corporation. It is called Fusion and runs uner VAX/VMS, Unix, MSDOS (and I believe the Execlan board). I am interested in its size requirements, performance characteristics, how many bugs, etc... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509240611.AA00539%40orion.ARPA] <1985092322111000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: medin@ORION.ARPA (Milo Medin, NASA ARC Code EDN Advanced Systems Group) Newsgroups: fa.tcp-ip Subject: Re: NRC Fusion Code Message-ID: <8509240611.AA00539@orion.ARPA> Date: Tue, 24-Sep-85 02:11:10 EDT Article-I.D.: orion.8509240611.AA00539 Posted: Tue Sep 24 02:11:10 1985 Date-Received: Thu, 26-Sep-85 06:41:35 EDT References: <8509232215.AA10653@ucbarpa.ARPA> Sender: usenet@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 8 I have heard from several people here at NASA that its pure junk, that it doesnt do what its designed to do, and that they make lots of promises they cant keep. All parties concerned are in the process of trying to get their money back. The product involved here was the VAX/VMS stuff, and XENIX for the 68000 boxes... Milo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509241520.AA04530%40nprdc.arpa] <1985092407160000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: stanonik@NPRDC.ARPA (Ron Stanonik) Newsgroups: fa.tcp-ip Subject: serial line (rick@seismo) ip fix Message-ID: <8509241520.AA04530@nprdc.arpa> Date: Tue, 24-Sep-85 11:16:00 EDT Article-I.D.: nprdc.8509241520.AA04530 Posted: Tue Sep 24 11:16:00 1985 Date-Received: Thu, 26-Sep-85 08:20:15 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 145 We encountered a situation where serial line ip code (from rick@seismo) would crash our system (vax 780 running 4.2bsd). Due to some changes in the host at the other end of the line (and perhaps aided by some noise on the line), we began receiving characters, but no FRAME_END. The slip code exhausted the pool of mbufs by allocating them all for the incoming characters, and we crashed, twice a day. We finally tracked down the problem on the other host, but to protect ourselves we now drop packets whose length exceeds SLMTU (1500). Ron Stanonik stanonik@nprdc.arpa RCS file: RCS/if_sl.c,v retrieving revision 1.1 diff -c -r1.1 if_sl.c *** /tmp/,RCSt1004251 Tue Sep 24 07:43:02 1985 --- if_sl.c Tue Sep 24 07:41:03 1985 *************** *** 53,58 struct tty *sc_ttyp; /* pointer to tty structure */ int sc_ttyspeed; /* baud rate of line */ int sc_len; /* length of buffer remaining */ struct mbuf *sc_m; /* head of mbuf chain */ struct mbuf *sc_mt; /* tail of mbuf chain */ u_char *sc_mp; /* pointer to next available buffer char */ --- 53,59 ----- struct tty *sc_ttyp; /* pointer to tty structure */ int sc_ttyspeed; /* baud rate of line */ int sc_len; /* length of buffer remaining */ + int sc_plen; /* packet length, <= SLMTU */ struct mbuf *sc_m; /* head of mbuf chain */ struct mbuf *sc_mt; /* tail of mbuf chain */ u_char *sc_mp; /* pointer to next available buffer char */ *************** *** 63,69 #define TRANS_FRAME_END 0334 /* transposed frame end */ #define TRANS_FRAME_ESCAPE 0335 /* transposed frame esc */ ! #define SLTU 1500 int sloutput(), slioctl(); --- 64,70 ----- #define TRANS_FRAME_END 0334 /* transposed frame end */ #define TRANS_FRAME_ESCAPE 0335 /* transposed frame esc */ ! #define SLMTU 1500 int sloutput(), slioctl(); *************** *** 105,111 sc->sc_ttyp = tp; sc->sc_if.if_unit = nsl; sc->sc_if.if_name = "sl"; ! sc->sc_if.if_mtu = SLTU; sc->sc_if.if_output = sloutput; sc->sc_if.if_ioctl = slioctl; sc->sc_if.if_flags = IFF_POINTOPOINT; --- 106,112 ----- sc->sc_ttyp = tp; sc->sc_if.if_unit = nsl; sc->sc_if.if_name = "sl"; ! sc->sc_if.if_mtu = SLMTU; sc->sc_if.if_output = sloutput; sc->sc_if.if_ioctl = slioctl; sc->sc_if.if_flags = IFF_POINTOPOINT; *************** *** 284,289 splx(s); sc->sc_mt = 0; sc->sc_len = 0; return; case FRAME_ESCAPE: sc->sc_escaped = 1; --- 285,291 ----- splx(s); sc->sc_mt = 0; sc->sc_len = 0; + sc->sc_plen = 0; return; case FRAME_ESCAPE: sc->sc_escaped = 1; *************** *** 290,295 return; } } if (sc->sc_len <= 0){ /* have to get more buffer space */ struct mbuf *mm; MGET(mm,M_DONTWAIT, MT_DATA); --- 292,305 ----- return; } } + if (sc->sc_plen >= SLMTU) { + m_freem(sc->sc_m); + sc->sc_mt = 0; + sc->sc_len = 0; + sc->sc_plen = 0; + sc->sc_if.if_ierrors++; + return; + } if (sc->sc_len <= 0){ /* have to get more buffer space */ struct mbuf *mm; MGET(mm,M_DONTWAIT, MT_DATA); *************** *** 297,302 m_freem(sc->sc_m); sc->sc_mt = 0; sc->sc_len = 0; sc->sc_if.if_collisions++; return; } --- 307,313 ----- m_freem(sc->sc_m); sc->sc_mt = 0; sc->sc_len = 0; + sc->sc_plen = 0; sc->sc_if.if_collisions++; return; } *************** *** 312,317 *sc->sc_mp++ = c; sc->sc_len--; } /* --- 323,329 ----- *sc->sc_mp++ = c; sc->sc_len--; + sc->sc_plen++; } /* ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509272052.AA17921%40UCB-VAX.ARPA] <1985092712182200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: fa.tcp-ip Subject: are you having trouble reaching Rutgers? Message-ID: <8509272052.AA17921@UCB-VAX.ARPA> Date: Fri, 27-Sep-85 16:18:22 EDT Article-I.D.: UCB-VAX.8509272052.AA17921 Posted: Fri Sep 27 16:18:22 1985 Date-Received: Sat, 28-Sep-85 08:45:22 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 7 Our Arpanet gateway shows that a number of sites still haven't caught up to the Internet address changes at Rutgers. These were done about a month ago. RED.RUTGERS.EDU, alias RUTGERS.ARPA, is now 128.6.4.2. You can no longer reach us at 10.1.0.89. That is now the address of ARPA-GW.RUTGERS.EDU, which is our gateway from 128.6 into the Arpanet. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985092712182201> Received: from RED.RUTGERS.EDU by SRI-NIC.ARPA with TCP; Fri 27 Sep 85 13:48:41-PDT Date: 27 Sep 85 16:18:22 EDT From: Charles Hedrick Subject: are you having trouble reaching Rutgers? To: tcp-ip@SRI-NIC.ARPA Our Arpanet gateway shows that a number of sites still haven't caught up to the Internet address changes at Rutgers. These were done about a month ago. RED.RUTGERS.EDU, alias RUTGERS.ARPA, is now 128.6.4.2. You can no longer reach us at 10.1.0.89. That is now the address of ARPA-GW.RUTGERS.EDU, which is our gateway from 128.6 into the Arpanet. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISI.ARPA%5D28-Sep-85.22:54:20.JRBRINKEMA] <1985092818540000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: JRBRINKEMA@USC-ISI.ARPA Newsgroups: fa.tcp-ip Subject: Implementation of tcp-ip on IBM-PC Wanted Message-ID: <[USC-ISI.ARPA]28-Sep-85.22:54:20.JRBRINKEMA> Date: Sat, 28-Sep-85 22:54:00 EDT Article-I.D.: <[USC-ISI.ARPA]28-Sep-85.22:54:20.JRBRINKEMA> Posted: Sat Sep 28 22:54:00 1985 Date-Received: Mon, 30-Sep-85 01:25:46 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 5 Would someone please give me a pointer to the public-domain implementation of a tcp-ip (ala UNIX 4.2) that was done by someone at MIT. (these specs subject to a fuzzy memory). Please respond directly; I'm not a regular tcp-ip reader. tia: John R. Brinkema. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509300242.AA22766%40UCB-VAX.ARPA] <1985092917202100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: fa.tcp-ip Subject: problems getting to CISL-SERVICE-MULTICS Message-ID: <8509300242.AA22766@UCB-VAX.ARPA> Date: Sun, 29-Sep-85 21:20:21 EDT Article-I.D.: UCB-VAX.8509300242.AA22766 Posted: Sun Sep 29 21:20:21 1985 Date-Received: Tue, 1-Oct-85 03:21:50 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 20 We can't seem to get CISL-SERVICE-MULTICS to accept our mail. We can normally send very short messages, but for anything substantial, the connection times out. This is a fairly new problem. We just changed our network configuration. Our DEC-20 used to be directly on the Arpanet. It is now on an Ethernet, and we are using a PDP-11/23 gateway, with the MIT code, further hacked and supported by Noel Chiappa. The major difference here is that we now have an MTU of 1500 instead of 9xx. The gateway is supposed to do fragmentation and reassembly. We wonder whether either the gateway or CISL is blowing it. Maybe some others of you can help us in this diagnosis by indicating whether you are having similar problems. Here is what we see: - we can get to MIT-MULTICS. They are running the same SMTP but a different TCP from CISL - we have the same problem from Topaz, our major Unix system, so it isn't TOPS-20 specific Are other folks having trouble getting long mail items to CISL-SERVICE-MULTICS? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985092917202101> Received: from RED.RUTGERS.EDU by SRI-NIC.ARPA with TCP; Sun 29 Sep 85 18:19:55-PDT Date: 29 Sep 85 21:20:21 EDT From: Charles Hedrick Subject: problems getting to CISL-SERVICE-MULTICS To: tcp-ip@SRI-NIC.ARPA We can't seem to get CISL-SERVICE-MULTICS to accept our mail. We can normally send very short messages, but for anything substantial, the connection times out. This is a fairly new problem. We just changed our network configuration. Our DEC-20 used to be directly on the Arpanet. It is now on an Ethernet, and we are using a PDP-11/23 gateway, with the MIT code, further hacked and supported by Noel Chiappa. The major difference here is that we now have an MTU of 1500 instead of 9xx. The gateway is supposed to do fragmentation and reassembly. We wonder whether either the gateway or CISL is blowing it. Maybe some others of you can help us in this diagnosis by indicating whether you are having similar problems. Here is what we see: - we can get to MIT-MULTICS. They are running the same SMTP but a different TCP from CISL - we have the same problem from Topaz, our major Unix system, so it isn't TOPS-20 specific Are other folks having trouble getting long mail items to CISL-SERVICE-MULTICS? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8509300400.AA02010%40MIT-BITSY.MIT.EDU] <1985092920002500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: jis@MIT-BITSY.MIT.EDU (Jeffrey I. Schiller) Newsgroups: fa.tcp-ip Subject: problems getting to CISL-SERVICE-MULTICS Message-ID: <8509300400.AA02010@MIT-BITSY.MIT.EDU> Date: Mon, 30-Sep-85 00:00:25 EDT Article-I.D.: MIT-BITS.8509300400.AA02010 Posted: Mon Sep 30 00:00:25 1985 Date-Received: Tue, 1-Oct-85 03:26:17 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 16 Actually the situation with CISL-SERVICE-MULTICS is more complicated then that. CISL is running an IP/TCP which doesn't understand about any other network but net 10 (The ArpaNet). There is a kludge installed in its IP that sends any non-net-10 packet to MIT-MULTICS who then routes it apropriately. Now MIT-MULTICS is constrainted to not send packets greater then 200 bytes (because if it does, the IMP it is plugged into crashes... a problem (unresolved now for over two years) with message mode HDH support in the IMP). So chances are now that CISL is sending you 572 byte packets which are being fragmented by MIT-MULTICS. It is quite possible that either your reassembly code is bad or MIT-MULTICS's fragmentation code is bad (MIT-MULTICS's TCP arranges never to send segments that would be fragmented by the IP layer). Some IP tracing would probably help. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985093005360000> Received: from BBNA.ARPA by SRI-NIC.ARPA with TCP; Mon 30 Sep 85 06:37:26-PDT Date: 30 Sep 1985 09:36-EDT Sender: CLYNN@BBNA.ARPA Subject: Re: problems getting to CISL-SERVICE-MULTICS From: CLYNN@BBNA.ARPA To: HEDRICK@RED.RUTGERS.EDU Cc: tcp-ip@SRI-NIC.ARPA Cc: CLynn@BBNA.ARPA Message-ID: <[BBNA.ARPA]30-Sep-85 09:36:43.CLYNN> In-Reply-To: The message of 29 Sep 85 21:20:21 EDT from Charles Hedrick Welcome to the world of gsteways. I have observed problems with the same symptoms. They resulted from a combination of two factors. One, you are not getting any flow control; the imps are very good at not accepting more data than they can handle. (Are you getting any ICMP Source Quench messages from the gateway? What does your TCP do with them?) Several TCPs run in bang-bang mode: sending everything they can until they either run out of data or fill the window. Going from an ethernet to an 1822 net with such an implementation is bound to flood the gateway (which has to process packets from all the TCP connections as well as any UDP traffic). The second factor which I have observed relates to fragmentation. Most fragmentation algorithms split a single packet into two or more fragments and queue them sequentially for the output interface. This increases the number of packets for a particular destination by at least a factor of two. 1822 nets have limits on the number of packets for an 1822 connection. The fragments cause this limit to be reached more quickly. Also, some receivers do not seem to be capable of receiving back-to-back packets, which frequently result from fragmented packets. Note that in such a situation no amount of TCP retransmissions will ever get the fragmented packet through. What can you do? Are the TCPs exchanging maximum segment size options? If you are not receiving any, your maximum packet size should be 576, so fragmentation should not be needed. The option works well if one of the hosts is on the network with the minimum MTU. Does TCP get information from IP about the size of the maximum IP packet received; it is a useful "hint" about the MTU of intermediate networks. Make sure that ICMP source quench messages are being processed. Consider algorithms to monitor traffic flow to give some feedback to TCP about how much data it is reasonable to have in transit at one time (when is the retransmission timer started for a given packet; hopefully not before the packet preceeding it has been acked). Think about flow control in an internet environment (maybe some students might like to work on the problem). Charlie ----MESSAGE-END----