The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1986)
DOCUMENT: TCP-IP Distribution List for January 1986 (127 messages, 72093 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1986/01.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Jan-86 12:24:08 EST
From:      JNC@MIT-XX.ARPA ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: Drop from Mailing List


	Once again, please send messages requested to be added or
dropped from the TCP-IP mailing list to 'TCP-IP-REQUEST' at SRI-NIC.
Do NOT send such messages to TCP-IP, since you are sending junk mail
to thousands of people. I am currently mildly harassing people who do
this, and may escalate to persecution if warranted.
		Noel
-------

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Jan-86 00:27:03 EST
From:      mills@DCN6.ARPA
To:        mod.protocols.tcp-ip
Subject:   Heath clocks compared

Folks,

I ran an experiment designed to compare the times across the network between two
Heath GC-1000 WWV clocks, one near Washington, DC, and the other in Ann Arbor,
Michigan. The experiment collected ICMP Timestamp messages from each site for
a nine-hour overnight period when both clocks were synchronized to the 5-MHz
WWV signal, at least most of the time. The collected data was then reduced and
graphed.

The results show the two clocks are in very close agreement and exhibit the same
three-minute sawtooth-looking error function as I described earlier. The peak-peak
amplitude of the error function is about 100 ms and the mean error is about 30 ms.
relative to our WWVB reference clock. Not bad at all.

The graphs themselves are in Sun rasterfile format and can be displayed using
the screenload program for the Sun. The files are on dcn9.arpa called umi.bit
(Ann Arbor) and dcn.bit (Washington) and are accessible with anonymous FTP.

Thanks to Milo Medin (medin@orion.arpa) for polishing up our Sun-resident NTP
server and rehosting under 4.3bsd. The server now runs in dcn9.arpa, orion.arpa
ames.arpa and trantor.umd.edu, as well as assorted fuzzballs.

Dave
-------

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      04-Jan-86 05:01:24-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   Heath clocks compared
Folks,

I ran an experiment designed to compare the times across the network between two
Heath GC-1000 WWV clocks, one near Washington, DC, and the other in Ann Arbor,
Michigan. The experiment collected ICMP Timestamp messages from each site for
a nine-hour overnight period when both clocks were synchronized to the 5-MHz
WWV signal, at least most of the time. The collected data was then reduced and
graphed.

The results show the two clocks are in very close agreement and exhibit the same
three-minute sawtooth-looking error function as I described earlier. The peak-peak
amplitude of the error function is about 100 ms and the mean error is about 30 ms.
relative to our WWVB reference clock. Not bad at all.

The graphs themselves are in Sun rasterfile format and can be displayed using
the screenload program for the Sun. The files are on dcn9.arpa called umi.bit
(Ann Arbor) and dcn.bit (Washington) and are accessible with anonymous FTP.

Thanks to Milo Medin (medin@orion.arpa) for polishing up our Sun-resident NTP
server and rehosting under 4.3bsd. The server now runs in dcn9.arpa, orion.arpa
ames.arpa and trantor.umd.edu, as well as assorted fuzzballs.

Dave
-------
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Jan-86 15:52:00 EST
From:      Swenson@MIT-MULTICS.ARPA ("Eric J. Swenson")
To:        mod.protocols.tcp-ip
Subject:   Public Domain FTP/TELNET in C

Do public domain versions of user/server FTP and user/server TELNET
exist for Unix systems?  Would someone point me in the right direction
if this is not the correct place for this kind of a query?  Thanks.
Please reply by mail, since I do receive reliable copies of messages
posted to this mailing list.  Thanks in advance.

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jan-86 04:18:45 EST
From:      ROODE@SUMEX-AIM.ARPA (David Roode)
To:        mod.protocols.tcp-ip
Subject:   non-Internet net name domains

An article in a recent CSNET-FORUM Digest concerns some practical
issues for extending name domains to cover CSNET.  CSNET
consists of a small part which runs TCP/IP protocols and a much
larger part which provides mail-only service using the switched
telephone network and modems to reach a central relay machine.
I'm concerned because of the references to permission
from NIC to establish a domain which is apparently being denied.
I can see a possibility for the establishment of a CSNET domain
being the right thing to do, just as I can for another CSNET-like
entity with which I am associated, but which is just in the formation
stage.  For that reason I hope passing this article along
might encourage some input to this decision and these
regulations.

------------------------------

Date: 10 Dec 85 11:18:03 EST (Tue)
From: Craig Partridge <craig@loki.ARPA>
To: Chris Johnson <JOHNSON%northeastern.csnet@CSNET-SH.ARPA>
Subject:  domains, subdomains ... etc ...

Chris,

    Dick Edmiston forwarded your note on this subject to me.

> ... I recently sent mail 
> to HOSTMASTER@SRI-NIC regarding domain names and was told that you and 
> they were currently working out a plan for domain names on CSNet.  True? 

    Yes this is correct.  We are to meet with them in January to
try to iron things out.  They have told us they do not want to support
a CSNET specific domain, such as .csnet or .cs.net.  By implication
this means that they'd like CSNET sites registered just like Internet
sites (so your domain would be something like NU.EDU).

    This is perfectly feasible, even though your host is not on
the Internet.  The domain system stores mail routing information as
well as network addresses, and we can set things up so that all
mail to hosts in NU.EDU  get forwarded (transparently) to the
CSNET relay.  In some ways, this would be rather nice.  For example,
your mail address would become JOHNSON@NU.EDU (or something close)
everywhere... No more CSNET vs. ARPANET addresses.  Oh yes,
final authority on names rests with the NIC.

    Now for the kicker.  For this to work, someone has to run a
domain server on the Internet for NU.EDU.  It is not clear that
this is practical.  Imagine the problems of trying to list all
the hosts at all the PhoneNet sites and keeping those databases
up to date.  To make things worse, the NIC currently requires TWO
independent servers so that if one goes down, your domain doesn't
suddenly go off into the great black void.  There are some compromise
positions available, but it isn't clear that people like them.  For
example, we can set up your domain such that any mail addressed to
anyhost in NU.EDU gets sent to you to sort out.  This means you
get to handle mail with invalid hostnames (like BAD.NU.EDU) at your
end.  It is not clear that this is desirable.

    We are currently working on the assumptions that (1) naming
will be the way I describe above (you'll be NU.EDU, or whatever the
NIC approves), and that (2) CSNET will try to provide domain server
facilities for PhoneNet sites.  Neither of these decisions is carved
in stone.  We'll know much more after the January meeting.

    I'm sorry if this all sounds a bit fuzzy.  The conversion to
domains throughout the Internet is going slower than anticipated.
We have only recently gotten reliable domain server software and
it still has misfeatures.  None of the major mailers knows about
domains yet, though there are beta releases of both MMDFII and
Sendmail that are currently being tested.  This all makes it very
hard to talk with absolute certainty about the future state of
mail software in the domain world.

    Let me know if I can be of further assistance.
 
Craig Partridge
CSNET Technical Staff
 
------------------------------
-------

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jan-86 16:08:21 EST
From:      glenn@LL-XN.ARPA (Glenn Adams)
To:        mod.protocols.tcp-ip
Subject:   Ethernet Type Field Assignments


Could someone please refer me to any online or hardcopy document which
specifies the 'Official' Ethernet Type Field assignments?

P.S. I don't mean the excerpt of this data included in RFC900 (Assigned
Numbers).

Thanks much,

Glenn Adams

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1986 19:35:58 PST
From:      POSTEL@USC-ISIB.ARPA
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Assigned Numbers

The most recent version of "Assigned Numbers" is RFC 960 and is
dated December 1985.

--jon.
-------
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jan-86 22:35:58 EST
From:      POSTEL@USC-ISIB.ARPA
To:        mod.protocols.tcp-ip
Subject:   Assigned Numbers


The most recent version of "Assigned Numbers" is RFC 960 and is
dated December 1985.

--jon.
-------

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Jan-86 01:20:53 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Ethernet Type Field Assignments


Seems like that is going to be an awfully long list but I
sure would like to see it if you get one.

Mike

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Jan-86 14:02:26 EST
From:      albitz@PURDUE.EDU ("Paul M. Albitz")
To:        mod.protocols.tcp-ip
Subject:   network address changes for Purdue CS dept.


On Thurs Jan 9 at 8pm EST the CS dept will be changing most of our host
addresses as a step towards subnetting.  

Hosts.txt will have our new addresses sometime on Thursday.  As a last
resort, you can edit /etc/hosts by hand.  Delete the 128.10.0.1 address
for Purdue.edu and use 192.5.48.1 as it will not change.

Paul Albitz

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jan 86 21:31:24 pst
From:      ucdavis!clover!apffel@ucbvax.berkeley.edu (Jim Apffel)
To:        tcp-ip@sri-nic
Subject:   VMS TCP/IP for uVAX II

Database Query:

    Are there any experts out there who know of cheap TCP/IP network
software which will run on the DEC VAXStation II under uVMS using the
DEC Ethernet interface?

    I know of two possible solutions:

    Wollongong (415) 962-7100
    supplies a TCP/IP software package running on uVMS for ~$3,000.

    EXCELAN (408) 434-2300
    supplies both an Ethernet board and TCP/IP software for <$3,000.

Are there any other good alternatives?  Please respond to:

   ucbvax!ucdavis!clover!apffel

Thanks,

Jim Apffel, Manager Computer Vision Research Lab
Electrical and Computer Engineering Department
3026 Bainer Hall
U.C. Davis
Davis,  CA  95616
Phone:    (916) 752-6349
Message:  (916) 753-8583

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jan-86 00:31:24 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   VMS TCP/IP for uVAX II


Database Query:

    Are there any experts out there who know of cheap TCP/IP network
software which will run on the DEC VAXStation II under uVMS using the
DEC Ethernet interface?

    I know of two possible solutions:

    Wollongong (415) 962-7100
    supplies a TCP/IP software package running on uVMS for ~$3,000.

    EXCELAN (408) 434-2300
    supplies both an Ethernet board and TCP/IP software for <$3,000.

Are there any other good alternatives?  Please respond to:

   ucbvax!ucdavis!clover!apffel

Thanks,

Jim Apffel, Manager Computer Vision Research Lab
Electrical and Computer Engineering Department
3026 Bainer Hall
U.C. Davis
Davis,  CA  95616
Phone:    (916) 752-6349
Message:  (916) 753-8583

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jan-86 06:29:00 EST
From:      JOHNSON@NORTHEASTERN.CSNET (Chris Johnson)
To:        mod.protocols.tcp-ip
Subject:   Hi!  Happy New Year!


     Hi!  Happy New Year to all!

     Last year I asked for info on Wollongong and VMS and DG's version of 
tcp/ip for AOS/VS.  Many replies where received and appreciated.  Thank 
you.

     Another couple of questions if I may.

     1) How is EXCELAN as far as reliability, usefulness, maintenance
        and bugs on VAX using VMS 4.2 or higher?

     2) Does anybody know of a FULL implementation of tcp/ip, smtp, ftp
        telnet etc for DG's mv/8000, mv/10000, mv/20000 series using 
        AOS/VS.  It turns out that DG's isn't a full implementation and
        I don't want to be caught needing something.

     Thanks again to all.

Chris Johnson
Northeastern University

johnson@northeastern                                      (CSNet)
johnson%northeastern@csnet-relay                          (ARPAnet)

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jan 86 07:29 EDT
From:      Chris Johnson <JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA>
To:        tcp-ip@sri-nic.arpa, johnson%northeastern.csnet@CSNET-RELAY.ARPA
Subject:   Hi!  Happy New Year!
     Hi!  Happy New Year to all!

     Last year I asked for info on Wollongong and VMS and DG's version of 
tcp/ip for AOS/VS.  Many replies where received and appreciated.  Thank 
you.

     Another couple of questions if I may.

     1) How is EXCELAN as far as reliability, usefulness, maintenance
        and bugs on VAX using VMS 4.2 or higher?

     2) Does anybody know of a FULL implementation of tcp/ip, smtp, ftp
        telnet etc for DG's mv/8000, mv/10000, mv/20000 series using 
        AOS/VS.  It turns out that DG's isn't a full implementation and
        I don't want to be caught needing something.

     Thanks again to all.

Chris Johnson
Northeastern University

johnson@northeastern                                      (CSNet)
johnson%northeastern@csnet-relay                          (ARPAnet)
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 86 17:18:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   ISO protocol discussions

There doesn't seem to be an ARPANET newsgroup listed at the NIC for
discussion of ISO protocols (especially MAP), so I'm posting this to
tcp-ip.

Is anyone working with ISO protocols and either in or would like to
establish an informal discussion group?  I'd like to see discussion
about problems with the existing protocol specifications, implementation
approaches, performance considerations, etc.  This would be for people
actually working with the protocols and not novice Q&A.  Current areas
include CLNS (IP), TP4, and Session.

					<Art@ACC.ARPA>

------
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      9-Jan-86 18:06:52-PST
From:      jbn@FORD-WDL1
To:        narten@PURDUE.EDU
Cc:        jbn@FORD-WDL1, TCP-IP-REQUEST@SRI-NIC
Subject:   Re: retransmission timers in TCP
I had to go into 4.3BSD recently and fix a few bugs here, so I'll document
how 4.3BSD does it, for the benefit of the community.

					John Nagle

The algorithm in 4.3BSD works as follows:

        1.  Round trip times are computed for one packet at a time.
	    Only packets containing data and which are not being retransmitted
	    contribute to the round-trip time calculation.  The timer starts
	    when a data packet is transmitted and no other packet is being
	    timed, and stops when an ACK covers the sequence number of the
	    packet being timed.

	2.  There is a smoothed round-trip timer.  Its value is initially
	    0 and is a smoothed running average of past round-trip times.
	    It is updated at the completion of each successful timing, as
	    described above.
	    The formula is 

			const = 0.1
			srtt = srtt * (1-const) + lastrtt * const;

	    This is actually computed in floating point.
	    On the first round-trip, srtt is simply set to lastrtt.
	    The result is then forced into the range 1 to 30 seconds.
	    [It's possible to use the 0 value if there is no good round-trip
	    before the first retransmit.  This is a bug; see net.bugs.4bsd
	    for a fix.]

	3.  The initial retransmit interval is 2*srtt.  A backoff algorithm
	    then applies.  The standard algorithm is table-driven, and
	    has a table of constants beginning 1.0, 1.2, etc.  These
	    are applied using the number of the retransmit as an index as
	    multipliers to srtt.  There is an alternate algorithm available
	    by patching a flag, which uses srtt*(2^retransmitnumber) as the
	    retransmit interval.  [There's a bug here; there is a multiply
	    by tcp-beta (=2.0) missing in one spot, and the time between
	    the first and second retransmit is shorter than between the
	    original and the first. Again, see net.bugs.4bsd for a fix.]
	    We prefer the alternate algorithm, which backs off faster.

Without the fixes, by the way, things are not good when the round-trip
time on the net actually exceeds one second.

						JN
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Thu 9 Jan 86 18:41:27-PST
From:      Michael A. Haberler <HABERLER@SU-SIERRA.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Data General AOS/VS TCP-IP
We have DG's TCP/IP since a year; also had the pleasure to beta-test it.

It is derived from an early 4.2 version and runs as a separate user process;
it is not integrated into the kernel and does not depend on the System III
emulator for AOS/VS DG sells as well.

The have pruned out all UDP code and quite a few features from FTP and Telnet
as well. Server Telnet functionality is severely limited as it treats all
virtual consoles as 'hardcopy' devices which means that one is restricted to
line-mode editing. The Unix emulator commands also won't run with Telnet login.
Therefore, Telnet login is practically unused. The DG people promised lots of
improvements and fixes, but I've seen few so far.

There is a native 4.2 for Eclipse machines as well which has nothing to do 
with the above mentioned product.

- michael
-------
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jan-86 19:09:41 EST
From:      HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   Re: Hi!  Happy New Year!

DG has a 4.2 that runs under AOS.  Presumably this would include
full TCP.
-------

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jan-86 20:18:00 EST
From:      art@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   ISO protocol discussions


There doesn't seem to be an ARPANET newsgroup listed at the NIC for
discussion of ISO protocols (especially MAP), so I'm posting this to
tcp-ip.

Is anyone working with ISO protocols and either in or would like to
establish an informal discussion group?  I'd like to see discussion
about problems with the existing protocol specifications, implementation
approaches, performance considerations, etc.  This would be for people
actually working with the protocols and not novice Q&A.  Current areas
include CLNS (IP), TP4, and Session.

					<Art@ACC.ARPA>

------

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jan-86 21:06:52 EST
From:      jbn@FORD-WDL1.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: retransmission timers in TCP

I had to go into 4.3BSD recently and fix a few bugs here, so I'll document
how 4.3BSD does it, for the benefit of the community.

					John Nagle

The algorithm in 4.3BSD works as follows:

        1.  Round trip times are computed for one packet at a time.
	    Only packets containing data and which are not being retransmitted
	    contribute to the round-trip time calculation.  The timer starts
	    when a data packet is transmitted and no other packet is being
	    timed, and stops when an ACK covers the sequence number of the
	    packet being timed.

	2.  There is a smoothed round-trip timer.  Its value is initially
	    0 and is a smoothed running average of past round-trip times.
	    It is updated at the completion of each successful timing, as
	    described above.
	    The formula is 

			const = 0.1
			srtt = srtt * (1-const) + lastrtt * const;

	    This is actually computed in floating point.
	    On the first round-trip, srtt is simply set to lastrtt.
	    The result is then forced into the range 1 to 30 seconds.
	    [It's possible to use the 0 value if there is no good round-trip
	    before the first retransmit.  This is a bug; see net.bugs.4bsd
	    for a fix.]

	3.  The initial retransmit interval is 2*srtt.  A backoff algorithm
	    then applies.  The standard algorithm is table-driven, and
	    has a table of constants beginning 1.0, 1.2, etc.  These
	    are applied using the number of the retransmit as an index as
	    multipliers to srtt.  There is an alternate algorithm available
	    by patching a flag, which uses srtt*(2^retransmitnumber) as the
	    retransmit interval.  [There's a bug here; there is a multiply
	    by tcp-beta (=2.0) missing in one spot, and the time between
	    the first and second retransmit is shorter than between the
	    original and the first. Again, see net.bugs.4bsd for a fix.]
	    We prefer the alternate algorithm, which backs off faster.

Without the fixes, by the way, things are not good when the round-trip
time on the net actually exceeds one second.

						JN

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jan-86 21:41:27 EST
From:      HABERLER@SU-SIERRA.ARPA (Michael A. Haberler)
To:        mod.protocols.tcp-ip
Subject:   Data General AOS/VS TCP-IP

We have DG's TCP/IP since a year; also had the pleasure to beta-test it.

It is derived from an early 4.2 version and runs as a separate user process;
it is not integrated into the kernel and does not depend on the System III
emulator for AOS/VS DG sells as well.

The have pruned out all UDP code and quite a few features from FTP and Telnet
as well. Server Telnet functionality is severely limited as it treats all
virtual consoles as 'hardcopy' devices which means that one is restricted to
line-mode editing. The Unix emulator commands also won't run with Telnet login.
Therefore, Telnet login is practically unused. The DG people promised lots of
improvements and fixes, but I've seen few so far.

There is a native 4.2 for Eclipse machines as well which has nothing to do 
with the above mentioned product.

- michael
-------

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Jan-86 05:33:58 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Connecting two VAXes via DMR-11 with TCP/IP

Help needed!

We have connected two VAX 11/780 via DMR-11 with TCP/IP-Protocol.
One of them is running ULTRIX-32 V1.0, the other one Berkeley 4.2 bsd.
After changing ULTRIX 1.0 to 1.1 the connection doesn't run
any longer, each call with telnet or rlogin times out. Now DEC sais,
ULTRIX 1.1 needs Berkeley 4.3 to connect via DMR-11. Does anybody
have similar experiences? Does anywhere a running connection ULTRIX 1.1
with Berkeley 4.3 exist? Is there a way to connect ULTRIX 1.1 with
Berkeley 4.2? Does this type of connection run anywhere?

Thanks in advance!

Wilhelm Methfessel
seismo!mcvax!unido!ztivax
Siemens AG, Munich

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1986 23:23:19 PST
From:      POSTEL@USC-ISIB.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   domains and "nets"

Domain names are supposed to be administrative and not related to
physical location, type of equipment, topology, or routing.

That the initial step in establishing domain name was to say that all
the existing hosts in the ARPA-Internet were in the .ARPA domain was
probably a mistake.  It is too easy for people to think that the
".ARPA" stands for the ARPANET rather than the ARPA administration.
We probably should have called it ".TEMP" or ".OLD".

It is very tempting for each communication world (such as, UUCP,
CSNET, MAILNET, BITNET) to think of itself as a top level domain.  And
most such entities probably meet the general requirements, and would
probably provide responsible management for the domain (maintaing the
databases, etc.).

But these entities really represent the managements of communication
systems.  It does not really seem appropriate to me to have my name
depend on which communication system i am on, and it especially seems
wrong that i would have as many different names as communication
systems i subscribed to.  For example, Berkeley participates in at
least the ARPA world, the UUCP world, the BITNET world, and the CSNET
world.

It seems much more reasonable to pick names that are independent of
the type of communication system, or protocols, or what ever technical
details are involved.  The general domain names of EDU (for
Education), COM (for Commercial), etc, were chosen to be neutral.  The
idea is that a place like Berkeley can choose a name like BERKELEY.EDU
and use that name in all the communication worlds it participates in.

