|
|
ARCHIVE: TCP-IP Distribution List - Archives (1985)
DOCUMENT: TCP-IP Distribution List for September 1985 (56 messages, 18195 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1985/09.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Tue, 3-Sep-85 15:54:35 EDT From: mills@DCN6.ARPA To: fa.tcp-ip Subject: Timetelling (continued)
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
-------
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 03-Sep-85 18:09:13-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Subject: Timetelling (continued)
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
-------
-----------[000002][next][prev][last][first]---------------------------------------------------- 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
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Sep-85 08:36:51 EDT From: mckenzie@BBNH.ARPA (Alex McKenzie) To: fa.tcp-ip Subject: Seeking Info about Ethernet BRIDGES
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
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Sep 85 8:36:51 EDT From: Alex McKenzie <mckenzie@BBNH.ARPA> To: tcp-ip@sri-nic.arpa Cc: mckenzie@BBNH.ARPA Subject: Seeking Info about Ethernet BRIDGES
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
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Sep-85 11:01:09 EDT From: MILLS@USC-ISID.ARPA To: fa.tcp-ip Subject: Re: TCP Performance and Compatibility
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 -------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Thu, 5-Sep-85 15:42:00 EDT From: DCP@SCRC-QUABBIN.ARPA (David C. Plummer in disguise) To: fa.tcp-ip Subject: TCP Performance and Compatibility
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.
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Fri, 6-Sep-85 04:31:00 EDT From: vshank%weizmann.BITNET@WISCVM.ARPA (Henry Nussbacher) To: fa.tcp-ip Subject: VMS and TCP/IP
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.
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 1985 12:00-PDT From: Jon Postel <POSTEL@USC-ISIB.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: Performance and Compatibilty
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.
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 85 10:15:26 EDT From: Charles <MCGREW@RED.RUTGERS.EDU> To: tcp-ip@SRI-NIC.ARPA Subject: MIT TCP-PC Source code?
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 -------
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Fri, 6 Sep 85 10:31 O From: Henry Nussbacher <vshank%weizmann.BITNET@WISCVM.ARPA> To: <tcp-ip@sri-nic.arpa> Subject: VMS and TCP/IP
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.
-----------[000011][next][prev][last][first]----------------------------------------------------
Date: Fri, 6-Sep-85 21:44:00 EDT
From: DCP@SCRC-QUABBIN.ARPA ("David C. Plummer in disguise")
To: fa.tcp-ip
Subject: Performance and Compatibilty
Date: 6 Sep 1985 12:00-PDT
From: Jon Postel <POSTEL@USC-ISIB.ARPA>
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.
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Mon, 9-Sep-85 13:30:37 EDT From: mills@DCN6.ARPA To: fa.tcp-ip Subject: Proposed Network Time Protocol (NTP)
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 -------
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 09-Sep-85 16:05:17-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Subject: Proposed Network Time Protocol (NTP)
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 -------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Tue, 10-Sep-85 08:02:45 EDT From: klute%gatech.csnet@CSNET-RELAY.ARPA (Gregory Kenley) To: fa.tcp-ip Subject: Re: Proposed Network Time Protocol (NTP)
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.
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Wed, 11-Sep-85 01:41:54 EDT From: mills@DCN6.ARPA To: fa.tcp-ip Subject: Ticking and tocking
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 -------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 11-Sep-85 04:06:39-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Subject: Ticking and tocking
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 -------
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Wed, 11-Sep-85 22:16:56 EDT From: walsh@BBN-LABS-B.ARPA (Bob Walsh) To: fa.tcp-ip 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
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Wed, 11 Sep 85 22:16:56 EDT From: Bob Walsh <walsh@BBN-LABS-B.ARPA> 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
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 1985 12:46-CDT From: SNELSON@STL-HOST1.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: FIBER INSTEAD OF COAX
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
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 1985 16:30:39 PDT From: POSTEL@USC-ISIB.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: re: Class B networks vs. Class C networks
Jon Solomon: Please consider the subnetting procedure described in RFC 950. --jon. -------
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Sep 1985 14:56 EDT From: Jon Solomon <JSOL%BUCS20%bostonu.csnet@CSNET-RELAY.ARPA> To: tcp-ip@sri-nic.csnet Subject: Class B networks Vs. Class C networks
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
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Fri, 13-Sep-85 19:30:39 EDT From: POSTEL@USC-ISIB.ARPA To: fa.tcp-ip Subject: re: Class B networks vs. Class C networks
Jon Solomon: Please consider the subnetting procedure described in RFC 950. --jon. -------
-----------[000023][next][prev][last][first]---------------------------------------------------- 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
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Mon, 16-Sep-85 07:54:26 EDT From: Morence@AVD-PLEXUS01 To: fa.tcp-ip 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
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 16 Sep 1985 18:26 PST From: Art Berggreen <ART@ACC.ARPA> To: tcp-ip@sri-nic Subject: ACC IF-11/HDH
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"<Art@ACC.ARPA>
------
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Mon, 16-Sep-85 22:26:00 EDT From: ART@ACC.ARPA (Art Berggreen) To: fa.tcp-ip Subject: ACC IF-11/HDH
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"<Art@ACC.ARPA>
------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Tue, 17-Sep-85 04:24:42 EDT From: matt@LLL-CRG.ARPA (Matt Thomas) To: fa.tcp-ip Subject: ARP & IP and numbers
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
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 17 Sep 1985 13:03:39 PDT From: POSTEL@USC-ISIB.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: re: ARP & IP anf numbers
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. -------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Tue, 17-Sep-85 15:49:45 EDT From: dougm@ico.UUCP To: fa.tcp-ip Subject: X.25 board driver wanted
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
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Tue, 17-Sep-85 16:03:39 EDT From: POSTEL@USC-ISIB.ARPA To: fa.tcp-ip Subject: re: ARP & IP anf numbers
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. -------
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 18 Sep 1985 08:31 PST From: Gary Krall <GARY@ACC.ARPA> To: TCP-IP@SRI-NIC Subject: X.25 drivers
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 ------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Wed, 18-Sep-85 07:53:29 EDT From: ddaly%xls-plexus01.amc@AMC-HQ.ARPA (DUSTY) To: fa.tcp-ip Subject: name removal
Please remove the following name from your mailing list as my activity already receives several copies. ddaly at amc-hq
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 18 Sep 85 7:53:29-EDT (Wed) From: DUSTY <ddaly%xls-plexus01.amc@AMC-HQ.ARPA> To: info-unix%brl.arpa@AMC-HQ.ARPA, tcp-ip%sri-nic.arpa@AMC-HQ.ARPA Subject: name removal
Please remove the following name from your mailing list as my activity already receives several copies. ddaly at amc-hq
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 18 Sep 85 11:43:32 PDT (Wed) From: Geoffrey H. Cooper <imagen!geof@su-shasta.arpa> To: Matt Thomas <shasta!matt@lll-crg.ARPA> Cc: shasta!tcp-ip@sri-nic Subject: Re: ARP & IP and numbers
ARP's Ethernet number is 0x806 (806 hex). 2054 for you decimal fans. - Geof
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 18 Sep 1985 14:15 PST From: Gary Krall <GARY@ACC.ARPA> To: TCP-IP@SRI-NIC Subject: a footnote
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 ------
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Wed, 18-Sep-85 12:31:00 EDT From: GARY@ACC.ARPA (Gary Krall) To: fa.tcp-ip Subject: X.25 drivers
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 ------
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Wed, 18-Sep-85 13:34:56 EDT From: ron@BRL.ARPA (Ron Natalie) To: fa.tcp-ip 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
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Sep 85 13:34:56 EDT From: Ron Natalie <ron@BRL.ARPA> To: Doug McCallum <hao!ico!dougm@UCB-VAX.ARPA> 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
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Wed, 18-Sep-85 14:03:36 EDT From: sdyer@BBNCC5.ARPA To: fa.tcp-ip Subject: Re: X.25 board driver wanted
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.
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Wed, 18-Sep-85 14:43:32 EDT From: geof@imagen.UUCP To: fa.tcp-ip Subject: Re: ARP & IP and numbers
ARP's Ethernet number is 0x806 (806 hex). 2054 for you decimal fans. - Geof
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Wed, 18-Sep-85 17:58:37 EDT From: ron@BRL.ARPA (Ron Natalie) To: fa.tcp-ip 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
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Sep 85 17:58:37 EDT From: Ron Natalie <ron@BRL.ARPA> To: sdyer@BBNCC5.ARPA Cc: Ron Natalie <ron@BRL.ARPA>, Doug McCallum <hao!ico!dougm@UCB-VAX.ARPA>, 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
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Wed, 18-Sep-85 18:15:00 EDT From: GARY@ACC.ARPA (Gary Krall) To: fa.tcp-ip Subject: a footnote
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 ------
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Fri, 20-Sep-85 16:15:52 EDT From: dougm@ico.UUCP To: fa.tcp-ip Subject: Re: x.25 board driver wanted
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
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Sat, 21 Sep 85 12:11:17 EDT From: Boots Cassel <cassel@dewey.udel.EDU> 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.
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Mon 23 Sep 85 15:44:15-EDT From: Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: NRC Fusion Code
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... -------
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Tue, 24-Sep-85 02:11:10 EDT From: medin@ORION.ARPA (Milo Medin, NASA ARC Code EDN Advanced Systems Group) To: fa.tcp-ip Subject: Re: NRC Fusion Code
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
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Tue, 24-Sep-85 11:16:00 EDT From: stanonik@NPRDC.ARPA (Ron Stanonik) To: fa.tcp-ip Subject: serial line (rick@seismo) ip fix
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++;
}
/*
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Fri, 27-Sep-85 16:18:22 EDT From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) To: fa.tcp-ip Subject: are you having trouble reaching Rutgers?
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. -------
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 85 16:18:22 EDT From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU> To: tcp-ip@SRI-NIC.ARPA Subject: are you having trouble reaching Rutgers?
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. -------
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Sat, 28-Sep-85 22:54:00 EDT From: JRBRINKEMA@USC-ISI.ARPA To: fa.tcp-ip Subject: Implementation of tcp-ip on IBM-PC Wanted
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.
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Sun, 29-Sep-85 21:20:21 EDT From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) To: fa.tcp-ip Subject: problems getting to CISL-SERVICE-MULTICS
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? -------
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 29 Sep 85 21:20:21 EDT From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU> To: tcp-ip@SRI-NIC.ARPA Subject: problems getting to CISL-SERVICE-MULTICS
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? -------
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Mon, 30-Sep-85 00:00:25 EDT From: jis@MIT-BITSY.MIT.EDU (Jeffrey I. Schiller) To: fa.tcp-ip Subject: problems getting to CISL-SERVICE-MULTICS
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
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 30 Sep 1985 09:36-EDT From: CLYNN@BBNA.ARPA To: HEDRICK@RED.RUTGERS.EDU Cc: tcp-ip@SRI-NIC.ARPA, CLynn@BBNA.ARPA Subject: Re: problems getting to CISL-SERVICE-MULTICS
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
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |