The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

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