The details of the domain name database structure make this possible,
and make possible the use of domain style names by hosts not directly
on the ARPA-Internet.  There is indeed some work involved, but not
significantly more than is involved without the domain name system.

--jon.
-------
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11-Jan-86 02:23:19 EST
From:      POSTEL@USC-ISIB.ARPA
To:        mod.protocols.tcp-ip
Subject:   domains and "nets"


Domain names are supposed to be administrative and not related to
physical location, type of equipment, topology, or routing.

That the initial step in establishing domain name was to say that all
the existing hosts in the ARPA-Internet were in the .ARPA domain was
probably a mistake.  It is too easy for people to think that the
".ARPA" stands for the ARPANET rather than the ARPA administration.
We probably should have called it ".TEMP" or ".OLD".

It is very tempting for each communication world (such as, UUCP,
CSNET, MAILNET, BITNET) to think of itself as a top level domain.  And
most such entities probably meet the general requirements, and would
probably provide responsible management for the domain (maintaing the
databases, etc.).

But these entities really represent the managements of communication
systems.  It does not really seem appropriate to me to have my name
depend on which communication system i am on, and it especially seems
wrong that i would have as many different names as communication
systems i subscribed to.  For example, Berkeley participates in at
least the ARPA world, the UUCP world, the BITNET world, and the CSNET
world.

It seems much more reasonable to pick names that are independent of
the type of communication system, or protocols, or what ever technical
details are involved.  The general domain names of EDU (for
Education), COM (for Commercial), etc, were chosen to be neutral.  The
idea is that a place like Berkeley can choose a name like BERKELEY.EDU
and use that name in all the communication worlds it participates in.

The details of the domain name database structure make this possible,
and make possible the use of domain style names by hosts not directly
on the ARPA-Internet.  There is indeed some work involved, but not
significantly more than is involved without the domain name system.

--jon.
-------

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12-Jan-86 14:45:28 EST
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   a couple of implementation issues

I would like to describe Rutgers current network configuration, and then
mention some of the problems we are looking into at the moment.  I would
like to see whether my ideas seem reasonable to this community, and 
whether others have any better approaches.  The major issues will involve
addressing in an environment that uses a mix of Ethernet-level and
IP-level gateways, and how to set up a system with redundant IP gateways
so that it will survive gateway failures.

First, the configuration.  We have 5 Ethernets currently in operation,
with several others coming on line shortly.  Four of them are
connected by an IP gateway built using a design from Stanford.  It is
a 68000 multibus system (Forward Technology SUN board), with 3Com
Ethernet interfaces.  The software handles PUP, IP, and XNS.  It is a
full PUP gateway, handling PUP directories and routing protocols.  IP
support is more limited, including only ARP and ICMP echo.  The IP
support assumes that subnetting is in use, with 8-bit host addresses
and 8-bit subnet addresses.  It implements the "ARP hack", so that
hosts can use it even if they don't know about subnets.  Stanford
estimates a capacity of about 250 packets per second.  However recent
tweaking of the code has probably increased this.  (We haven't pushed
it hard enough to see this limit yet. The only limit we have seen is
that Sun 3's that use NFS through the gateway have to have some
non-default parameter settings.  This is a known problem with the 3Com
Ethernet interface, which also affects some older Sun 2's.) [For
those who may be interested in duplicating this, there are now
commercial equivlents of this gateway.  Proteon sells one that should
be fairly similar, though with higher performance and more IP support.
It should handle EGP.  Len Bosack from Stanford has apparently started
a company that will market a re-engineered version of the Stanford
gateway.  You might also check Bridge Communications and DEC.]

For hosts in isolated buildings, we are installing a broadband cable
system.  We plan to use Applitek Ethernet bridges.  That is, each
building will have an Ethernet.  The Ethernets will be connected via
the broadband cable.  The Applitek bridges work at the Ethernet level.
That is, they watch every packet on the Ethernet.  They dynamically
build a list of all machines on the local Ethernet.  When they see a
packet addressed to a machine that is not on the local Ethernet, they
forward it to the proper Ethernet via the broadband.  (Actually, there
is somewhat more control available if you need it.)  They forward all
broadcast packets to all Ethernets.  We do not yet have throughput
data on it, as the system is new and is still in test.  It does seem
to be able to handle Sun 3 NFS transmissions with default parameter
settings on the Sun.  The Applitek bridges are 68000-based systems,
with a fair amount of hardware in them.  I'm fairly sure there is more
than one 68000 in there.  It uses a modern Ethernet interface, with
its own processor.  The broadband communications use one 6MHz channel,
and can handle 10Mbits/sec.  (Yes, it is possible to get more bits in
a channel than its bandwidth.  This has always seemed to me to violate
some basic principle, but sophisticated communications technology can
get more bits/sec than Hz.)  Our first setup, which will probably be
put in operation this week, will connect two Ethernets, one of which
is also on the gateway described in the previous paragraph.  [If you
are in the market for one of these, other vendors that I know of with
similar products are Proteon and possibly Bridge Communications.  Both
of these products will use IP gateways between the local Ethernet and
their long-haul network.  This has both advantages and disadvantages.
It allows some improvements in support of TCP/IP, but it also means
that you can't handle DECnet and other protocols.]

The first issue is how to set up IP addresses for the Ethernets to be
connected via the Applitek bridges.  Initially we figured that each
Ethernet would be a subnet, just like those connected by the IP
gateway.  However on second thought, I believe that is a mistake.
Consider the following situation.
   subnets 6 and 7 are connected via Applitek bridge
   subnets 4 and 6 are connected via IP gateway
   a host on subnet 6 wants to talk to a host on subnet 7.
The conversation will have to go through the Applitek bridge.  Recall
that this operates at Ethernet level.  That means that the source host
will have to send an Ethernet packet with the final destination's
Ethernet address in it.  In order to find this address, it will have
to issue an ARP.  If the host on 6 knows about subnets, it will
consider subnet 7 to be a separate network.  It will not issue an ARP
to try to find the host.  Rather, it will expect to find a gateway in
its gateway table (or use its default gateway).  With all subnet
implementations that I know, there is no way to tell a host to use a
gateway to talk to subnet 4, but to issue ARP's and talk directly to
subnet 7.  Once you turn on subnetting, it will expect to find
gateways for all subnets.  Obviously we could change this behavior.
But we are reluctant to adopt a network design that violates the
subnetting RFC's, and requires us to make kernel changes to systems that
use it.  Thus we reluctantly conclude that all of the Ethernets that
are connected by the Applitek bridge must be considered a single 
subnet.  I don't much like this, because I think eventually we are
going to end up using IP gateways.  In order to install an IP gateway
between two Ethernets that are currently connected by the Applitek
bridges, we would have to remove the Applitek bridge from one of them,
give it a different subnet number, change the addresses of all of
its hosts, and then install the IP gateway.  Does anyone see something
I am missing?

The second issue involves gateway reliability.  This is not a problem
that is immediately pressing.  The gateway code from Stanford is the
only piece of software I have used that has never crashed.  But now
and then we do take it down for development work, and we do get
complaints from people who are suddenly disconnected.  We have several
Unix systems with more than one Ethernet interface.  These hosts could
act as gateways.  While their performance as gateways would not be as
good as a dedicated 68000 gateway, they would be fine as backup
gateways.  The question is, how do we set things up so that a
connection will move from one gateway to an alternate when the first
one goes down.  4.3 has some hint of the basic ability needed.  When
TCP is about to time out a connection, it first tries to compute a new
route.  However in order for this to help, two things must be true:
  - the system has to know that a gateway is in use.  This means
	that we can't use the ARP hack.  We have to install subnet
	support on all the hosts.
  - something has to change in the system's routing database, or it
	will choose the same bad route again.  This seems to imply
	that all of the hosts must be running routed or EGP, and
	that the gateways must all support it.
Initially I had hoped that all of the intelligence could be put
into the gateways.  However this seems to be incompatible with the
current design of Unix.  Here's how I would do it with TOPS-20:
The gateways would know about each other.  They would exchange
EGP, so they know if the other is up.  Dual-homed hosts would
know that it is better to use the dedicated gateway if it is up.
So any attempt to use a dual-homed host as a gateway would result
in an ICMP redirect telling the sender to try the dedicated gateway,
unless the dedicated gateway is down.  Here is what a normal host
would do:
  - its gateway table would list both the dedicated gateway and
	the dual-homed host.  (If there were losts of gateways
	accessible to it, only 2 or 3 would need to be listed.)
  - when starting a connection, if the system didn't already have
	a route to the destination system, it would send the packet
	to a randomly chosen "prime" gateway.  If it chose the
	wrong one (e.g. a dual-homed host, when the dedicatd
	gateway is up), it would be directed to the right one
	via ICMP redirect.
  - it periodically pings all gateways that it knows about.  If
	one goes down, it is marked as such, and a new route is
	used in the future.
Since we have a mix of Unix and TOPS-20 systems, it looks like
we may have to do either
  - add routed support to TOPS-20
or
  - add EGP support to Unix and TOPS-20.  (This assumes that it is
	practical to use EGP on every host.  I have a suspicion that
	EGP was really only intended for use between gateways.)
or
  - add code to Unix to mark gateways as down when connections
	using them time out.  (It is not clear quite how we
	would find that they are up again.)
  - add code to Unix so that dual-homed gateways issue ICMP
	redirects if they are asked to forward a packet for which
	they know of a better gateway
Does anybody have reason to prefer one of the other approach?

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 86 22:28:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   Bits, Bauds and Hz

This is not really about tcp/ip, but the excerpt came off this newgroup
and someone may find it interesting since most protocols usually get
down to a real comm channel.

> The broadband communications use one 6MHz channel,
> and can handle 10Mbits/sec.  (Yes, it is possible to get more bits in
> a channel than its bandwidth.  This has always seemed to me to violate
> some basic principle, but sophisticated communications technology can
> get more bits/sec than Hz.)

Remember that these types of communication channels are really analog
circuits.  Whereas digital channels have basically only two variables
(binary state and bit duration), analog channels have such variables
as frequency, amplitude, phase change.  Analog channels use these
variables to carry more information in a given unit of time.

9600 4-wire modems still have to communicate over phone circuits which
have a useful bandwidth somewhat over 3kHz.  This is accomplished by
sending 4 bits at a time, 2400 groups/second.  The four bits are
encoded as one of eight phase shifts (3 bits) and one of two amplitudes
(4th bit).  The time unit of a particular modulation state is named
after Baudot and is called a "Baud", and the rate at which the modulation
state changes is the "Baud Rate".  Thus, most 9600 bit/second modems
are not really "9600 Baud" modems.  But, most 300/1200 bit/second
modems use Frequency-Shift-Keying (FSK) where the binary state of the
data directly controls which of two frequencies is being transmitted.
In this case the bit/second rate is the same as the baud rate.

Most broadband systems are based on CATV technology developed for
video distribution.  These systems use a range of frequencies broken
into 6mHz bands.  By modulating the carrier frequency within a 6 mHz
band, each band can carry separate information.  The 802.4 token bus
protocol used in GM's MAP specifications uses two pairs of adjacent
6mHz channels, one pair for transmitting and the other for receiving.
The channel is modulated with a technique called Duobinary AM-PSK
which uses both amplitude and phase to convey information at a
10 mHz rate.

Unless laboratory developments change things, fiber optics will be
used digitally.  A laser will generate monochromatic light which is
either on or off.  But Bell Labs has demonstrated that the light can
be switched (and detected) many billions of times per second over
useful distances.  (24 telephone voice channels only use 1.544 Mbit/sec)

					<Art@ACC.ARPA>

------
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jan-86 01:28:00 EST
From:      art@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   Bits, Bauds and Hz


This is not really about tcp/ip, but the excerpt came off this newgroup
and someone may find it interesting since most protocols usually get
down to a real comm channel.

> The broadband communications use one 6MHz channel,
> and can handle 10Mbits/sec.  (Yes, it is possible to get more bits in
> a channel than its bandwidth.  This has always seemed to me to violate
> some basic principle, but sophisticated communications technology can
> get more bits/sec than Hz.)

Remember that these types of communication channels are really analog
circuits.  Whereas digital channels have basically only two variables
(binary state and bit duration), analog channels have such variables
as frequency, amplitude, phase change.  Analog channels use these
variables to carry more information in a given unit of time.

9600 4-wire modems still have to communicate over phone circuits which
have a useful bandwidth somewhat over 3kHz.  This is accomplished by
sending 4 bits at a time, 2400 groups/second.  The four bits are
encoded as one of eight phase shifts (3 bits) and one of two amplitudes
(4th bit).  The time unit of a particular modulation state is named
after Baudot and is called a "Baud", and the rate at which the modulation
state changes is the "Baud Rate".  Thus, most 9600 bit/second modems
are not really "9600 Baud" modems.  But, most 300/1200 bit/second
modems use Frequency-Shift-Keying (FSK) where the binary state of the
data directly controls which of two frequencies is being transmitted.
In this case the bit/second rate is the same as the baud rate.

Most broadband systems are based on CATV technology developed for
video distribution.  These systems use a range of frequencies broken
into 6mHz bands.  By modulating the carrier frequency within a 6 mHz
band, each band can carry separate information.  The 802.4 token bus
protocol used in GM's MAP specifications uses two pairs of adjacent
6mHz channels, one pair for transmitting and the other for receiving.
The channel is modulated with a technique called Duobinary AM-PSK
which uses both amplitude and phase to convey information at a
10 mHz rate.

Unless laboratory developments change things, fiber optics will be
used digitally.  A laser will generate monochromatic light which is
either on or off.  But Bell Labs has demonstrated that the light can
be switched (and detected) many billions of times per second over
useful distances.  (24 telephone voice channels only use 1.544 Mbit/sec)

					<Art@ACC.ARPA>

------

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      13-Jan-86 14:22:13-PST
From:      jbn@FORD-WDL1
To:        TCP-IP-REQUEST@NIC
Subject:   4.3BSD TCP fixes
      In response to popular demand, I am sending out two fixes to 4.3BSD
(beta release).  Fix #1 affects interoperability with non-4.xBSD systems,
apparently including TOPS-20 machines.  Fix #2 reduces network congestion
on long-haul nets.  (Yes, yet another of Nagle's continuing attempts to
get network congestion under control.)  The effect of #2 is substantial;
in some situations, an order of magnitude improvement in file transfer
speeds will be observed.
      With these in, 4.3BSD TCP behaves quite well.  In 4.3, all the right
machinery is there, but there are a few easily-fixed bugs.
      These fixes are going out via several routes (net.bugs.4bsd, the
Berkeley buglist, and to some key individuals) because they have a marked
effect on interoperability and Internet performance.

				John Nagle
===============================================================================
Index: sys/netinet/tcp_input.c 4.3BSD-beta Fix

Description:
	TCP connections to some non-BSD systems open, but will not
	accept data from the remote system.

	The "advertised window", tcp_adv, was not initialized during
	connection synchronization.  Also, one comparison on sequence
	numbers was made incorrectly, using a difference of unsigned 
	values, which in C is always positive(!).

					John Nagle

Repeat-By:
	Try to establish a TCP connection with a system which sets
	the high bit in the TCP sequence number.  (A 4.3BSD system
	which has been up for more than 195 days will do this, or
	you can change the initial value of tcp_iss to some value
	with the high bit set.)


Fix:
tcp_input.c
327a328,329
> 	 * Be careful with arithmetic here; differences of sequence
> 	 * numbers compare in unexpected ways.  Hence the (int) cast.
329c331
< 	tp->rcv_wnd = MAX(sbspace(&so->so_rcv), tp->rcv_adv - tp->rcv_nxt);
---
> 	tp->rcv_wnd = MAX(sbspace(&so->so_rcv),(int)(tp->rcv_adv-tp->rcv_nxt));
tcp_seq.h:
22a23
>  * Note that our rcv_adv variable needs to be initialized too.
25c26
< 	(tp)->rcv_nxt = (tp)->irs + 1
---
> 	(tp)->rcv_adv = (tp)->rcv_nxt = (tp)->irs + 1
===============================================================================
Index: ucb/netinet/tcp_timer.c 4.3BSD-beta Fix

Description:
	Excessive retransmissions on long-haul nets.  Serious congestion
	in Internet gateways.  File transfer speeds under 10% of expected
	values over 9600 baud point-to-point links.  Angry network
	managers.

	The basic machinery is right but some of the special cases
	are wrong, resulting in bad host behavior on slow links.
	Several problems combine to result in very short retransmit
	intervals:
	1) The smoothed round-trip time is zero until the first
	   successful round-trip without retransmission.  If there
	   is a retransmission of the first packet, the zero value
	   is actually used to compute the round-trip time, resulting
	   in a minumum retransmission time.

	2) The standard backoff algorithm not only backs off rather
	   slowly, but due to an incorrect calculation, the first
	   retransmit interval is 2.0*t_srtt, but the second is only
	   1.0*t_srtt, and not until retransmit #4 or so does the
	   retransmit time get back up to 2*t_srtt.  The supplied
	   "experimental" backoff algorithm backs off at rate 2**n,
	   which reduces retransmits under overload conditions.

					John Nagle

Repeat-By:
	Connect two 4.3BSD systems via a 9600 baud DMR link.  Try a
	big file transfer with ftp(I).  Be prepared for a long wait.

Fix:
tcp_timer.c
112c112
< int	tcpexprexmtbackoff = 0;
---
> int	tcpexprexmtbackoff = 1;		/* use exponential backoff if 1 */
154a155,169
> 		/*
> 		 * Calculate retransmit timer for non-first try.
> 		 * Start with the same value used for the first retransmit.
> 		 * Then use either the table tcp_backoff to scale this up
> 		 * based on the number of retransmits, or if the patchable
> 		 * flag tcpexprexmtbackoff is set, just multiply it by
> 		 * 2**number of retransmits.
> 		 * If t_srtt is zero when we get here, we have never
> 		 * had a successful round-trip and are already retransmitting,
> 		 * which indicates trouble, so we apply a larger initial guess
> 		 * for the round-trip time.  This prevents serious network 
> 		 * overload when talking to faraway hosts, especially when
> 		 * they aren't answering.
> 		*/
> 		if (tp->t_srtt == 0) tp->t_srtt = TCPTV_SRTTRTRAN;
156c171
< 		    (int)tp->t_srtt, TCPTV_MIN, TCPTV_MAX);
---
> 		    (int)(tcp_beta * tp->t_srtt), TCPTV_MIN, TCPTV_MAX);
tcp_timer.h:
60a61,62
> #define TCPTV_SRTTRTRAN ( 10*PR_SLOWHZ)	/* base roundtrip time if retran
> 						   before 1st good roundtrip */
===============================================================================
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jan-86 16:39:54 EST
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        mod.protocols.tcp-ip
Subject:   Re: retransmission timers in TCP

Speaking of 4.3BSD, I have heard that we were not the only beta test
site to experience trouble talking to TOPS-20 machines.  Does anyone
have fixes for 4.3/TOPS-20 TCP/IP problems?  (If so I sure hope you
sent them on to Berkeley....)

Chris

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jan-86 17:21:03 EST
From:      JNC@MIT-MC.ARPA ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Wollongoing subnet support (sic)


	I am visiting some network people at NASA Ames and they are
discussing switching to using subnets for the IP installation.
Apparently one of the main stumbling blocks is the fact that the
Wollongoing software does not support subnets, and they are not
getting much satisfaction from Wollongong on finding out if and when
Wollongong will ever getting around to supporting subnets. As one
of the people who originated the subnet change to the architecture,
I was interested in finding out how it is doing, and in talking
to manufacturers who are being slow in installing it.
	The experience they report (which was duplicated when I tried
to contact someone at Wollongong) is that the people you get when you
call up don't know anything (which you sort of expect), and, moreover,
you can't get ahold of anyone who does know anything. I asked to speak
to someone in engineering to ask about the subnet support issues, and
got shunted to a software support person who wanted to know my license
number and wouldn't talk to me because I wasn't the 'contact point'
for the license number I ws prepared to give her. I gave up on her and
called back and asked to speak to the VP of Engineering or some such
person, and was informed that everyone was 'out to lunch'.
	Does anyone know if Wollongong is ever going to make any
effort to keeping up with the changes in the IP spec? They certainly
don't meet it now, and, from what I understand, don't seem to really
care that they don't. In addition, they have one of the worst
attitudes to people who call in that I have ever heard. I would
recommend that people not deal with such an organization.

	Noel

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jan-86 17:22:13 EST
From:      jbn@FORD-WDL1.ARPA
To:        mod.protocols.tcp-ip
Subject:   4.3BSD TCP fixes


      In response to popular demand, I am sending out two fixes to 4.3BSD
(beta release).  Fix #1 affects interoperability with non-4.xBSD systems,
apparently including TOPS-20 machines.  Fix #2 reduces network congestion
on long-haul nets.  (Yes, yet another of Nagle's continuing attempts to
get network congestion under control.)  The effect of #2 is substantial;
in some situations, an order of magnitude improvement in file transfer
speeds will be observed.
      With these in, 4.3BSD TCP behaves quite well.  In 4.3, all the right
machinery is there, but there are a few easily-fixed bugs.
      These fixes are going out via several routes (net.bugs.4bsd, the
Berkeley buglist, and to some key individuals) because they have a marked
effect on interoperability and Internet performance.

				John Nagle
===============================================================================
Index: sys/netinet/tcp_input.c 4.3BSD-beta Fix

Description:
	TCP connections to some non-BSD systems open, but will not
	accept data from the remote system.

	The "advertised window", tcp_adv, was not initialized during
	connection synchronization.  Also, one comparison on sequence
	numbers was made incorrectly, using a difference of unsigned 
	values, which in C is always positive(!).

					John Nagle

Repeat-By:
	Try to establish a TCP connection with a system which sets
	the high bit in the TCP sequence number.  (A 4.3BSD system
	which has been up for more than 195 days will do this, or
	you can change the initial value of tcp_iss to some value
	with the high bit set.)


Fix:
tcp_input.c
327a328,329
> 	 * Be careful with arithmetic here; differences of sequence
> 	 * numbers compare in unexpected ways.  Hence the (int) cast.
329c331
< 	tp->rcv_wnd = MAX(sbspace(&so->so_rcv), tp->rcv_adv - tp->rcv_nxt);
---
> 	tp->rcv_wnd = MAX(sbspace(&so->so_rcv),(int)(tp->rcv_adv-tp->rcv_nxt));
tcp_seq.h:
22a23
>  * Note that our rcv_adv variable needs to be initialized too.
25c26
< 	(tp)->rcv_nxt = (tp)->irs + 1
---
> 	(tp)->rcv_adv = (tp)->rcv_nxt = (tp)->irs + 1
===============================================================================
Index: ucb/netinet/tcp_timer.c 4.3BSD-beta Fix

Description:
	Excessive retransmissions on long-haul nets.  Serious congestion
	in Internet gateways.  File transfer speeds under 10% of expected
	values over 9600 baud point-to-point links.  Angry network
	managers.

	The basic machinery is right but some of the special cases
	are wrong, resulting in bad host behavior on slow links.
	Several problems combine to result in very short retransmit
	intervals:
	1) The smoothed round-trip time is zero until the first
	   successful round-trip without retransmission.  If there
	   is a retransmission of the first packet, the zero value
	   is actually used to compute the round-trip time, resulting
	   in a minumum retransmission time.

	2) The standard backoff algorithm not only backs off rather
	   slowly, but due to an incorrect calculation, the first
	   retransmit interval is 2.0*t_srtt, but the second is only
	   1.0*t_srtt, and not until retransmit #4 or so does the
	   retransmit time get back up to 2*t_srtt.  The supplied
	   "experimental" backoff algorithm backs off at rate 2**n,
	   which reduces retransmits under overload conditions.

					John Nagle

Repeat-By:
	Connect two 4.3BSD systems via a 9600 baud DMR link.  Try a
	big file transfer with ftp(I).  Be prepared for a long wait.

Fix:
tcp_timer.c
112c112
< int	tcpexprexmtbackoff = 0;
---
> int	tcpexprexmtbackoff = 1;		/* use exponential backoff if 1 */
 154a155,169
> 		/*
> 		 * Calculate retransmit timer for non-first try.
> 		 * Start with the same value used for the first retransmit.
> 		 * Then use either the table tcp_backoff to scale this up
> 		 * based on the number of retransmits, or if the patchable
> 		 * flag tcpexprexmtbackoff is set, just multiply it by
> 		 * 2**number of retransmits.
> 		 * If t_srtt is zero when we get here, we have never
> 		 * had a successful round-trip and are already retransmitting,
> 		 * which indicates trouble, so we apply a larger initial guess
> 		 * for the round-trip time.  This prevents serious network 
> 		 * overload when talking to faraway hosts, especially when
> 		 * they aren't answering.
> 		*/
> 		if (tp->t_srtt == 0) tp->t_srtt = TCPTV_SRTTRTRAN;
156c171
< 		    (int)tp->t_srtt, TCPTV_MIN, TCPTV_MAX);
---
> 		    (int)(tcp_beta * tp->t_srtt), TCPTV_MIN, TCPTV_MAX);
tcp_timer.h:
60a61,62
> #define TCPTV_SRTTRTRAN ( 10*PR_SLOWHZ)	/* base roundtrip time if retran
> 						   before 1st good roundtrip */
 ===============================================================================

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jan-86 19:24:50 EST
From:      rick@NGP.UTEXAS.EDU (Rick Watson)
To:        mod.protocols.tcp-ip
Subject:   Re:  Wollongoing subnet support (sic)

After MUCH telephoning to TWG, I finally talked to John Caughy (spelling?)
who I think is the TCP/IP product Project Manager. (415/962-7177).
He said that neither subnets or name servers will be in the March
release, but that the September (86) release would be based on 
4.3 BSD. I got the idea that they are not interested in doing much
more development on TCP/IP and from their end, they saw little interest
in subnets. They were not even interested in our doing the work for them.

Disclaimer: The above is from brief notes I made during our phone conversation
of a couple of months ago. 

Does anyone know of a GOOD TCP/IP (well supported, etc) product for VMS?
Anyone interested in a public domain (or othersise) TCP/IP for VMS effort? 

Rick Watson
University of Texas Computation Center
 arpa:   rick@ngp.UTEXAS.EDU   rick@ngp.ARPA
 uucp:   ...seismo!ut-sally!ut-ngp!rick   rick@ut-ngp.UUCP
 bitnet: ccaw001@utadnx
 phone:  512/471-3241

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jan-86 20:17:59 EST
From:      JNC@MIT-XX.ARPA ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re:  Wollongoing subnet support (sic)


	I just finally managed to get a hold of someone at the VP
level. He was fairly helpful, but apparently nothing will come out of
the pipe quickly, unless enough customers ask loudly enough. He had
never even heard of the subnet spec, and I had to give him the RFC
numbers. Apparently part of the problem is that there isn't a good
path to get info about changes like this to companies if they aren't
on the Internet. Perhaps a path exists for getting the existing RFC
announcements into a UUCP group, e.g. net.rfcs? That would help these
people. (Also, the subnet stuff is only marked 'recommended' rather
than 'required' both on RFC950 (the subnet spec) and in the Official
IP Protocols list (RFC961). This seems like a poor idea since if a single
implementation at a site is missing it it can be difficult to turn
on subnetting. It's harder to beat on companies to add something if it's
not marked 'required', too..)

	Noel
-------

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jan-86 21:08:49 EST
From:      GEOF@MIT-XX.ARPA (Geoffrey H. Cooper)
To:        mod.protocols.tcp-ip
Subject:   TCP Send buffer constraints destroy datarate



The other day I was playing with Imagen's TCP with a collegue, and we discovered
an interesting thing.  If we decreased the printer box' offered window from 6KB
to 2KB, the source-to-sink datarate transferring from a Vax 4.2 to the printer
increased dramatically (from 30 Kbit/s to 300 Kbit/s).

The reason for this behavior is apparently that the vax allocates only 2K of
buffer space to an outgoing TCP connection.  Thus it can only send 2K before
receiving an Ack.  In the printer box, ACKs are carefully delayed for
1/2 a second to increase piggybacking unless the window is opened.  The window
is opened when it is half consumed (i.e., after about 3KB of data is transferred).
In the vax's case, this allows 2KB of data every 1/2 second, or 32Kbit/s.  This
was just the figure I had been getting.

The general problem is that the window flow control reflects the receiver's buffer
constraints, and there is no way for the sender's constraints to be tr)n{mitted
across the connection.  In the XNS Sequenced Packet Protocol, an ACK bit in a
packet performs this function; it allows the sender to explicitly request an
immediate acknowledgement for the last packet in the "send window."

I've been trying to figure ways to fix the problem.  One algorithm would be to
send the ack after a dally or immediately if the connection's packet input queue is
empty after processing an input packet.  This would allow an entire string of
packets to be received properly and would not tend to cause excessive ack's.
It works well if the TCP process was dequeuing packets at a lower priority
than the internet process was enqueuing them.

This doesn't work in systems like mine which do not have separate processes with
queues between them for TCP connections.  In my case, the TCP module is upcalled
with each packet as a pseudo-interrupt, and all processing takes place either
during the upcall, during the client's downcall to get data, or during a timer
interrupt.  I can check the interface to see if additional packets have arrived,
but it is not assured that they are from the right connection.  Another possibility
is to notice that an ack is being sent after a dally, and decrease the offered window.
This would work (especially since the printer's only application is for bulk data
input), but I am concerned about the lack of generality in the scheme.  For one
thing, there is no way to increase the offered window once it is decreased -- sounds
like a perfect way to develop silly window syndrome.

I'd like to see some other thought on this problem.  How do other implementations
of TCP deal with this situation?  Do they set tight timers? Do they get trapped
by it (be honest...)?

Please respond to the list and sign all messages (otherwise I can't tell where
they come from on usenet-news), my incoming mail is not working well.

- Geof Cooper
  IMAGEN
-------

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jan-86 00:52:23 EST
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   more (possibly too many) thoughts on systems of gateawys

Since my posting yesterday, I have given a bit more thought to the
issue of keeping track of network topology.  I got several responses
acknowledging that the issue was an important and difficult one, but
none proposing any real solutions.  So it seemed worth putting a bit
more thought into the issue. While I haven't come up with any
startling innovations, I think I see a couple of approaches that would
work.  First, let me start by enumerating the possibilities that I
have seen.  We have several issues.  The first is how hosts keep track
of what gateways are up.  The second is how hosts keep track of
changes in gateway status.  The third is how hosts know what gateways
exist.  Of course these are not orthogonal.

Keeping track of what gateways are up:
  pinging - every host sends an echo request to every gateway that
	it knows about every 30 sec. or so.  Most people consider
	this unacceptable because it generates too much network
	traffic.  TOPS-20 does this, though with an interval of
	several minutes.  I believe it must be done every 30 sec.,
	because we have to be able to discover that a gateway is
	down in time to move to another one before connections start
	timing out or users start thinking that the system is down.
  gateway broadcast - every gateway sends a broadcast every 30 sec.
	For a network that supports broadcasts, this gives as good
	results as pinging, but the number of packets is far smaller.
	PUP and XNS gatewayinfo do this.  So does Unix routed.  The
	only disadvantage I can see is that it only works if the 
	network supports broadcasts, and that it may not be so good
	for single-process systems (e.g. IBM PC).  On an IBM PC, you
	can't just have a daemon sitting there keeping track of what
	networks are up.  Telnet could have to wait a minute or two
	gathering gateway information before starting to make the
	connection.
  host broadcast - when a host wants to make a connection, it sends
	a broadcast asking for any gateways to a certain host to
	respond.  This is effectively done now by ARP-hacking gateways.
	Since an ARP is needed anyway to initiate a connection, it
	adds no overhead.  This strategy is appropriate for single-
	process systems.  The only disadvantage I can think of is that
	it only works on media that support broadcast.  Note that in
	a complex network, this stategy requires that the gateways
	have some other way to keep track of each other.  They must
	arrange things so that only the preferred gateway will respond
	to an ARP.

Keeping track of changes.  These techniques would normally be combined
with those above.  
  timeouts - when a connection times out, one has a good suspicion
	that some part of the current route is down.  What to do
	about it depends upon which of the above strategies one is
	using.  If you are using pinging or gateway broadcast, 
	strictly speaking you don't need to do anything about timeouts.
	4.3 uses timeouts because 4.3 establishes a route when a
	connection is opened.  Even if routed has figured out that
	the gateway involved is down, the connection will still try
	to use it.  A timeout triggers the system to reexamine the
	route, using its latest gateway information.  On TOPS-20,
	this is not needed, since the route is recomputed for each
	packet sent.  If you are depending upon a host broadcast
	(e.g. ARP), a timeout should cause the current route (in this
	case ARP table entry) to be removed, so that the host sends
	another broadcast to look for a new route.  Note that timeouts
	do not totally solve the problem of detecting down gateways,
	if we have traffic to some gateway (or for ARP-based schemes,
	host) that is not connection-oriented.  That is, UDP-based
	protocols may not have a concept of timeout, or may find it
	hard to feed back information about timeouts to lower levels
	of the system.
  ICMP redirect - depending upon the design, the system may not know
	when a better route has become available.  Again, TOPS-20
	always will, because it recomputes routes each time, and
	continually pings all gateways.  But 4.2 will not change
	routes during a connection.  And a system that depends upon
	the ARP hack probably doesn't have enough information to do
	so either.  So one can arrange for gateways to keep track of
	each other, and to issue an ICMP redirect if a better route
	becomes available.  Note that this does not necessarily
	require the host to keep track of gateway information.  If
	all of the gateways do the ARP hack, a host can process an
	ICMP redirect simply by removing the ARP table entry for
	the destination host involved.
  ARP table expiration - Unix expires entries in the ARP table after
	N minutes of non-use.  This is primarily intended to keep
	down the number of entries in the ARP table.  However in
	theory this could be used to keep routing up to date.  If
	we expired entries even when they are in use, it would
	force a new ARP request.  This would (we hope) come back
	with the latest routing, taking into account any gateways
	that have come up or gone down.  The problem with doing
	this is that it would increase the number of ARP requests.
	If we only use it to discover better routes, we could afford
	to do it fairly infrequently, say once every 30 min.  If we
	depend upon it to discover gateways that are down, we probably
	have to do it every 30 sec.  This is likely to cause results 
	that are about as bad as pinging.  It would also interfere
	with performance, since our experience shows that waiting
	for an ARP causes a noticable pause in telnet.  Doing this
	once every 30 min is not likely to cause a significant
	load.  Suppose we have 256 hosts on a subnet, each talking
	to 4 other hosts at a time (this is probably a gross
	overestimate for any real network).  That is 1000 ARP
	requests in 1800 sec.  This is a packet rate of around
	1 per second.  That should be tolerable.  However the
	requests are probably not going to be random.  There may be
	a tendency for them to cluster, due to the fact that all of
	the systems will have been rebooted at the same time (the
	last power failure).

Knowledge of network topology.
  builtin tables - this is fairly common, but with a large network
	it becomes a pain to update all the tables.
  gateway broadcasts - the gateway broadcast strategy mentioned
	above also solves this problem, since it allows the host
	to discover what gateways exist simply by monitoring
	broadcasts.
  host broadcasts - the host broadcast strategy mentioned above
	also solves this problem, since the host no longer has to
	know the network topology.  When it needs to make a connection
	it broadcasts a request and the gateways have to figure out
	who should respond.  To use changes in topology, this should be
	combined with ICMP redirects when a better route becomes
	available.
  try a random gateway - TOPS-20 keeps a table with a small number
	of "prime" gateways.  When it wants to make a connection,
	and none of the currently known gateways is right for the
	job, it chooses a random prime gateway.  This gateway is
	expected to know about all of the others, and to issue an
	ICMP redirect to the right one.  However this only works
	if one knows which of the prime gateways are up.  TOPS-20
	uses pinging.  Any other solution to the problem of knowing
	which gateway is up will also solve the problem of knowing
	what gateways there are, so this strategy is probably not
	terribly useful.

Some choices are clear:
  - we probably don't want pinging to be the primary method of
	keeping track of the network.
  - ARPs are probably the only reasonable way for single-process
	machines to find out about the network, since they can't
	be expected to have daemons that keep track of topology.
	This implies that all gateways should be expected to
	support the "ARP hack", even when subnetting is general
	implemented.

Now the question is whether we also want the gateways to broadcast,
a la routed.  My initial reaction is that if we can come up with
a mechanism based on ARPs that will solve all of our problems, there
is no need to run routed or its equivalent on each host.  So first,
let's look at a design based on ARPs, and no protocol like routed.
  - connections are initially established by issuing an ARP
	request.  The gateways arrange to answer these in such a
	way as to give an optimal route.
  - when a connection times out, the ARP table entry for the host 
	involved is removed.  This forces a new ARP for the next
	packet to be sent.
  - when a better route becomes available, it would be helpful
	if the gateway currently being used issues an ICMP
	redirect.  Because of the timing out of ARP table
	entries, this is not completely necessary.
  - if non-connection-oriented protocols are being used (so that
	timeouts are not possible), or if it is not practical
	for gateways to issue ICMP redirects when a better route
	becomes available, ARP table entries must expire after
	30 minutes.


This mechanism is obviously not sufficient for hosts with more than
one Ethernet interface, since they have no way to choose which
interface to use.  ARP's don't help, since in general some other 
gateway will probably be able to find a route to any host on any
subnet, so there will be responses to ARP requests on both interfaces.
However a host with more than one interface is effectively a gateway.
It should participate in whatever protocol is used among the gateways,
probably EGP or routed.

There are several reasons why one might prefer some other mechanism
for hosts that are capable of running daemons:
  - if UDP-based protocols are in heavy use, it may be impractical to
	detect down gateways by depending upon timeouts.  For Suns,
	the Network File System is critical, and that uses UDP.
	While NFS does have a concept of timeout, our experience
	shows that timeouts may indicate a number of conditions
	other than routing failures.  It is not clear whether it
	would be appropriate to clear ARP table entries when there
	is an NFS timeout.
  - one may believe that it is not practical to implement ICMP
	redirect in the gateways when a better route becomes
	available, and that the overhead of expiring ARP entries
	is unacceptable.

If one decides that another scheme is needed other than having the
host broadcast requests, it seems clear that the best alternative is
to have the gateway broadcast the fact that it is up.  In that case,
routed seems to make a lot of sense.  It is widely implemented, and
seems to do what needs to be done.  In a Unix implementation, one also
needs a way to force routes to be recomputed when there is a change in
the gateway table.  The method in 4.3 seems to depend upon timeouts.
I suspect it might be better to have an IOCTL that routed could do to
invalidate routes (either all routes whenever a topology change
happens, or some slightly more selective method).

Unfortunately, the problem I have to solve is not just picking the
combination of strategies that I like the best.  I also have to be
able to live with existing TCP/IP implementations.  Currently Rutgerse
is using 4.2 (Sun, Pyramid, Celerity, Ultrix), TOPS-20, DG, Symbolics,
Bridge, ...  We only have source to some of these, and even where we
do have source, it may not be desirable to do major network development
work.  If we are unable to change the host implementation, then
the advice to a gateway designer is pretty much the obvious:

1) Do the best one can for hosts that will depend upon ARP's to
discover routing.  This means trying to coordinate gateways so
that only the best one responds.

2) Enough systems use code based on 4.2, and routed is a reasonable
enough way of doing things, that it probably makes sense for the
gateways to implement routed.

3) One should probably try to get gateways to issue ICMP redirects
whenever appropriate.  However it is not clear which existing
implementations this is going to help.  Certainly it would help
TOPS-20.  Existing systems that use ARP are pretending that all all of
the hosts are directly connected, so an ICMP redirect is going to be
irrelevant to them.  For Unix systems, ICMP redirect doesn't add much
to what routed already provides (and indeed may even confuse it, if
routed thinks it is managing the gateway tables).  Circumstances where
ICMP redirects could be generated are when a packet is sent to a
gateway that knows it is not the best route.  Len Bosack at Stanford
suggests that gateways should have a command that says we are about to
shut them down.  In that case, they can start issuing ICMP redirects
to an alternate.  (However one has to be careful to avoid loops.  If
the alternate doesn't know you are shutting down, and it is a less
prefered route, it may issue a redirect right back to you.)

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jan-86 01:59:12 EST
From:      karn@MOUTON.ARPA (Phil R. Karn at mouton.ARPA)
To:        mod.protocols.tcp-ip
Subject:   Re: TCP Send buffer constraints destroy datarate

Delaying acknowledgements with timers has always bothered me.  Either the
application will send something in reply almost immediately (e.g., Telnet
echoing) or it will take so long that the acknowledgment timer will expire
with nothing to send, increasing the effective round trip time and limiting
throughput when the windows are small.

In an upcall environment, it would seem better to just note the fact that an
ack is owed and upcall the user, giving him a chance to send some data. Once
the user returns, you immediately invoke the tcp output routine which sends
the ack plus reply data, if any.  This avoids having to set a short timer,
which is often hard to do efficiently in an operating system environment.
Of course, the user cannot be permitted to block.

Another approach is to look at the incoming PSH bit. Since PSH from the
remote TCP usually means "I think my client doesn't have any more data to
send for a while", you could start the acknowledgement delay timer only if
PSH is clear; otherwise you would immediately return an ACK. This would
have the additional advantage of allowing you to acknowledge a burst of
segments with a single response.

Phil Karn

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jan-86 02:25:00 EST
From:      Miyata@MIT-MULTICS.ARPA
To:        mod.protocols.tcp-ip
Subject:   IBMPC-based implementations

Anyone have any experience with TCP/IP implementations for IBM-PCs (and
compatibles)?  If there is sufficient response, I will summarize them
for the distribution.

Thanks,
Gaylord

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jan-86 09:00:42 EST
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        mod.protocols.tcp-ip
Subject:   Re: retransmission timers in TCP

My thanks to John Nagle for an amazingly fast response.  Our telnet
to TOPS-20 troubles have terminated.  Three times thanks.  Ta ta...

Tchris

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      14-Jan-86 14:49:51-PST
From:      jbn@FORD-WDL1
To:        TCP-IP@NIC
Subject:   Short course on DDN to be avoided
     Computerworld this week has an article about the DoD protocol
standards.  It contains such gems as

    ``DOD-issued protocol standards include the following:

    [Sections on IP, TCP, FTP, SMTP deleted. JN]
  
    * Telenet.  A terminal-handling program, GTE Telenet Communications
      Corp.'s Telenet was designed primarily to handle simple asynchronous
      terminals but will also support synchronous terminal traffic.''


					CW, 13JAN86, p. 19

The author of the article, William Stallings (some DC-area consultant) is 
suppposedly conducting a seminar on this at the University of Maryland on 
4-6 June, 1986.  Surely the U of Md can come up with somebody who actually
knows the subject; this guy doesn't even know what the big words mean yet.

				John Nagle

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jan-86 14:53:47 EST
From:      JNC@MIT-XX.ARPA ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: more (possibly too many) thoughts on systems of gateawys

Chuck:

	Some of the issues you raise (e.g. how do hosts find dead
gateways) are already covered in the RFC's Dave Clark wrote for the
Internet Implementor's Guide; the one you want is the one about fault
isolation. The Gateway commitee is working on an RFC about Routing in
the Host IP Layer which talks about the others (e.g. finding gateways,
etc.) We want to insulate the hosts as much as possible from the
details of routing since we are going to be changing that, so having
routing tables sent to hosts is out. Remember also that whatever
mechanisms we use have to also work on nets that do not support
broadcast.

	Noel
-------

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jan-86 16:33:54 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP/IP-request

Please post the following to the net:


Hello out there, we have ordered an IBM DACU to be used as a 
Gateway between our ethernet LAN and IBM (VM/CMS).

The DACU and the VM/CMS program package supports FTP, TELNET and SMTP.
I have  following questions:

  o  Does anyone have any experience in using the DACU as a Gateway
     to UNIX.

  o  We are also looking for a 3270 emulator to be used in combination
     with telnet.

Thanks in advace,

        Jan Andersson                janne@erix.UUCP
	Ericsson Telecom             (...!seismo!enea!erix!janne)

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jan-86 17:49:51 EST
From:      jbn@FORD-WDL1.ARPA
To:        mod.protocols.tcp-ip
Subject:   Short course on DDN to be avoided


     Computerworld this week has an article about the DoD protocol
standards.  It contains such gems as

    ``DOD-issued protocol standards include the following:

    [Sections on IP, TCP, FTP, SMTP deleted. JN]
  
    * Telenet.  A terminal-handling program, GTE Telenet Communications
      Corp.'s Telenet was designed primarily to handle simple asynchronous
      terminals but will also support synchronous terminal traffic.''


					CW, 13JAN86, p. 19

The author of the article, William Stallings (some DC-area consultant) is 
suppposedly conducting a seminar on this at the University of Maryland on 
4-6 June, 1986.  Surely the U of Md can come up with somebody who actually
knows the subject; this guy doesn't even know what the big words mean yet.

				John Nagle

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jan-86 20:10:04 EST
From:      lixia@COMET.LCS.MIT.EDU (Lixia Zhang)
To:        mod.protocols.tcp-ip
Subject:   Re:  Short course on DDN to be avoided

John,

I'm not so sure how CW made such a joke.  I happened to be the reviewer
of one of Stallings' books, "Data and Computer Communications", in which the
author talked both "Telenet" and "Telnet" right (though the INDEX made a mess
on the two words).

Lixia

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jan-86 22:43:34 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Moderated newsgroup

This newsgroup is moderated, and cannot be posted to directly.
Please mail your article to the moderator for posting.
Relay-Version: version B 2.10 5/3/83; site mtsol.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: mtsol!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!hropus!riccb!ihopa!ihnp4!ucbvax!tcp-ip
From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
Newsgroups: mod.protocols.tcp-ip
Subject: a couple of implementation issues
Message-ID: <8601121945.AA19100@topaz.rutgers.edu>
Date: Sun, 12-Jan-86 14:45:28 EST
Article-I.D.:    topaz.8601121945.AA19100
Posted: Sun Jan 12 14:45:28 1986
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 149
Approved: tcp-ip@sri-nic.arpa

I would like to describe Rutgers current network configuration, and then
mention some of the problems we are looking into at the moment.  I would
like to see whether my ideas seem reasonable to this community, and 
whether others have any better approaches.  The major issues will involve
addressing in an environment that uses a mix of Ethernet-level and
IP-level gateways, and how to set up a system with redundant IP gateways
so that it will survive gateway failures.

First, the configuration.  We have 5 Ethernets currently in operation,
with several others coming on line shortly.  Four of them are
connected by an IP gateway built using a design from Stanford.  It is
a 68000 multibus system (Forward Technology SUN board), with 3Com
Ethernet interfaces.  The software handles PUP, IP, and XNS.  It is a
full PUP gateway, handling PUP directories and routing protocols.  IP
support is more limited, including only ARP and ICMP echo.  The IP
support assumes that subnetting is in use, with 8-bit host addresses
and 8-bit subnet addresses.  It implements the "ARP hack", so that
hosts can use it even if they don't know about subnets.  Stanford
estimates a capacity of about 250 packets per second.  However recent
tweaking of the code has probably increased this.  (We haven't pushed
it hard enough to see this limit yet. The only limit we have seen is
that Sun 3's that use NFS through the gateway have to have some
non-default parameter settings.  This is a known problem with the 3Com
Ethernet interface, which also affects some older Sun 2's.) [For
those who may be interested in duplicating this, there are now
commercial equivlents of this gateway.  Proteon sells one that should
be fairly similar, though with higher performance and more IP support.
It should handle EGP.  Len Bosack from Stanford has apparently started
a company that will market a re-engineered version of the Stanford
gateway.  You might also check Bridge Communications and DEC.]

For hosts in isolated buildings, we are installing a broadband cable
system.  We plan to use Applitek Ethernet bridges.  That is, each
building will have an Ethernet.  The Ethernets will be connected via
the broadband cable.  The Applitek bridges work at the Ethernet level.
That is, they watch every packet on the Ethernet.  They dynamically
build a list of all machines on the local Ethernet.  When they see a
packet addressed to a machine that is not on the local Ethernet, they
forward it to the proper Ethernet via the broadband.  (Actually, there
is somewhat more control available if you need it.)  They forward all
broadcast packets to all Ethernets.  We do not yet have throughput
data on it, as the system is new and is still in test.  It does seem
to be able to handle Sun 3 NFS transmissions with default parameter
settings on the Sun.  The Applitek bridges are 68000-based systems,
with a fair amount of hardware in them.  I'm fairly sure there is more
than one 68000 in there.  It uses a modern Ethernet interface, with
its own processor.  The broadband communications use one 6MHz channel,
and can handle 10Mbits/sec.  (Yes, it is possible to get more bits in
a channel than its bandwidth.  This has always seemed to me to violate
some basic principle, but sophisticated communications technology can
get more bits/sec than Hz.)  Our first setup, which will probably be
put in operation this week, will connect two Ethernets, one of which
is also on the gateway described in the previous paragraph.  [If you
are in the market for one of these, other vendors that I know of with
similar products are Proteon and possibly Bridge Communications.  Both
of these products will use IP gateways between the local Ethernet and
their long-haul network.  This has both advantages and disadvantages.
It allows some improvements in support of TCP/IP, but it also means
that you can't handle DECnet and other protocols.]

The first issue is how to set up IP addresses for the Ethernets to be
connected via the Applitek bridges.  Initially we figured that each
Ethernet would be a subnet, just like those connected by the IP
gateway.  However on second thought, I believe that is a mistake.
Consider the following situation.
   subnets 6 and 7 are connected via Applitek bridge
   subnets 4 and 6 are connected via IP gateway
   a host on subnet 6 wants to talk to a host on subnet 7.
The conversation will have to go through the Applitek bridge.  Recall
that this operates at Ethernet level.  That means that the source host
will have to send an Ethernet packet with the final destination's
Ethernet address in it.  In order to find this address, it will have
to issue an ARP.  If the host on 6 knows about subnets, it will
consider subnet 7 to be a separate network.  It will not issue an ARP
to try to find the host.  Rather, it will expect to find a gateway in
its gateway table (or use its default gateway).  With all subnet
implementations that I know, there is no way to tell a host to use a
gateway to talk to subnet 4, but to issue ARP's and talk directly to
subnet 7.  Once you turn on subnetting, it will expect to find
gateways for all subnets.  Obviously we could change this behavior.
But we are reluctant to adopt a network design that violates the
subnetting RFC's, and requires us to make kernel changes to systems that
use it.  Thus we reluctantly conclude that all of the Ethernets that
are connected by the Applitek bridge must be considered a single 
subnet.  I don't much like this, because I think eventually we are
going to end up using IP gateways.  In order to install an IP gateway
between two Ethernets that are currently connected by the Applitek
bridges, we would have to remove the Applitek bridge from one of them,
give it a different subnet number, change the addresses of all of
its hosts, and then install the IP gateway.  Does anyone see something
I am missing?

The second issue involves gateway reliability.  This is not a problem
that is immediately pressing.  The gateway code from Stanford is the
only piece of software I have used that has never crashed.  But now
and then we do take it down for development work, and we do get
complaints from people who are suddenly disconnected.  We have several
Unix systems with more than one Ethernet interface.  These hosts could
act as gateways.  While their performance as gateways would not be as
good as a dedicated 68000 gateway, they would be fine as backup
gateways.  The question is, how do we set things up so that a
connection will move from one gateway to an alternate when the first
one goes down.  4.3 has some hint of the basic ability needed.  When
TCP is about to time out a connection, it first tries to compute a new
route.  However in order for this to help, two things must be true:
  - the system has to know that a gateway is in use.  This means
	that we can't use the ARP hack.  We have to install subnet
	support on all the hosts.
  - something has to change in the system's routing database, or it
	will choose the same bad route again.  This seems to imply
	that all of the hosts must be running routed or EGP, and
	that the gateways must all support it.
Initially I had hoped that all of the intelligence could be put
into the gateways.  However this seems to be incompatible with the
current design of Unix.  Here's how I would do it with TOPS-20:
The gateways would know about each other.  They would exchange
EGP, so they know if the other is up.  Dual-homed hosts would
know that it is better to use the dedicated gateway if it is up.
So any attempt to use a dual-homed host as a gateway would result
in an ICMP redirect telling the sender to try the dedicated gateway,
unless the dedicated gateway is down.  Here is what a normal host
would do:
  - its gateway table would list both the dedicated gateway and
	the dual-homed host.  (If there were losts of gateways
	accessible to it, only 2 or 3 would need to be listed.)
  - when starting a connection, if the system didn't already have
	a route to the destination system, it would send the packet
	to a randomly chosen "prime" gateway.  If it chose the
	wrong one (e.g. a dual-homed host, when the dedicatd
	gateway is up), it would be directed to the right one
	via ICMP redirect.
  - it periodically pings all gateways that it knows about.  If
	one goes down, it is marked as such, and a new route is
	used in the future.
Since we have a mix of Unix and TOPS-20 systems, it looks like
we may have to do either
  - add routed support to TOPS-20
or
  - add EGP support to Unix and TOPS-20.  (This assumes that it is
	practical to use EGP on every host.  I have a suspicion that
	EGP was really only intended for use between gateways.)
or
  - add code to Unix to mark gateways as down when connections
	using them time out.  (It is not clear quite how we
	would find that they are up again.)
  - add code to Unix so that dual-homed gateways issue ICMP
	redirects if they are asked to forward a packet for which
	they know of a better gateway
Does anybody have reason to prefer one of the other approach?

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jan-86 23:25:00 EST
From:      CERF@USC-ISI.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Bits, Bauds and Hz

Art,

about light pipes - recent reports indicate that it is feasible to
modulate light by heterodyning as in radio carriers.  This is an
analog method (as opposed to baseband on/off signalling) which permits
much better signal to noise ratios, longer distances between repeaters,
and increased total bandwidth usable in a single mode fiber which
might otherwise have to use wavelength multiplexing to achieve increased
capacity with multiple channels each running in digital on/off mode.

Vint

P.S. as for 24 telephone channels on the 1.544 Mbps T1, there are
commercial compression systems out (one made by Paul Baran!) which
will put up to 96 voice channels on a single 1.544 mbps T1 link.

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jan-86 10:59:15 EST
From:      leong%ANDREW@PT.CS.CMU.EDU (John Leong)
To:        mod.protocols.tcp-ip
Subject:   re:  Bits, Bauds and Hz


General Interest .....

T1 is the lowest TDM digital transmission rate used by the phone companies
for long line transmission. The standard bit rates are :

DS1  :  1.544M  (24 voice)@*
DS2  :  6.312M  (4 * DS1,  96 voice)@*
DS3  :  44.736M  (7 * DS2, 672 voice)@*
DS4  :  274.176M  (6 * DS3, 4032 voice)

Most DS1 or T1 data are done with twisted pairs. Fibre is normally used
only for DS4 or T4 data rate  which is heavily used for (real long distance)
inter-citiy traffics. 

Leong

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jan-86 11:58:42 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: retransmission timers in TCP

We're running 4.3BSD too, and we also have problems with TOPS-20
systems.

Could you please send me a copy of the note you got from John Nagle so
we can fix it here too?

	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			UCSD B-028, La Jolla, CA 92093 (619) 452-6865

	decvax\ 	brian@sdcsvax.ucsd.edu
	ihnp4  >---  sdcsvax  --- brian
	ucbvax/		Kantor@Nosc 

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jan-86 12:04:20 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: retransmission timers in TCP

Whoops!  Cancel that; they just arrived in the mailing list!

Thanks anyway!
	- Brian

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jan-86 14:11:45 EST
From:      OLE@SRI-NIC.ARPA (Ole Jorgen Jacobsen)
To:        mod.protocols.tcp-ip
Subject:   Implementors step forward!


To make our TCP/IP Implementations and Vendors Guide as complete and
up-to-date as possible, may I ask again that you check the current
file: [SRI-NIC.ARPA]<NETINFO>TCP-IP-IMPLEMENTATIONS.TXT. If you have
(or know of) any other implementations (hardware or software), please
complete and return the attached form to me (OLE@SRI-NIC.ARPA) as soon
as you can. Thanks for your cooperation!

Ole J Jacobsen,  DDN Network Information Center.


------------------------------cut here--------------------------------



                     TCP/IP IMPLEMENTATIONS TEMPLATE

                      DDN Network Information Center
                            SRI International
                           Menlo Park, CA 94025


PRODUCT-OR-PACKAGE-NAME:


DESCRIPTION:




DOCUMENTATION:


CPU:   

	(If product is a *hardware* implementation write the processor
	on which it is based, otherwise "CPU" means computer on which
	software implementation will run)



O/S (OPERATING SYSTEM):


IMPLEMENTATION-LANGUAGE:


DISTRIBUTOR:




CONTACT:


ORDERING-PROCEDURE:


PROPRIETY-STATUS:


------------

   NOTE:  This registry in no way constitutes an endorsement of any 
   product or software package by the NIC, SRI International, or the 
   U.S. government.  It is compiled for informational purposes
   only.



-------

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jan-86 16:53:10 EST
From:      geof@MIT-BORAX.ARPA (Geoffrey H. Cooper)
To:        mod.protocols.tcp-ip
Subject:   Re^2: TCP Send buffer constraints destroy datarate

The idea of giving the application one chance to send data before transmitting
the ack is a good one, but it doesn't solve my problem entirely.  Under
that scheme, TCP would always send an ack for every packet received, either
containing client-level data or not.  I need a scheme that allows the
receiver to send the minimum number of acks that will allow the sender to send 
at full speed.

The idea of using the push bit is also a good one, but I fear that it would
have the same result.  This is because some TCP's almost always set the push
bit, and some other TCP's never forward data to the client unless they see a 
push bit (which is part explaination for the sender's behavior).{_  For 
example, I think that 4.2 unix sends a push bit for every write call, since
it has no way of knowing whether there will be more client-level data or not.
This translates the push bit always being on for most connections (even
bulk data connections like FTP or sending to the printer).
'
Any other ideas?

- Geof
(PS, please continue to post replies to the net.  I still don't receive
incoming mail well, and rely on a usenet news feed.)

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jan-86 16:59:47 EST
From:      geof@MIT-BORAX.ARPA (Geoffrey H. Cooper)
To:        mod.protocols.tcp-ip
Subject:   Getting info to non-arpanauts

Noel Chiappa expressed a concern about getting information to non-arpanet
subscribers about current ideas from the mainstream tcp world.  I think
that his idea of using usenet is a great one.  The TCP-IP list is
carried on usenet as mod.protocols.tcp-ip.  I don't know exactly how
this forwarding is set up (since mod.... means that it is supposed to be 
a moderated list, and I didn't think that the arpanet one was moderated),
but it would be a great boon to those of us who mostly (or entirely) rely
on UUCP links if RFC's were automatically fed down the pipe.  We might
avoid sending very long ones (>60 pages or so) for evfficiency reasons.

[Please respond to the list, since incoming mail is flakey for me
theseedays]

- Geof Cooper
  Imagen

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jan-86 10:30:59 EST
From:      HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   gateway speed

Bill Yeager at Sumex has asked me to correct a miss-statement in
a previous note.  I said that our 68000 gateway, constructed using
plans from Stanford, could handle at least 250 packets per sec.
Bill tells me the real number is 500+ per second.  They routinely
experience 300 packets per second in gateways connected to 3
networks.
-------

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 1986 14:52-CST
From:      HARMAN@STL-HOST1.ARPA
To:        jbn@FORD-WDL1.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Short course on DDN to be avoided
Request future traffic on this subject be routed to DELHD-MI at
STL-HOST1.  This will expedite delivery.  Regards, Dick Harman
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jan-86 15:07:26 EST
From:      cassel@DEWEY.UDEL.EDU (Boots Cassel)
To:        mod.protocols.tcp-ip
Subject:   Tech Report

University of Delaware Department of Computer and Information Sciences
                     Technical Report 86-12 

  Local Area Broadcast Network Measurement: Traffic Characterization

                by      Paul D. Amer
                        Ram N. Kumar
                        Rueybin Kao
                        Jeffrey T. Phillips
                        Lillian N. Cassel
 
                            Abstract

    Eight weeks of traffic were monitored on an Ethernet with five
major hosts and interconnections to another LAN and the ARPAnet.  Over
104.7 million packets consisting of 10+ billion octets were observed.
This paper characterizes the monitored traffic and concludes for our
LAN that the overall arrival of packets on the Ethernet is not Poisson
as often assumed in analytic studies, the bit error rate is low with
periodic bursts caused by faulty hardware and software, the network
load is, as expected, bursty in nature, the packet size distribution
is not bimodal (as observed in other studies), most of the traffic is
generated by network servers (terminal switches), and less than 10% of
the traffic travels outside the local network.

Key words and phrases:  broadcast network, CSMA/CD, Ethernet, local
area network, measurement center, performance evaluation, traffic
characterization, workload characterization.


The technical report is now available. Anyone who would like a copy of
the tech report should send name and address to 

Boots Cassel
cassel@dewey.udel.EDU
or
Department of Computer and Information Sciences
University of Delaware
Newark, DE 19716

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jan 86 15:07:26 EST
From:      Boots Cassel <cassel@dewey.udel.EDU>
To:        tcp-ip@dewey.udel.EDU, trlist@dewey.udel.EDU
Cc:        cassel@dewey.udel.EDU, phillips@dewey.udel.EDU, rkao@dewey.udel.EDU, amer@dewey.udel.EDU, hokuf@dewey.udel.EDU
Subject:   Tech Report
University of Delaware Department of Computer and Information Sciences
                     Technical Report 86-12 

  Local Area Broadcast Network Measurement: Traffic Characterization

                by      Paul D. Amer
                        Ram N. Kumar
                        Rueybin Kao
                        Jeffrey T. Phillips
                        Lillian N. Cassel
 
                            Abstract

    Eight weeks of traffic were monitored on an Ethernet with five
major hosts and interconnections to another LAN and the ARPAnet.  Over
104.7 million packets consisting of 10+ billion octets were observed.
This paper characterizes the monitored traffic and concludes for our
LAN that the overall arrival of packets on the Ethernet is not Poisson
as often assumed in analytic studies, the bit error rate is low with
periodic bursts caused by faulty hardware and software, the network
load is, as expected, bursty in nature, the packet size distribution
is not bimodal (as observed in other studies), most of the traffic is
generated by network servers (terminal switches), and less than 10% of
the traffic travels outside the local network.

Key words and phrases:  broadcast network, CSMA/CD, Ethernet, local
area network, measurement center, performance evaluation, traffic
characterization, workload characterization.


The technical report is now available. Anyone who would like a copy of
the tech report should send name and address to 

Boots Cassel
cassel@dewey.udel.EDU
or
Department of Computer and Information Sciences
University of Delaware
Newark, DE 19716

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jan-86 15:28:19 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: IBMPC-based implementations

In article <860114072549.207020@MIT-MULTICS.ARPA> you write:
>Anyone have any experience with TCP/IP implementations for IBM-PCs (and
>compatibles)?  If there is sufficient response, I will summarize them
>for the distribution.
>
>Thanks,
>Gaylord

I have used the MIT PC/IP package with some degree of success.  I have
largely quit using it, however, in favor of serial protocols like Kermit
because of various problems like:

	1.  Can't upload a file unless it already exists.
	2.  Can't upload a file unless it is accessible by everyone.
	3.  Occasional bit errors.

What I would really like is rcp, rsh, and rlogin on a PC.  Let me
know if you find such.



-- 

Thomas N. Anderson      ...uw-beaver!teltone!tna 
Teltone Corporation, 10801 120th Ave NE, Kirkland, WA 98033 (206) 827-9626
		"This Statement is False."

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jan-86 15:52:00 EST
From:      HARMAN@STL-HOST1.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Short course on DDN to be avoided

Request future traffic on this subject be routed to DELHD-MI at
STL-HOST1.  This will expedite delivery.  Regards, Dick Harman

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jan-86 17:15:37 EST
From:      Haas@UTAH-20.ARPA (Walt)
To:        mod.protocols.tcp-ip
Subject:   SYN with a window size of zero

One of our TCP implementations (TOPS-20) opens a TCP connection
with a segment that contains the usual SYN and a window size of
zero.  According to one interpretation of the spec there should be
no legal response to such a segment since the normal response is
SYN+ACK and the SYN in the response would take up sequence number
space, which does not exist according to the sender of the first
segment.  According to another intepretation, the window size
refers to data octets only, and the sequence number space taken by
SYNs and FINs shouldn't count.

Various implementations handle this in various ways - some apparantly
assume that it's silly to send SYN with a window size of zero, and just
go ahead and reply with SYN+ACK.  One implementation appears to go
into a tight loop in this situation.

Does anybody have any references that would resolve the apparent
ambiguity?  It isn't clear to me how to apply the robustness principle
to this case - one could imagine that an implementation could have
an unusual situation where it needed to open a connection but didn't
at the moment have any place to put a reply.

Thanks in advance for any helpful comments  -- Walt
-------

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jan-86 18:16:27 EST
From:      DP4Q@TE.CC.CMU.EDU (Drew D. Perkins)
To:        mod.protocols.tcp-ip
Subject:   Excelan tcp-ip on VMS

We're thinking about getting a few of the Excelan TCP/IP boards/software
for our 11/780's running VMS.  I remember a few problems mentioned about
their products before, but don't have that mail to refer back to now.
What are peoples experiences with Excelan, and mostly with the current
revision of their software EXOS 8043 3.2?  Also, are there any archives
of tcp-ip mail around?

On another note, by this summer everyone at CMU will have the capability
of having a dedicated 56k bps link from their homes back to CMU, if they
live in one of the surrounding areas nearby.  This service is going to
be provided cheaply by the local telephone company.  We'd like to be able
use these links to extend our IP network from campus to users workstations
at home.  Is there any standard for IP communications over synchronous
links?  Does anyone know of a company that makes boards (preferable multibus)
that have 8 or so syncronous links that go this speed?  Hopefully the board
should be capable of sending and receiving packets at a time in order for
the gateway to handle the traffic.  Something on the order of a Zilog SCC
chip per link.  Is anything like this being done anywhere else?

Drew
-------

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jan-86 18:52:10 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Getting info to non-arpanauts

A year or two ago I posted copies of the IP, ICMP, TCP, UDP, TELNET, and
FTP RFCs, as well as a few other ones like RFC822, to the USENET
net.sources group (which is where big things like that get posted).

It may be time to do that again.  I'll confer with the moderator of the
USENET mod.sources group to see what he thinks, and if he approves, this
will be a reasonable way to spread the gospel.

Wouldn't be too bad an idea if Berkeley would include some of these with
their distribution tape either.  They already send RFC822 (I think) with
it so people will understand the 'sendmail' program better.

	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			UCSD B-028, La Jolla, CA 92093 (619) 452-6865

	decvax\ 	brian@sdcsvax.ucsd.edu
	ihnp4  >---  sdcsvax  --- brian
	ucbvax/		Kantor@Nosc 

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jan-86 21:44:00 EST
From:      CERF@USC-ISI.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: SYN with a window size of zero

Walt,

since one could not successfully "open" a connection without
getting the matching SYN-ACK, it seems appropriate for the
recipient of such a packet to respond, despite the apparent
violation. As you know, it is allowed to send at least one
octet into a closed (0) window to assure that when it
opens you hear that. The SYN can safely elicit an ACK without
opening the window any further.

Depending on the implementation, some systems don't apply the
window size until AFTER the connection has reached the OPEN state
which it cannot get to without first exchanging SYN-ACKs.

Jon Postel will undoubtedly have a reference to page xx para gg
and sugestion to look in one of Dave Clark's marvelous
tutorial sections...

Vint Cerf

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jan-86 02:21:36 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Moderated newsgroup

This newsgroup is moderated, and cannot be posted to directly.
Please mail your article to the moderator for posting.
Relay-Version: version B 2.10 5/3/83; site solar.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!tcp-ip
From: jbn@FORD-WDL1.ARPA
Newsgroups: mod.protocols.tcp-ip
Subject: Short course on DDN to be avoided
Message-ID: <8601150017.AA28089@ucbvax.berkeley.edu>
Date: Tue, 14-Jan-86 17:49:51 EST
Article-I.D.:   ucbvax.8601150017.AA28089
Posted: Tue Jan 14 17:49:51 1986
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 21
Approved: tcp-ip@sri-nic.arpa


     Computerworld this week has an article about the DoD protocol
standards.  It contains such gems as

    ``DOD-issued protocol standards include the following:

    [Sections on IP, TCP, FTP, SMTP deleted. JN]
  
    * Telenet.  A terminal-handling program, GTE Telenet Communications
      Corp.'s Telenet was designed primarily to handle simple asynchronous
      terminals but will also support synchronous terminal traffic.''


					CW, 13JAN86, p. 19

The author of the article, William Stallings (some DC-area consultant) is 
suppposedly conducting a seminar on this at the University of Maryland on 
4-6 June, 1986.  Surely the U of Md can come up with somebody who actually
knows the subject; this guy doesn't even know what the big words mean yet.

				John Nagle

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jan-86 02:22:42 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Moderated newsgroup

This newsgroup is moderated, and cannot be posted to directly.
Please mail your article to the moderator for posting.
Relay-Version: version B 2.10 5/3/83; site solar.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!tcp-ip
From: jbn@FORD-WDL1.ARPA
Newsgroups: mod.protocols.tcp-ip
Subject: Re: retransmission timers in TCP
Message-ID: <8601150355.AA01040@ucbvax.berkeley.edu>
Date: Thu, 9-Jan-86 21:06:52 EST
Article-I.D.:   ucbvax.8601150355.AA01040
Posted: Thu Jan  9 21:06:52 1986
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 46
Approved: tcp-ip@sri-nic.arpa

I had to go into 4.3BSD recently and fix a few bugs here, so I'll document
how 4.3BSD does it, for the benefit of the community.

					John Nagle

The algorithm in 4.3BSD works as follows:

        1.  Round trip times are computed for one packet at a time.
	    Only packets containing data and which are not being retransmitted
	    contribute to the round-trip time calculation.  The timer starts
	    when a data packet is transmitted and no other packet is being
	    timed, and stops when an ACK covers the sequence number of the
	    packet being timed.

	2.  There is a smoothed round-trip timer.  Its value is initially
	    0 and is a smoothed running average of past round-trip times.
	    It is updated at the completion of each successful timing, as
	    described above.
	    The formula is 

			const = 0.1
			srtt = srtt * (1-const) + lastrtt * const;

	    This is actually computed in floating point.
	    On the first round-trip, srtt is simply set to lastrtt.
	    The result is then forced into the range 1 to 30 seconds.
	    [It's possible to use the 0 value if there is no good round-trip
	    before the first retransmit.  This is a bug; see net.bugs.4bsd
	    for a fix.]

	3.  The initial retransmit interval is 2*srtt.  A backoff algorithm
	    then applies.  The standard algorithm is table-driven, and
	    has a table of constants beginning 1.0, 1.2, etc.  These
	    are applied using the number of the retransmit as an index as
	    multipliers to srtt.  There is an alternate algorithm available
	    by patching a flag, which uses srtt*(2^retransmitnumber) as the
	    retransmit interval.  [There's a bug here; there is a multiply
	    by tcp-beta (=2.0) missing in one spot, and the time between
	    the first and second retransmit is shorter than between the
	    original and the first. Again, see net.bugs.4bsd for a fix.]
	    We prefer the alternate algorithm, which backs off faster.

Without the fixes, by the way, things are not good when the round-trip
time on the net actually exceeds one second.

						JN

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jan-86 02:23:17 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Moderated newsgroup

This newsgroup is moderated, and cannot be posted to directly.
Please mail your article to the moderator for posting.
Relay-Version: version B 2.10 5/3/83; site solar.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!tcp-ip
From: lixia@COMET.LCS.MIT.EDU (Lixia Zhang)
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Short course on DDN to be avoided
Message-ID: <8601150110.AA01229@COMET.LCS.MIT.EDU>
Date: Tue, 14-Jan-86 20:10:04 EST
Article-I.D.:    COMET.8601150110.AA01229
Posted: Tue Jan 14 20:10:04 1986
Sender: adrion@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 8
Approved: tcp-ip@sri-nic.arpa

John,

I'm not so sure how CW made such a joke.  I happened to be the reviewer
of one of Stallings' books, "Data and Computer Communications", in which the
author talked both "Telenet" and "Telnet" right (though the INDEX made a mess
on the two words).

Lixia

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jan-86 02:27:52 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Moderated newsgroup

This newsgroup is moderated, and cannot be posted to directly.
Please mail your article to the moderator for posting.
Relay-Version: version B 2.10 5/3/83; site solar.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!tcp-ip
From: tcp-ip@ucbvax.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Moderated newsgroup
Message-ID: <8601150343.AA05178@vax135.UUCP>
Date: Tue, 14-Jan-86 22:43:34 EST
Article-I.D.:   vax135.8601150343.AA05178
Posted: Tue Jan 14 22:43:34 1986
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 166
Approved: tcp-ip@sri-nic.arpa

This newsgroup is moderated, and cannot be posted to directly.
Please mail your article to the moderator for posting.
Relay-Version: version B 2.10 5/3/83; site mtsol.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: mtsol!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!hropus!riccb!ihopa!ihnp4!ucbvax!tcp-ip
From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
Newsgroups: mod.protocols.tcp-ip
Subject: a couple of implementation issues
Message-ID: <8601121945.AA19100@topaz.rutgers.edu>
Date: Sun, 12-Jan-86 14:45:28 EST
Article-I.D.:    topaz.8601121945.AA19100
Posted: Sun Jan 12 14:45:28 1986
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 149
Approved: tcp-ip@sri-nic.arpa

I would like to describe Rutgers current network configuration, and then
mention some of the problems we are looking into at the moment.  I would
like to see whether my ideas seem reasonable to this community, and 
whether others have any better approaches.  The major issues will involve
addressing in an environment that uses a mix of Ethernet-level and
IP-level gateways, and how to set up a system with redundant IP gateways
so that it will survive gateway failures.

First, the configuration.  We have 5 Ethernets currently in operation,
with several others coming on line shortly.  Four of them are
connected by an IP gateway built using a design from Stanford.  It is
a 68000 multibus system (Forward Technology SUN board), with 3Com
Ethernet interfaces.  The software handles PUP, IP, and XNS.  It is a
full PUP gateway, handling PUP directories and routing protocols.  IP
support is more limited, including only ARP and ICMP echo.  The IP
support assumes that subnetting is in use, with 8-bit host addresses
and 8-bit subnet addresses.  It implements the "ARP hack", so that
hosts can use it even if they don't know about subnets.  Stanford
estimates a capacity of about 250 packets per second.  However recent
tweaking of the code has probably increased this.  (We haven't pushed
it hard enough to see this limit yet. The only limit we have seen is
that Sun 3's that use NFS through the gateway have to have some
non-default parameter settings.  This is a known problem with the 3Com
Ethernet interface, which also affects some older Sun 2's.) [For
those who may be interested in duplicating this, there are now
commercial equivlents of this gateway.  Proteon sells one that should
be fairly similar, though with higher performance and more IP support.
It should handle EGP.  Len Bosack from Stanford has apparently started
a company that will market a re-engineered version of the Stanford
gateway.  You might also check Bridge Communications and DEC.]

For hosts in isolated buildings, we are installing a broadband cable
system.  We plan to use Applitek Ethernet bridges.  That is, each
building will have an Ethernet.  The Ethernets will be connected via
the broadband cable.  The Applitek bridges work at the Ethernet level.
That is, they watch every packet on the Ethernet.  They dynamically
build a list of all machines on the local Ethernet.  When they see a
packet addressed to a machine that is not on the local Ethernet, they
forward it to the proper Ethernet via the broadband.  (Actually, there
is somewhat more control available if you need it.)  They forward all
broadcast packets to all Ethernets.  We do not yet have throughput
data on it, as the system is new and is still in test.  It does seem
to be able to handle Sun 3 NFS transmissions with default parameter
settings on the Sun.  The Applitek bridges are 68000-based systems,
with a fair amount of hardware in them.  I'm fairly sure there is more
than one 68000 in there.  It uses a modern Ethernet interface, with
its own processor.  The broadband communications use one 6MHz channel,
and can handle 10Mbits/sec.  (Yes, it is possible to get more bits in
a channel than its bandwidth.  This has always seemed to me to violate
some basic principle, but sophisticated communications technology can
get more bits/sec than Hz.)  Our first setup, which will probably be
put in operation this week, will connect two Ethernets, one of which
is also on the gateway described in the previous paragraph.  [If you
are in the market for one of these, other vendors that I know of with
similar products are Proteon and possibly Bridge Communications.  Both
of these products will use IP gateways between the local Ethernet and
their long-haul network.  This has both advantages and disadvantages.
It allows some improvements in support of TCP/IP, but it also means
that you can't handle DECnet and other protocols.]

The first issue is how to set up IP addresses for the Ethernets to be
connected via the Applitek bridges.  Initially we figured that each
Ethernet would be a subnet, just like those connected by the IP
gateway.  However on second thought, I believe that is a mistake.
Consider the following situation.
   subnets 6 and 7 are connected via Applitek bridge
   subnets 4 and 6 are connected via IP gateway
   a host on subnet 6 wants to talk to a host on subnet 7.
The conversation will have to go through the Applitek bridge.  Recall
that this operates at Ethernet level.  That means that the source host
will have to send an Ethernet packet with the final destination's
Ethernet address in it.  In order to find this address, it will have
to issue an ARP.  If the host on 6 knows about subnets, it will
consider subnet 7 to be a separate network.  It will not issue an ARP
to try to find the host.  Rather, it will expect to find a gateway in
its gateway table (or use its default gateway).  With all subnet
implementations that I know, there is no way to tell a host to use a
gateway to talk to subnet 4, but to issue ARP's and talk directly to
subnet 7.  Once you turn on subnetting, it will expect to find
gateways for all subnets.  Obviously we could change this behavior.
But we are reluctant to adopt a network design that violates the
subnetting RFC's, and requires us to make kernel changes to systems that
use it.  Thus we reluctantly conclude that all of the Ethernets that
are connected by the Applitek bridge must be considered a single 
subnet.  I don't much like this, because I think eventually we are
going to end up using IP gateways.  In order to install an IP gateway
between two Ethernets that are currently connected by the Applitek
bridges, we would have to remove the Applitek bridge from one of them,
give it a different subnet number, change the addresses of all of
its hosts, and then install the IP gateway.  Does anyone see something
I am missing?

The second issue involves gateway reliability.  This is not a problem
that is immediately pressing.  The gateway code from Stanford is the
only piece of software I have used that has never crashed.  But now
and then we do take it down for development work, and we do get
complaints from people who are suddenly disconnected.  We have several
Unix systems with more than one Ethernet interface.  These hosts could
act as gateways.  While their performance as gateways would not be as
good as a dedicated 68000 gateway, they would be fine as backup
gateways.  The question is, how do we set things up so that a
connection will move from one gateway to an alternate when the first
one goes down.  4.3 has some hint of the basic ability needed.  When
TCP is about to time out a connection, it first tries to compute a new
route.  However in order for this to help, two things must be true:
  - the system has to know that a gateway is in use.  This means
	that we can't use the ARP hack.  We have to install subnet
	support on all the hosts.
  - something has to change in the system's routing database, or it
	will choose the same bad route again.  This seems to imply
	that all of the hosts must be running routed or EGP, and
	that the gateways must all support it.
Initially I had hoped that all of the intelligence could be put
into the gateways.  However this seems to be incompatible with the
current design of Unix.  Here's how I would do it with TOPS-20:
The gateways would know about each other.  They would exchange
EGP, so they know if the other is up.  Dual-homed hosts would
know that it is better to use the dedicated gateway if it is up.
So any attempt to use a dual-homed host as a gateway would result
in an ICMP redirect telling the sender to try the dedicated gateway,
unless the dedicated gateway is down.  Here is what a normal host
would do:
  - its gateway table would list both the dedicated gateway and
	the dual-homed host.  (If there were losts of gateways
	accessible to it, only 2 or 3 would need to be listed.)
  - when starting a connection, if the system didn't already have
	a route to the destination system, it would send the packet
	to a randomly chosen "prime" gateway.  If it chose the
	wrong one (e.g. a dual-homed host, when the dedicatd
	gateway is up), it would be directed to the right one
	via ICMP redirect.
  - it periodically pings all gateways that it knows about.  If
	one goes down, it is marked as such, and a new route is
	used in the future.
Since we have a mix of Unix and TOPS-20 systems, it looks like
we may have to do either
  - add routed support to TOPS-20
or
  - add EGP support to Unix and TOPS-20.  (This assumes that it is
	practical to use EGP on every host.  I have a suspicion that
	EGP was really only intended for use between gateways.)
or
  - add code to Unix to mark gateways as down when connections
	using them time out.  (It is not clear quite how we
	would find that they are up again.)
  - add code to Unix so that dual-homed gateways issue ICMP
	redirects if they are asked to forward a packet for which
	they know of a better gateway
Does anybody have reason to prefer one of the other approach?

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jan-86 02:28:23 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Moderated newsgroup

This newsgroup is moderated, and cannot be posted to directly.
Please mail your article to the moderator for posting.
Relay-Version: version B 2.10 5/3/83; site solar.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!tcp-ip
From: CERF@USC-ISI.ARPA
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Bits, Bauds and Hz
Message-ID: <[USC-ISI.ARPA]14-Jan-86.23:25:31.CERF>
Date: Tue, 14-Jan-86 23:25:00 EST
Article-I.D.: <[USC-ISI.ARPA]14-Jan-86.23:25:31.CERF>
Posted: Tue Jan 14 23:25:00 1986
References: <art@acc.arpa>
Sender: adrion@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 15
Approved: tcp-ip@sri-nic.arpa

Art,

about light pipes - recent reports indicate that it is feasible to
modulate light by heterodyning as in radio carriers.  This is an
analog method (as opposed to baseband on/off signalling) which permits
much better signal to noise ratios, longer distances between repeaters,
and increased total bandwidth usable in a single mode fiber which
might otherwise have to use wavelength multiplexing to achieve increased
capacity with multiple channels each running in digital on/off mode.

Vint

P.S. as for 24 telephone channels on the 1.544 Mbps T1, there are
commercial compression systems out (one made by Paul Baran!) which
will put up to 96 voice channels on a single 1.544 mbps T1 link.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jan-86 09:05:22 EST
From:      MRC@SIMTEL20.ARPA (Mark Crispin)
To:        mod.protocols.tcp-ip
Subject:   IP over synchronous links

I too am interested in this.  I have a 2020 with a KMC11/DUP11 (a.k.a.
KDP or DN20-BA) low-speed synchronous interface.  I think the KMC11
microcode does some DDCMP handling; I don't have sources for it.  So I
guess the real question is if there is a de facto standard for IP over
a KDP that is nominally microcoded for DECnet?

Has anybody successfully used TCP/IP over a 1200 baud link?  Is it at
all effective at such a low speed?  I already have TELNET and reliable
file transfer and mail connectivity with "Dialnet" and various tools
(e.g. Kermit).  I'm somewhat worried that TCP/IP at such a slow speed
would introduce enough overhead to reduce my connectivity over "Dialnet",
in which case I might want to hold off until I get a faster modem.
-------

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1986 17:08:17 PST
From:      Dan Lynch <LYNCH@USC-ISIB.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        LYNCH@USC-ISIB.ARPA
Subject:   mod.protocols.tcp-ip
Some thing has gone bonzo and is sending "rejection slips" to
all of us in the TCP-IP mailing list reflected off of SRI-NIC.
It is coming from the bowels of Berkeley.  I doubt each of us
needs to see each message twice along with a canned tougue lashing
that is entirely inappropriate.  This just started happening so
would the person who caused it to start cause it to stop?


Many thanks,
Dan
-------
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jan-86 20:08:17 EST
From:      LYNCH@USC-ISIB.ARPA (Dan Lynch)
To:        mod.protocols.tcp-ip
Subject:   mod.protocols.tcp-ip

Some thing has gone bonzo and is sending "rejection slips" to
all of us in the TCP-IP mailing list reflected off of SRI-NIC.
It is coming from the bowels of Berkeley.  I doubt each of us
needs to see each message twice along with a canned tougue lashing
that is entirely inappropriate.  This just started happening so
would the person who caused it to start cause it to stop?


Many thanks,
Dan
-------

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jan-86 21:58:18 EST
From:      bzs@BOSTONU.CSNET (Barry Shein)
To:        mod.protocols.tcp-ip
Subject:   Re: IBMPC-based implementations


>I have used the MIT PC/IP package with some degree of success.  I have
>largely quit using it, however, in favor of serial protocols like Kermit
>because of various problems like:
>
>	1.  Can't upload a file unless it already exists.
>	2.  Can't upload a file unless it is accessible by everyone.
>	3.  Occasional bit errors.
>
>What I would really like is rcp, rsh, and rlogin on a PC.  Let me
>know if you find such.
>Thomas N. Anderson      ...uw-beaver!teltone!tna 

Obviously your problem is not really PC/IP but the way TFTP works. A while
back I modified our 4.2bsd TFTP to add the following capability:

	On a WRQ or a RRQ if there are strings past the mode
	they are assumed to be a login-name/password to be used,
	the fork from the server changes to that person's home
	directory and sets itself to be that user (setuid/setgid
	in UNIX.) Otherwise the default rules apply.

For example:

	RRQ thesis/chapter1\0netascii\0bzs\0passwd\0
(where \0 means a null byte)

I needed this because we had lisp machines and my own IP/UDP/TFTP
implementations for the 3B2 and the mentioned restrictions would be,
well, too restrictive for use, they didn't have TCP. It's all
backwards compatible, if I were you I would consider this with your
administration (there are security problems but they are worse in my
opinion the old way, in fact my server currently *demands* a legal
login/password, I just wouldn't run it at all without the addition.)

It requires a few minor changes to server and client, I would suggest it
(is this too far out of spec to be accepted? I think TFTP is almost
useless w/o it for the user these days. The TFTP RFC also mentions that
extensions are appreciated, here's one...[I realize diskless nodes are
using TFTP to boot, that's a slightly different issue but manageable.])

	-Barry Shein, Boston University

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jan 86 21:58:18 est
From:      Barry Shein <bzs%bostonu.csnet@CSNET-RELAY.ARPA>
To:        tcp-ip@sri-nic.csnet
Subject:   Re: IBMPC-based implementations

>I have used the MIT PC/IP package with some degree of success.  I have
>largely quit using it, however, in favor of serial protocols like Kermit
>because of various problems like:
>
>	1.  Can't upload a file unless it already exists.
>	2.  Can't upload a file unless it is accessible by everyone.
>	3.  Occasional bit errors.
>
>What I would really like is rcp, rsh, and rlogin on a PC.  Let me
>know if you find such.
>Thomas N. Anderson      ...uw-beaver!teltone!tna 

Obviously your problem is not really PC/IP but the way TFTP works. A while
back I modified our 4.2bsd TFTP to add the following capability:

	On a WRQ or a RRQ if there are strings past the mode
	they are assumed to be a login-name/password to be used,
	the fork from the server changes to that person's home
	directory and sets itself to be that user (setuid/setgid
	in UNIX.) Otherwise the default rules apply.

For example:

	RRQ thesis/chapter1\0netascii\0bzs\0passwd\0
(where \0 means a null byte)

I needed this because we had lisp machines and my own IP/UDP/TFTP
implementations for the 3B2 and the mentioned restrictions would be,
well, too restrictive for use, they didn't have TCP. It's all
backwards compatible, if I were you I would consider this with your
administration (there are security problems but they are worse in my
opinion the old way, in fact my server currently *demands* a legal
login/password, I just wouldn't run it at all without the addition.)

It requires a few minor changes to server and client, I would suggest it
(is this too far out of spec to be accepted? I think TFTP is almost
useless w/o it for the user these days. The TFTP RFC also mentions that
extensions are appreciated, here's one...[I realize diskless nodes are
using TFTP to boot, that's a slightly different issue but manageable.])

	-Barry Shein, Boston University

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Jan-86 03:42:36 EST
From:      Lepreau@UTAH-20.ARPA (Jay Lepreau)
To:        mod.protocols.tcp-ip
Subject:   Re: SYN with a window size of zero

This recently came up in another context: the TAC's put garbage in the
window field in their initial SYN, all the way up to 64K.  This raised
havoc with some of our hosts which remembered the max window size they'd
ever seen.  I talked to the TAC folks at BBN who maintained that since
the window is only defined relative to the ack seq number, the window is
meaningless unless ACK is set, and therefore it's not their bug, it's
ours.  Sounds plausible, so we fixed it here.  (A zero initial window
is quite good behavior, in contrast with the TAC's, which are clearly
violating the robustness principle.)
-------

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Jan-86 18:22:28 EST
From:      Vivian@SRI-NIC.ARPA (Vivian Neou)
To:        mod.protocols.tcp-ip
Subject:   TCP-IP mailing list

Until I can figure out which address is causing the rebroadcast of
the list to itself, I will be hand filtering the messages to this
list.  

Vivian Neou
-------

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19-Jan-86 16:06:56 EST
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: IP over synchronous links

In response to the message sent  Fri 17 Jan 86 07:05:22-MST from MRC@SIMTEL20.ARPA

Mark,

I know of several ad-hoc synchronous gizmos used to pipe IP grams from one
host/gateway to another, including one suggested in RFC-892 which has been used
for several years around here. However, we have found DDCMP most popular, primarily
because DMA hardware is readily available for the PDP11 (DMV11 for the Q bus).
The U Michigan folk also have a nifty interface board for the Q bus that runs
LAPB. I suspect several other folk have done similar things.

TCP/IP is completely reasonable with most (but not all) implementations known
to me at 1200 bps. In fact, I have used these protocols over amateur AX.25
packet-radio links at 1200 bps when one packet in four died. However, some
famous TCP implementations croak dismally via such paths, especially when the
implementor has not read RFC-889.

Dave
-------

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19-Jan-86 23:58:14 EST
From:      tcs@USNA.ARPA (Terry Slattery)
To:        mod.protocols.tcp-ip
Subject:   Excelan tcp-ip on VMS

> We're thinking about getting a few of the Excelan TCP/IP boards/software
> for our 11/780's running VMS.  I remember a few problems mentioned about
> their products before, but don't have that mail to refer back to now.
> What are peoples experiences with Excelan, and mostly with the current
> revision of their software EXOS 8043 3.2?  Also, are there any archives
> of tcp-ip mail around?

I have installed Excelan's TCP/IP front-end-protocol hardware/software
on several 2.9BSD Unix PDP11's at the Naval Academy.  I can't comment
on the VMS installation, but will try to shed some light on the
implementation.

Excelan makes several boards for Unibus, Q-bus, Multibus, and VME-bus.
In terms of operation and capabilities, they are all identical.  An on
board 80186 CPU, ethernet chip, and SEEQ xcvr chip do most of the
work.  (The Unibus board is quite nice, Quad height, 5.5 amps total
current.)  When operated in link level mode, an on board PROM based
kernel communicates with the host to transfer packets between the host
and the wire.  The driver is somewhat similar to the DEC DEUNA driver in
that the host and interface communicate via a set of message buffers
(organized in circular queues). In this mode, the measured throughput is
60Kbytes per second of user data from memory to memory between two Vax
780 processors with a cpu load of about 50% (BRL Vax Unix; based on
4.2BSD).

When operated in front-end mode, the on board PROM module implements
a skeleton operating system in which the TCP/IP network code module
can execute.  The net code is RAM resident and is generally downloaded
to the board at boot time.  (Avoid the 128Kb RAM configuration board
for front-end operation; the additional memory is used for buffering
to increase performance.)  The host communicates with the net code via
four device drivers and a set of library routines.  The library
implements the 4.1a network semantics which are sufficient for most
applications.

At the application level, they supply Telnet, FTP, rlogin, rcp, rsh,
and rwho.  The rlogin and telnet daemons run in the card for performance
reasons.  This implies that their rlogin daemon doesn't handle automatic
authentication. They currently don't have an SMTP server, but I'm told
that they are seriously considering one so that they have a full
implementation.  ARP, ICMP echo, and ICMP redirect are also supported.
Gateways are supported and routes are determined by incoming ICMP
packets or can be built manually with a maintenance program that they
supply.  (The older version 3.1 couldn't handle gateways.  In fact,
version 3.1 would crash if it received a packet from a host with a
different net address.  The 3.1a network module fixes this serious
flaw.  Anyone running Excelan software which says that the net module is
version 3.1 should contact their supplier for the 3.1a version. )  The
board status (things like ethernet collisions, etc) can be polled using
another program.  Sub-nets are not supported but I have mailed them some
of the recent discussion and suggested that they work on it.  I have
measured the data rate of the PDP11 to Vax at 60Kbytes/sec for memory to
memory transfers.

Having ported their old 3.1 version and then beta tested the 3.2 version
before its release, I found that they significantly cleaned up the code
in their port to RSX and VMS.  (I did find some additional bugs, but
they have been reported and presumably fixed.  Most of the ones I found
would have appeared only on a machine like the PDP11 with its restricted
addressing.)

I'm quite pleased with my decision to use the Excelan cards.  I've had
no problems with the hardware and their software and documentation has
improved significantly.  Excelan has been quite helpful. Why didn't I
chose CMC cards?  They didn't have a shippable product at the time I
needed the cards.  Excelan's presence in the market seems to have been
hurt a bit by the time they spent in getting the VMS/RSX ports done, but
it has probably helped their code significantly.  The next release is
supposed to increase the performance.  Now, if they just had an SMTP
server for VMS, I'd buy it for our VMS machine.

	-tcs
	Terry Slattery	  U.S. Naval Academy	301-267-4413
	ARPA: tcs@usna.arpa
	UUCP: decvax!brl-bmd!usna!tcs

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Jan 86 23:58:14 EST
From:      Terry Slattery <tcs@USNA.ARPA>
To:        dp4@cmu-cc-te.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Excelan tcp-ip on VMS
> We're thinking about getting a few of the Excelan TCP/IP boards/software
> for our 11/780's running VMS.  I remember a few problems mentioned about
> their products before, but don't have that mail to refer back to now.
> What are peoples experiences with Excelan, and mostly with the current
> revision of their software EXOS 8043 3.2?  Also, are there any archives
> of tcp-ip mail around?

I have installed Excelan's TCP/IP front-end-protocol hardware/software
on several 2.9BSD Unix PDP11's at the Naval Academy.  I can't comment
on the VMS installation, but will try to shed some light on the
implementation.

Excelan makes several boards for Unibus, Q-bus, Multibus, and VME-bus.
In terms of operation and capabilities, they are all identical.  An on
board 80186 CPU, ethernet chip, and SEEQ xcvr chip do most of the
work.  (The Unibus board is quite nice, Quad height, 5.5 amps total
current.)  When operated in link level mode, an on board PROM based
kernel communicates with the host to transfer packets between the host
and the wire.  The driver is somewhat similar to the DEC DEUNA driver in
that the host and interface communicate via a set of message buffers
(organized in circular queues). In this mode, the measured throughput is
60Kbytes per second of user data from memory to memory between two Vax
780 processors with a cpu load of about 50% (BRL Vax Unix; based on
4.2BSD).

When operated in front-end mode, the on board PROM module implements
a skeleton operating system in which the TCP/IP network code module
can execute.  The net code is RAM resident and is generally downloaded
to the board at boot time.  (Avoid the 128Kb RAM configuration board
for front-end operation; the additional memory is used for buffering
to increase performance.)  The host communicates with the net code via
four device drivers and a set of library routines.  The library
implements the 4.1a network semantics which are sufficient for most
applications.

At the application level, they supply Telnet, FTP, rlogin, rcp, rsh,
and rwho.  The rlogin and telnet daemons run in the card for performance
reasons.  This implies that their rlogin daemon doesn't handle automatic
authentication. They currently don't have an SMTP server, but I'm told
that they are seriously considering one so that they have a full
implementation.  ARP, ICMP echo, and ICMP redirect are also supported.
Gateways are supported and routes are determined by incoming ICMP
packets or can be built manually with a maintenance program that they
supply.  (The older version 3.1 couldn't handle gateways.  In fact,
version 3.1 would crash if it received a packet from a host with a
different net address.  The 3.1a network module fixes this serious
flaw.  Anyone running Excelan software which says that the net module is
version 3.1 should contact their supplier for the 3.1a version. )  The
board status (things like ethernet collisions, etc) can be polled using
another program.  Sub-nets are not supported but I have mailed them some
of the recent discussion and suggested that they work on it.  I have
measured the data rate of the PDP11 to Vax at 60Kbytes/sec for memory to
memory transfers.

Having ported their old 3.1 version and then beta tested the 3.2 version
before its release, I found that they significantly cleaned up the code
in their port to RSX and VMS.  (I did find some additional bugs, but
they have been reported and presumably fixed.  Most of the ones I found
would have appeared only on a machine like the PDP11 with its restricted
addressing.)

I'm quite pleased with my decision to use the Excelan cards.  I've had
no problems with the hardware and their software and documentation has
improved significantly.  Excelan has been quite helpful. Why didn't I
chose CMC cards?  They didn't have a shippable product at the time I
needed the cards.  Excelan's presence in the market seems to have been
hurt a bit by the time they spent in getting the VMS/RSX ports done, but
it has probably helped their code significantly.  The next release is
supposed to increase the performance.  Now, if they just had an SMTP
server for VMS, I'd buy it for our VMS machine.

	-tcs
	Terry Slattery	  U.S. Naval Academy	301-267-4413
	ARPA: tcs@usna.arpa
	UUCP: decvax!brl-bmd!usna!tcs
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jan 86 08:12:05 cst
From:      ulysses!uahcs1!ingr!dorf@ucbvax.berkeley.edu
To:        uahcs1!tcp-ip
Subject:   Re:  Wollongoing subnet support (sic)
I am interested in a public domain TCP/IP for VMS (or what ever). I have
not seen anything good though. Let me know if you do...

David Dorfmueller		ihnp4!akgua!ingr!bldg11!dorf
(205) 772-6162




-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 86  1504 PST
From:      Joe Weening <JJW@SU-AI.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   TCP question
Suppose the following happens:

	Host A			Host B
	----------		----------
	Sends SYN
	Enters SYN-SENT state
				Receives SYN
				Enters SYN-RECEIVED state
				Sends SYN ACK, but packet is lost
	Retransmits SYN
				Receives SYN

The second SYN received by host B is out of the window, so my reading of
RFC 793 is that host B should send an ACK and drop the segment (bottom of
page 69).  But this way, host A never receives a SYN from host B.

Have I missed something?  It seems that Host B should reply with another
SYN ACK when it receives a SYN in the SYN-RECEIVED state (maybe after
checking to make sure the sequence number on the SYN is one less than the
current RCV.NXT), but I can't find this anywhere.  Our implementation
actually acts as described above, and I'd like to fix it.

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      20-Jan-86 16:35:49-PST
From:      jbn@FORD-WDL1
To:        TCP-IP@NIC
Cc:        jbn@FORD-WDL1
Subject:   Re: 1200 baud links
     I have tried IP/TCP over a 1200 baud link.  I advise against it.  It
can be made to work, if all hosts and gateways using the path are 
very well-behaved.  If my previously-posted fixes are put into 4.3BSD,
it may indeed work between two 4.3BSD sites.  General attachment to
the Internet will definitely NOT work.
     Operation at 9600 baud is quite workable, and we've been doing it for
years.  We still have trouble with bad host implementations, but we talk
routinely, using FTP, TELNET, and SMTP, to many Internet sites, over a
path with three concatenated 9600 baud links.
     As dial-up modems approach 9600 baud and TCP/IP implementations for
PCs become available, dial-up Internet service may start to appear.  Anybody
thinking seriously about this yet?  Clearly there are naming and addressing
problems, but I think that the congestion problem can be managed.  See RFC970
for details.

					John Nagle
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jan 86 22:10:34 est
From:      romkey@BORAX.LCS.MIT.EDU (John Romkey)
To:        TCP-IP@NIC
Cc:        jbn@FORD-WDL1
Subject:   1200 baud links
The first net interface we supported in PC/IP was the PC's serial line
using (of course) our own packet framing protocol over the serial
line. The protocol is rather stupid in some ways (it's very wasteful
of bytes), but it has worked fine for several years. We also
implemented it for the C Gateway so that the PC's could talk to the
rest of the world. We haven't done much with it since Ethernet and
proNET cards became available for the PC; our interest was mostly in
doing a TCP/IP implementation for the PC, not in investigating serial
line dialups to the Internet, but that gateway is still there. It's
two major uses now are some leased 9600 baud lines going to faculty
members houses and a 1200 baud dialup modem that's on it that some
people used to use to do file transfers. Getting the TFTP timeout
algorithm to work well with line speeds varying from 1200 baud to
56kbps to 10Mbps (well...) was a bit of a challenge...

The gateway supported 8 serial lines; we used a very simple addressing
scheme. We assigned a whole subnet number to the serial lines and then
gave them host numbers 1 through 8. The gateway had a host number on
that subnet as well. Since we tend not to name PC's around here, there
was never a problem with "Jerry Saltzer's home PC" changing its
internet address (actually, the 9600 baud ports are all dedicated,
anyway, so the addresses wouldn't change).
					- John Romkey
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jan 86 22:34:21 est
From:      romkey@BORAX.LCS.MIT.EDU (John Romkey)
To:        tcp-ip@sri-nic.arpa
Subject:   IBMPC-based implementations
>    From: hplabs!hplsla!tikal!tna@ucbvax.berkeley.edu (Tom Anderson)
>
>    I have used the MIT PC/IP package with some degree of success.  I have
>    largely quit using it, however, in favor of serial protocols like Kermit
>    because of various problems like:
>
>    1.  Can't upload a file unless it already exists.
>    2.  Can't upload a file unless it is accessible by everyone.
>    3.  Occasional bit errors.
>
>    What I would really like is rcp, rsh, and rlogin on a PC.  Let me
>    know if you find such.

Thanks to Barry Shein who already pointed out that most of these are
just problems with TFTP itself. Actually, there shouldn't ever be bit
errors; if you have a reproducable problem with PC/IP's TFTP where
files get corrupted, let me know and I'll try to fix it. Maybe you
were TFTP'ing with a 4.2 machine? 4.2 as shipped had *lots* of
problems with TFTP and UDP checksums that might have caused bit errors.

Having a real FTP would also solve your problems, and I know somewhere
where you'll be able to get that, rcp, rsh and rlogin for the PC
"soon". Some of the original authors of PC/IP have formed a company
that will be commercially selling and supporting an "enhanced" (read:
"lots of bugs fixed and some new programs") version of PC/IP. If you
want more information, get in touch with them. The company's address
is:
	FTP Software, Inc.
	PO Box 150
	Kendall Square Branch
	Boston, MA  02142

Not sure of the phone number right now. Please forgive them if they're
slow in responding to requests for information right now; they
(honestly, *we*) are just getting organized now. If there's enough
interest, I'll post a message describing what is supported in FTP
Software's version of PC/IP (if you want to know, mail directly to
me...), but I'd rather not right now 'less it be misconstrued as
advertising.
				- John Romkey
				  romkey@borax.lcs.mit.edu

Disclaimer: I *am* strongly associated with FTP Software, so anything I
say is quite prejudiced...

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 86 11:49:49 PST (Tue)
From:      Milo S. Medin (NASA ARC Code ED) <medin@orion.ARPA>
To:        tcp-ip@sri-nic.arpa
Subject:   OMB and ISO

A friend of mine here at Ames met with a representative of OMB (Office
of Management and Budget) last week while I was in USENIX, and was told
that OMB is drafting a requirement that all computers bought by
the Federal Government (including DoD) will be required to speak
the "ISO" protocol (meaning TP-4 etc...).  He said it should be
out in the next couple of months.  The idea is apparently to save bunches
of money by forcing everyone to use 1 communications protocol.  Has anyone
else heard about this?  This could be a VERY bad thing.  Also, the
vendors that OMB were talking to were very reluctant to start working
on the ISO stuff right now, and OMB wanted to encourage them to start doing
so quickly.  


						Milo Medin
						NASA Ames Research Center
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 1986 18:01:06 EST
From:      MILLS@USC-ISID.ARPA
To:        romkey@MIT-BORAX.ARPA, TCP-IP@SRI-NIC.ARPA
Cc:        jbn@FORD-WDL1.ARPA, MILLS@USC-ISID.ARPA
Subject:   Re: 1200 baud links
In response to the message sent  Mon, 20 Jan 86 22:10:34 est from romkey@BORAX.LCS.MIT.EDU 

John & Co.,

Interestingly enough, our ubiquitous Fuzzballs support your IBM PC
protocol for the same reason - to provide a handy-dandy way to access the
Internet from random spots, including 1200-bps packet-radio channels. In point
of fact, we haven't tamed the PC timeouts to deal properly with radio
channel congestion, but they work fine with direct serial connection at speeds
as low as 1200 bps. Each "PC gateway" module is implemented as a single-line
device driver with configured IP address.

Having said that, you should not construe my pragmatics as endorsing the
serial protocol itself for proliferated use.

Dave
-------
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jan 86 04:00 EST
From:      Miyata@MIT-MULTICS.ARPA
To:        "Milo S. Medin" <medin@ORION.ARPA> (NASA ARC Code ED)
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: OMB and ISO
See National Research Council's Report to the Department of Defense and
the National Bureau of Standards "Transport Protocols for Department of
Defense Data Networks", National Academy Press, February 1985.  The
Executive Summary is in RFC 939.
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1986 10:31:02 PST
From:      POSTEL@USC-ISIB.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   re: OMB and ISO


> See National Research Council's Report to the Department of Defense
> and the National Bureau of Standards "Transport Protocols for
> Department of Defense Data Networks", National Academy Press, February
> 1985.  The Executive Summary is in RFC 939.

The full report is RFC-942.

--jon.
-------
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Wed 22 Jan 86 09:57:18-EST
From:      "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
To:        jbn@FORD-WDL1.ARPA, TCP-IP@SRI-NIC.ARPA
Cc:        JNC@XX.LCS.MIT.EDU
Subject:   Re: 1200 baud links
	One thing I'd advise for slow speed links is header compression.
Two sequential TCP packets on a connection look pretty much alike, and
if you only send the bytes that are different you wind up with
substantially smaller packets. For interactive typing, this makes a big
difference.

	 Dave Reed at MIT was one person who noticed this, and he took
some statistics on which patterns of repeated bytes were most common.
He proposed using a 'type byte' to identify the 250 most common patterns
of commonality (the extras were for various flags, etc). He was going to
compare the packet to the previous one, figure out which pattern applied
best, and send the pattern number and the changed bytes; the packet
would then be reassembled into the previous form at the far end.
He also had a framing system that had only one byte per packet of
overhead for sequential packets, and there are tricky issues like
needing a checksum on the *uncompressed* data otherwhise things can
get out of synch, etc.
	He wrote a note describing this but I don't think it is
available online.  If you want a copy (and please don't ask unless you
are really interested, since the supply is limited) send a message to
"Staton@xx.lcs.mit.edu", asking for "RFC 248, Improving Internet
Protocol Performance on Low Speed Lines".

	I implemented the bulk of his proposal on the serial line code
for the Portable C Gateway; this has been in service on the 4800 baud
link to Proteon for several years, and works well. It was measured to
reduce the amount of bytes actuallly sent down the wire by about 50%
over a 2 month period! This is a figure averaged over *all* traffic,
including mail and file transfer!
	We used a slightly different scheme for the compression, since I
couldn't figure out an easy algorithm to pick the best pattern (he
didn't give one)! I simply used a 32 bit mask, one bit for each of the
first 32 bytes; you sent the mask, the changed bytes, and the rest of
the packet. It was easy to compute the mask, and on a 4800 baud line I
didn't need to squeeze every drop of compression out. (I think I figured
out that 32 was almost as good as 48, even though the TCP header is
40 bytes, since many of the 8 bytes that are missed change from packet
to packet, and you have to have an extra two bytes to mask to charge
against the savings.)

	Noel
-------
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jan 86 14:40:31 pst
From:      hplabs!sdcrdcf!psivax!nrcvax!andre@ucbvax.berkeley.edu (Andre Hut)
To:        psivax!tcp-ip, mod.protocols.tcp-ip
Subject:   Re: SYN with a window size of zero

MIL-STD-1778 (Transmission Control Protocol) Section 9.4.6.3.23
on generating a SYN specifies that when a SYN is sent without
an ACK, the window is set to 0.

Is this standard adhered to, or has it been abandoned for
something else?

-----------------------------------------------------------------------------

                                ihnp4-\
                sdcsvax-\              \
Andre' Hut              sdcrdcf!psivax!nrcvax!nrcutah!andre
                hplabs--/              /                
                         ucbvax!calma-/

Network Research Corporation
923 Executive Park Dr. Suite C
Salt Lake City, Utah 84117
-----------------------------------------------------------------------------
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 86  2020 PST
From:      Joe Weening <JJW@SU-AI.ARPA>
To:        CERF@USC-ISI.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP question
Vint,

Thanks for your explanation and I'm sorry for bothering the list with this.
The SYN ACK packet should indeed be retransmitted.  I definitely observed
that this was not happening, but unfortunately it's hard to reproduce and
find out why.  In any case, it seems to be a bug with our implementation
and not the protocol.

						Joe

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jan 1986  17:48 EST
From:      "Karen R. Sollins" <sollins@XX.LCS.MIT.EDU>
To:        arpanet-bboards@MC.LCS.MIT.EDU, tcp-ip@SRI-NIC.ARPA, msggroup@BRL-AOS.ARPA, header-people@MC.LCS.MIT.EDU, namedroppers@SRI-NIC.ARPA, info-nets@OZ.AI.MIT.EDU
Subject:   IMPORTANT NOTICE ABOUT MC.LCS.MIT.EDU
Many rumors have been spreading about MC.LCS.MIT.EDU.  The following are the
facts:
* The maintenance contract on the machine will be discontinued at the end
  of March.

* MIT will continue to support the mail and mailing list activities that
  have run historically on MC.  After the end of March this service will
  reside on other hardware that will be named MC.LCS.MIT.EDU.

* The KL-10 will not evaporate immediately, although its name and possibly
  internet address will change.

			Karen R. Sollins
			Director of Computing Resources
			MIT/Laboratory for Computer Scinece
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1986 23:05-PST
From:      William "Chops" Westfield <BillW@SU-SCORE.ARPA>
To:        JNC@XX.LCS.MIT.EDU
Cc:        jbn@FORD-WDL1.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   Re: 1200 baud links
RFC914 discusses various means of using TCP/IP over "thin"
transmission lines, doing thing along the lines that others
have suggested (only sending changed header bytes, etc).
It was written by dave Farber and some others...

BillW
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1986 21:50-EST
From:      CERF@USC-ISI.ARPA
To:        JJW@SU-AI.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP question

In theory, once both hosts have orignated SYN packets, they will treat
these as "occupying address space and therefore require ACKS and must
be retransmitted until ACK received."  What this means is that the
host that went into SYN-RECEIVED state, when it gets another SYN,
can respond with the appropriate ACK (namely indicating what sequence
number it is expecting next). This is always a legitimate response.

The SYN that was lost will also have to be retransmitted by the host
that sent it (host B) upon finding by timeout, for instance, that the
original SYN (pun intended) was not acknowledged.  I believe it is
correct that this retransmission of the lost SYN/ACK need not be correlated
with ACK responses to SYNs sent from host A.  That is, Host B may send
ACKs for the packets it receives from Host A independently of retransmitting
its unacknowledged SYN.

The concept of the retransmitted SYN from HOST A being out of B's received
window sounds wrong-headed.  Since ACKS are cumulative (acking all previously
received packets) an ACK from HOST B asserting what it is next expecting,
implicitly ACKs the SYN from A as well.

It has been a while since I looked carefully at the TCP state diagrams,
and I don't have the material at hand, so I may be missing something here,
but that's my recollection.

Perhaps one of the current internet gurus like Jon or Dave M or Dave C
might comment further.

Vint
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1986 21:58-EST
From:      CERF@USC-ISI.ARPA
To:        medin@ORION.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: OMB and ISO
Milo,

The OMB requirement may not be as damaging as it sounds if it simply
requires the vendors to support ISO but doesn't CONSTRAIN them to only
ISO.  I would imagine IBM would be pretty fierce if it was told the
government could not make use of SNA... or DoD was told that operational
networks protecting national security suddenly had to switch to an
untested implementation...

The thing to watch out for is a directive which prohibits all protocols
except ISO.  Considering the present state of implementation and test
of that protocol suite, there is still a long way to go before it is
reasonable to consider it robust.

I hope I am not being too sanguine, here. Perhaps another reader
will contribute further insights on this no doubt well-intended
bit of bureaucracy.

Vint Cerf
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      22 JAN 86 22:54-EST
From:      WITLICKI%WILLIAMS.BITNET@WISCVM.WISC.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: OMB and ISO
   Could someone please post a brief summary about TP-4 ?

   Is it really an *improvement* over TCP/IP (i assume that is what
it would replace).  Or is it merely Invented By The ISO and Part Of
The Holy Heptad ?

   Is there interoperability between TCP/IP and TP-4 or would one
be faced with a switchover?

 - Randy Witlicki   Williams College, Williamstown, Massachusetts
   Witlicki%Williams.Bitnet@Wiscvm.ARPA
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 1986 06:48-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        JJW@SU-AI.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP question
And the answer is...

Host B will retransmit the SYN upon time out since host A never sends an
ACK accounting for host B's SYN.  THe SYN is considered part of the
sequence space and has to be handled like any other byte of unacknowledged
data.  You might want to see the TCP mill std (mil-std-1778) pgs 151 and 152
which shows some of the hair you need to consider when retransmitting
SYNs.  Mike

(Oh yeah, proper behavior for Host B when it recieves a duplicate SYN
is to reply with an ACK segment and drop the incoming, duplicate SYN)
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jan 86 16:15:54 -0500
From:      Craig Partridge <craig@LOKI.ARPA>
To:        Vshank%Weizmann.bitnet@wiscvm.wisc.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   re: Tp4

> Can anyone summerize the differences between Tcp/Ip and Tp4?  I would
> be interested in a sort of chart showing what Tc/Ip can do that Tp4 can't
> and visa versa.

    When I asked about this of some people locally who were heavily involved
with TP4 I seem to recall they said that TP4 was designed to offer all
the functions that TCP offers.  This was a while ago so I may well
mis-remember (someone please correct me if I am wrong).

Craig Partridge
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jan 86 16:27:43 -0500
From:      Gary Delp <delp@huey.udel.EDU>
To:        William Chops Westfield <BillW@su-score.ARPA>
Cc:        JNC@xx.lcs.mit.EDU, jbn@ford-wdl1.ARPA, TCP-IP@sri-nic.ARPA f-troup@huey.udel.EDU
Subject:   Re: 1200 baud links

>> RFC914 discusses various means of using TCP/IP over "thin"
>> transmission lines, doing thing along the lines that others
>> have suggested (only sending changed header bytes, etc).
>> It was written by dave Farber and some others...

	The others were Gary Delp and Tom Conte.  Hard copies are
available upon request.  

	An alternative to header compression is discussed at the end
of the RFC.  In the paper it is called thinwire III, but as the header
compression gives at best 2:1 IP level compression, we have abandoned
thinwires I, and II, and are continuing this work with thinwire II as
the only thinwire. (confusing enough?)

	 In some instances, the linking of machines at the IP level is
not what is desired.  When only "tcp user services" are needed, using
a gateway which provideds the tcp/ip/udp processing on the fast side
of the 1200 baud baud link is not only sufficient, it is *much*
better.

	We are putting together a gateway which provides these
services to dialup clients.  Maybe TCP/UDP connection server would be
a more accurate title.

regards,

Gary Delp
140 Evans Hall
Department of Electrical Engineering
University of Delaware
Newark DE 19716
(302) 451-6653  messages at 2405
delp@huey.udel.edu
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jan 1986 11:31 O
From:      Henry Nussbacher, <Vshank%Weizmann.BITNET@WISCVM.WISC.EDU>
To:        <tcp-ip@sri-nic.ARPA>
Subject:   Tp4
Can anyone summerize the differences between Tcp/Ip and Tp4?  I would
be interested in a sort of chart showing what Tc/Ip can do that Tp4 can't
and visa versa.  Also, can someone tell me the full name for RFC942 on
SRI-NIC so that I can FTP it.

Thanks,
Hank
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jan 86  8:28:18 EST
From:      Alex McKenzie <mckenzie@BBNH.ARPA>
To:        tcp-ip@sri-nic.arpa
Subject:   TP4 and TCP
TP4 is intended to be functionally equivalent to TCP.  The NBS and BBN people
who worked in the ANSI and ISO committees defining the OSI Transport protocols
were all familiar with TCP and had, as an explicit goal, getting TP4 to be as
close to TCP functionality as they could manage.  In fact, the inital NBS
proposal was for ANSI and ISO to adopt TCP as it stood.

The biggest differences I can remember offhand are:

-For the purposes of allowing fragmentation, TCP numbers every byte.  TP4
allows (requires) the two implementations to negotiate a maximum fragment size.
Every message is broken into fragments of this size (only the final fragment of
the message may be shorter) and numbers these fragments.  [Silly window syndrome
is not likely.]  The motivation here was primarily to make the reassembly task
as easy as possible, with fixed buffer pools and no byte shifting.  A secondary
motivation was to reduce the size of the field used to hold the number.

-TP4 and TCP both allow a receiver to specify a zero window.  TCP treats this
as a "hint" and handles the loss of an ACK which opens the window by source
probes.  TP4 strongly discourages probing a zero window and provides a
reliability mechanism for the ACK which opens a closed window.  The motivation
here is that the designers felt that a system might close windows when it was
overloaded and really didn't want to spend ANY cycles processing traffic from
the sources it had closed.

-TCP (as I recall) has an "urgent" bit in the header of all data which, if set,
tells the receiver to scan ahead looking for something special.  TP4 has an
"expedited" flow of limited capacity which is completely separate from the
regular flow.  [The expedited flow allows one outstanding message of up to 16
octets, I think.]

I hope this helps,
Alex McKenzie

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jan 86 14:09:08 est
From:      swanson@EDN-VAX.ARPA (John Swanson)
To:        tcp-ip@sri-nic.ARPA
TCP-TP4
The ISO Transport Protocol Class 4 was designed to provide services
similar to TCP i.e. a reliable transport medium, it does not provide 
an intranet service (ISO has its own IP).  The TP4 services are similar
with notable execptions.  TP4 offers a true out-of-band signaling
capability which can only simulated in TCP.  However, TP4 does not have
the ability to do graceful close, so that an Application that would
need to have that capbility would have to incorperate that function
above TP4.  
The protocols are not similar and therefore a conversion will
be necessary.  Hoever, the real question is once one goes to
TP4 what does that buy you.  Is the OMB going to require/suggest that
the rest of the ISO suite also be adopted or are we going to be
running FTP over TP4?
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Fri 24 Jan 86 17:58:11-EST
From:      Geoffrey H. Cooper <GEOF@XX.LCS.MIT.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        imagen!geof@DECWRL.DEC.COM
Subject:   SUN V2 tcp checksum problems
In the 2.2 release of Imagen's TCP code the printer accepts TCP segments
of 1425 bytes.  The latest version of the SUN network software (2.x?) 
sends these segments with a bad tcp checksum.  The checksums are random,
not just off by one or two.  A Vax 4.2 sending the same file with the
same sender program to the same printer also sends 1425 byte segments,
but the tcp checksums in these are accepted by the printer.  Also, I
tried two different checksum subroutines on the SUN packets (one with
fancy unrolled loops, and one with a simple tight loop).  Both indicated
the same computation and both rejected the same segments.  Finally, I 
took a look at the network statistics on a vax that is often connected to 
SUN's.  Guess what?  There were several hundred bad TCP checksums recorded.
Apologies in advance if it turns out that the problem is mine, but the
evidence points quite strongly to the SUN.

To generate the full sized segments you must attempt to write more than 1425
bytes at once.  I did it by calling write with 2048 byte blocks.  I have
empirically determined that calling write with smaller values (e.g., 512
bytes) does not exercise the bug.

Has anyone else seen this?  (does anyone else request such large and odd
sized segments from a SUN?)  If there is anyone from SUN out there who
would like to track down the problem, I will be more than happy to help.  
Contact me through IMAGEN (408)986-9400 or at decwrl!imagen!geof or
imagen!geof@decwrl.

- Geof Cooper
  IMAGEN
-------
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1986 18:29-EST
From:      CERF@USC-ISI.ARPA
To:        WITLICKI%WILLIAMS.BITNET@WISCVM.WISC.EDU
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: OMB and ISO

my opinion, biased as it may be, is that TP-4 is simply part of the
Holy Heptad as you so wonderfully put it.  There is no interoperability
between TCP and TP although there has been some work, I believe by 
the Canadian Defense Research Establishment, on an on-the-fly conversion
concept. I do not believe this has ever been implemented.  John Robinson
at DREO (Def Res Est Ottawa) is the point of contact.  An Interoperability
task force, sponsored by ARPA, has taken this up as one of many topics
arising in interoperability of protocol systems. Jon Postel may be
able to point to some on-line material available on the subject.

Vint

P.S. as to whether TP-4 is an improvement over TCP, I think one has
to see what the implementation and operational experience with TP-4
is - it has not been implemented and used in nearly as many 
circumstances as TCP, so it is rather hard to say.  The National
Academy of Science study (RFC942) was more sanguine about the
equivalence of the two protocols than I am, but I supposed I cannot
be considered an unbiased source of opinion!
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 86 18:57:23 GMT
From:      Bob Stine <stine@edn-vax.arpa>
To:        tcp-ip <tcp-ip@sri-nic>
Subject:   Re: Tp4
One of the major differences between TCP and TP-4 is
in the support of passive opens.  As related on p.16 of
RFC 942, TP-4 "passes a Call Indication to a user entity
whenever a Call Request is received."  But, it is left
as ".. an implementation decision as to how TP-4 finds
and/or creates an appropriate user entity to give the
Call Indication...".  In other words, there is "... no
Listen Service Primitive."  This should make implementation
of server processes interesting.

Also, though TP-4 allows for the transmission of up to
16 octets of "expedited data," it has no equivalent of
the TCP 'push.'  'Push' is useful for supporting record
oriented or transaction oriented applications.  Each
expedited data PDU of TP-4 requires a separate ack, which
could lead to high control traffic overhead if this option
is overused.

Another difference that could impact protocol developers is
the fact that TP-4 uses negotiated "segment sizes" (max
allowable TPDU sizes), rather than octets, as its unit of
space allocation.  Inappropriate segment sizes could result
in over-allocation, and under utilization, of available
memory resources (e.g., tinygrams could be stored in blocks
of 512 bytes).

Many of the other differences between TCP and TP-4 have to
do with what TP-4 has not yet specified.  In particular,
"... the use of addresses at different levels in the ISO
model has not yet been solidified ... addressing capabilities
similar to TCP's will EVENTUALLY be provided by TP-4 ..."
(p.15, RFC 942, emphasis added).

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jan 86 17:31:14 -0800
From:      Marshall Rose <mrose%NRTC@USC-ECL.ARPA>
To:        CERF@USC-ISI.ARPA
Cc:        WITLICKI%WILLIAMS.BITNET@CRYS.WISC.EDU, TCP-IP@SRI-NIC.ARPA
Subject:   Re: OMB and ISO
    Although it's still in the embryonic stage, some work's being done
    to specify and implement a TCP socket for ISO session.  This is
    misleading, actually the approach is to present a Transport-Service
    Access Point (TSAP) to applications which run over TCP/IP
    internetworks.  A draft RFC is in the writing and a prototype 4.2BSD
    implementation is running now.  Of course, until I can get my hands
    on some real ISO session/presentation/application programs, I really
    can't judge the merits of the approach.

    Along separate lines, I had heard (third hand, sigh) that Berkeley
    was going to be working on ISO stuff for a future release of BSD
    UNIX and that they thought they might try their hand at a TCP/TP4
    gateway as a way of familiarizing themselves with the ISO protocols!
    Now this same third hand source gave me some bum information on
    another topic dealing with Berkeley and networking, so I won't put
    too much faith on it until someone from UCB says something.

/mtr

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Sat 25 Jan 86 18:35:18-PST
From:      Vivian Neou <Vivian@SRI-NIC.ARPA>
To:        tcp-ip-rebroadcast@SRI-NIC.ARPA
Cc:        vivian@SRI-NIC.ARPA
Subject:   TCP-IP mail yesterday
I don't mean to seem ungrateful, but please stop sending me copies of
the messages that went out yesterday with the list prepended to it.
I am aware of the problem, and I think it has been fixed.  Thanks.

Vivian
-------
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Sun 26 Jan 86 19:02:07-PST
From:      Jeannie Siegman <SIEGMAN@SUMEX-AIM.ARPA>
To:        bboard@SRI-KL.ARPA, bboard@AI.AI.MIT.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   LAN Consultant Position at Stanford
Experienced professional to serve as networking consultant to academic
departments of the University.  Assist users with requirements definition,
planning and operatingng LAN's, and connecting them to SUNet (Stanford's
cross-campus video and data network).  Prerepare configurations and
bid requests oversee installation, teach, give demonstrations, write and 
review networking documents.  Test new products and recommend support
strategies.

Qualifications:  working experience with Ethernet, micro nets.  Prefer
some broadband experience.  Excellent written and oral expression.
Ask for detailed job description.  Dynamic work environment, competitive
salary, and excellent benefits.

Full-time, immediate opening.
-------
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 86 21:42:13 PST (Sun)
From:      karels@monet.berkeley.edu (Mike Karels)
To:        TCP-IP@sri-nic.arpa
Subject:   Re: OMB and ISO
Marshall,

I think you should stop paying that third-hand source for information
about Berkeley plans.  If someone here was planning an ISO protocol
implementation and a TCP/TP4 gateway (whatever such a beast might be),
I think I would have heard of it.

		Mike
		(Berkeley CSRG)
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jan 86 17:54:01 -0800
From:      Marshall Rose <mrose%NRTC@USC-ECL.ARPA>
To:        Mike Karels <karels%monet@UCBVAX.BERKELEY.EDU>
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: OMB and ISO
Yes, well it's good I don't pay anyone for any of that info!  It was
yet-another-rumor-floating-around-usenix-that-I-didn't-attend-but-got-reported-
back-to-me.

Thanks for clearing it up,

/mtr


-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      27-Jan-86 04:43:50-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   Network Time Protocol update
Folks,

Several faithful clockwatchers who desiged and built synchronized clocks based
on the RFC-958 Network Time Protocol (NTP) have suggested revisions and
additions to the specification. An updated copy of RFC-958 incorporating these
suggestions and others on impelmentation techniques is available for ANONYMOUS
FTP in the MILLS directory at ISID and called RFC958.DOC.

Mike Petry kindly pointed out a bug in the Fuzzball NTP servers which was
easily fixed, but might glitz some client implementations that do not follow
the RFC-958 suggestions closely. Specifically, the Fuzzball servers formerly
copied the Originate Timestamp field of the request into the same field of the
reply; however, for correct symmetric-mode operation, they should (and now do)
copy the Transmit Timestamp field into the Originate Timestamp field instead.
If unsymmetric-mode client programs copy the transmit time into all three
timestamp fields of the request, as suggested in RFC-958, this change will be
transparent.

The following message from Milo Medin shows where updated copies of the Unix
servers now live.

Dave

---Beginning of forwarded message(s)---

Return-path: <medin@orion.ARPA>
Received: from orion.ARPA by DCN6.ARPA ; 26-Jan-86 23:02:02-UT
Received: by orion.ARPA (5.28/1.2)
	id AA00418; Sun, 26 Jan 86 15:01:31 PST
Message-Id: <8601262301.AA00418@orion.ARPA>
To: mills@dcn6.arpa
Subject: Re: Star time
In-Reply-To: Your message of 26-Jan-86 22:26:24-UT.
	     <8601262237.AA00331@orion.ARPA>
Date: 26 Jan 86 15:01:29 PST (Sun)
From: Milo S. Medin (NASA ARC Code ED) <medin@orion.ARPA>


Dave, I've fixed the code so that things work again.  No big deal at all.
You can tell everyone to ftp the code from orion, login anonymous password
foo, and that its in pub/time, as usual.   It really was pretty trivial
to fix, so they might just recompile it themselves, but its available
here in any case...

					Milo

PS What all changes did you make in the fuzzball ntp server?  I'd like
to put them into ntpd as well.

PPS  Have you had a chance to attack a 4.3 implementation with
a fuzzball and inspect it for glitches?  I know UMD has mimsy (I
believe running 4.3)  and my machines of course...
---End of forwarded message(s)---
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Mon 27 Jan 86 14:22:54-PST
From:      Vivian Neou <Vivian@SRI-NIC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Direct distribution is back
I think the problem with the list getting remailed back to the
list has been fixed, so I'm switching the list back to a direct
distribution format.

Vivian
-------
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jan 86 15:37:36 EST
From:      Mike Muuss <mike@BRL.ARPA>
To:        Henry Nussbacher <Vshank%Weizmann.BITNET@wiscvm.wisc.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Tp4
The only real concern about the ISO protocols is the current lack of
support for security and precedence, which are defined (but only
minimally implemented) in IP already.
	-Mike
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1986 22:17:03 EST (Monday)
From:      T. Michael Louden (MS W422) <louden@mitre-gateway.arpa>
To:        tcp-ip@sri-nic
Cc:        louden@mitre-gateway.arpa
Subject:   RE: TP4
Mike Muuss missed one concern.
In TCP the checksum takes 10-15% of the CPU cycles.
In TP4 it takes 67%!!!!
This has a big performance impact.
Otherwise performance is similar.

-Mike Louden
Louden@MITRE
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 86 07:41:40 est
From:      swb@devvax.tn.cornell.edu (Scott Brim)
To:        ibm-nets%bitnic.bitnet@wiscvm.wisc.edu, tcp-ip@sri-nic.arpa
Subject:   Enhancing Wiscnet
(For those of you who don't know what Wiscnet is: it's the University
of Wisconsin's TCP/IP networking software for IBM systems running
VM/SP.)

We at Cornell are feeling a strong need to improve Wiscnet's overall
functionality and performance.  It's a great start but it's just not
robust enough for heavy use in a production environment.  We'd like to
start up a conversation with other sites that use Wiscnet.  What are
your plans for fixing bugs?  dealing with performance?  improving
reliability?  adding functionality (like subnetting and ARP)?  Wiscnet
is becoming critical to a goodly number of users here.  We would like
to share not only lists of problems, but also improvements, with anyone
and everyone, in order to avoid redundant effort.  We're also curious
about the levels of commitment and effort going on out there.  How many
people are in the position we are, where we absolutely have to do
something about it?  Is there anyone considering a total re-write of
Wiscnet (we certainly are!)?  If you are not, what levels of
performance, reliability and functionality are you aiming for, and what
are your plans for getting there?

We hope this conversation will end up being highly beneficial to all of
us.  Please write,
					Thanks ...... Scott
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 86  12:14 PST
From:      Greg Minshall <MINSHALL%UCBCMSA@BERKELEY.EDU>
To:        swb@devvax.tn.cornell.edu
Cc:        ibm-nets%bitnic.bitnet@wiscvm.wisc.edu, tcp-ip@sri-nic.arpa
Subject:   Enhancing Wiscnet
Scott,

I don't understand about enhancing WISCNET for ARP.  It HAS ARP already.

We did subnet enhancements, which we have fed back to Wisconsin.

There is a need for an enhanced product, with support and continuing
development.

Greg
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 1986 1031-EST
From:      Kevin Paetzold <PAETZOLD@MARLBORO.DEC.COM>
To:        tcp-ip@sri-nic
Subject:   802.3
I have a couple of questions about 802.3/802.2 TCP/IP protocol suite 
implementations.  

First off i am curious as to how ARP has been implemented under 802.3 (eg.
which SAP does it use?)  Does anyone know of any existing 802.3 
implementation that uses the 16 bit addressing "feature" of 802.3?

   --------
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 86 12:30:12 EST
From:      jas@proteon.arpa
To:        PAETZOLD@MARLBORO.DEC.COM
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: 802.3
I rattled this cage with respect to 802.5 a while ago. Basically,
the regulators of SAP's will not provide another one of the 64
globally-defined SAP's for ARP. Period. If Tony Lauck's scheme
to extend the SAP space to 48 bits goes through 802.1/802.2,
then one of those would be avaiable. What currently is done by
CMU for their PC/IP on the 802.5 board is to just steal
one of the "unadministered" SAP's. Any SAP with the
low two bits 0 is unadministered, and not a broadcast SAP.

What we need to do is wait for IBM to publish which unadministered
SAP's they used for SNA. When that happens, we know which ones
to dodge, and can just use some other one for the time being.

I don't know exactly which SAP CMU used. Do you remember, Drew?

					John Shriver
					Proteon
-------

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 86 13:23:03 EST
From:      Mike Muuss <mike@BRL.ARPA>
To:        tcp-ip@sri-nic.arpa
Cc:        DCAb602@ddn1.arpa
Subject:   Bad Network Performance
From 1312 to 1315 today (Tuesday 28-Jan-86), I was obtaining wretched
service from the network, between BRL and Berkeley.

PINGing between BRL-SAW (192.5.23.33) and UCBVAX.berkeley.edu (10.2.0.78)
----ucbvax.berkeley.edu PING Statistics----
198 packets transmitted, 82 packets received, 58% packet loss
round-trip (ms)  min/avg/max = 6500/18939/28080

An average of 18.9 seconds from Maryland to California!  Awful!

The only thing that I could reliably determine was that the problem
was not on our end;  PINGs from SAW to BRL-GATEWAY ran at a constant
10-20 ms, and PING from SAW to BRL-TAC (which includes the Gateway->IMP
access line, and MILNET IMP --> MILNET TAC) were running 50-80 ms.
This rules out interface blocking or processor overload in our gateway.

Anybody care to speculate on the cause of this?  Any indications
as to future trends?
	-Mike
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 86 17:25:59 EST
From:      John Leong <leong%ANDREW@PT.CS.CMU.EDU>
To:        Kevin Paetzold <PAETZOLD@MARLBORO.DEC.COM>
Cc:        tcp-ip@sri-nic.arpa, postel@usc-isif.arpa, ira%upenn.csnet@csnet-relay.arpa
Subject:   Re: 802.3

We have TCP-IP running on the PC's (PC, PC-XT, PC-AT and the PC-RT)
using the IBM (802.5 superset) token ring.

During the implementation, we encountered the problem of assigning SAP
to ARP. After a number of exchanges with Postel and Ira Winston (aurthor
of RFC 948), we came to a conclusion that this is not going to get resolved
in a hurry, we just pick a random number for ARP for our implementation.

The way I will like to see it done is as follows : [using the bit ordering
convention as defined in fig.3-2a of IEEE 802.2-1985 spec]


For IP packets : 

DSAP     01 10 0000         SSAP     00 10 0000

For ARP packets :

DSAP    01 10 0000          SSAP     00 01 0000

This is really to say, in view of the fact that SAP is really used as
protocol ID,  having two SAP fields is pretty redundant. (Can't image
an SNA SAP meaningfully sending to an IP SAP).  In which case, we bastardise
the SSAP field to denote whether the IP 'family' packet [as denoted
by the DSAP] is for IP or ARP or IP trailer or whatever .....

This does not conflict with any standard since (1) 802.2 does not define
the relationship between  DSAP and SSAP and (2) our SSAP encoding does
not conflict with 802.2 standard.

I will like to receive comment from on the above and if I do not get
jump upon too heavily, I may submit it as an RFC (amendment to 948).

John Leong@*
leong@@h.cs.cmu.edu

P.S.  In RFC943 (Assigned Number), the DSAP for IP is given as binary
0110000 or decimal 96. It is actually incorrect. It is really 01100000
in IEEE terminology or 00000110 in binary or 6 in decimal.  

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 86 20:25:55 EST
From:      jas@proteon.arpa
To:        leong%ANDREW@PT.CS.CMU.EDU
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Re: 802.3
The last 802.2 / 802.1 meeting approved Tony Lauck's extension
scheme for SAPs. Basically, if you have a DSAP of 01010101
(10101010 for those of us who think forwards, or AA hex),
then the next 5 (?) bytes of the packet after the SAPs are
an extension of the DSAP. These would be administered just like
the 48-bit addresses. Now we need to find out how to get a 48-bit
DSAP for ARP. Of course, I hate variable length headers, and we
could steal an unadministered DSAP.

I, too, am completely mystified by the use and purpose of SSAPs.
I would not want to jump too quickly at the scheme of stealing it,
as CMU went through the 802.5 interface to the IBM board, rather
than the 802.2 interface. It works, but is it really the
cleanest way to go. IBM may not allow you to demulitplex on
DSAP and SSAP, or may not pass up the SSAP to the network layer.
I bet we need to wait until IBM releases the manuals, which apparently
wont't be until April 1, 1986. (Some definition of first quarter 1986!)
-------

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jan 86 08:27 EST
From:      Ira Winston <Ira%upenn.csnet@CSNET-RELAY.ARPA>
To:        John Leong <leong%ANDREW%pt.cs.cmu.edu@csnet-relay.arpa>, Kevin Paetzold <PAETZOLD%marlboro.dec.com@csnet-relay.arpa>
Cc:        tcp-ip%sri-nic.arpa@csnet-relay.arpa, postel%usc-isif.arpa@csnet-relay.arpa, ira%upenn.csnet@csnet-relay.arpa
Subject:   Re: 802.3
I have heard that the IEEE committee is considering an extension that defines
a special SAP value to handle Ethernet protocol types.  When the SAP is set
to this special value, the Ethernet protocol type appears later in the packet.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jan 86 19:30:10 EST
From:      John Leong <leong%ANDREW@PT.CS.CMU.EDU>
To:        jas@proteon.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re : 802.2

If Tony Lauck's managed to get the SAP extension scheme accepted by
IEEE, I think we should consider adopting  it.  [ I also dislike variable
length header, but then IP header is also variable (sigh) ] .

 Who in the TCP/IP community will grap a 48 bit SAP for ARP (and one
for trailer protocol, and why not get one also for IP for the extended
format too ....) ????

P.S. : In our IBM token ring implementations, all IP packets are encapsulated
by 802.2 LLC headers. We did not go directly 802.5 interface.  (Again,
the SAP number for ARP we used is bogus)

P.P.S. :  For general interest, the IBM token ring interface cards for
the IBM PC and the RT is different. The PC uses IBM's own chip set while
the RT's interface is OEM'ed from TI and uses TI's chipset.  The RT
version is higher performance and can also be used with the AT (since
the RT has an AT bus). Amazingly, both cards work well together in the
same ring.  We run MIT PCIP (and derivatives) in the PC and 4.2 in the
RT.
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-JAN-1986 22:38 EST
From:      Ronald A. Jarrell  <JARRELLRA%VTVAX3.BITNET@WISCVM.WISC.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   tcp/ip implementations
I'm sure this has been asked before, but we are in the middle of trying
to come up with a configuration proposal for our multiple systems, with an
eye towards getting an internet connection.  Would people send me directly
their recomendations on tcp/ip packages for the following system types:

IBM 30xx series running VM/SP 3 or 4 and CMS
VAX 7xx and 8xxx series running VMS 4.2
VAX 11/785 running Ultrix 1.1
Vax 11/785 running System V

(I realize that the Ultrix supports tcp/ip.. I was thinking in terms of
enhanced performance packages for that system..)

Our environment is/will be all the Vaxen and some other unix-based workstations
on ethernet.  The IBM is not substantially connected.  We'd really like to
put an internet connection if we get one on the IBM and one VMS machine.

Any suggestions?  Once again, please send them to me.. If there's sufficient
interest I'll summarize and post to the list.


Thanks!

Ron Jarrell
Systems Programming Department
Va Tech
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jan 86 00:47:04 EST
From:      Louis A. Mamakos <louie@trantor.UMD.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Attention clockwatchers
  There's a newly installed Spectracom WWVB clock on UMD1.UMD.EDU available
for your (ab)use.  This clock should normally be synchronized to WWVB; when
the radio link goes down, there is an automatic fallback to synchronize to
DCN1.ARPA, also with its own WWVB clock.

  You can politely ask UMD1 for the time using ICMP echos, UDP
time server and an NTP timerserver.  You can also connect to the TCP timeserver
port, but this is discouraged.  UMD1.UMD.EDU is a fuzzball for those of you
interested in such things.  Its clock configuration is very similar to that
on DCN1.ARPA.  Enjoy.

Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
  University of Maryland, Computer Science Center - Systems Programming

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jan 86 12:19:37 pst
From:      gould9!joel@nosc.ARPA (Joel West @ CACI)
To:        mod.protocols.tcp-ip, tcp-ip@sri-nic.ARPA
Subject:   alleged TCP/IP controversy in BSD 4.3
As I recall, last summer BSD 4.3 was just "a few months away".
It's still not out.

David Chandler writes an article in UNIX Review (January 1986, p. 8)
in which he claims to have an answer.

The delay, Chandler writes, was caused by conflicts over the version
of TCP/IP to be included in 4.3.  According to Chandler:
	* the 4.2 TCP/IP was BBN code rewritten by UCB; 
	* BBN then encouraged people to use an enhanced BBN code
	* DARPA decided only ONE of these would be allowed for 4.3
	* after much vacillation, DARPA chose UCB for political
	  and technical reasons.

For more on this, see the mag.

	Joel West	 CACI, Inc. Federal, La Jolla
	{cbosgd,floyd,ihnp4,pyramid,sdcsvax,ucla-cs}!gould9!joel
	gould9!joel@nosc.ARPA
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jan 86 14:41:57 EST
From:      Ross Callon <rcallon@SRN-VAX.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        leong%ANDREW@PT.CS.CMU.EDU, PAETZOLD@MARLBORO.DEC.COM, rcallon@SRN-VAX.ARPA
Subject:   on SAPs
The same scheme for combined use of SSAPs and DSAPs was discussed in 
802 several years ago, and was heavily beat upon, primarily on the
basis that it conflicted with the reference model.  SAPs should be 
significant in the context of the rest of the associated address, not
in the context of the other specified SAP.  For example, suppose the
ultimate other end of the connection is not on the same LAN, but is on
some other LAN that does not follow your convention.  In this case you
won't be able to figure out what to do.  Also, since the SAP is supposed
to be a continuation of the address, for traffic in the other direction
you would expect to continue to associate each SAP value with the same
address, (i.e., when you exchange source and destination addresses for
return traffic you would also exchange SAP values).  This of course
wouldn't work with the proposed scheme.

If you used the alternate scheme in which each SAP by itself identifies
the user protocol, then these problems don't occur.  For example, suppose
that you use an explicit mapping between the SAP and the protocol, and the 
other end uses some other scheme (such as table lookup, or it implements
only one protocol and uses the user specified part of the SAP for some 
other purpose).  Here when you receive a packet you can determine what 
protocol it contains, and know what addresses to use for return packets.

Originally the 802 standards were not going to include any SAPs at all.
When the idea first came up I suggested that there was an alternate idea
of a "user protocol" field that would eliminate the redundancy of having 
the same field twice.  This was rejected quickly, partly on the rather
compelling grounds that saving a single octet on a multi-megabit LAN
didn't seem very important.

Ross Callon
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Thu 30 Jan 86 16:09:08-EST
From:      Kevin Paetzold <PAETZOLD@MARLBORO.DEC.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   more on saps
Thanks to all of you who replied to my original message on this subject.
The whole 802.3/802.2 SAP issue seems like a major can of worms.  I find it
amazing that the IEEE and ISO could not come up with a better scheme or at
least a scheme that allows more than 64 assigned SAPs!.  I also find it 
amazing that the bureaucrats involved do not find ARP important enough to
allocate its own SAP.  Apparently the ISO networking world believes that it
is never going to have any address mapping problems (or any other problems 
that ARP solves) due to great foresight.  Having 64 SAPs available did not 
however indicate a lot of foresight.

If this message sounds like a flame then so be it.  I think the TCP/IP
community should really push to get a SAP assigned to ARP.  This issue seems 
like a major non technical stumbling block preventing wider acceptance of
802.3 (at least in this community).

-------
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 86 00:21:26 EST
From:      Stephen Carter <SCARTER@RED.RUTGERS.EDU>
To:        tcp-ip@SRI-NIC.ARPA, iso@ACC.ARPA
Subject:   TOP Subcommittee's Formed


	I am sending a copy of this to the tcp folks as I thought some of them
may be interested.  Just received this in the USnail..

To: Top Participants  [ of the TOP User's meeting in Seattle in December]
From: Victor Lukasik, Vice Chair of TOP Technical and Test
Subject: TOP Subcommittee's Formed

TOP Executive Committee announces the formation of TOP Technical Subcommittees.
The TOP Technical Subcommittees will address standards for the technical and
office environment.  The subcommittees formed are:
			- TOP Document Exchange
			- TOP Electronic Mail
			- TOP Graphics Exchange
			- TOP Physical Layer
			- TOP Product Data
			- TOP Virtual Terminal
All interested vendors and user companies are asked and encouraged to join.
Membership in the TOP technical subcommittee(s) is open to any individual with
an interest to contribute to either defining standards, or equally important,
to provide clear user requirement definitions to the vendor community.

....[for more info, contact Victor Lukasik- phone given below]

The first TOP Technical and Test Review Meeting has been scheduled for 
Thursday, February 6, 1986 in Seattle, Washington.  These meetings will 
primarily be a summation by each of the [..] chairs of work done to date,
and planned work items. All are invited to attend these sessions to receive
a status of current work activities, and have a forum to provide input to the
technical activities of TOP.

[Last paragraph states that these meetings will be the first Thursday of each
month unless there is a MAP/TOP User's meeting in that month and they will 
held at that meeting instead....]

If you are interested in this,  the subcommittees will be meeting in
Seattle on February 5th (with the exception of the Physical Layer which
will be held January 30 in Austin, Tx.).  For more info, contact person
listed:

	Physical Layer (Jan 30) -- Arthur Miller (512) 440-2119
	Electronic Mail -- Victor Lukasik (206) 763-5457
	Document Exchange -- Frank Dawson (314) 232-5251
	Product Data Exchange -- Herbert Ryan (314) 234-5161
	Virtual Terminal -- Davis Dowlin (206) 763-5457
	Graphics Exchange -- no chair yet, contact Victor above.

-------
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 86 11:27:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   TCP port question

I thought that I would forward this to tcp-ip for comment.

					<Art@ACC.ARPA>

------------------------------------------------------------------------

> From:	SAGE::KEITH        30-JAN-1986 05:59
> To:	ART,KEITH       
> Subj:	
> 
> Hi Art,
> 
>     Can I ask you a TCP Question ?  It concerns our TCP implementation, the
> one in SIMON, and in the SPOT-FE (IBM-Ethernet I/F).  We return a parameter
> error to the caller of TCP if an Active-Open is issued with local Port = 0.
> The guys at Ford had trouble with using low-valued ports on their 
> 4.2bsd on a Sun workstation (authorization problems, I think).  So they
> tried using port 0.  Unix was apparently quite happy for them to issue an
> Open for Port-0.   So when they called us they were wondering why we gave
> their IBM program a parameter error.

BSD UNIX reserves TCP ports 1-1023 (well known ports) as privileged, which
only super-user is allowed to bind.  If someone tries to bind to local port 0,
the socket is bound to an unused port > 1023.  This would make a listen to
port 0 of little use (because the active end does not know the actual port).

> 
>    I can find nothing prohibiting Port-0 in any TCP Spec.  However, RFC-943
> (Assigned Numbers) lists Port-0 as Reserved, so nobody is supposed to listen
> on it.  In terms on defensive programming, a zero is the most probable
> value which could result from a bug in a ULP.
> 
> Any suggestions ?  Should we remove our restriction on Port-0, or suggest
> it to the TCP Community ?
> 
> Keith.

I would discourage use of port 0.

------

END OF DOCUMENT