The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1987 10:48-EST
From:      CERF@A.ISI.EDU
To:        JSLove@MIT-MULTICS.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: secure replacements for passwords

In the design of the TCP, we intended to detect half-open connections and
to resolve them by means of the RST criteria. The line of reasoning was
that the discovery would occur if an attempt were made to re-open an
already (from recipient perspective) open connection. Similarly, such a
half-open connection could be detected if a data packet were received
on an otherwise closed connection.


Once a connection had reached an established state, our primary objective
was to deal with integrity in the face of various failures included pre-
historic packets arriving at inopportune moments.

Now, there were so many possible ways to spoof things, given the right
level of access and control over the data flowing on the connection
that we appealed to cryptographic methods where serious spoofing was a
concern.

It looks as if we overlooked the fact that the SENDER of a precognitive
ACK might already have accepted bogus data. Our analysis, as I dimly
recall it, centered on a bogus (prehistoric) precognitive ACK which
had NOT actually been sent by the current party at the other end of
the connection. I believe we assumed that the probability of the other
side receiving a valid data packet which had NOT been sent was small
because of the size of the sequence number space and the probably age
of a packet which did, in fact, arrive so inopportunely sequence numbered.

The change you suggest might catch an attempt at spoofing, but I submit
that any serious concerns about spoofing are inadequately addressed by
anything less than and/end security techniques. 

Ignoring spoofing, it is fair to say, in my view, that the scenario in
which an old packet engenders what looks like a precognitive ACK is
a bad case since the precognitive ACK will be sent after the data 
recipient has accepted as valid an ancient piece of information.
Rather than quietly continuing the connection, this sounds serious
enough to warrant a more drastic indication of a problem.

It will be essential to assure that if a RST is used, it WILL
reset the connection if the other side really has accepted bad data
but will NOT reset it if the precognitive ACK is really prehistoric.

It will be very interesting to see what the other members of this
community have to say about the analysis and consequences.

Vint Cerf
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Mar-87 11:41:41 EST
From:      dorl@seismo.CSS.GOV@uwmacc.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: uwmacc!dorl
From: dorl@uwmacc.UUCP (Michael Dorl)
Newsgroups: mod.protocols.tcp-ip,comp.sys.dec,comp.mail.misc
Subject: VMS Mail Systems
Message-ID: <1163@uwmacc.UUCP>
Date: 1 Mar 87 16:41:41 GMT
Organization: UWisconsin-Madison Academic Comp Center
Lines: 10

We run a Vax VMS system with connections to the IP Internet (The
Wollongong Groups WIN/VX), BITNET (Joiners JNET and GMAIL), and
DECNet.  Both the IP and BITNET systems are accessable from DEC's
MAIL utility but the user interface is poor.  We are looking for
something that presents a better more fully coordinated interface
to these nets.

If you have or know of such products, please mail to....

dorl@unix.macc.wisc.edu    dorl@wiscmacc.bitnet

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Mar-87 16:47:40 EST
From:      broscius@LINC.CIS.UPENN.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Standard for async port emulation under NetBIOS, MS-DOS ?



Hi,
	Does anyone know of an existing or evolving standard for
emulating an async port under NetBIOS and MS-DOS ? Who are some
of the contacts for the NetBIOS working group(s) ? 

Thanx
Al broscius
broscius@linc.cis.upenn.edu		:Internet

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Mar-87 22:09:41 EST
From:      ken@HAMLET.CALTECH.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: VMS Mail Systems

> We run a Vax VMS system with connections to the IP Internet (The
> Wollongong Groups WIN/VX), BITNET (Joiners JNET and GMAIL), and
> DECNet.  Both the IP and BITNET systems are accessable from DEC's
> MAIL utility but the user interface is poor.	We are looking for
> something that presents a better more fully coordinated interface
> to these nets.

    The Software Tools Mail System is a public domain RFC821/2 based
mailer which interfaces to MultiNet TCP/IP (compatible with WIN/VX),
Jnet, and DECnet-VMSmail. Caltech uses it to provide a gateway
between ARPAnet, BITnet, and our local DECnet.

    VMSmail users sometimes have trouble adapting to its user interface,
but an interface to VMSmail is available (in a uniform fashion).

    Below is an adapted INFO-VAX posting of mine:

---
    As our VAX is now running the Multinet TCP/IP software, there has
been a recent change in the location of the Software Tools
Distribution.

    The latest distribution of the Software Tools Mail System is
available from HAMLET.CALTECH.EDU [192.12.19.3] via FTP as the ASCII
files:

	ST_SRC:DISTN.COM	build kit for the Software Tools VOS
	ST_SRC:DOC.COM		\
	ST_SRC:VMS.COM		 | sources for the Software Tools VOS
	ST_SRC:SRC.COM		/

	ST_SRC:MSGSYS.COM	sources for the Software Tools Mail System.
				(Requires the VOS to build.)

    The distribution is also available via DECnet on SPAN/HEPnet from host
SHAKES:: (5.859) in the same directory (ST_SRC:).

    I can send the distribution via BITnet to any requesters. Please
specify /VMSDUMP or /NETDATA format when requesting, as some lines are
over 80 characters. What you will receive is many smaller .COM files
which when executed in lexical order have the same result as the one
big one. Please also specify whether you want just DISTNx.COM and
MSGSYSx.COM (the default) or the entire source distribution (not
needed for the mail system).

    These are "DCL-archives". You unpack them by executing them in an
empty directory, and build them by following the instructions in
README.1ST or BUILD.DOC.  Only DISTN.COM and MSGSYS.COM are required
to build the mail system.

    This distribution includes the new drivers for Jnet V3.0 and
Excelan's TCP/IP card. Much work has been done in the conversion of
the mail system from RATFOR to C. We currently have the C version
running on PC/ATs under Xenix and on VAXen under both 4.3bsd and VMS,
but are not prepared to distribute this version (yet).

					Kenneth Adelman
					Caltech
KEN@HAMLET.CALTECH.EDU
KEN@HAMLET.BITNET

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Mar-87 23:29:16 EST
From:      jsol@buit1.bu.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   "sndmsg balks"

Ha! I fixed that bug while working for BBN. That was like the first
thing I did some 3 years ago. If some site is still running the older
versions of sndmsg/smtp_server then it's manager should have his head examined.
:-)

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Mar-87 23:31:28 EST
From:      jsol@buit1.bu.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   wollongong

I think Wollongong got a very old copy of BBN SNDMSG for unix systems.

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Mar-87 00:48:48 EST
From:      van@LBL-CSAM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: tcp counters

>>I realize that some UNIX(tm) systems and derivatives provide a
>>netstat command with a '-s' option that gives the following
>>counters for the tcp level. 
>>
>>tcp:
>>	0 bad header checksums
>>	0 bad header offset fields
>>	0 incomplete headers

Mike Karels and I recently expanded the tcp counters in 4bsd.
"netstat -s" now spits out the following tcp info:

tcp:
        409459 packets sent
                348357 data packets (176132584 bytes)
                4580 data packets (4180410 bytes) retransmitted
                36809 ack-only packets (35384 delayed)
                37 URG only packets
                470 window probe packets
                17169 window update packets
                2037 control packets
        388768 packets received
                215725 acks (for 176151367 bytes)
                31643 duplicate acks
                0 acks for unsent data
                204363 packets (40447108 bytes) received in-sequence
                5905 completely duplicate packets (21670 bytes)
                104 packets with some dup. data (195 bytes duped)
                795 out-of-order packets (15985 bytes)
                1 packet (1024 bytes) of data after window
                7 window probes
                3219 window update packets
                0 packets received after close
                0 discarded for bad checksums
                0 discarded for bad header offset fields
                0 discarded because packet too short
        729 connection requests
        425 connection accepts
        1069 connections established (including accepts)
        1183 connections closed (including 9 drops)
        93 embryonic connections dropped
        178425 segments updated rtt (of 179970 attempts)
        3745 retransmit timeouts
                1 connection dropped by rexmit timeout
        315 persist timeouts
        77992 keepalive timeouts
                21298 keepalive probes sent
                73 connections dropped by keepalive

This includes almost everything you were asking about though some
of the numbers require a good understanding of the 4bsd tcp
implementation to interpret.  I promised Mike that I would write
a short document (probably an appendix to the 4bsd "Networking
Implementation Notes") saying what these numbers mean and how
various ratios and differences can be used to find network
problems.  I have about 30 pages of notes on good things to
include in this document but it will probably take me two or
three months to get round to writing it. 

This stuff will presumably go out with the next BSD release.  It
might even become available as a "bug fix" or something before
the next release (I speak from complete ignorance -- I know nothing
about BSD distribution policies or plans).  I do know that Wollongong
has a VMS version of the 4.3bsd networking code that includes these
stats (though they don't seem to be distributing it yet -- bang on
your TWG salesman if you want it).  I also have a strong suspicion
that SRI's Multinet will soon include these stats.

  - Van

ps: given the problem you're working on, the socket debugging
    option and "trpt" might be a quicker way to find it.  E.g.,
    "ftp -d host-B" to generate some traffic with debugging enabled
    then "/etc/trpt -f" (with, say, an ftp data transfer running)
    to get a complete protocol trace including all the packet
    arrivals and departures, state transitions, timeouts, rtt's
    and srtt estimates, user process actions, etc. ("man 8 trpt"
    will get you more information on how to use it and what
    optional information is available).  Trpt, like netstat,
    should be available to any "lowly user" on a 4bsd system.

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Mar-87 09:53:23 EST
From:      kluger@Sun.COM@roundhouse.UUCP
To:        mod.protocols.tcp-ip
Subject:   Certification tests for TCP/IP?


Hello fellow tcp-ip'ers,

I know of the DCA conducted certification tests for DDN-X.25.

But what about certification tests for TCP/IP? I heard a rumour a while
back that such tests were being developed, but did anything ever happen?

Thanks,

Larry Kluger
Sun Europe Data Communications

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Mar-87 10:21:00 EST
From:      BEAME@MCMASTER.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Ultrix TCP/IP

The following is a trace (excelan monitor) of a PC communicating to a GPX
micro-vax running ULTRIX. The ethernet is < 1% loaded, the GPX has no other
users on it. CFB/IN is packets going to the PC, CFB/OUT is packets going to
the uVax. The command executed is "cat file". The first number in the form
xxx.xxx is the time since the first packet in milli.micro seconds, the
second number is the time since the last packet in milli.mico seconds.

QUESTION:
   Why does Ultrix wait about 5 seconds after the PC ACK's to send it's
next packet? Remember there are no gateways and almost noload on the
network or GPX.

1    : CFB/IN
ether: IP    aa-00-04-00-07-04 -> 02-60-8c-10-46-46   140        0.000    0.000
   ip: TCP   01.00001f -> 01.004646
  tcp: TELNET  -> 7464     ACK
  tcp: seq:  64807377  ack:        40  win: 4096  len:   82
    0: 66 20 25 66 20 25 66 20 25 66 20 25 75 20 25 75  |f %f %f %f %u %u|
   16: 20 25 75 22 2c 26 58 6d 69 6e 2c 26 58 6d 61 78  | %u",&Xmin,&Xmax|
   32: 2c 26 59 6d 69 6e 2c 26 59 6d 61 78 2c 26 44 65  |,&Ymin,&Ymax,&De|
   48: 70 74 68 2c 26 47 72 69 64 78 2c 26 47 72 69 64  |pth,&Gridx,&Grid|
   64: 79 29 3b 0d 0a 20 20 20 20 20 20 20 20 64 69 73  |y);..        dis|
   80: 70 6c                                            |pl              |

2    : CFB/OUT
ether: IP    02-60-8c-10-46-46 -> aa-00-04-00-07-04    64        6.981    6.981
   ip: TCP   01.004646 -> 01.00001f
  tcp: 7464    -> TELNET   ACK
  tcp: seq:        40  ack:  64807459  win:   82  len:    0

3    : CFB/IN
ether: IP    aa-00-04-00-07-04 -> 02-60-8c-10-46-46   140     4998.996  ***.***
   ip: TCP   01.00001f -> 01.004646
  tcp: TELNET  -> 7464     ACK
  tcp: seq:  64807459  ack:        40  win: 4096  len:   82
    0: 61 79 20 3d 20 58 4f 70 65 6e 44 69 73 70 6c 61  |ay = XOpenDispla|
   16: 79 28 4e 55 4c 4c 29 3b 0d 0a 20 20 20 20 20 20  |y(NULL);..      |
   32: 20 20 77 20 3d 20 58 43 72 65 61 74 65 57 69 6e  |  w = XCreateWin|
   48: 64 6f 77 28 52 6f 6f 74 57 69 6e 64 6f 77 2c 31  |dow(RootWindow,1|
   64: 2c 31 2c 47 72 69 64 78 2c 47 72 69 64 79 2c 31  |,1,Gridx,Gridy,1|
   80: 2c 57                                            |,W              |

4    : CFB/OUT
ether: IP    02-60-8c-10-46-46 -> aa-00-04-00-07-04    64     5006.198    7.203
   ip: TCP   01.004646 -> 01.00001f
  tcp: 7464    -> TELNET   ACK
  tcp: seq:        40  ack:  64807541  win:   82  len:    0

5    : CFB/IN
ether: IP    aa-00-04-00-07-04 -> 02-60-8c-10-46-46   140     9998.735  ***.***
   ip: TCP   01.00001f -> 01.004646
  tcp: TELNET  -> 7464     ACK
  tcp: seq:  64807541  ack:        40  win: 4096  len:   82
    0: 68 69 74 65 50 69 78 6d 61 70 2c 42 6c 61 63 6b  |hitePixmap,Black|
   16: 50 69 78 6d 61 70 29 3b 0d 0a 20 20 20 20 20 20  |Pixmap);..      |
   32: 20 20 58 4d 61 70 57 69 6e 64 6f 77 28 77 29 3b  |  XMapWindow(w);|
   48: 0d 0a 20 20 20 20 20 20 20 20 58 53 65 6c 65 63  |..        XSelec|
   64: 74 49 6e 70 75 74 28 77 2c 30 78 30 33 38 30 29  |tInput(w,0x0380)|
   80: 3b 0d                                            |;.              |

    Thanks in advance,

             Carl Beame

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Mar 87 10:21 EST
From:      <BEAME%MCMASTER.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Ultrix TCP/IP
The following is a trace (excelan monitor) of a PC communicating to a GPX
micro-vax running ULTRIX. The ethernet is < 1% loaded, the GPX has no other
users on it. CFB/IN is packets going to the PC, CFB/OUT is packets going to
the uVax. The command executed is "cat file". The first number in the form
xxx.xxx is the time since the first packet in milli.micro seconds, the
second number is the time since the last packet in milli.mico seconds.

QUESTION:
   Why does Ultrix wait about 5 seconds after the PC ACK's to send it's
next packet? Remember there are no gateways and almost noload on the
network or GPX.

1    : CFB/IN
ether: IP    aa-00-04-00-07-04 -> 02-60-8c-10-46-46   140        0.000    0.000
   ip: TCP   01.00001f -> 01.004646
  tcp: TELNET  -> 7464     ACK
  tcp: seq:  64807377  ack:        40  win: 4096  len:   82
    0: 66 20 25 66 20 25 66 20 25 66 20 25 75 20 25 75  |f %f %f %f %u %u|
   16: 20 25 75 22 2c 26 58 6d 69 6e 2c 26 58 6d 61 78  | %u",&Xmin,&Xmax|
   32: 2c 26 59 6d 69 6e 2c 26 59 6d 61 78 2c 26 44 65  |,&Ymin,&Ymax,&De|
   48: 70 74 68 2c 26 47 72 69 64 78 2c 26 47 72 69 64  |pth,&Gridx,&Grid|
   64: 79 29 3b 0d 0a 20 20 20 20 20 20 20 20 64 69 73  |y);..        dis|
   80: 70 6c                                            |pl              |

2    : CFB/OUT
ether: IP    02-60-8c-10-46-46 -> aa-00-04-00-07-04    64        6.981    6.981
   ip: TCP   01.004646 -> 01.00001f
  tcp: 7464    -> TELNET   ACK
  tcp: seq:        40  ack:  64807459  win:   82  len:    0

3    : CFB/IN
ether: IP    aa-00-04-00-07-04 -> 02-60-8c-10-46-46   140     4998.996  ***.***
   ip: TCP   01.00001f -> 01.004646
  tcp: TELNET  -> 7464     ACK
  tcp: seq:  64807459  ack:        40  win: 4096  len:   82
    0: 61 79 20 3d 20 58 4f 70 65 6e 44 69 73 70 6c 61  |ay = XOpenDispla|
   16: 79 28 4e 55 4c 4c 29 3b 0d 0a 20 20 20 20 20 20  |y(NULL);..      |
   32: 20 20 77 20 3d 20 58 43 72 65 61 74 65 57 69 6e  |  w = XCreateWin|
   48: 64 6f 77 28 52 6f 6f 74 57 69 6e 64 6f 77 2c 31  |dow(RootWindow,1|
   64: 2c 31 2c 47 72 69 64 78 2c 47 72 69 64 79 2c 31  |,1,Gridx,Gridy,1|
   80: 2c 57                                            |,W              |

4    : CFB/OUT
ether: IP    02-60-8c-10-46-46 -> aa-00-04-00-07-04    64     5006.198    7.203
   ip: TCP   01.004646 -> 01.00001f
  tcp: 7464    -> TELNET   ACK
  tcp: seq:        40  ack:  64807541  win:   82  len:    0

5    : CFB/IN
ether: IP    aa-00-04-00-07-04 -> 02-60-8c-10-46-46   140     9998.735  ***.***
   ip: TCP   01.00001f -> 01.004646
  tcp: TELNET  -> 7464     ACK
  tcp: seq:  64807541  ack:        40  win: 4096  len:   82
    0: 68 69 74 65 50 69 78 6d 61 70 2c 42 6c 61 63 6b  |hitePixmap,Black|
   16: 50 69 78 6d 61 70 29 3b 0d 0a 20 20 20 20 20 20  |Pixmap);..      |
   32: 20 20 58 4d 61 70 57 69 6e 64 6f 77 28 77 29 3b  |  XMapWindow(w);|
   48: 0d 0a 20 20 20 20 20 20 20 20 58 53 65 6c 65 63  |..        XSelec|
   64: 74 49 6e 70 75 74 28 77 2c 30 78 30 33 38 30 29  |tInput(w,0x0380)|
   80: 3b 0d                                            |;.              |

    Thanks in advance,

             Carl Beame
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Mar-87 10:30:11 EST
From:      heker@JVNCA.CSC.ORG.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  wollongong

Talking about the Wollongong mailer, which doesn't accept canonical names
for a host such as i.e. "ucbarpa.berkeley.edu", does anybody know if they
plan to do anything about it?.  By the end of March there will not be
aliases in the hosts tables without a domain specification, then the
mailer will not be able to deliver any mail at all.

					-- SFH --

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Mar-87 10:56:39 EST
From:      PADLIPSKY@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

I had already seen the GOSIP document and been asked, under
extreme time contraints, to comment on it for "my sponsor".
The comments follow.  They should be understood as being
fragmentary, in the sense that I feel a lot more could be
said, and various points don't even get the emphasis they
deserve (e.g., the very negative implications of the fact
that the NBS variations aren't "pure ISO"), but I wanted
to get them out on the table as soon as possible, so I haven't
made an editorial pass over them for this mailing.

Please note that I have tried very hard to refrain from what
I call Constructive Snottiness (and what many doubtless call
abrasiveness) here, but I don't want anybody to think it's
from lack of intensity of feelings on the subject.  Quite the
opposite, indeed.  But let the record show that I think the
promulgating of GOSIP AT THIS POINT IN TIME is utterly
irresponsible, and amounts to "go sip at the public trough
for years to come."  I urge anybody who sees this and
agrees with my negative assessment of GOSIP to alert
everybody they can think of that it should be forestalled
until the ISO and/or the NBS can offer an INTEGRAL suite
of widely-implemented, tested, performance-acceptable protocols.
(I personally believe that they're still five years away--
and attach some significance to the fact that I, and other
knowledgable observers it should be noted, have been saying that
very thing for at least five years.)

cheers, map





                 Comments on "GOSIP" Draft

                      M. A. Padlipsky


I urge that DIA take the strongest possible action to assure
that the DoD take the strongest possible action to prevent
the promulgation of a finalized version of the "GOSIP" Draft
(dated December 18, 1986).

There are three broad grounds on which the dissent should be
based: (1) There is ample evidence within the document
itself that it is premature for any branch of the Government
to standardize on the ISO/OSI protocols.  (2) There are leg-
itimate DoD concerns and requirements that the ISO/OSI pro-
tocols do not, and in some cases cannot in principle,
address.  (3) There are sufficient technical flaws and
inconsistencies in the GOSIP document as to cast doubt on
the qualifications of its progenitors to be prescribing net-
working policy for the DoD, much less for the Government as
a whole.  Although time does not permit an exhaustive
analysis of each of these areas, some indication of the
lines of argument will comprise the remainder of this note.

The support for (1) is as follows: The Preface states "This
specification will change..." and "Appendices specify future
work items needed to enrich the specification...".  This is
prima facie evidence that the Government is being asked to
make procurements to a moving target, the costs of doing
which should be well known.  Since a major rationale for
choosing international standards has traditionally been to
save on procurement and maintenance costs, the fact that the
document acknowlegdes that there is not yet in existence a
stable, seasoned, integral suite of protocols in the ISO/OSI
arena indicates that this rationale does not apply at the
present time.  On the strength of its Preface alone, then,
an appropriate response to the GOSIP document would be "Come
back in three or four years, when you've got something solid
to plug".  The absence of a Virtual Terminal Protocol stan-
dard in 1.3 is further evidence of the underdeveloped state
of the ISO/OSI work, since the ability such a protocol would
confer to perform remote logins is fundamental to an inter-
computer network worthy of the name.  The presence of 1.5.2
and 1.5.3 on "Secondary Sources" and "Tertiary Sources" (of
protocol specifications) is still further evidence of incom-
pleteness.  It is also implicit evidence of fiscal impru-
dence: implementing a Draft Proposed Standard can be a waste
of money when the Draft International Standard takes a sub-
stantially different technical approach, as witness the
experience with FTAM; reinterfacing DoD "Telnet" to "TP4"--
as would be consistent with 1.5.3--would also be expensive,
and would prove to have been wasted motion whenever the
"official" Virtual Terminal Protocol were proclaimed.  The
footnote to 1.6.1 is also suggestive: if OSI is so "new"
that there's no "testing service," isn't it too new to
invest in?  And if, as 1.6.3 states, "GOSIP does not cite
performance criteria," might we not be buying a dead pig in
a poke?  Finally, it is not enough to say, as 1.6.4 does,
that "It is expected that most vendors will update their
products..."; unless GOSIP can somehow mandate updating at
known, extremely modest cost, isn't GOSIP asking the Govern-
ment to sign a blank check?  In summary, until ISO has pro-
duced specifications for an integral suite of seasoned pro-
tocols, GOSIP will almost surely generate more expenditures
than savings.

The support for (2) is as follows: The technical areas of
concern to the DoD which are not addressed by ISO/OSI have
been dealt with elsewhere; see References 1-3, for example.
For present purposes, it should suffice to note that, among
other technical areas, the DoD is--and must be--particularly
concerned with the mobility and survivability of its commun-
ications, yet GOSIP 4.1.1 mandates a choice of proximate
network interface protocols that seems to preclude use of
such media as Packet Radio and 5.1.3 specifies static
routing--both of which dictates run counter to the DoD needs
in the area--and that the DoD has deep Security concerns,
yet the GOSIP section on that topic on the one hand does not
necessarily reflect the DoD view and on the other hand does
not even reflect the prevailing ISO/OSI view (it is, in
fact, modeled apparently fairly closely on a view which has
been proposed in DoD circles), so that even if it were to
prove on closer inspection to be acceptable to the DoD its
implementation would engender additional charges by the ven-
dors.  (It should also be noted that there are inherent,
possibly insurmountable difficulties in addressing DoD Secu-
rity concerns in the public standards arena.) There is a
non-technical concern that deserves even more attention than
the technical points in the present context, however.  For
the DoD, after all, is not "made of money," and it has in
place and running an integral suite of intercomputer net-
working protocols which indisputably possesses both of the
significant desirable properties claimed for OSI: it is
"open," in the sense that it is not vendor-idiosyncratic and
anyone who implements it can interoperate, and it is widely
available, in the sense that dozens of vendors offer DoD
Protocol Suite products.  (It is also arguable that the DoD
Suite is technically superior to the ISO/OSI Suite, but that
is not the point at issue here--any more than that there are
probably more DoD Suite products available today than OSI
Suite products.)  Why should the DoD be told in effect to
send a well-maintained, late-model, paid-for, "loaded" Buick
to the junkyard in order to have the garage space so that it
can buy a "stripped" Renault that doesn't even claim to get
better gas milage and doesn't have a passenger's seat and
other key components?  Is this not throwing bad money after
good?  That is, whatever economic justification there is for
ISO/OSI in the de novo case--and certainly, if the Depart-
ment of Commerce, say, had no intercomputer networks whatso-
ever right now, a better case could be made for "going
GOSIP," even though it's premature to do so, rather than
"going SNA"--it simply doesn't apply in the case where the
fruits of an investment in seasoned art are actively being
enjoyed, as is the case in the DoD with respect to the DoD
Protocol Suite.  Therefore, I would suggest that if points
(1) and (3) are not deemed sufficient to put GOSIP on hold
for several years the Applicability section of GOSIP (1.4)
must be reworked to take cognizance of the realities, with
DoD explicitly empowered to exercise its own best judgment
on whether/in what specialized circumstance it will "go
GOSIP."

(It might not be germane to the argument, but it is at least
interesting to note that the conceptual underpinnings of OSI
were invented and given proof of concept in the DoD-
sponsored ARPANET, which is why the statement above about
"openness" in the DoD was labeled as indisputable: the prin-
ciple of Layering and the goal of Host heterogeneity both
come from what is now the DoD Protocol Suite.  Therefore,
the position I am urging the DoD to take is not one of "Not
Invented Here," by any means; it was invented "here," and
why should we pay to have it reinvented elsewhere when it
works fine here is more like it.)

The support for (3) is as follows:  The very definition of
"End system" in the GOSIP Glossary is inaccurate.  In the
first place, the defining characteristic of a "terminal" in
the intercomputer networking context is that it does not
implement the protocols; "intelligent terminals," "worksta-
tions," and "personal computers," by contrast, can be "end
systems," since they can implement the protocols (but when
they merely emulate ["dumb"] terminals, they're not being
end systems).  More damaging to the GOSIP Draft's credibil-
ity, though, the entire weight of the Outboard Processing
("Network Front-End") art militates against the assertion
that the protocols must all be implemented "in" the end sys-
tem.  Another Glossary flaw: "intermediate systems" actually
participate in routing, in concert with end systems, they do
not "perform routing." Further, in 1.1 GOSIP is stated to be
"consistent with and complementary to [MAP and TOP]."  If
so, it's not consistent with the ISO/OSI "Reference Model"
it explicitly espouses elsewhere, since MAP and TOP are not
consistent with the reference model.  (They prescribe per-
forming L6 functions in L7 and they ignore L5.)  Also, in
1.4 it cannot be optional to employ the protocols in
microprocessors, etc. "that will be connected as end sys-
tems..."; it must be mandatory to do so if they're end sys-
tems, by definition.  Then there's the statement in 3.1 that
"Achieving OSI...is best accomplished by using...one
protocol specification at each layer": this is palpable non-
sense, since if there were one protocol at each layer you
wouldn't need Layering, which was invently precisely to
allow the existence of different protocols at each layer
without having to change the upper (or lower) layer proto-
cols to take cognizance of the differences.  Indeed, the
statement is contradicted in both of the next two para-
graphs.  And the description of the "transport layer" in 3.2
is incorrect in that it omits reference to both "connection-
less" L4 alternatives and to "unreliable, but rapid" L4 con-
nections, both of which are necessary and desirable in many
intercomputer networking contexts (including several of par-
ticular interest to the DoD).  Similarly, in 4.1.1, "tran-
sport class 4" should not be mandatory: it's merely one of a
number of L4 alternatives, even if it was NBS's "baby." For
that matter, forcing a choice among a limited number of L2-1
"technologies" betrays a lack of understanding of the power
of Layering (you can prefer certain technologies for certain
contexts, but if you're properly layered it doesn't matter
if the bits are going over a direct wire), and exempting
"messaging" from having to comply with L6 (and apparently
from L5) simply flouts the very reference model espoused, in
a nearly scandalous fashion.  (Just because CCITT has enough
"clout" to ignore the ISO/OSI reference model doesn't mean
that a Government standards program intended to bring good
networking practice to participants economically should.)
Without bothering to scrutinize the rest of the document for
still more evidence, then (although the lack of definitions
of terms in 5.2.1 is particularly annoying), it certainly
appears that GOSIP is preaching an approach it doesn't prac-
tice.

Time constraints do not permit a more comprehensive adducing
of evidence, but one would hope that the points raised here
at least suggest that it is premature for the Government to
impose GOSIP upon itself.  It is folly to chase a moving
target in technological implementations; it is folly to dis-
card state-of-the-art technology in favor of less mature
technology; and it is folly to adopt misunderstood stan-
dards, irrespective of whether they are or are not ever
understandable, since it will be too expensive to get them
understood even if they are.  Let GOSIP go sit for as many
years as it takes to come up with a complete set of well-
specified, well-implemented protocols that are mutually com-
patible.  (And then let it come up with a more reasonable
position with respect to the DoD Protocol Suite.)


References

[I'll formalize these if anybody's willing to hand the paper
to some Authority; they'll be 1: The Book, 2: Cerf and
Lyons' paper on Military Networking, and 3: A Norwegian
paper (in English) on the same general topic; just don't
feel like digging them up at nearly 6 on Friday.]
-------

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1987 10:56:39 EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        postel@BEL.ISI.EDU (Jon Postel)
Cc:        TCP-IP@SRI-NIC.ARPA, Corrigan@SRI-NIC.ARPA, Heafner@NBS-VMS.ARPA
Subject:   Re: GOSIP
I had already seen the GOSIP document and been asked, under
extreme time contraints, to comment on it for "my sponsor".
The comments follow.  They should be understood as being
fragmentary, in the sense that I feel a lot more could be
said, and various points don't even get the emphasis they
deserve (e.g., the very negative implications of the fact
that the NBS variations aren't "pure ISO"), but I wanted
to get them out on the table as soon as possible, so I haven't
made an editorial pass over them for this mailing.

Please note that I have tried very hard to refrain from what
I call Constructive Snottiness (and what many doubtless call
abrasiveness) here, but I don't want anybody to think it's
from lack of intensity of feelings on the subject.  Quite the
opposite, indeed.  But let the record show that I think the
promulgating of GOSIP AT THIS POINT IN TIME is utterly
irresponsible, and amounts to "go sip at the public trough
for years to come."  I urge anybody who sees this and
agrees with my negative assessment of GOSIP to alert
everybody they can think of that it should be forestalled
until the ISO and/or the NBS can offer an INTEGRAL suite
of widely-implemented, tested, performance-acceptable protocols.
(I personally believe that they're still five years away--
and attach some significance to the fact that I, and other
knowledgable observers it should be noted, have been saying that
very thing for at least five years.)

cheers, map





                 Comments on "GOSIP" Draft

                      M. A. Padlipsky


I urge that DIA take the strongest possible action to assure
that the DoD take the strongest possible action to prevent
the promulgation of a finalized version of the "GOSIP" Draft
(dated December 18, 1986).

There are three broad grounds on which the dissent should be
based: (1) There is ample evidence within the document
itself that it is premature for any branch of the Government
to standardize on the ISO/OSI protocols.  (2) There are leg-
itimate DoD concerns and requirements that the ISO/OSI pro-
tocols do not, and in some cases cannot in principle,
address.  (3) There are sufficient technical flaws and
inconsistencies in the GOSIP document as to cast doubt on
the qualifications of its progenitors to be prescribing net-
working policy for the DoD, much less for the Government as
a whole.  Although time does not permit an exhaustive
analysis of each of these areas, some indication of the
lines of argument will comprise the remainder of this note.

The support for (1) is as follows: The Preface states "This
specification will change..." and "Appendices specify future
work items needed to enrich the specification...".  This is
prima facie evidence that the Government is being asked to
make procurements to a moving target, the costs of doing
which should be well known.  Since a major rationale for
choosing international standards has traditionally been to
save on procurement and maintenance costs, the fact that the
document acknowlegdes that there is not yet in existence a
stable, seasoned, integral suite of protocols in the ISO/OSI
arena indicates that this rationale does not apply at the
present time.  On the strength of its Preface alone, then,
an appropriate response to the GOSIP document would be "Come
back in three or four years, when you've got something solid
to plug".  The absence of a Virtual Terminal Protocol stan-
dard in 1.3 is further evidence of the underdeveloped state
of the ISO/OSI work, since the ability such a protocol would
confer to perform remote logins is fundamental to an inter-
computer network worthy of the name.  The presence of 1.5.2
and 1.5.3 on "Secondary Sources" and "Tertiary Sources" (of
protocol specifications) is still further evidence of incom-
pleteness.  It is also implicit evidence of fiscal impru-
dence: implementing a Draft Proposed Standard can be a waste
of money when the Draft International Standard takes a sub-
stantially different technical approach, as witness the
experience with FTAM; reinterfacing DoD "Telnet" to "TP4"--
as would be consistent with 1.5.3--would also be expensive,
and would prove to have been wasted motion whenever the
"official" Virtual Terminal Protocol were proclaimed.  The
footnote to 1.6.1 is also suggestive: if OSI is so "new"
that there's no "testing service," isn't it too new to
invest in?  And if, as 1.6.3 states, "GOSIP does not cite
performance criteria," might we not be buying a dead pig in
a poke?  Finally, it is not enough to say, as 1.6.4 does,
that "It is expected that most vendors will update their
products..."; unless GOSIP can somehow mandate updating at
known, extremely modest cost, isn't GOSIP asking the Govern-
ment to sign a blank check?  In summary, until ISO has pro-
duced specifications for an integral suite of seasoned pro-
tocols, GOSIP will almost surely generate more expenditures
than savings.

The support for (2) is as follows: The technical areas of
concern to the DoD which are not addressed by ISO/OSI have
been dealt with elsewhere; see References 1-3, for example.
For present purposes, it should suffice to note that, among
other technical areas, the DoD is--and must be--particularly
concerned with the mobility and survivability of its commun-
ications, yet GOSIP 4.1.1 mandates a choice of proximate
network interface protocols that seems to preclude use of
such media as Packet Radio and 5.1.3 specifies static
routing--both of which dictates run counter to the DoD needs
in the area--and that the DoD has deep Security concerns,
yet the GOSIP section on that topic on the one hand does not
necessarily reflect the DoD view and on the other hand does
not even reflect the prevailing ISO/OSI view (it is, in
fact, modeled apparently fairly closely on a view which has
been proposed in DoD circles), so that even if it were to
prove on closer inspection to be acceptable to the DoD its
implementation would engender additional charges by the ven-
dors.  (It should also be noted that there are inherent,
possibly insurmountable difficulties in addressing DoD Secu-
rity concerns in the public standards arena.) There is a
non-technical concern that deserves even more attention than
the technical points in the present context, however.  For
the DoD, after all, is not "made of money," and it has in
place and running an integral suite of intercomputer net-
working protocols which indisputably possesses both of the
significant desirable properties claimed for OSI: it is
"open," in the sense that it is not vendor-idiosyncratic and
anyone who implements it can interoperate, and it is widely
available, in the sense that dozens of vendors offer DoD
Protocol Suite products.  (It is also arguable that the DoD
Suite is technically superior to the ISO/OSI Suite, but that
is not the point at issue here--any more than that there are
probably more DoD Suite products available today than OSI
Suite products.)  Why should the DoD be told in effect to
send a well-maintained, late-model, paid-for, "loaded" Buick
to the junkyard in order to have the garage space so that it
can buy a "stripped" Renault that doesn't even claim to get
better gas milage and doesn't have a passenger's seat and
other key components?  Is this not throwing bad money after
good?  That is, whatever economic justification there is for
ISO/OSI in the de novo case--and certainly, if the Depart-
ment of Commerce, say, had no intercomputer networks whatso-
ever right now, a better case could be made for "going
GOSIP," even though it's premature to do so, rather than
"going SNA"--it simply doesn't apply in the case where the
fruits of an investment in seasoned art are actively being
enjoyed, as is the case in the DoD with respect to the DoD
Protocol Suite.  Therefore, I would suggest that if points
(1) and (3) are not deemed sufficient to put GOSIP on hold
for several years the Applicability section of GOSIP (1.4)
must be reworked to take cognizance of the realities, with
DoD explicitly empowered to exercise its own best judgment
on whether/in what specialized circumstance it will "go
GOSIP."

(It might not be germane to the argument, but it is at least
interesting to note that the conceptual underpinnings of OSI
were invented and given proof of concept in the DoD-
sponsored ARPANET, which is why the statement above about
"openness" in the DoD was labeled as indisputable: the prin-
ciple of Layering and the goal of Host heterogeneity both
come from what is now the DoD Protocol Suite.  Therefore,
the position I am urging the DoD to take is not one of "Not
Invented Here," by any means; it was invented "here," and
why should we pay to have it reinvented elsewhere when it
works fine here is more like it.)

The support for (3) is as follows:  The very definition of
"End system" in the GOSIP Glossary is inaccurate.  In the
first place, the defining characteristic of a "terminal" in
the intercomputer networking context is that it does not
implement the protocols; "intelligent terminals," "worksta-
tions," and "personal computers," by contrast, can be "end
systems," since they can implement the protocols (but when
they merely emulate ["dumb"] terminals, they're not being
end systems).  More damaging to the GOSIP Draft's credibil-
ity, though, the entire weight of the Outboard Processing
("Network Front-End") art militates against the assertion
that the protocols must all be implemented "in" the end sys-
tem.  Another Glossary flaw: "intermediate systems" actually
participate in routing, in concert with end systems, they do
not "perform routing." Further, in 1.1 GOSIP is stated to be
"consistent with and complementary to [MAP and TOP]."  If
so, it's not consistent with the ISO/OSI "Reference Model"
it explicitly espouses elsewhere, since MAP and TOP are not
consistent with the reference model.  (They prescribe per-
forming L6 functions in L7 and they ignore L5.)  Also, in
1.4 it cannot be optional to employ the protocols in
microprocessors, etc. "that will be connected as end sys-
tems..."; it must be mandatory to do so if they're end sys-
tems, by definition.  Then there's the statement in 3.1 that
"Achieving OSI...is best accomplished by using...one
protocol specification at each layer": this is palpable non-
sense, since if there were one protocol at each layer you
wouldn't need Layering, which was invently precisely to
allow the existence of different protocols at each layer
without having to change the upper (or lower) layer proto-
cols to take cognizance of the differences.  Indeed, the
statement is contradicted in both of the next two para-
graphs.  And the description of the "transport layer" in 3.2
is incorrect in that it omits reference to both "connection-
less" L4 alternatives and to "unreliable, but rapid" L4 con-
nections, both of which are necessary and desirable in many
intercomputer networking contexts (including several of par-
ticular interest to the DoD).  Similarly, in 4.1.1, "tran-
sport class 4" should not be mandatory: it's merely one of a
number of L4 alternatives, even if it was NBS's "baby." For
that matter, forcing a choice among a limited number of L2-1
"technologies" betrays a lack of understanding of the power
of Layering (you can prefer certain technologies for certain
contexts, but if you're properly layered it doesn't matter
if the bits are going over a direct wire), and exempting
"messaging" from having to comply with L6 (and apparently
from L5) simply flouts the very reference model espoused, in
a nearly scandalous fashion.  (Just because CCITT has enough
"clout" to ignore the ISO/OSI reference model doesn't mean
that a Government standards program intended to bring good
networking practice to participants economically should.)
Without bothering to scrutinize the rest of the document for
still more evidence, then (although the lack of definitions
of terms in 5.2.1 is particularly annoying), it certainly
appears that GOSIP is preaching an approach it doesn't prac-
tice.

Time constraints do not permit a more comprehensive adducing
of evidence, but one would hope that the points raised here
at least suggest that it is premature for the Government to
impose GOSIP upon itself.  It is folly to chase a moving
target in technological implementations; it is folly to dis-
card state-of-the-art technology in favor of less mature
technology; and it is folly to adopt misunderstood stan-
dards, irrespective of whether they are or are not ever
understandable, since it will be too expensive to get them
understood even if they are.  Let GOSIP go sit for as many
years as it takes to come up with a complete set of well-
specified, well-implemented protocols that are mutually com-
patible.  (And then let it come up with a more reasonable
position with respect to the DoD Protocol Suite.)


References

[I'll formalize these if anybody's willing to hand the paper
to some Authority; they'll be 1: The Book, 2: Cerf and
Lyons' paper on Military Networking, and 3: A Norwegian
paper (in English) on the same general topic; just don't
feel like digging them up at nearly 6 on Friday.]
-------
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Mar-87 11:12:45 EST
From:      jh@seismo.CSS.GOV@tut.fi
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: tut!jh
From: jh@tut.UUCP (Juha Hein{nen)
Newsgroups: mod.protocols.tcp-ip
Subject: How to have two networks in a single Ethernet?
Message-ID: <646@sotka.tut.UUCP>
Date: 2 Mar 87 16:12:44 GMT
Reply-To: jh@tut.UUCP ()
Distribution: world
Organization: Tampere University of Technology, Finland
Lines: 15

We have just got Bridge GS-3M boxes with Vitalink software that
connect protocol independently four separate Ethernets.  The separate
Ethernets each have their own Class C Internet numbers.  Our problem
is, how to configure the 4.2bsd machines (Suns and Vaxen) in each of
the separate networks so that they could talk to each other.

We have tried to add new entries in /etc/hosts and add new arp info
but when trying to connect a machine in another network, we get back
an error message "Network is unreachable".  It looks like we should be
able to generate one of our machines as a gateway machine with only
one Ethernet controller.  Any help is appreciated.
-- 
	Juha Heinanen
	Tampere Univ. of Technology
	Finland

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Mar-87 11:16:28 EST
From:      ben@CERNVAX.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: cernvax!ben
From: ben@cernvax.UUCP (ben)
Newsgroups: mod.protocols.tcp-ip
Subject: TCP/IP for OS-9 Anywhere?
Keywords: TCP/IP OS-9 NFS
Message-ID: <445@cernvax.UUCP>
Date: 2 Mar 87 16:16:25 GMT
Reply-To: ben@cernvax.UUCP (via mcvax)
Distribution: world
Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Sw
Lines: 5

We are looking for possible TCP/IP implementations for 68K systems running
the Microware OS-9 operating system. We are interested both in the case where
all of the protocols and utilities run on the 68K, or where an intelligent
board is used, e.g. Excelan, CMC, etc. (for VME-based systems). A big bonus
would be the additional availability of (at least client) NFS.

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Mar-87 15:43:11 EST
From:      nobody@COLUMBIA.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: columbia!cunixc!cck
From: cck@cunixc (Charlie C. Kim)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Ultrix TCP/IP
Message-ID: <4410@columbia.UUCP>
Date: 2 Mar 87 20:43:10 GMT
References: <8703021756.AA15720@ucbvax.Berkeley.EDU>
Sender: nobody@columbia.UUCP
Reply-To: cck@cunixc.UUCP (Charlie C. Kim)
Distribution: world
Organization: Columbia University Center for Computing Activities
Lines: 45

In article <8703021756.AA15720@ucbvax.Berkeley.EDU> BEAME@MCMASTER.BITNET writes:
>The following is a trace (excelan monitor) of a PC communicating to a GPX
>micro-vax running ULTRIX. The ethernet is < 1% loaded, the GPX has no other
>...
>
>QUESTION:
>   Why does Ultrix wait about 5 seconds after the PC ACK's to send it's
>next packet? Remember there are no gateways and almost noload on the
>network or GPX.
>

I'm not sure what software you're running on your pc or what version
of ultrix you are running, but both BSD 4.3 and Ultrix 1.2 delays
sends by the TCP 'PERSIST' timeout if the window is too "small" (e.g.
segment to be sent is "larger" than remotely advertised window).  This
might have been the case in Ultrix 1.1 and is probably the case in
Ultrix 2.0.  The PERSIST timeout is around 5 seconds.  The tcp
segments resulting from the cat output are probably pretty large, so
in the following you can see that the delay happens when the window
advertised by the PC TCP/IP is quite small - probably quite a bit
smaller than the segment that the Unix TCP wants to send.

>2    : CFB/OUT
>ether: IP    02-60-8c-10-46-46 -> aa-00-04-00-07-04    64        6.981    6.981
>   ip: TCP   01.004646 -> 01.00001f
>  tcp: 7464    -> TELNET   ACK
>  tcp: seq:        40  ack:  64807459  win:   82  len:    0
>
>3    : CFB/IN
>ether: IP    aa-00-04-00-07-04 -> 02-60-8c-10-46-46   140     4998.996  ***.***
>   ip: TCP   01.00001f -> 01.004646
>  tcp: TELNET  -> 7464     ACK
>  tcp: seq:  64807459  ack:        40  win: 4096  len:   82
>    0: 61 79 20 3d 20 58 4f 70 65 6e 44 69 73 70 6c 61  |ay = XOpenDispla|
>...

Enough of the analysis, what you probably want is a workaround which I
can offer for the MIT version of PC/IP: simply set the telnet low
window close to the telnet window using custom and you'll find things
a lot more zippy.  (This I discovered by experimentation much before I
tried to figure out what was really happening).

Charlie C. Kim
User Services
Columbia University

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Mar-87 15:50:22 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Certification tests for TCP/IP?

Larry,  As of now there is no certification program in place for
TCP/IP and above.  Much development work was done under contract to
DCA to develop such tests.  The results of that work are being considered
to be released into the public domain so that testing companies can
come forth and offer testing services for TCP/IP based upon that (or
additional) work.  I don't know when it will happen (or it is for sure)
but i expect it to be in the next few months.  

Dan
-------

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Mar-87 07:50:30 EST
From:      hedrick@seismo.CSS.GOV@topaz.rutgers.edu
To:        mod.protocols.tcp-ip
Subject:   Re:  Submission for mod-protocols-tcp-ip

Let us suppose that you have the following configuration:

--------- network 192.1.1
   |
 router, with addresses 192.1.1.1 and 192.1.2.2
   |
 --------- network 192.1.2
   |
 router, with addresses 192.1.2.1 and 192.1.3.1
   |
--------- network 192.1.3

Now suppose you have a 4.2 machine on network 192.1.2, whose own
address is 192.1.2.10.  Here is the way I would set up routing.

   /usr/etc/route add 192.1.1 192.1.2.2 1
   /usr/etc/route add 192.1.3 192.1.2.1 1

That is, you tell route the address of the router that is used to get
to each other the other networks.  The address you give must be the
address of the router's interface on your own network.  With this
approach, you need one route command for each network other than the
one your machine is on.  If the router has the ability to issue ICMP
redirects, you can do things with a single entry:

  /usr/etc/route add 0 192.1.2.1 1

A network number of 0 specifies this as a default route.  That means
that any address not on the local network is sent to 192.1.2.1.  If
that machine is not the right one, it should issue a redirect command
that will cause your machine to add a proper routing entry automatically.
I don't know whether the Bridge products issue ICMP redirects or not.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Mar-87 10:27:01 EST
From:      mrose@NRTC-GREMLIN.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP


    Mike - I do not claim to have all the answers on GOSIP, but I
    believe that one of us is severely misinformed as to GOSIP's
    *intent*.

    GOSIP simply states (according to my paraphrasing):

	 If a US Govt.  organization wishes to buy OSI networking
	 technology, then these are the guidelines that organization's
	 procurement authority should use when specifying the
	 requirements for said technology.

    As such, the GOSIP spec, although containing some minor errors, is
    entirely consistent with reality.  I believe that the problem
    arises from the fact that you (and I) consider TCP/IP to be OSI in
    addition to the ISO/CCITT stuff.  The people writing the spec do
    not view it that way, they view OSI as being "proprietary" to the
    international standards organizations.

    Given this perspective, let me make a couple of observations:

    GOSIP does not say "let's trash this TCP/IP and ISO".  It says "if
    you're going to buy ISO, then in FY87, this is what you should be
    buying".  Mike, you've really got to get this us vs. iso chip off
    of your shoulder, it is starting to damage your spinal cord and
    hence you sense of balance.  

    GOSIP is actually quite realistic in what it suggests:

	 There is no usable virtual terminal protocol from ISO these
	 days, so they don't try to specify one.  That is responsible.  

	 The FTAM DIS will be an IS "any day now" and the changes from
	 DIS to IS are very minor.  So, saying the FTAM DIS is OK, is
	 again, a fine thing.  

	 Finally, the reason that the CCITT X.400 (MHS) stuff doesn't
	 have a presentation layer, is that it pre-dates the ISO
	 presentation layer.  There are, however, several
	 implementations of X.400 which do work (and interoperate with
	 each other).  The current joint ISO/CCITT work in message
	 handling, called MOTIS, does make use of ISO presentation
	 layer, adhering to that model of 7+3i that we love so well.
	 Again, since there are X.400 implementations that are working,
	 let me remind you what someone said in his collection of essays
	 on networking:  

	      Do you want protocols that look nice or protocols that
	      want nice?  

	 Given the charter of GOSIP as I interpret it, again they are
	 doing just fine.

    Now, if you want to talk about unrealistic goals, I will privately
    tell you what other OSI mavens are proposing for the '88 time-frame
    (you think SDI is complex and has to do a lot?  heh, heh, heh, have
    I got a user profile for you!)

    But, I digress:  let me come back to the start of the message.
    GOSIP does not say "TRASH TCP/IP".  It would be much better for the
    networking gurus of the Internet to look at the spec and be helpful
    rather than view it as an attack on motherhood.  Of course, as you
    know, I like both technologies:  that's why I'm running FTAM DIS now
    in a TCP/IP network.  I have this great ISO application running on
    a stable Internet.  What can I say?  It's great!

/mtr

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Mar-87 10:40:05 EST
From:      jon@CS.UCL.AC.UK.UUCP
To:        mod.protocols.tcp-ip
Subject:   pings


Who is sending ICMP echos to our terminal gateway on it's old
address (128.16.9.3). It won't answer now, nor did it ever.

We are seeing a source at LINC.CIS.UPENN.EDU or UPENN-LINC.ARPA

Try 128.16.9.0, or 128.16.5.1 (our primary nameserver) if you
need a very remote echo host.

i am interested what you are doing.

jon

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Mar-87 10:58:10 EST
From:      PADLIPSKY@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

Marshall--

Sorry, but your "paraphrase" is not supported by the words on
the page. See 1.4, Applicability: "GOSIP is to be used by all
Federal Government agencies when procuring ADP systems or
services and communication systems or services.  It is
mandatory for all new network implementations and should be carefully
considered for retrofits."  See also 1.2, Purpose: "This
specification is _the_ standard reference for all Federal
Government agencies to use when procuring ADP systems or services
and communication systems or services."  See, for that matter,
1.1, Background: "GOSIP  addresses the need fo the Federal
Government to move immediately to multi vendor [sic]
interconnectivity...."  Perhaps you saw an earlier draft.

I don't have a chip on my shoulder, I have a clear and present
danger in my sights.  If this be paranoia, let's make the most
of it.

cheers, map

P.S.  Just so nobody thinks I'm quoting unfairly, 1.4 does offer:
"For a period of two years, agencies are permitted to procure
alternative interoperable protocols, but they must provide a
mechanism for those protocols to interoperate with OSI protocols
as well."  Perhaps you construe this as keeping the TCP/IP
Suite; I can't.
-------

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1987 10:58:10 EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        Marshall Rose <mrose@NRTC-GREMLIN.ARPA>
Cc:        Michael Padlipsky <PADLIPSKY@A.ISI.EDU>, Jon Postel <postel@BEL.ISI.EDU>, TCP-IP@SRI-NIC.ARPA, Corrigan@SRI-NIC.ARPA, Heafner@NBS-VMS.ARPA
Subject:   Re: GOSIP
Marshall--

Sorry, but your "paraphrase" is not supported by the words on
the page. See 1.4, Applicability: "GOSIP is to be used by all
Federal Government agencies when procuring ADP systems or
services and communication systems or services.  It is
mandatory for all new network implementations and should be carefully
considered for retrofits."  See also 1.2, Purpose: "This
specification is _the_ standard reference for all Federal
Government agencies to use when procuring ADP systems or services
and communication systems or services."  See, for that matter,
1.1, Background: "GOSIP  addresses the need fo the Federal
Government to move immediately to multi vendor [sic]
interconnectivity...."  Perhaps you saw an earlier draft.

I don't have a chip on my shoulder, I have a clear and present
danger in my sights.  If this be paranoia, let's make the most
of it.

cheers, map

P.S.  Just so nobody thinks I'm quoting unfairly, 1.4 does offer:
"For a period of two years, agencies are permitted to procure
alternative interoperable protocols, but they must provide a
mechanism for those protocols to interoperate with OSI protocols
as well."  Perhaps you construe this as keeping the TCP/IP
Suite; I can't.
-------
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Mar-87 13:11:00 EST
From:      BEAME@MCMASTER.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Ultrix TCP/IP


Hello,
     Thanks to everyone who responded to my query. To those who
suggested that I set the minimum window size to the maximum window size

for the PC/IP, this method will send two ACK's for every packet. But it
should work.

     The real answer is to have the PC/IP send the "maximum segment option"
on connect to be the same as the PC's maximum window.

     Thanks again to every one,

           Carl Beame

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Mar 87 13:11 EST
From:      <BEAME%MCMASTER.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Ultrix TCP/IP

Hello,
     Thanks to everyone who responded to my query. To those who
suggested that I set the minimum window size to the maximum window size

for the PC/IP, this method will send two ACK's for every packet. But it
should work.

     The real answer is to have the PC/IP send the "maximum segment option"
on connect to be the same as the PC's maximum window.

     Thanks again to every one,

           Carl Beame
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Mar-87 13:18:59 EST
From:      louie@TRANTOR.UMD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   UMDNET hosts to change addresses

Effective 0700 EST on March 12, 1987 a subset of UMDNET hosts will change
their addresses.  All of the hosts on subnet 0 (those hosts whose addresses
are of the form 128.8.0.x) will change to subnet 10.  For example,
UMD5.UMD.EDU currently has the internet address 128.8.0.5.  It's address
will change to 128.8.10.5.  An updated HOSTS.TXT will be available from
the NIC on that day.

Please note that the current domain name servers (TRANTOR.UMD.EDU 128.8.0.14
and NEOTRANTOR.UMU 128.8.0.9) will migrate to TRANTOR.UMD.EDU at 128.8.10.14,
TERP.UMD.EDU 128.8.10.90, UMD5.UMD.EDU 128.8.10.5, and SNOOPY.UMD.EDU
128.8.10.18.

People who query the UDP TIME and UDP NTP servers on UMD1.UMD.EDU 128.8.0.1
should query UMD1.UMD.EDU 128.8.10.1 after the conversion.  Please note
that we actively discourage people from using TCP/TIME.

In summary:

	Old host addr	    New host addr
	-------------       -------------	
	128.8.0.x     ==>   128.8.10.x
	128.8.y.z     ==>   128.8.y.z     (no change where y != 0)
	

	Old Name servers		New name servers
	---------------			---------------
	128.8.0.14 (trantor.umd.edu)	128.8.10.14	(trantor.umd.edu)
	128.8.0.9  (neotrantor.umd.edu)	128.8.10.90	(terp.umd.edu)
					128.8.10.5	(umd5.umd.edu)
					128.8.10.18	(snoopy.umd.edu)

	Old time server			New time server
	---------------			----------------
	128.8.0.1  (umd1.umd.edu)	128.8.10.1 	(umd.umd.edu)

If you have any questions, please feel free to send me mail.

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

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Mar-87 14:50:00 EST
From:      stanonik@NPRDC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Re: xerox -> 4.3bsd telnet

Thanks.  I asked about the correctness of 4.3bsd's telnet server
because I was uncertain about what a host should do between sending
a telnet option request and receiving a response.  The rfc doesn't
seem to say what the host should do, although now I notice that it
(rfc 854) does say what the host may do: "may wish to buffer data,
after requesting an option, until it learns whether the request is
accepted or rejected".  In effect, that is what 4.3bsd does, buffers
all data (well, it throws some away if the buffer fills) until
receiving a response.

Thanks,

Ron
stanonik@nprdc.arpa

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Mar-87 18:00:52 EST
From:      mrose@NRTC-GREMLIN.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

We are looking at the same draft.  My problem is that I attended the meeting,
and formed my opinions on that, instead of interpreting the fine points of
the draft.  It was quite clear at the last meeting that GOSIP was not intended
to mandate OSI networking.  Rather it was intended to mandate the types of
OSI networking technology, if one were to buy OSI.

The authority to mandate OSI networking over any other technology, e.g.,
TCP/IP, SNA, or XNS, lies with OMB.  I'm not real clear on this, but there is
some OMB directive in the works which makes that mandate.  If you want to get
paranoid, that is where to start.  It was clear to the GOSIP committee during
the meeting that they were only interested in specifying the OSI technology
they wanted.

From this perspective, GOSIP is a reasonable thing.

Perhaps someone in authority and/or with more insight can shed some light on
this discussion.

/mtr

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue, 03 Mar 87 15:02:20 +0000
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   pings

Who is sending ICMP echos to our terminal gateway on it's old
address (128.16.9.3). It won't answer now, nor did it ever.

We are seeing a source at LINC.CIS.UPENN.EDU or UPENN-LINC.ARPA

Try 128.16.9.0, or 128.16.5.1 (our primary nameserver) if you
need a very remote echo host.

i am interested what you are doing.

jon
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Mar-87 10:07:29 EST
From:      pogran@CCQ.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

Marshall,

But the document states (p. 2, sec. 1.4):

    "GOSIP is to be used by all Federal Government agencies
     when procuring ADP systems or services and communica-
     tion systems or services.  It is mandatory for all new
     network implementations ...  Specifically, this speci-
     fication is mandatory and applies to the procurement of
     all mini computers and mainframes that are to be inter-
     connected as end systems or intermediate systems."

If the framers of this document wanted to say, "Use this
specification IF you want to procure OSI stuff", it certainly
didn't come out that way!  My paraphrase of it would be, "If you
want to buy systems that communicate, you MUST use this spec." I
vote with MAP on this one (that's Michael A. Padlipsky, not
Manufacturing Automation Protocol).

Ken Pogran

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Mar 87 10:07:29 EST
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        Marshall Rose <mrose@nrtc-gremlin.arpa>
Cc:        Michael Padlipsky <PADLIPSKY@a.isi.edu>, Jon Postel <postel@bel.isi.edu>, TCP-IP@sri-nic.arpa, Corrigan@sri-nic.arpa, Heafner@nbs-vms.arpa, pogran@ccq.bbn.com
Subject:   Re: GOSIP
Marshall,

But the document states (p. 2, sec. 1.4):

    "GOSIP is to be used by all Federal Government agencies
     when procuring ADP systems or services and communica-
     tion systems or services.  It is mandatory for all new
     network implementations ...  Specifically, this speci-
     fication is mandatory and applies to the procurement of
     all mini computers and mainframes that are to be inter-
     connected as end systems or intermediate systems."

If the framers of this document wanted to say, "Use this
specification IF you want to procure OSI stuff", it certainly
didn't come out that way!  My paraphrase of it would be, "If you
want to buy systems that communicate, you MUST use this spec." I
vote with MAP on this one (that's Michael A. Padlipsky, not
Manufacturing Automation Protocol).

Ken Pogran
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Mar-87 10:49:30 EST
From:      PADLIPSKY@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

Marshall--
   It's difficult for me to see how anyone could call the
Applicability section of a proposed Federal standard a
"fine point."  For more on the topic of how the wording
of the spec can subvert the intent of the committee, see 
pp. 84-5 of The Book (which you must have, since you were
good enough to have quoted p. 228 at me [somewhat out of
context] in your previous msg).
   Re the presumed "OMB mandate": In my view, it's almost
certainly a red herring (stipulating that it does indeed
exist, which you didn't seem sure of), for two separate
reasons: (1) OMB almost certainly was put up to it by NBS,
so your appeal to it represents a type of circular reasoning,
not an external confirmation.  (2) It's manifestly
premature, regardless of whose idea it was originally;
see my critique of the GOSIP draft.  But I'm certainly quite
willing to join you in encouraging anybody who's tracking
this disucssion who knows how to alert OMB to the error of
its ways to do so--as quickly and as emphatically as possible.
(I don't, however, agree with your implication that they
shouldn't bother to try to beat on NBS, too.)
   cheers, map
-------

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1987 10:49:30 EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        Marshall Rose <mrose@NRTC-GREMLIN.ARPA>
Cc:        Michael Padlipsky <PADLIPSKY@A.ISI.EDU>, Jon Postel <postel@BEL.ISI.EDU>, TCP-IP@SRI-NIC.ARPA, Corrigan@SRI-NIC.ARPA, Heafner@NBS-VMS.ARPA
Subject:   Re: GOSIP
Marshall--
   It's difficult for me to see how anyone could call the
Applicability section of a proposed Federal standard a
"fine point."  For more on the topic of how the wording
of the spec can subvert the intent of the committee, see 
pp. 84-5 of The Book (which you must have, since you were
good enough to have quoted p. 228 at me [somewhat out of
context] in your previous msg).
   Re the presumed "OMB mandate": In my view, it's almost
certainly a red herring (stipulating that it does indeed
exist, which you didn't seem sure of), for two separate
reasons: (1) OMB almost certainly was put up to it by NBS,
so your appeal to it represents a type of circular reasoning,
not an external confirmation.  (2) It's manifestly
premature, regardless of whose idea it was originally;
see my critique of the GOSIP draft.  But I'm certainly quite
willing to join you in encouraging anybody who's tracking
this disucssion who knows how to alert OMB to the error of
its ways to do so--as quickly and as emphatically as possible.
(I don't, however, agree with your implication that they
shouldn't bother to try to beat on NBS, too.)
   cheers, map
-------
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Mar-87 12:09:16 EST
From:      porter%itsgw@CSV.RPI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)


RFC 985 "Requirements for Internet Gateways" specifies
functions that are available, in some form, in some products
from suppliers such as Proteon (P4200), Bridge, Cisco, etc.
At RPI we have had some experience with the P4200 product
through its use in NYSERNet. We are considering evaluating
other competing products for further use on campus in
connecting LANs to a backbone.
 
This note is to ask for feedback from current users of such
products -- in particular those from Bridge, CMC, Cisco.
Warnings welcome; cheers accepted cheerfully.
 
Don Porter
RPI Information Technology Services
porter@itsgw.rpi.edu

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Mar-87 16:47:56 EST
From:      mrose@NRTC-GREMLIN.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP


    Well Mike, what can I say?  You got me on a technicality.  Final
    defense:  It is my belief that the scope and applicability sections
    of the GOSIP spec are mis-stated in that they are not consistent
    with what I thought was going on at the meeting.  Perhaps I am wrong
    and have misinterpreted what was agreed at the last meeting.  If I
    am correct in this assumption, then these two sections should be
    fixed in the final copy.  If this is done, then GOSIP is a fine
    thing.  

    If, on the other had, I am wrong, and these sections are to be an
    accurate representation of GOSIP's intent, then I have wasted
    everyone's time trying to defend something which is patently wrong
    (as most of your arguments point out) and I'll appologize.  

    However, since none of the people in the know have commented on our
    discussion, it is difficult for me to gauge how right/wrong I am.

/mtr

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Mar 87 09:24:10 pst
From:      well!slf@lll-lcc.ARPA (Sharon Lynne Fisher)
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

For those of us who ahve entered this discussion late, what is GOSIP?
How can a person obtain a copy of this infamous document?
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Mar-87 07:46:24 EST
From:      solomon@GJETOST.WISC.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Telnet Option Negotiation to IBMish Hosts

OK, here's the "Wisconsin view" on the 3270/telnet controversy.  Sorry
I took so long to respond, but I somehow got deleted from the TCP/IP
list.  I think I tracked down all the relevant mail on this subject
from the list, but if I seem to be ignoring some past message, it may
be because I missed it.

I used to think that no new rfc was needed, since the existing telnet
specs (especially rfc885 and rfc930) told the whole story.  I now think
that while a new spec may not be needed, an rfc might be called for
just to make things clearer.

I pretty much agree with Bob Braden about what SHOULD happen:

> The terminal type negotiation and the EOR negotiations may occur
> in any order.  If EOR has been negotiated in both directions and if a 3278
> terminal type has been negotiated, THEN negotiation of BINARY will cause
> the mode to change from NVT to full-screen-3278.  Note that the BINARY
> is negotiated separately in each direction, which correctly synchronizes
> the mode change (any NVT data in the pipeline in each direction should
> be correctly handled).

The remainder of this (rather long) message contains my views about the
philosophy of telnet, some of the practical problems in implementing
it, and some explanation of why Wiscnet behaves the way it does.

Telnet assumes that there is a set of "options".  Corresponding to each
option is a pair of Boolean variables, one for each end of the
connection.  The telnet spec (rfc854) gives a protocol for changing any
one of these Boolean variables.  It gives no information about what
they may mean.  The individual options are described in separate rfc's,
some in more detail than others.  Telnet also provides a "suboption"
facility to send more complicated out-of-band information.  Finally,
telnet defines a "network virtual terminal" (NVT), which is a dumb
teletype-like device that dictates the default syntax and semantics of
data on the connection.  Telnet has no facilities for tying together a
package of options that are logically interdependent.  The general
strategy is to hold back data during a flurry of option negotiations
until everything settles down, so that you don't send anything while
the options are in an inconsistent state.

The ASCII option is misnamed.  It should be called "NVT", since it
means that data sent (from an end where ASCII is "true") will conform
to NVT conventions.  The negation of ASCII is BINARY (perhaps
"transparent" would be a better name), which means that the data is NOT
assumed to have any particular telnet-defined structure.  The 327x
terminals have their own protocol, which is very unlike NVT.
Therefore, it seems reasonable for two consenting telnet ends to
exchange data in the "raw" 327x format.  Other "bilateral" agreements
could similarly be defined.  The BINARY option almost, but not quite,
fits the bill.  There are two problems.

First, the details of the protocol depend on the particular model of
327x terminal, and perhaps on other information, such as the type of
controller and whether SNA is in use.  Thus there has to be a way of
exchanging terminal type information.  The set of terminal types
defined in rfc930 is small, but the intention is that this option
negotiation be used to convey whatever information is necessary to set
up whatever ad hoc protocol is desired.  Berkeley's tn3270 always says
"ibm3278-2".  The 3270 emulator I wrote (included with the Wiscnet
distribution), says 3278-2, -3, or -4 depending on the number of line
on the screen (from termcap or from the tty driver on 4.3BSD UNIX
systems).  If the need arises, one can easily define other "terminal
types" to describe SNA, or whatever.

Second, the 327x protocol is a record-oriented rather than byte-stream
protocol.  There has to be a way of signaling the end of a record
outside the set of 256 possible octets.  (By the way, for the same
reason, IMAGE mode in FTP is not adequate for transferring IBM files;
the end of a record is not indicated by any of the 256 EBCDIC
characters, but by out-of-band data.  You have to use PAGE mode
instead.) I originally suggested that we simply define an escape
sequence IAC EOR (where EOR is some code distinct from WILL, WONT, etc)
to mark the end of a record.  Since this sequence could never legally
occur according to the existing spec (even in BINARY mode!), it
shouldn't cause any confusion.  However,  Jon Postel insisted that a
telnet process shouldn't send IAC EOR without first getting permission
via IAC DO EOR.

Thus the general scheme is as follows:  Consenting telnets use BINARY
to agree that they will not use NVT, but rather their own private
protocol agreed upon by bilateral negotiation.  Before doing so, they
have to establish the details of this bilateral protocol.  Thus a
telnet process may refuse BINARY if it feels adequate groundwork has
not been laid out.  In the present case, an acceptable terminal type
and permission to use EOR are required.  I can imagine similar variants
of this scheme for other non-NVT protocols.

Now for implementation problems.  If you want to implement server
telnet, you either have to modify every application so that it can talk
to the telnet server rather than a terminal, or you need an
operating-system facility for the server to masquerade as a terminal to
another process.  The latter facility is called a pseudo-tty (pty) in
UNIX jargon; under VM, it's called "logical device support facility"
(LDSF or ldev).  Under LDSF, the information passed between the
application and the server must be a 327x data stream.  One of the
parameters to the "initiate" LDSF call is the terminal type.  Once the
logical device is created, there is no way to change the terminal
type.  Thus the Wiscnet server tries to avoid creating the logical
device as long as possible.  If a telnet connection begins with an
appropriate negotiation for BINARY mode, the server has all the
necessary information.  Otherwise, it creates the logical device with
type "3278-2" and goes though the painful process of translating
between that protocol and NVT.  If any NVT data arrives before the
terminal type is established, the server is forced to create a logical
device, and so it must choose a terminal type.  Subsequent attempts to
go into BINARY mode are simply rejected.  I suppose two enhancements
are possible:  First, if the other end sends some NVT data and then
decides to advertise a terminal type that "just happens" to match the
type chosen by the server, it should be possible to accept it.  Second,
the server could save up a "small" amount of NVT data before setting up
the LDSF device, in hopes that the necessary info will soon arrive.
Both are kludgy, but both might be very helpful in practice.

A similar problem comes up in backing out of BINARY mode.  Backing out
of BINARY/3278-2 to NVT shouldn't be too hard in principle (simply a
matter of programming :-).  Backing out of some other 327x model would
be a bit harder.  Right now Wiscnet refuses to do either.

Finally, I should discuss sequencing of negotiations.  As I think I've
made clear, the terminal type and EOR have to be settled before BINARY
makes sense.  The current Wiscnet code insists on EOR before terminal
type.  That's probably a bug.  However, the Wiscnet code will also be
willing to go into BINARY mode without first agreeing on EOR.  That's a
"feature"--really a historical curiosity (see the discussion above and
the comment in the Wiscnet code), but it also conforms to the maxim,
"be conservative in what you send and liberal in what you send".
Telnet can understand IAC EOR perfectly well whether or not DO EOR has
been established.

Well Bob, can this longwinded discussion serve as a draft of the needed
rfc, or should be rfc just be the single paragraph of yours that I
quoted above?

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Mar-87 09:22:00 EST
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

Marshall--

Tell ya what, if you'll promise to agitate through your "OSINET"
channels against the Applicability stuff I'll promise not to
debate whether I got you on a technicality or a TKO.

cheers, map

P.S. I'm told John Heafner has left NBS; trust you know some other
addressee there.
-------

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Mar-87 10:06:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

Mike,

John has indeed left NBS and gone to some part of DEC - don't know
which, but since John is on this distribution, maybe he will say,
if he still reads his Internet mail.

Vint

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 1987 10:06-EST
From:      CERF@A.ISI.EDU
To:        PADLIPSKY@A.ISI.EDU
Cc:        mrose@NRTC-GREMLIN.ARPA, postel@BEL.ISI.EDU TCP-IP@SRI-NIC.ARPA, Corrigan@SRI-NIC.ARPA Heafner@NBS-VMS.ARPA
Subject:   Re: GOSIP
Mike,

John has indeed left NBS and gone to some part of DEC - don't know
which, but since John is on this distribution, maybe he will say,
if he still reads his Internet mail.

Vint
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Mar-87 11:40:01 EST
From:      braden@ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

Marshall,

It would seem that the important issue is not whether you are right or
wrong; either case seems to lead to the same conclusion, that the present
wording in the GOSIP document is badly damaged and damaging.

Bob Braden

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Mar-87 12:44:32 EST
From:      bryan@ACC-SB-UNIX.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)

The confusion and indecision that is prevalent among those in
government that write network specifications and RFQ's has come
about over the last several years, first by all of the different
companies and types of products that were offered, and now by the
much touted new protocols.

They are not aware that there are "standard" protocols in use now,
in networks already in operation.  Moreover they are not aware that
the new ISO protocols have not been completed, and will not be ready
for some time.

ACC is a believer in ISO and has now spent significant resource on
developing products for use in networks employing the new protocols.
The customers are reluctant, and rightly so since there are few
suppliers of similar products today.

It is interesting to find out that network planners in Europe have
grown tired of waiting for the release of software modeled on ISO
and have begun to specify use of TCP/IP in commercial systems.

If the government planners and spec writers embrace GOSIP as the 
rule today and not as a guideline for future improvements, we will
be waiting a long time for network growth.  Most of the press and
the articles that are read by these planners talk as though ISO
exists and is ready "off the shelf".

From the report below, it is clearly evident that GOSIP may soon be
interpreted as a directive, by those ignorant of technical reality.


From COMPUTERWORLD 12 January, 1987, By Mitch Betts


Feds Back OSI Standards 

Gaithersburg, MD - The U.S. Government, a user organization with a
$16 billion information systems budget, is throwing its weight behind
the Open Systems Interconnect (OSI) standards with a new contracting
document that will require vendors to supply off-the-shelf networking
systems that meet certain OSI standards.

Federal agencies may now incorporate the Government OSI Procurement
(GOSIP) specification in bid requests at their discretion, but
eventually GOSIP will be a mandatory part of government contracts,
according to Shirley M. Radack, coordinator of standards programs
at the National Bureau of Standards institute for Computer Sciences
and Technology.

In addition to saving money and headaches by buying open systems, the
government hopes to use its own clout to prod vendors into developing
standard OSI products.

OSI is the seven layer reference model for communications standards
that has previously been established by the International Standards
Organization.


MAP/TOP-compatible

According to the U.S. Government OSI Users Committee, GOSIP is 
compatible with the industry's Manufacturing Automation Protocol
(MAP) and Technical Office Protocol (TOP) and will be updated as
new OSI protocols are developed and approved.

For starters, the government is adopting the File Transfer and Access
Management (FTAM) standard for file transfer and the Message
Handling Systems (X.400) standard for electronic mail as well as
X.25 for wide-area networking and the Token Bus (IEEE 802.4) for
local-area networking.

"GOSIP addresses the need of the federal government to move
immediately to multivendor interconnectivity without sacrificing
essential functionality already implemented in critical networking
systems," the GOSIP document said.  It noted that the capabilities
required by GOSIP "exist as standard products or are close enough
to market that they can be proposed by vendors."

In 1988 the government expects to adopt standards for document
interchange, transaction processing and the token-ring local-area
network, Standards for graphics, the exchange of financial and
management data, videotext and data base updates are slated for 1989.
An Integrated Services Digital Network (ISDN) standard for voice,
data and video traffic is expected in 1990.

The Dec.18 version of GOSIP is intended for use in procurements
of new networks of mainframes and minicomputers through September
1989.  The National Bureau of Standards plans to adopt it as a
Federal Information Processing Standard later this year, and the
General Services Administration plans to incorporate it into
mandatory procurement rules, Radack said.

"In the past, vendor-specific implementations of data communications
protocols led to isolated domains of information, very difficult
and expensive to bridge," the GOSIP document explained.  "By
implementing open systems, the government expects to realize
significant savings through reducing duplicate circuits and
wiring, training, custom software, workstations and custom
hardware interfaces."

However, some observers said the government faces a big challenge
in standardizing on OSI, given the fact that many existing networks
depend on the Pentagon-developed Transmission Control 
Protocol/Internet Protocol and IBM's Systems Network Architecture.

-----END----

Roland Bryan

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Mar 87 17:05:09 pst
From:      amdcad!bandy@decwrl.DEC.COM (Andy Beals)
To:        hedrick@topaz.rutgers.edu, mod.protocols.tcp-ip
Cc:        tcp-ip@sri-nic.ARPA, phil@decwrl.DEC.COM
Subject:   Re:  Submission for mod-protocols-tcp-ip
>I don't know whether the Bridge products issue ICMP redirects or not.

No, Bridge does not issue ICMP redirects.  They implement no part of the
ICMP protocol.  (the first paragraph of RFC792 not withstanding) Their
claim is that "until recently, ICMP was not completely described".  They
just came out with a new release for their GS/3 (release 11000) and
claim that the next release will have full ICMP support.  (due sometime
during the summer?)

From talking to them, it seems that they don't quite believe that they
should support IP to the extent they support Xerox NS.

Cheers,
	andy
-- 
Andrew Scott Beals, {lll-crg,decwrl,allegra}!amdcad!bandy +1 408 749 3683
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Mar-87 14:51:09 EST
From:      mrose@NRTC-GREMLIN.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

Yes, you are absolutely correct Bob.  Tell 'ya what: Let's forget about
my recollections of the subject and concentrate on the specification as
published.  That should be a much more productive use of our time.  Sorry
to have confused the list with this...

/mtr

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Mar-87 21:07:52 EST
From:      kolacki@nrl-csr.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   MAILING LIST


Please put me on your mailing list.

I'm currently reviewing the GOSIP document.

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Mar-87 22:12:25 EST
From:      mknox@NGP.UTEXAS.EDU (Margaret H. Knox)
To:        mod.protocols.tcp-ip
Subject:   TCP retransmission header question


This is probably a simple question for most of the TCP hackers out
there, but we cant agree on the information in the TCP standard.

Case:  A number of packets are sent and placed on the retransmission
	queue awaiting acknowledge.  Then a packet is received 
	acknowledging SOME of them, and also sending more data.
	We now send another packet, with a new acknowledge because
	of the additional data just received.

Question:  If it becomes necessary to resend the packets still on the
	retransmission queue, should the headers be updated to reflect
	the new acknowledge.  The alternative is to send the packets
	exactly as they were sent originally.  This has the interesting
	affect of causing us to send an acknowledge of a LOWER value
	than one just previously sent.

Answer: ???

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Mar-87 23:01:54 EST
From:      budd@BU-CS.BU.EDU (Philip Budne)
To:        mod.protocols.tcp-ip
Subject:   IBMish (WISCNET) Telnet negotations

What I find most upsetting about WISCNETs behavior is that it makes it
impossible to use the terminal type subnegotion for what is was meant
for: terminal types!

4.3 telnet and telnetd use the terminal type subnegotion, but if you
try to use 4.3 tn3270 to connect to a 4.3 host you end up as an
ibm-3277-2. We have a more recent version from Bekeley that will
negotiate based on screen size.

The problem is that the version of WISCNET we run sends DO TERMINAL
before there is any indication that the client telnet is willing to do
327x emulation.  This forces any tn3270-like program to assume the
worst.

IBM 327x emulation is not a simple (or unique) instance of the desire
to transparently transmit binary data.  Why isn't there an explicit
(sub)negotiation for "DO 327x"? The reply could be WILL/WONT or the
emulated 327x terminal type.

I thought that EOR had been invented explicitly for this. But WISCNET
negotiates EOR *AFTER* TERMINAL TYPE.

	oy gevalt!

	-Phil

Here is a log of a conversation between a SUN running the most recent
tn3270 we have from Berkely and our 3090, the faint of heart might
wish to stop here.


Connected to buacca.bu.edu.
SENT do SUPPRESS GO AHEAD
RCVD do TERMINAL TYPE (reply)
SENT will TERMINAL TYPE (don't reply)
RCVD wont SUPPRESS GO AHEAD (reply)
SENT dont SUPPRESS GO AHEAD (reply)
Received suboption Terminal type - request to send.
Sent suboption Terminal type is IBM-3278-3
<nasty escape seqences>
RCVD do END OF RECORD (reply)
SENT will END OF RECORD (don't reply)
RCVD will END OF RECORD (reply)
SENT do END OF RECORD (reply)
RCVD do BINARY (reply)
SENT will BINARY (don't reply)
RCVD will BINARY (reply)
SENT do BINARY (reply)
Unable to find entry for xterm in file /usr/etc/map3270
Unable to find entry for xterm in file /usr/etc/map3270
Using default key mappings.
<more nasty escape seqences here>
RCVD do BINARY (don't reply)
RCVD will BINARY (don't reply)
<madness ensues from here on it>

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Mar-87 00:12:42 EST
From:      karn@FLASH.BELLCORE.COM (Phil R. Karn)
To:        mod.protocols.tcp-ip
Subject:   GOSIP vs TCP/IP

Indeed, one wonders if the computer public is at all aware of the fact that
the Internet has been quietly doing what the ISO hawkers are only promising
in big bold trade rag headlines.  On the other hand, most vendors have
certainly heard of TCP/IP, considering that most of them already sell it,
so they have less of an excuse.

I think there are other, darker forces at play here. Recent developments
(or, more precisely, the lack of same) in the high definition TV standards
game illustrate what I think is going on in our own field.  It seems that
over the past few years, certain Japanese companies have led the way by
developing a complete line of compatible, working, high quality video
components. You can buy their stuff off the shelf right now.  At a recent
international standards convention in Europe, the Americans and the
Canadians enthusiastically supported the Japanese standard. After all, it
works and it's available now. "Can't have that", the Europeans replied. "It'd
be too hard to scan-convert back to our existing 625-line 50-Hz formats".
And everybody went home without an international standard.

Really now. And they said it with a straight face.  This has to be about the
thinnest technical excuse anyone has ever invented.  The *real* reason (and
this was openly stated in a EUROPEAN trade journal editorial) is that the
European manufacturers deeply resent the Japanese head start into the high
definition TV business. There is just no way they are going to approve
anybody else's standard, regardless of how good it is technically or whether
it's good for the users or not. It'd be bad for business.

To the European vendors, I am truly sorry that the Americans got a head
start by inventing TCP/IP and being the first to build big, operational
internetworks in which the common carriers ("PTTs") are only minor
subcomponents.  To the American vendors of protocol software, I am truly
sorry that so many public domain implementations of TCP/IP are out there
stealing your sales.  To those well-meaning souls in the Federal government
and elsewhere who naively trust vendor groups and standards organizations to
know what's best for your networking needs: take a look at the prices
they're charging for the few ISO packages out there. After you've put your
eyeballs back into your head, kick out the salesman and take a good close
look at just what these slickly advertised protocols will do for you (as
distinguished from your vendor's stock price).  Then decide if you want to
throw everything away and start over just so you can use the magic phrase
"ISO compatible" to describe your network.

TCP/IP is uniquely successful among communications standards because it was
one of the very few ever designed by the USERS (who just want to get their
work done as efficiently and as cheaply as possible) instead of the VENDORS
(who want to make as much money as possible, an entirely different goal).
What's good for General Motors may sometimes be good for the country, but in
the protocol standards game it's a different story.  Michael Padlipsky was
right on target on this one.  Only the most hopelessly naive user succumbs to
the "Illusion of Vendor Support."

These are obviously my own personal opinions only.

Phil Karn

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 1987 05:39-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Malformed mail header?, [kolacki@nrl-csr (Bob Kolacki): MAILING LIST]
Hmm...   according to the host table, thios enclosed message came
from a VAX7/50 running UNIX.  Doesn't sendmail  (or  whatever  it
is) do the translation of nicnames into primary names?  I mention
this due to the forthcoming removal of  nicnames  from  the  host
table.  Mike
	
Begin forwarded message
Received: from MIT-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Fri 6 Mar 87 04:25:45-PST
          from SRI-NIC.ARPA by MIT-MULTICS.ARPA TCP; 06-Mar-1987 07:19:25-est
          from nrl-csr.ARPA by SRI-NIC.ARPA with TCP; Thu 5 Mar 87 18:06:26-PST
Date: Thu, 5 Mar 87 21:07:52 est
From: kolacki@nrl-csr (Bob Kolacki)
To: tcp-ip@sri-nic
Subject: MAILING LIST
Return-Path: <@MIT-MULTICS.ARPA:tcp-ip-RELAY@SRI-NIC.ARPA>
Message-ID: <8703060207.AA00898@nrl-csr.ARPA>


Please put me on your mailing list.

I'm currently reviewing the GOSIP document.


          --------------------
End forwarded message
		
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Mar-87 03:02:00 EST
From:      WBD.MDC@OFFICE-1.ARPA (William Daul / McDonnell-Douglas / APD-ASD)
To:        mod.protocols.tcp-ip
Subject:   US GOVERNMENT OPEN SYSTEMS PROCUREMENT (Open Systems Communication - Feb. 1987, pg. 4)

The US Government Open Systems Interconnection User's Committee, which was 
established by the National Bureau of Standards, is preparing a standard for 
the procurement of OSI products by Federal Agencies in the US.  The draft of 
this standard, Government Open Systems Interconnection Procurement (GOSIP) 
Specification for the Fiscal Years 1987 and 1988, is currently being reviewed 
by government and industry.  The purpose of the Government OSI User's Committee
is to develop and maintain a Federal Government procurement specification for 
open systems computer network products.  As such, the specification supports 
the Office of Management and Budget's (OMB) pending policy, "United States 
Government Computer-Communications Architecture Policy".

It is expected that the Administrator of the General Services Administration 
(GSA) will provide for the implementation of OSI according to the GOSIP 
specification.  The NBS will issue this specification as a Federal Information 
Processing Standard (FIPS), and the National Communications System (NCS) will 
issue GOSIP as a Federal Standard.

Organizations contributing to the development of the GOSIP specification are as
follows:

   Dept. of Agriculture
   Dept. of Commerce
   Dept. of Defense
   Dept. of Energy
   Environmental Protection Agency
   General Services Administration
   Health and Human Services
   Dept. of Interior
   Dept. of Housing and Urban Development
   Dept. of Justice
   Labor
   NASA
   NSF
   OMB
   Dept. of Transporation
   Dept. of Treasury
   National Communitations System

This specification is based on agreements reached at the NBS workshop for 
Implementors of OSI.  GOSIP is consistent with, and complementary to, the 
Manufacturing Automation Protocol (MAP) and the Technical and Office Protocols 
(TOP) specifications developed by industry.  GOSIP addresses the need of the 
Federal Government to move immediately to multivendor interconnectivity without
sacrificing essential functionality already implemented in critical networking 
systems.  All capabilities described in the specifications exist as standard 
products or are close enough to market that they can be implemented by vendors.

GOSIP is to be used by all Federal Government agencies when procuring data 
processing systems of services and communications systems or services.  It is 
mandatory for all new network implementations and should be carefully 
considered for retrofits.  For a period of two years, agencies are permitted to
procure alternative interoperable protocols, by they must provide a mechanism 
for those protocols to interoperate with OSI protocols as well.

GOSIP addresses communication and interoperation among end-systems and 
intermediate systems.  It provides specific peer-level, process-to-process, and
terminal access functionality between computer systems within and across 
government agencies.  The primary source of protocol specifications used in 
GOSIP is the Implementation Agreements of Open Systems Interconnection 
Protocols, which is maintained by the NBS Workshop.  Because the Workstation 
Agreements continue to evolve, GOSIP augments protocol and service 
specifications for the following sources,

   ISO Standards and CCITT Recommendations

   ISO Draft International Standards

   ISO Draft Proposed Standards

   Working papers within international standards bodies

GOSIP's use of open systems standards minimizes the number of standards used 
while satisfying the diverse application encompassing government-wide needs.  
The specification provides a range of protocol choices at different layers.  A 
subset of these protocols may adequately satisfy an individual acquisition 
requirement, and may be used.  At least on lower layer technology must be used 
(i.e., CSMA/CD, Token Bus, or X.25).  The following protocols are mandatory:  
the connectionless internetwork protocol, Transport Class 4, and Session Layer 
protocol.  Transport Class 0 is to be used only in conjunction with public 
network messaging.  The Presentation Layer protocol and Common Application 
Service Elements (CASE) are required for all applications except messaging.  At
least on Application Layer protocol is required to support the intended 
application.  That is, if messaging is required, MHS will be specified; if file
transfer is required, FTAM will be specified.

The GOSIP specification will be revised annually and will be corrected or 
amended as needed.  The current draft of GOSIP will apply to fiscal years 1987 
and 1988.  OMNICOM subscribers can obtain a cop[y of the draft (Dec. 18, 1987) 
GOSIP specification as an OMNICOM File.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Mar-87 06:38:51 EST
From:      PERRY@VAX.DARPA.MIL (Dennis G. Perry)
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

I think Rose has a fair interpretation of the GOSIP document, at least
according to my understanding of the discussion at the last PSSG
meeting.  On the other hand, please do get your constructive comments
in to Corrigan so that they may properly be relected in the document.

dennis
-------

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Fri 6 Mar 87 06:38:51-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        mrose@nrtc-gremlin.arpa
Cc:        PADLIPSKY@a.isi.edu, postel@bel.isi.edu, TCP-IP@sri-nic.arpa, Corrigan@sri-nic.arpa, Heafner@nbs-vms.arpa, perry@vax.darpa.mil
Subject:   Re: GOSIP
I think Rose has a fair interpretation of the GOSIP document, at least
according to my understanding of the discussion at the last PSSG
meeting.  On the other hand, please do get your constructive comments
in to Corrigan so that they may properly be relected in the document.

dennis
-------
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 1987 0942-PST (Friday)
From:      Glenn Trewitt <trewitt@amadeus.stanford.edu>
To:        tcp-ip@sri-nic.arpa, Gateway Monitors <gwmon@sh.cs.net>
Cc:        
Subject:   TCP/IP Interoperability Conference -- Birds of a Feather Session
This is to announce a birds-of-a-feather session at the TCP/IP
conference in Montery, March 16-19.  Here is the abstract.

		      Birds of a Feather Session
		  TCP/IP Interoperability Conference
		       Tuesday, March 17, 7-9 pm


		     ISSUES IN GATEWAY MONITORING

We will discuss current work that is aimed at developing standard monitoring
protocols for the Internet.  The scope of this standardization is not
limited to gateways, but includes other entities operating at the IP layer.
There are many issues here:  what data to monitor, data representation, how
to request specific data, security, and transport protocols.

Security and transport protocols have been discussed at some length on the
gateway monitoring mailing list (gwmon-request@sh.cs.net) organized by Craig
Partridge.  This session will primarily focus on the data-related issues
mentioned above.

The session will start with several 5-minute presentations from people who
are working in this area, describing what they are doing and what their
needs are.  Following the presentations, we will have round-robin discussion
until we stop.

If you are interested in giving a presentation, please contact Glenn
Trewitt, trewitt@amadeus.stanford.edu.  (You will have 5 minutes to talk,
followed by questions.  There should be an overhead projector available, so
you can bring along a slide or two.  Also feel free to bring along handouts
for people to read.)
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Mar-87 08:39:00 EST
From:      STJOHNS@SRI-NIC.ARPA
To:        mod.protocols.tcp-ip
Subject:   Malformed mail header?

Hmm...   according to the host table, thios enclosed message came
from a VAX7/50 running UNIX.  Doesn't sendmail  (or  whatever  it
is) do the translation of nicnames into primary names?  I mention
this due to the forthcoming removal of  nicnames  from  the  host
table.  Mike
	
Begin forwarded message
Received: from MIT-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Fri 6 Mar 87 04:25:45-PST
          from SRI-NIC.ARPA by MIT-MULTICS.ARPA TCP; 06-Mar-1987 07:19:25-est
          from nrl-csr.ARPA by SRI-NIC.ARPA with TCP; Thu 5 Mar 87 18:06:26-PST
Date: Thu, 5 Mar 87 21:07:52 est
From: kolacki@nrl-csr (Bob Kolacki)
To: tcp-ip@sri-nic
Subject: MAILING LIST
Return-Path: <@MIT-MULTICS.ARPA:tcp-ip-RELAY@SRI-NIC.ARPA>
Message-ID: <8703060207.AA00898@nrl-csr.ARPA>


Please put me on your mailing list.

I'm currently reviewing the GOSIP document.


          --------------------
End forwarded message
		

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Mar-87 12:42:00 EST
From:      trewitt@AMADEUS.STANFORD.EDU (Glenn Trewitt)
To:        mod.protocols.tcp-ip
Subject:   TCP/IP Interoperability Conference -- Birds of a Feather Session

This is to announce a birds-of-a-feather session at the TCP/IP
conference in Montery, March 16-19.  Here is the abstract.

		      Birds of a Feather Session
		  TCP/IP Interoperability Conference
		       Tuesday, March 17, 7-9 pm


		     ISSUES IN GATEWAY MONITORING

We will discuss current work that is aimed at developing standard monitoring
protocols for the Internet.  The scope of this standardization is not
limited to gateways, but includes other entities operating at the IP layer.
There are many issues here:  what data to monitor, data representation, how
to request specific data, security, and transport protocols.

Security and transport protocols have been discussed at some length on the
gateway monitoring mailing list (gwmon-request@sh.cs.net) organized by Craig
Partridge.  This session will primarily focus on the data-related issues
mentioned above.

The session will start with several 5-minute presentations from people who
are working in this area, describing what they are doing and what their
needs are.  Following the presentations, we will have round-robin discussion
until we stop.

If you are interested in giving a presentation, please contact Glenn
Trewitt, trewitt@amadeus.stanford.edu.  (You will have 5 minutes to talk,
followed by questions.  There should be an overhead projector available, so
you can bring along a slide or two.  Also feel free to bring along handouts
for people to read.)

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Mar-87 17:43:40 EST
From:      slf@lll-lcc.ARPA@well.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  US GOVERNMENT OPEN SYSTEMS PROCUREMENT (Open Systems Communication - Feb. 1987, pg. 4)

Thank you so much for the very detailed explanation.  How does one go about
getting a copy of this document?  And is tha antipathy on Usenet universal,
or do most people think it's ok?

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Mar-87 00:22:58 EST
From:      ari@AMES-NAS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   add to mailing list


Please add me to the mod.protocols.tcp-ip list.

ari@ames-nas.arpa

Thank you,
Ari Ollikainen 
General Electric Company
NASA Ames Research Center

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7 Mar 87 14:11:34 PST
From:      jordan@ucbarpa.Berkeley.EDU (Jordan Hayes)
To:        tcp-ip@sri-nic.arpa, mod.protocols.tcp-ip
Subject:   Re: Malformed mail header?
	Doesn't sendmail  (or  whatever  it is) do the translation of
	nicnames into primary names?

*sigh*

it does, only if you wave the magic wand in the config file.

	"it should be fixed"

/jordan
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Mar-87 13:51:00 EST
From:      BEAME@MCMASTER.BITNET
To:        mod.protocols.tcp-ip
Subject:   CS/100 Version 12010 software.

Hello CS100 users,

     We installed Version 12010 of the bridge CS/100 TCP/IP software a few
weeks ago. I was wondering if anyone else has seen the problem illustrated
below ? It seems that the CS/100 is sending invalid IP and TCP packets.
This only occurs on sustained output. The invalid packet is retransmitted
several times in it's invalid state. After a while, about 1 minute, the
packet is retransmitted correctly.

     CFB/IN  - packets arriving at the PC from the CS/100
     CFB/OUT - packets from the PC to the CS/100

287  : CFB/IN
ether: IP    08-00-02-00-51-23 -> 02-60-8c-19-48-15    88    14755.966    3.297
   ip: TCP   01.00000b -> 01.004815
  tcp: TELNET  -> 7438     ACK
  tcp: seq: 322186923  ack:        32  win:  104  len:   30
    0: 50 1d 2c 7c 3c 50 4c 1d 2c 7d 3c 4d 4f 1d 2c 7c  |P.,|<PL.,}<MO.,||
   16: 3c 4c 4c 4c 7d 4d 4d 4d 4e 7e 4e 7d 4f 4f        |<LLL}MMMN~N}OO  |

288  : CFB/OUT
ether: IP    02-60-8c-19-48-15 -> 08-00-02-00-51-23    64    14762.347    6.381
   ip: TCP   01.004815 -> 01.00000b
  tcp: 7438    -> TELNET   ACK
  tcp: seq:        32  ack: 322186953  win:   82  len:    0

289  : CFB/IN
ether: IP    08-00-02-00-51-23 -> 02-60-8c-19-48-15    80    14799.065   36.718
   ip: TCP   01.00000b -> 01.004815
  tcp: TELNET  -> 7438     PUSH ACK
  tcp: seq: 322186953  ack:        32  win:  104  len:   22
    0: 4f 50 7c 50 50 7b 50 50 4f 7a 4f 4f 4e 4e 4d 7b  |OP|PP{PPOzOONNM{|
   16: 4d 4d 7c 4c 1d 2c                                |MM|L.,          |

290  : CFB/OUT
ether: IP    02-60-8c-19-48-15 -> 08-00-02-00-51-23    64    14801.970    2.905
   ip: TCP   01.004815 -> 01.00000b
  tcp: 7438    -> TELNET   ACK
  tcp: seq:        32  ack: 322186975  win:   82  len:    0

291  : CFB/IN
ether: IP    08-00-02-00-51-23 -> 02-60-8c-19-48-15   122    14820.583   18.613
   ip: TCP   01.00000b -> 01.004815
   ip: BAD LENGTH: IHL=20, TL=122, PKT=122
  tcp: TELNET  -> 7438     ACK
  tcp: seq: 322186975  ack:        32  win:  104  len:   82
  tcp: CKSUM ERROR: received=ac3b, calculated=82dd
    0: 7b 3c 4b 4e 1d 2c 7c 3c 4e 4b 1d 2c 7d 3c 4b 4e  |{<KN.,|<NK.,}<KN|
   16: 1d 2c 7c 3c 4b 4b 4b 7d 4b 4b 4c 7e 4c 4c 7d 4d  |.,|<KKK}KKL~LL}M|
   32: 4d 4e 4e 7c 4e 4e 7b 4e 4e 4e 7a 4d 4d 4c 4c 4c  |MNN|NN{NNNzMMLLL|
   48: 7b 4b 4b 7c 4b 1d 2c 75 3c 48 4b 1d 2c 76 3c 4b  |{KK|K.,u<HK.,v<K|

       Thanks,
              Carl Beame
              BEAME@MCMASTER.BITNET

P.S: I re-installed Version 12000 and everything was correctly.

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7 Mar 87 13:51 EST
From:      <BEAME%MCMASTER.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   CS/100 Version 12010 software.
Hello CS100 users,

     We installed Version 12010 of the bridge CS/100 TCP/IP software a few
weeks ago. I was wondering if anyone else has seen the problem illustrated
below ? It seems that the CS/100 is sending invalid IP and TCP packets.
This only occurs on sustained output. The invalid packet is retransmitted
several times in it's invalid state. After a while, about 1 minute, the
packet is retransmitted correctly.

     CFB/IN  - packets arriving at the PC from the CS/100
     CFB/OUT - packets from the PC to the CS/100

287  : CFB/IN
ether: IP    08-00-02-00-51-23 -> 02-60-8c-19-48-15    88    14755.966    3.297
   ip: TCP   01.00000b -> 01.004815
  tcp: TELNET  -> 7438     ACK
  tcp: seq: 322186923  ack:        32  win:  104  len:   30
    0: 50 1d 2c 7c 3c 50 4c 1d 2c 7d 3c 4d 4f 1d 2c 7c  |P.,|<PL.,}<MO.,||
   16: 3c 4c 4c 4c 7d 4d 4d 4d 4e 7e 4e 7d 4f 4f        |<LLL}MMMN~N}OO  |

288  : CFB/OUT
ether: IP    02-60-8c-19-48-15 -> 08-00-02-00-51-23    64    14762.347    6.381
   ip: TCP   01.004815 -> 01.00000b
  tcp: 7438    -> TELNET   ACK
  tcp: seq:        32  ack: 322186953  win:   82  len:    0

289  : CFB/IN
ether: IP    08-00-02-00-51-23 -> 02-60-8c-19-48-15    80    14799.065   36.718
   ip: TCP   01.00000b -> 01.004815
  tcp: TELNET  -> 7438     PUSH ACK
  tcp: seq: 322186953  ack:        32  win:  104  len:   22
    0: 4f 50 7c 50 50 7b 50 50 4f 7a 4f 4f 4e 4e 4d 7b  |OP|PP{PPOzOONNM{|
   16: 4d 4d 7c 4c 1d 2c                                |MM|L.,          |

290  : CFB/OUT
ether: IP    02-60-8c-19-48-15 -> 08-00-02-00-51-23    64    14801.970    2.905
   ip: TCP   01.004815 -> 01.00000b
  tcp: 7438    -> TELNET   ACK
  tcp: seq:        32  ack: 322186975  win:   82  len:    0

291  : CFB/IN
ether: IP    08-00-02-00-51-23 -> 02-60-8c-19-48-15   122    14820.583   18.613
   ip: TCP   01.00000b -> 01.004815
   ip: BAD LENGTH: IHL=20, TL=122, PKT=122
  tcp: TELNET  -> 7438     ACK
  tcp: seq: 322186975  ack:        32  win:  104  len:   82
  tcp: CKSUM ERROR: received=ac3b, calculated=82dd
    0: 7b 3c 4b 4e 1d 2c 7c 3c 4e 4b 1d 2c 7d 3c 4b 4e  |{<KN.,|<NK.,}<KN|
   16: 1d 2c 7c 3c 4b 4b 4b 7d 4b 4b 4c 7e 4c 4c 7d 4d  |.,|<KKK}KKL~LL}M|
   32: 4d 4e 4e 7c 4e 4e 7b 4e 4e 4e 7a 4d 4d 4c 4c 4c  |MNN|NN{NNNzMMLLL|
   48: 7b 4b 4b 7c 4b 1d 2c 75 3c 48 4b 1d 2c 76 3c 4b  |{KK|K.,u<HK.,v<K|

       Thanks,
              Carl Beame
              BEAME@MCMASTER.BITNET

P.S: I re-installed Version 12000 and everything was correctly.

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Mar-87 02:28:41 EST
From:      doug@UXC.CSO.UIUC.EDU (Doug Gilmore)
To:        mod.protocols.tcp-ip
Subject:   Cheap Gateway?

Though I don't have time to investigate this at
the moment, I think its worth noting.  As you may
have learned from other messages I have sent on the
net, I have ported 4.3BSD to the IBM PC-AT.
Though the port is far from complete, the network
code is fairly solid, thus it would not take too
much effort to build reliable gateway machines
using this code.  In my earlier message, I
neglected to mention that kernel has a resident
debugger that allows one single step and set
breakpoints in the kernel (the user interface is
special version of adb that runs on a VAX that
communicate with the resident debugger via a
serial line).  Thus the debugging environment is
quite reasonable.

Also it may be relatively easy to port the BRL
Gateway to the PC-AT using the 4.3BSD code as a
basis -- again the kernel debugger would prove
very useful here.

Send me mail if you would like more information.

Doug Gilmore
doug@uiucux, doug@uxc.cso.uiuc.edu

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Mar-87 15:02:01 EST
From:      MRC%PANDA@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        mod.protocols.tcp-ip
Subject:   ISO controversy


     The single thing about the whole ISO controversy that irritates
me the most is the apparent glee in which the ISO groupies (no, I don't
mean you, Marshall!) are shoving this mess down our throats.  I have
heard (and read) truly incredible statements; certain individuals are
evidentally getting quite a kick over the trauma the entire DoD Internet
will have to go through to migrate to ISO.  This is apparently our
punishment for developing an internetwork without waiting for ISO to
come through.

     A secondary source of annoyance to me is the lie that various
vendors are going to jump in and offer ISO support.  The vendor of
TOPS-20 isn't going to implement it.  Some poor schmuck (probably me)
will have to do it.  I have this nasty hunch that my friends the
Multics hackers will be in the same situation.  At least we'll have
guaranteed employment for a long time :-).

     I thought the original intent of the ISO migration issue was to
migrate to ISO *only* when it is reasonable to do so.  Any migration
now is going to cost the US taxpayers BIG bucks.  In case the paper-
pushers haven't been looking lately, us hackers no longer sell our
services cheaply.  Has ANYONE done an economic analysis of the impact
of an ISO migration on the DoD Internet?
-------

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Mar-87 16:34:53 EST
From:      jmainini@SPAM.ISTC.SRI.COM (John Mainini)
To:        mod.protocols.tcp-ip
Subject:   Re: Cheap Gateway?

Doug,
	I have an associate interested in using a PC AT as a
gateway between XNS and 3PLUS.  I've been told the 2 protocols
are very similiar, and personally I can't imagine  what 3Com 
was thinking about when they didn't follow an established standard.
Any ideas?

Thanks in advance...John Mainini.

 

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Mar-87 18:37:29 EST
From:      Mills@UDEL.EDU
To:        mod.protocols.tcp-ip
Subject:   Re:  ISO controversy

Mark,

The gloom spreading on this list about the apparent intent of ISO to
overtake and destroy TCP/IP may be premature. When the IAB was briefed
on GOSIP recently, it was understood that GOSIP would serve as the
guide to selecting conforming ISO protocols, which eventually would
be required of all new procurements, in much the same fashion as MAP/TOP.
However, there was no explicit requirement that TCP/IP could not be
operated and procured indefinately in addition to ISO protocols, just
that every procurement must include ISO, even if it isn't actually used.

From my own perspective, which I suspect is similar to that of many other
players in this band, I am working as hard as I can to assist in the
development of an Internet supporting both IP and ISO Connectionless
datagrams. Thus, the system could be used for both protocol suites in
much the same fashion that DDN Basic and Standard X.25 protocols are used
now on ARPANET/MILNET. Then, if our much beloved protocols deserve to
die in the long run, they can be accorded a funeral with honor.

It is easy to ignite discourse on both sides of the ISO-TCP/IP issue, as
seen recently in the newsprint both on and off this list. If in fact
the wrong impression was gathered at the IAB briefing and something more
sinister is afoot, it would be well to resolve the issue quickly, perhaps
in the nature of a DDN Management Bulletin.

Dave

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Mar-87 23:50:00 EST
From:      minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU
To:        mod.protocols.tcp-ip
Subject:   Re: Telnet Option Negotiation to IBMish Hosts

All,
	First, as to Philip Budne's complaint about 3270
negotiation making it hard to pass the REAL terminal type
across the telnet connection - true.  But, you have to
think about where this all came from.  The original intent
was that real, live, ibm 327x's, when initiating telnet from
their real, live ibm host, should be able to talk to other
ibm hosts in a "native" fashion.  No one should complain
about this - we let vt241 users get their vt241's connected
in "native" fashion when talking between two Vax Unix systems.

	However, the people at Wisconsin, Rice, Berkeley,
Yorktown labs, Cornell, and who knows where else have realized
that "hey, we can do that from Unix/ms-dos/macintosh-land, too!"
Then, there IS a problem.  Maybe what we need is "do terminal-type"
and also "do charlatan-terminal-type".  Anyway, the point is that
it WOULD be convenient if we knew we were trying for 3270 emulation;
or we could pass both a series of 3270 types and of "real" terminal
types.

	Say you are connecting to a system (any old system) from a PC.
The system may have a "preferred" terminal type (VT241, say), and the
PC may have a few emulation modes (adm3a, vt100, tvi950, say).  So,
the system keeps says "send terminal type", and the PC sends them
all, and finally indicates end-of-file with "unknown".  Now, we have just
"lost", since the system might just wish it had been willing to
take the best of what had been offered at the time (maybe vt100).
This is something like "the price is right" (TV show, for the uncultured).
"You may now take this vt100 and run with it, OR you may toss it
away in the hopes that what lies hidden behind that door may be better
for you".

	In fact, it may be more complicated than that.  Still, I don't
think so.  So, maybe the ability to "see the list again" would allow
for things to work.  If so, then the server could see the whole list,
keep track of "what seemed best", and then go back and ask for that
(so, why not "send terminal LIST", and "SET terminal type"?).
(The point is, right, that we are TRYING to learn; not that "we made
a mistake!".)

	As to Marvin Solomon's comments, I doubt I can add much.
I do believe that the server could buffer some data, waiting for
the end of the terminal type/eor/binary negotiations to happen
before committing to either NVT or 3270 mode.  The server is
probably in error in not accepting even some of the negotiation
out of order (but, it isn't the only server with this bug).

	The bottom line in the Wiscnet case is, probably, people
to do the various "small" things.  To my knowledge, Wisconsin is
no longer getting any IBM money to support (let alone enhance)
Wiscnet.

	I think an RFC would be nice.  I think, however, that maybe
it needs to address a fairly large amount of issues.

Greg

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Mar-87 10:24:00 EST
From:      NS-DDN@DDN2.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP


 
 
I am compelled to respond to what I perceive is a rather low opinion of
protocol vendors (which would include me, I guess). Granted, it's caveat
emptor out there, and the low opinion is deserved IN GENERAL. But there
are some vendors who are not money-grubbing capitalists to the extent that
customer dissatisfaction is irrelevant. Indeed, all vendors implicitly
understand this truth about any marketplace to some degree. The ones who
lose sight of the fact that customers buy data flowing between their
computers (not software) reap the inevitable consequences.
 
My experience would indicate that a significant number of nodes don't
want to employ network protocol experts. They would much rather find a
cradle-to-grave network solution (sorry, I couldn't resist) that they can
entrust with their data comm requirements. It's easier for managers to
beat on one vendor than on one or more employees and one or more vendors.
Yes, there is public domain software, but there are learning curves and
other hidden costs associated with it, and you still need the hardware.
 
The theory is that more than one vendor springs up to provide these
services, each with approximately the same savoir faire and customer
commitment. The choices available to the customer cause prices to be
competitive. It's lack of alternatives which cause customer gouging.
 
Believe it or not, we do have satisfied customers.
 
And these are obviously my own personal opinions only, too.
 
Dave Craig
Network Solutions, Inc.

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 87 10:24 EST
From:      NS-DDN @ DDN2
To:        karn @ flash.bellcore.com
Cc:        TCP-IP @ SRI-NIC.ARPA
Subject:   Re: GOSIP vs TCP/IP
 
 
I am compelled to respond to what I perceive is a rather low opinion of
protocol vendors (which would include me, I guess). Granted, it's caveat
emptor out there, and the low opinion is deserved IN GENERAL. But there
are some vendors who are not money-grubbing capitalists to the extent that
customer dissatisfaction is irrelevant. Indeed, all vendors implicitly
understand this truth about any marketplace to some degree. The ones who
lose sight of the fact that customers buy data flowing between their
computers (not software) reap the inevitable consequences.
 
My experience would indicate that a significant number of nodes don't
want to employ network protocol experts. They would much rather find a
cradle-to-grave network solution (sorry, I couldn't resist) that they can
entrust with their data comm requirements. It's easier for managers to
beat on one vendor than on one or more employees and one or more vendors.
Yes, there is public domain software, but there are learning curves and
other hidden costs associated with it, and you still need the hardware.
 
The theory is that more than one vendor springs up to provide these
services, each with approximately the same savoir faire and customer
commitment. The choices available to the customer cause prices to be
competitive. It's lack of alternatives which cause customer gouging.
 
Believe it or not, we do have satisfied customers.
 
And these are obviously my own personal opinions only, too.
 
Dave Craig
Network Solutions, Inc.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Mar-87 10:36:12 EST
From:      PADLIPSKY@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ISO controversy

Dave--
   You appear to have fallen into the same trap as Marshall Rose
did (and as Dennis Perry did, as witness his recent msg to Marshall,
copied to TCP-IP): what they say to you in a meeting is NOT binding;
what they publish in a specification IS.
   See 1.4, Applicability (emphasis added): "GOSIP is to be USED
by ALL Federal Government agencies..." and "FOR A PERIOD OF TWO
YEARS, agencies are PERMITTED to procure alternative interoperble
protocols...."  Does that sound like "peaceful coexistence"?
   Rather than get all pedantic over how much havoc even an "i.e."
instead of an "e.g." in a spec can cause, I'll settle for urging
you to take whatever action you think appropriate to make the
GOSIP spec come out with language supporting the position you
heard rather than the position it currently takes.
   cheers, map
-------

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1987 10:36:12 EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        Mills@LOUIE.UDEL.EDU
Cc:        Mark Crispin <MRC%PANDA@SUMEX-AIM.STANFORD.EDU>, TCP-IP@SRI-NIC.ARPA
Subject:   Re:  ISO controversy
Dave--
   You appear to have fallen into the same trap as Marshall Rose
did (and as Dennis Perry did, as witness his recent msg to Marshall,
copied to TCP-IP): what they say to you in a meeting is NOT binding;
what they publish in a specification IS.
   See 1.4, Applicability (emphasis added): "GOSIP is to be USED
by ALL Federal Government agencies..." and "FOR A PERIOD OF TWO
YEARS, agencies are PERMITTED to procure alternative interoperble
protocols...."  Does that sound like "peaceful coexistence"?
   Rather than get all pedantic over how much havoc even an "i.e."
instead of an "e.g." in a spec can cause, I'll settle for urging
you to take whatever action you think appropriate to make the
GOSIP spec come out with language supporting the position you
heard rather than the position it currently takes.
   cheers, map
-------
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Mar-87 12:41:07 EST
From:      ucdla%topaz.Berkeley.EDU@UCBVAX.BERKELEY.EDU (U.C. Div of Library Automa)
To:        mod.protocols.tcp-ip
Subject:   gosip


anyone know how to go about getting a copy of the gosip document?

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Mar-87 13:45:32 EST
From:      kzm@ACC-SB-UNIX.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

Mike,

I agree with your comments on the GOSIP spec, but not because I am
opposed to ISO/OSI.  On the contrary, on that future day when
it replaces TCP/IP, I think it will be to the benefit of all, since
it will encompass a larger audience.  This is irrespective of the
technical arguments of which is currently better.

Here are a few more technical criticisms you might add to your paper :

1. [4.2.4] Packet Voice definitely requires use of other than Transport
class 4.

2. [4.2.7.3] says that end systems connected to public data networks
must implement TP0, but end systems connected to a private subnetwork
must implement TP4 !!  This is clearly not inter-operable.

3. [page 19] says "Note that the SNPA is interpreted as decimal digits,
even though the AFI of 47 indicates a binary representation" !!  Is
this following the standards ??

4. [top of page 20] specifies that the level-3 address must be encoded 
according to which Level-1 protocol is used (eg. 802.3 is given a
NSAP Selector different from 802.4 when both have 802.2 above them).
There is already a subnet-id included in the address.  Why mix the 
layers like this ?

Cheers,
Keith McCloghrie
ACC 
Columbia, Md.

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1987 06:00-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: GOSIP
The following is sent on behalf of Mike Corrigan:
_____________________________________________________________





          A few comments:
          
          1.  GOSIP is the Government OSI Protocol Specification. 
          It was prepared by a working group of the Government OSI
          Users Group, chaired by NBS, which was formed in reaction
          to what was a pending Office of Management and Budget
          announcement mandating use of OSI, without benefit of a
          specification.  I don't know the exact status of the OMB
          announcemnet, but I believe it is still pending.  
          
          2.  GOSIP is supposed to have been made available for
          FTPing from the NIC, but I'm not sure it is really there. 
          I will find out and let you know.
          
          3.  A specification such as GOSIP consists of two key
          parts: what it is you hope to buy and when you have to buy
          it, or, the body of the spec and the applicability
          statement.  If these don't match as well as they might,
          you get some very peculiar discussions.  I think Mike P's
          discussion makes it clear that the GOSIP spec pulls no
          punches with respect to what ypu can currently acquire in
          OSI, and if the applicability statement were not part of
          the document, it would meet truth in labelling, full
          disclosure and informed consent concerns a lot better than
          we have ever managed in the ARPA/DOD protocol standards
          arena (for example, did anyone ask themselves about
          guidance or capabilities in the areas of performance,
          testing, and user interfaces for TCP/IP/SMTP/FTP/TELNET
          when reading Mike P's comments?).  If we had waited for
          adequacy in these areas in DOD, we would still be waiting.
          
          4.  The group responsible for resolving the mismatch
          between the applicability statement and the spec body in
          DOD is the protocol standards steering group (actually, it
          is more complicated than that, but the PSSG invited all
          the complications to participate with them).  At its
          recent meeting, the issues Mike P. raised were brought to
          the table by his sponsor, as well as a number of others,
          and I believe they will be adequately addressed in the DOD
          comments on the spec, and for the most part will be
          incorporated in the final spec.  I believe that the result
          will be to place the applicability statement somewhere
          between the Mike P. reading and the Marshall Rose reading.
          After the GOSIP is published, there will still need to be
          guidance prepared by the different agencies for its use in
          each agency, since different agencies have different plans
          and concerns.
          
          5.  At this point, I believe additional comments would be
          most useful if they adopted the Marshall Rose
          interpretation, that is, "If you want to do interoperable
          OSI, this is how to do it."  An additional issue is how
          OSI should be used by the protocol research community. 
          For really far out research, clearly OSI (or current
          ARPA/DOD) are minimally relevant.  But there is a lot of
          


          



                                                                      



          research in the nearer term which could result in changes
          to currently planned and operational protocols.  Assuming
          that one believes that the operational protocols for lots
          of folks are going to be OSI, then the question is how
          might improvements best be researched.  One approach would
          be to adopt OSI as the research base.  This has a lot of
          apparent advantages: direct applicability and shared
          terminology for two.  A possible difficulty is that the
          OSI protocols might be a bit "rich" to use when
          investigating particular points, and a "leaner" protocol
          suite might be easier to use as the research suite.  This
          approach, however, would have the disadvantage of needing
          a translation step.  (Incidentally, I thought Mike P's
          protocol to car analogy was less than apt.  I would go
          with OSI is to DOD as Lincoln Town Car is to MGB.)
          
          Mike C.
          








































          


-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Mar-87 09:00:00 EST
From:      STJOHNS@SRI-NIC.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

The following is sent on behalf of Mike Corrigan:
_____________________________________________________________





          A few comments:
          
          1.  GOSIP is the Government OSI Protocol Specification. 
          It was prepared by a working group of the Government OSI
          Users Group, chaired by NBS, which was formed in reaction
          to what was a pending Office of Management and Budget
          announcement mandating use of OSI, without benefit of a
          specification.  I don't know the exact status of the OMB
          announcemnet, but I believe it is still pending.  
          
          2.  GOSIP is supposed to have been made available for
          FTPing from the NIC, but I'm not sure it is really there. 
          I will find out and let you know.
          
          3.  A specification such as GOSIP consists of two key
          parts: what it is you hope to buy and when you have to buy
          it, or, the body of the spec and the applicability
          statement.  If these don't match as well as they might,
          you get some very peculiar discussions.  I think Mike P's
          discussion makes it clear that the GOSIP spec pulls no
          punches with respect to what ypu can currently acquire in
          OSI, and if the applicability statement were not part of
          the document, it would meet truth in labelling, full
          disclosure and informed consent concerns a lot better than
          we have ever managed in the ARPA/DOD protocol standards
          arena (for example, did anyone ask themselves about
          guidance or capabilities in the areas of performance,
          testing, and user interfaces for TCP/IP/SMTP/FTP/TELNET
          when reading Mike P's comments?).  If we had waited for
          adequacy in these areas in DOD, we would still be waiting.
          
          4.  The group responsible for resolving the mismatch
          between the applicability statement and the spec body in
          DOD is the protocol standards steering group (actually, it
          is more complicated than that, but the PSSG invited all
          the complications to participate with them).  At its
          recent meeting, the issues Mike P. raised were brought to
          the table by his sponsor, as well as a number of others,
          and I believe they will be adequately addressed in the DOD
          comments on the spec, and for the most part will be
          incorporated in the final spec.  I believe that the result
          will be to place the applicability statement somewhere
          between the Mike P. reading and the Marshall Rose reading.
          After the GOSIP is published, there will still need to be
          guidance prepared by the different agencies for its use in
          each agency, since different agencies have different plans
          and concerns.
          
          5.  At this point, I believe additional comments would be
          most useful if they adopted the Marshall Rose
          interpretation, that is, "If you want to do interoperable
          OSI, this is how to do it."  An additional issue is how
          OSI should be used by the protocol research community. 
          For really far out research, clearly OSI (or current
          ARPA/DOD) are minimally relevant.  But there is a lot of
          


          



                                                                      



          research in the nearer term which could result in changes
          to currently planned and operational protocols.  Assuming
          that one believes that the operational protocols for lots
          of folks are going to be OSI, then the question is how
          might improvements best be researched.  One approach would
          be to adopt OSI as the research base.  This has a lot of
          apparent advantages: direct applicability and shared
          terminology for two.  A possible difficulty is that the
          OSI protocols might be a bit "rich" to use when
          investigating particular points, and a "leaner" protocol
          suite might be easier to use as the research suite.  This
          approach, however, would have the disadvantage of needing
          a translation step.  (Incidentally, I thought Mike P's
          protocol to car analogy was less than apt.  I would go
          with OSI is to DOD as Lincoln Town Car is to MGB.)
          
          Mike C.
          








































          

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Mar-87 10:20:08 EST
From:      PADLIPSKY@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   GOSIP (Re)action?

Jon--
   Rather than hold fire until everybody who has HEARD things
about GOSIP that are rather different from what has been WRITTEN
about it manages to catch up with their reading (after all,
Marshall has already thrown in the towel and presumably Dave will
soon), may I suggest we assume consensus has been reached in the
TCP-IP "world" that the GOSIP draft AS CIRCULATED is inappropriate
and turn to discussing ways of combatting it?  Does it make sense
to encourage everybody who has/will come out against it
to send hardcopy to Corrigan and Sullivan, seeing that they don't
appear to be responding to netmail?  Would you like to join me
in encouraging Dennis Perry to encourage DARPA to take a formal
stand?  Should we be suggesting to all interested readers of
TCP-IP that they write to Congress? to the GOSIP address you
put in your first msg on the topic? to the chaplain?  Does
anybody out there have any connections with "60 Minutes"?
(Not totally facetious, that; they might like one where the
DoD has the right end of the stick and it's OMB and/or NBS
who are leading to the overexpenditures, if only to balance
the one they did the other week about the Bradley Armored
Personnel Incinerator--er, uh, Carrier.)
   I'll be sending my own hardcopy, in compliance with a
suggestion Dennis made, but I'd like to think all concerned
parties can "do something" in concert.  Any ideas?
(For that matter, can you publish on the List appropriate
p-mail addresses for Sullivan and Corrigan [p=physical],
and should the NBS copy go to the attention of Jim Burrows,
who was Heafner's boss before he left, perhaps, rather than
just to GOSIP?)
   totally unfacetious cheers, map
P.S.  As evidence of my seriousness, note that I consciously
resisted saying that the hardcopy should be sent Return
Receipt Requested.
-------

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1987 10:20:08 EST
From:      PADLIPSKY@A.ISI.EDU
To:        postel@A.ISI.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   GOSIP (Re)action?
Jon--
   Rather than hold fire until everybody who has HEARD things
about GOSIP that are rather different from what has been WRITTEN
about it manages to catch up with their reading (after all,
Marshall has already thrown in the towel and presumably Dave will
soon), may I suggest we assume consensus has been reached in the
TCP-IP "world" that the GOSIP draft AS CIRCULATED is inappropriate
and turn to discussing ways of combatting it?  Does it make sense
to encourage everybody who has/will come out against it
to send hardcopy to Corrigan and Sullivan, seeing that they don't
appear to be responding to netmail?  Would you like to join me
in encouraging Dennis Perry to encourage DARPA to take a formal
stand?  Should we be suggesting to all interested readers of
TCP-IP that they write to Congress? to the GOSIP address you
put in your first msg on the topic? to the chaplain?  Does
anybody out there have any connections with "60 Minutes"?
(Not totally facetious, that; they might like one where the
DoD has the right end of the stick and it's OMB and/or NBS
who are leading to the overexpenditures, if only to balance
the one they did the other week about the Bradley Armored
Personnel Incinerator--er, uh, Carrier.)
   I'll be sending my own hardcopy, in compliance with a
suggestion Dennis made, but I'd like to think all concerned
parties can "do something" in concert.  Any ideas?
(For that matter, can you publish on the List appropriate
p-mail addresses for Sullivan and Corrigan [p=physical],
and should the NBS copy go to the attention of Jim Burrows,
who was Heafner's boss before he left, perhaps, rather than
just to GOSIP?)
   totally unfacetious cheers, map
P.S.  As evidence of my seriousness, note that I consciously
resisted saying that the hardcopy should be sent Return
Receipt Requested.
-------
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Mar-87 10:31:20 EST
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

Phil--
   Your comments on "the Europeans" reminded me that I'd never
gotten around to commenting on a msg Jon sent some time back
containing a quotation to the effect that the trouble with 5,000-
member standards committees is that they spend all their time
debating whether to have croissants or doughnuts for breakfast.
I'm sure you'll agree that the quotation couldn't have been about
ISO or CCITT, since they'd have been debating croissants vs.
brioches--doughnuts would give the American vendors too big a
headstart.
   cheers, map
-------

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1987 10:31:20 EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        karn@FLASH.BELLCORE.COM (Phil R. Karn)
Cc:        bryan@ACC-SB-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: GOSIP vs TCP/IP
Phil--
   Your comments on "the Europeans" reminded me that I'd never
gotten around to commenting on a msg Jon sent some time back
containing a quotation to the effect that the trouble with 5,000-
member standards committees is that they spend all their time
debating whether to have croissants or doughnuts for breakfast.
I'm sure you'll agree that the quotation couldn't have been about
ISO or CCITT, since they'd have been debating croissants vs.
brioches--doughnuts would give the American vendors too big a
headstart.
   cheers, map
-------
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Mar-87 13:38:00 EST
From:      andrews@wharton-10.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   schools doing Network research



   I'm interested in which schools are doing computer networking
design and implementation or protocol design and implementation.
  I need aplication information for graduate school and would 
appreciate information on who could I contact at these schools.



Thank You

Scott W Andrews
University of Pennsylvania
Philadelphia PA 19104
(215)898-5392
arpa: andrews@wharton-10

------

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 87 13:38:00 EST
From:      "Scott W. Andrews" <andrews@wharton-10>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   schools doing Network research


   I'm interested in which schools are doing computer networking
design and implementation or protocol design and implementation.
  I need aplication information for graduate school and would 
appreciate information on who could I contact at these schools.



Thank You

Scott W Andrews
University of Pennsylvania
Philadelphia PA 19104
(215)898-5392
arpa: andrews@wharton-10

------
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Mar-87 15:24:41 EST
From:      PERILLO@SRI-NIC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   GOSIP doc now online at SRI-NIC.ARPA

The NIC has received approval from Mike Corrigan to release the
GOSIP document online.  It may be FTPed from the SRI-NIC.ARPA host
using the pathname NETINFO:GOSIP.DOC.  It is 50 disk pages long.
SRI-NIC.ARPA supports "anonymous" login.

-Francine  /NIC
-------

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Mar-87 23:09:57 EST
From:      jbvb@BORAX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: TCP/IP header question

I don't see any reason to send obsolete information; our
implementation updates both ACKs and Window to the values current at
the instant the packet is sent.  Of course, this does mean we have to
re-checksum the packet, but we have to do this anyway if a packet gets
partially ack'ed (which you'd better be prepared for...)  Note that it
*does* seem like a good idea (not mine) to retain the IP
'identification' so that fragments can be assembled from any instance
of (re)transmission of a given packet.

jbvb@ai.ai.mit.edu
James B. VanBokkelen
FTP Software, Inc.

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Mar-87 23:24:42 EST
From:      jbvb@BORAX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Thanks to all the TN3270 posters:

The discussion was very timely: my TN3270 (ancestry: PC/TCP Telnet and
Greg Minshall's emulator code, less curses) succeeded in negotiating
to BINARY, EOR & terminal type 3278-2 on its second try (against
Wiscnet).  I don't require EOR to enter 3270 mode, which seems to be
de rigeur, given Spartacus's current behavior.  I'll test that
tomorrow.  Anyone out there want to volunteer a UCLA MVS so I can see
how well it backs out of 3270?

This one will probably get to terminal type 3278-2 with a 4.3 as
well, but that seems to be the way the cookie crumbles (if I've read
the postings right).

jbvb@ai.ai.mit.edu
James B. VanBokkelen
FTP Software Inc.

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Mar-87 08:23:19 EST
From:      mckee@MITRE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

I circulated the note from Phil ("...darker forces at play ...")
among several colleagues here at MITRE-Washington; herewith the 
views of Steve Silverman.
--------------------------------------

 *** Reply to note of 03/08/87 10:09
 From:    Steve Silverman
 Subject: GOSIP vs TCP/IP
 I would like to reply to your note on TCP/IP and its non-acceptance by the
 commercial world.  First of all, I doubt that there is any connection with
 the various television standards other than the prevalence of the NIH
 syndrome.  This seems to be fairly prevalent in many places including the DOD.
     
 As far as TCP/IP versus ISO, it must be recongnized that there are two ISO
 suites being developed.  One, the Connection-Based (CB), uses TP over X.25.
 The second one, the Connectionless (CL) suite, uses IP between TP and X.25.
 The CL suite is a datagram approach in the tradition of the ARPANET. This was
 used in the first generation packet networks, but has significant costs
 in comparison with the CB approach used by later generation commercial
 packet networks.  The CL approach means that each packet must contain
 a larger header (TCP/IP = 40 bytes) than a CB packet (X.25 = 3 bytes).
 The CL approach requires each switch to make a routing decision on each packet
 while the CB approach allows transit switches to do a simple table lookup for
 following packets.
     
 Each suite has its benefits; the CL approach is better for tactical networks
 with very mobile nodes.  The CB approach is much more economical for higher
 data requirements.  The public data networks are almost exclusively CB.
 The design work being done today for future networks by the common carrier
 network builders is almost exclusively CB based, although the OSI 7 layer
 model is being downplayed (really discarded).  To some of us, the use of
 a CL stationary packet network is equivalent to forcing all military
 ground vehicles to be armored and armed.  If 495 (our local beltway) were
 filled with tanks, it would be a major waste of money.
     
 It is about time, in my opinion, that the military networkers realized that
 the commercial data users are not stupid.  They demand the same reliability
 that the DOD requires.  The Reconnect feature of X.25 prevents loss of
 user data when a transit node fails.  This has been widely deployed for
 years.  Meanwhile the cost of running the ARPANET is comparable to running
 the Telenet public network which carries ten times as many user packets.
     
 The reluctance of some people to embrace TCP/IP is not just based on NIH.
 Some of us reject it on technical grounds.
 Steve Silverman
 *
 *        Steve
:::GOSIP vs TCP/IP                                                        R

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Mar-87 15:20:48 EST
From:      MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP


     If OSI is to DoD the way a Lincoln Town Car is to an MGB,
I guess we'll be running DoD protocols for a long long time to
come.

     As a network programmer, I am delighted at the prospect of
full employment for everybody in my field for a very long time,
at US government expense.  As a taxpayer, I'm outraged, and am
starting to make comparisions in my mind with the Sgt. York and
the B-1.

     I am wondering if what we are seeing is OSI having become
so large and unmanagable that implementability has become a
forgotten goal.  I read the FTAM specification and still am not
completely sure what FTAM is all about.  "Eschew obfuscation"
seems to have been forgotten.

     More to the point; I don't think the US government should
be in the business of trying to establish OSI as a standard
protocol.  The current regime is big on "market" based decisions.
If the US government sees itself as a USER of an international
standard protocol but is otherwise neutral on what that protocol
should be, then the current de facto international standard is
TCP/IP.  If OSI is so wonderful, then all the other users of
network protocols -- industry, research, our foreign allies,
the socialist countries(!!) -- will migrate to OSI without US
government pressure being brought to bear.

     If OSI fails to gain such widespread acceptance, then
perhaps it was a bad idea to begin with.  Nobody is seriously
suggesting that TCP/IP should be retained indefinitely; what
we ARE saying is that there should not be *any* talk of
migration until there is clearly something better available.
-------

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Mar-87 17:34:59 EST
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP (Re)action?

Mike, I have made a very strong request to Corrigan at the PSSG meeting
to include something in the GOSIP document to exempt research related
procurement.  Mick C. agreed to include such suggestion, as I believe
he alluded to in his response to the net.  DARPA's position is that research
should not be hampered by standards, but shoud use them as appropriate
to further their research.  It may also mean not using them to further
their research.  The Arpanet is a research network.  You can draw your
own conclusions from  their on my position.

dennis
-------

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Wed 11 Mar 87 17:34:59-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        PADLIPSKY@a.isi.edu
Cc:        postel@a.isi.edu, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: GOSIP (Re)action?
Mike, I have made a very strong request to Corrigan at the PSSG meeting
to include something in the GOSIP document to exempt research related
procurement.  Mick C. agreed to include such suggestion, as I believe
he alluded to in his response to the net.  DARPA's position is that research
should not be hampered by standards, but shoud use them as appropriate
to further their research.  It may also mean not using them to further
their research.  The Arpanet is a research network.  You can draw your
own conclusions from  their on my position.

dennis
-------
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Mar-87 22:55:43 EST
From:      zhuang@seismo.CSS.GOV@dalcs.UUCP
To:        mod.protocols.tcp-ip
Subject:   submission

This is my submission to the list of tcp.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Mar-87 23:41:27 EST
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP

Could you forward this back to Mike Corrigan:

My primary concern is that we don't push OSI so fast that we ruin its
long-term future.  TCP/IP proceeded the way it did because there was
no choice.  We had to get things out quickly because we needed the
facilities.  After all, it was originally claimed to be a research
vehicle.  OSI is supposed to be different.  It is supposed to be a
second-generation, production system, commerically supported, and all
that.  I have my own scepticism about this, but the point is that it
will accomplish absolutely nothing if we push people into it so fast
that we just duplicate the history of TCP/IP.  One thing that 4.1 and
4.2 make very clear is how hard it is to get improved software into
everybody's hands once large groups of people have started to use
something.  How many years will it have taken to get subnets in use?
(It still isn't finished.)  I understand the political pressure to
move ahead quickly with OSI, but I think that should be resisted.  I
think you should be writing specs for pilot implementations, but be
suggesting that all production work be done with TCP/IP.  The point is
that we should give OSI a chance to get some actual use in
well-controlled environments, and do lots of testing.  When something
is offered for general use, that something should be well-tested and
the robust.  The last thing we should be doing is pressuring vendors
to come out with products prematurely, as GOSIP seems sure to do.

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Thu 12 Mar 87 18:48:01-PST
From:      Karl Auerbach <AUERBACH@CSL.SRI.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   A defense of GOSIP
I think GOSIP is a good idea.  I support it.

I have read GOSIP.  I have read, indeed participated in, the NBS
Implementors' workshops.  I have read, and believe I understand many,
if not most of the ISO and CCITT specifications.  I have been
implementing one of the larger parts (X.400).

1. As for GOSIP mandating a universal government wide requirement: No
matter how one reads the express language of the document, does anyone
really think that agencies will abandon SNA?  If SNA is an implicit
exception why not TCP, XNS, ... ?

2. The entire validity of the ISO protocol suite has been called into
question because some of the standards have changed as they progressed
through the standardization process.  So what?  Couldn't the same
reasoning be applied to the TCP suite because new RFC's are issued?

Yes, the ISO protocols and services are changing.  Our own X.400
implementation will be, in part, invalidated due to changes which will
be "approved" next year.

And is ISO missing important parts?  Yes.  For instance its protocols
for handling routing between intermediate systems ("gateways" in TCP
terms) are still being developed.  But can one really say that the
Internet has done a really good job of inter-gateway routing?

Does MAP/TOP contain some really incredibly dumb ideas?  Yes.  For
example, network level addresses (NSAPs) contain the PHYSICAL media
addresses (e.g. the 48 bit Ethernet address).  This can become a
management nightmare, especially as the NSAP is a necessary component
of higher level addresses and will be stored by the various
application level directory services.  But this oddity is NOT a
necessary part of ISO, only a temporary expedient reasonably adopted
by the MAP folks to defer inventing ARP and routing protocols.  GOSIP
places a high priority on resolving this issue.  And answers are
presently being considered, just read for example, RFC 995.

Does this mean that one should not "go ISO".  Perhaps, if you are
measuring costs over a short term.  But, if you take a long view, and
believe that ISO will, in fact, mature, then perhaps you ought to
invest now, grow-up with the technology, and avoid a conversion
expense.

3. The ISO protocols and services contain many, many good ideas.  They
are in many respects superior to TCP services.  There has been
criticism that the ISO work is bloated.  I believe this is a valid
objection.  But if you look at the Implementors' Agreements you will
find many portions of the full ISO specifications which have been
chopped off or limited.  In addition, as I have worked with ISO my
viewpoint has changed.  For example, at first I considered most of the
session synchronization functions to be questionable.  Why should I
pay their cost when I am never going to use them?  It turns out that
they are extremely useful.  And, in practice, they don't seem to cost
much.  I remember similar arguments being raised by assembler language
programmers against "the terrible waste of high level languages."

               --karl--  Karl Auerbach
                         Epilogue Technology Corporation
-------
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Mar-87 21:48:01 EST
From:      AUERBACH@CSL.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   A defense of GOSIP

I think GOSIP is a good idea.  I support it.

I have read GOSIP.  I have read, indeed participated in, the NBS
Implementors' workshops.  I have read, and believe I understand many,
if not most of the ISO and CCITT specifications.  I have been
implementing one of the larger parts (X.400).

1. As for GOSIP mandating a universal government wide requirement: No
matter how one reads the express language of the document, does anyone
really think that agencies will abandon SNA?  If SNA is an implicit
exception why not TCP, XNS, ... ?

2. The entire validity of the ISO protocol suite has been called into
question because some of the standards have changed as they progressed
through the standardization process.  So what?  Couldn't the same
reasoning be applied to the TCP suite because new RFC's are issued?

Yes, the ISO protocols and services are changing.  Our own X.400
implementation will be, in part, invalidated due to changes which will
be "approved" next year.

And is ISO missing important parts?  Yes.  For instance its protocols
for handling routing between intermediate systems ("gateways" in TCP
terms) are still being developed.  But can one really say that the
Internet has done a really good job of inter-gateway routing?

Does MAP/TOP contain some really incredibly dumb ideas?  Yes.  For
example, network level addresses (NSAPs) contain the PHYSICAL media
addresses (e.g. the 48 bit Ethernet address).  This can become a
management nightmare, especially as the NSAP is a necessary component
of higher level addresses and will be stored by the various
application level directory services.  But this oddity is NOT a
necessary part of ISO, only a temporary expedient reasonably adopted
by the MAP folks to defer inventing ARP and routing protocols.  GOSIP
places a high priority on resolving this issue.  And answers are
presently being considered, just read for example, RFC 995.

Does this mean that one should not "go ISO".  Perhaps, if you are
measuring costs over a short term.  But, if you take a long view, and
believe that ISO will, in fact, mature, then perhaps you ought to
invest now, grow-up with the technology, and avoid a conversion
expense.

3. The ISO protocols and services contain many, many good ideas.  They
are in many respects superior to TCP services.  There has been
criticism that the ISO work is bloated.  I believe this is a valid
objection.  But if you look at the Implementors' Agreements you will
find many portions of the full ISO specifications which have been
chopped off or limited.  In addition, as I have worked with ISO my
viewpoint has changed.  For example, at first I considered most of the
session synchronization functions to be questionable.  Why should I
pay their cost when I am never going to use them?  It turns out that
they are extremely useful.  And, in practice, they don't seem to cost
much.  I remember similar arguments being raised by assembler language
programmers against "the terrible waste of high level languages."

               --karl--  Karl Auerbach
                         Epilogue Technology Corporation
-------

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 1987 07:20:45 PST
From:      PADLIPSKY@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Cc:        corrigan@SRI-NIC.ARPA, GTSullivan@DOCKMASTER.ARPA
Subject:   Still More Re GOSIP
[This might be a redundant resend, but the copy I thought was going to 
the List came back with

Message failed for the following:
tcp-ip@SRI-NIC.ARPA: Forwarding error: Cannot find indirect file - No such device
	    ------------

so I figured I'd better try again (maybe it's some kind of cosmic
compensation for all the ones I thought I'd sent once that have
shown up twice). NOTE, by the way, that I've expanded the contents,
so even if you think you've seen it before, you haven't really.]

[Mainly for Mike C.]

Mike--
   Glad to hear from you finally.  Guess I can save the Government
the postage on hardcopy after all.
   A couple of quick rejoinders: The reason why testing and
performance stuff is not relevant to the ARPANET Suite but is
relevant to GOSIP (and eventually to OSI--which, it must be realized,
must be distinguished from GOSIP) is contained in the final
sentence of 1.1, Background (of the GOSIP Draft): "By
implementing open systems, the government expects to realize
significant savings through reducing duplicate circuits and
wiring, training, custom software, work stations, and custom hardware
interfaces."  Without testing and performance criteria, GOSIP
(as it stands) would have to lead to INCREASED costs in "custom
software"--to pay for the interoperability-bug fixes and the
code tightening, that is.   (On a somewhat different, but actually
more threatening, tack, another way in which the promise of cost
savings from "off-the-shelf"/"standard" software is betrayed lies
in the fact that those [DoD] systems which will be using "Blacker"
will have to have their X.25 implementations gutted and rehabbed,
but let's save the details on that for a venue other than the
TCP-IP "bulletin board"/mailing list.)  Note, however, that when the
ARPANET Suite was being adopted, nobody claimed the advantages
of vendor support for it.  GOSIP is claiming such advantages
and demonstrably won't achieve them, both because of the need
for further work on the current stuff and because of the need for
further expenditure on the new stuff.  A moving target is a moving target.
(There's an irony in the fact that now that the ARPANET Suite
is enjoying most of the advantages of vendor support after all,
we're being asked to chuck it; but let it [the irony, not the 
Suite] pass.)
   Re automotive analogies: I'd be inclined to go with your
recasting provided you make it a picture of an artist's
conception of a "car of the future" model Lincoln vs. an actual MBG.
I was trying to be polite by saying GOSIP was a stripped Renault,
but if you insist on focusing on what OSI is eventually intended
to be, we're in the realm of promises vs. realities.
   cheers, map
P.S. Bravo on getting DARPA not to be considered a Government
agency.  Here's hoping you can do the same for DoD.  (I.e., get
it exempted from forced transition; after all, the ARPANET Suite
is paid for and could be run in parallel with the OSI Suite when
the OSI Suite is really here and really needed to interoperate
with, e.g., NATO.)
P.P.S. New metaphor: everybody's being told to run as hard as
they can to get on this merry-go-round, and when they do they
discover the brass ring dispenser's empty.  (For those who
don't remember such things, if you grabbed the brass ring you'd
get a free ride.)
-------
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Mar-87 10:20:45 EST
From:      PADLIPSKY@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Still More Re GOSIP

[This might be a redundant resend, but the copy I thought was going to 
the List came back with

Message failed for the following:
tcp-ip@SRI-NIC.ARPA: Forwarding error: Cannot find indirect file - No such device
	    ------------

so I figured I'd better try again (maybe it's some kind of cosmic
compensation for all the ones I thought I'd sent once that have
shown up twice). NOTE, by the way, that I've expanded the contents,
so even if you think you've seen it before, you haven't really.]

[Mainly for Mike C.]

Mike--
   Glad to hear from you finally.  Guess I can save the Government
the postage on hardcopy after all.
   A couple of quick rejoinders: The reason why testing and
performance stuff is not relevant to the ARPANET Suite but is
relevant to GOSIP (and eventually to OSI--which, it must be realized,
must be distinguished from GOSIP) is contained in the final
sentence of 1.1, Background (of the GOSIP Draft): "By
implementing open systems, the government expects to realize
significant savings through reducing duplicate circuits and
wiring, training, custom software, work stations, and custom hardware
interfaces."  Without testing and performance criteria, GOSIP
(as it stands) would have to lead to INCREASED costs in "custom
software"--to pay for the interoperability-bug fixes and the
code tightening, that is.   (On a somewhat different, but actually
more threatening, tack, another way in which the promise of cost
savings from "off-the-shelf"/"standard" software is betrayed lies
in the fact that those [DoD] systems which will be using "Blacker"
will have to have their X.25 implementations gutted and rehabbed,
but let's save the details on that for a venue other than the
TCP-IP "bulletin board"/mailing list.)  Note, however, that when the
ARPANET Suite was being adopted, nobody claimed the advantages
of vendor support for it.  GOSIP is claiming such advantages
and demonstrably won't achieve them, both because of the need
for further work on the current stuff and because of the need for
further expenditure on the new stuff.  A moving target is a moving target.
(There's an irony in the fact that now that the ARPANET Suite
is enjoying most of the advantages of vendor support after all,
we're being asked to chuck it; but let it [the irony, not the 
Suite] pass.)
   Re automotive analogies: I'd be inclined to go with your
recasting provided you make it a picture of an artist's
conception of a "car of the future" model Lincoln vs. an actual MBG.
I was trying to be polite by saying GOSIP was a stripped Renault,
but if you insist on focusing on what OSI is eventually intended
to be, we're in the realm of promises vs. realities.
   cheers, map
P.S. Bravo on getting DARPA not to be considered a Government
agency.  Here's hoping you can do the same for DoD.  (I.e., get
it exempted from forced transition; after all, the ARPANET Suite
is paid for and could be run in parallel with the OSI Suite when
the OSI Suite is really here and really needed to interoperate
with, e.g., NATO.)
P.P.S. New metaphor: everybody's being told to run as hard as
they can to get on this merry-go-round, and when they do they
discover the brass ring dispenser's empty.  (For those who
don't remember such things, if you grabbed the brass ring you'd
get a free ride.)
-------

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Mar-87 11:14:16 EST
From:      markl@THYME.LCS.MIT.EDU
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP


>     If OSI is to DoD the way a Lincoln Town Car is to an MGB,
>I guess we'll be running DoD protocols for a long long time to
>come.

Well *I* have always found MGs to be paragons of reliability...

				markl

Internet: markl@ptt.lcs.mit.edu

MIT Laboratory for Computer Science
Distributed Systems Group

----------

"When all else fails, pour a pint of Guinness in the gas tank, advance
the spark 20 degrees, cry "God Save the Queen!", and pull the starter
knob."
	-- MG "Series MGA" Workshop Manual :-)

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Mar-87 13:12:13 EST
From:      slf@well.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP (Re)action?


I'm not 60 Minutes, but I am a computer journalist who has been following
this discussion for the past couple of weeks with much interest.  I am
considering doing an article on this for InfoWorld (I'm the communications
editor).  To get this past my editors, I have to demonstrate that there is
some PC connection; also, I would have to talk to people on 'the other side'
(i.e., pro-GOSIP) to get their views as well.  Does anybody have any
information that can help me?  Thanks.

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Mar-87 02:58:49 EST
From:      WANCHO@SIMTEL20.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Black Art: sendmail.cf files

It seems the root of many of the improperly formed message headers,
and the reason that many hosts have had difficulty in switching to the
domain format host names is poorly constructed sendmail.cf files.
This problem will shortly become acute when the NIC will no longer
disribute its HOSTS.TXT file containing host alias entries.

Therefore, I'd like to propose that a small handful of sendmail
wizards get together and produce one proven sendmail.cf file for each
of the major environments: Internet only, UUCP only, a combination of
the two, and whatever else they deem necessary.  Then make the
resulting versions available either somewhere on NIC or ucbvax or
both, and advertise where they are.

Of course, if this has been done already, it would pay to make that
information known much more widely, particularly at this time.

--Frank
-------

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Mar-87 16:35:56 EST
From:      braden@ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: TCP/IP header question

If two instances of a given IP datagram contain TCP segments with differing
TCP headers, you may be able to reassemble them but it won't do much good...
presumably the 

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Mar-87 18:59:45 EST
From:      JBVB@AI.AI.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: TCP/IP header question

Bob,

I only got the first few sentences of your message.  What I see looks
like a point I hadn't thought about.  If the TCP header has changed,
then using the same IP identification is counter-productive.  In 
conventional implementations, I suppose it is up to the individual designer
or tuner to decide whether the fragment reassembly potential is worth
the cost of re-sending obsolete Window and Ack.  Our current TCP sends
the up-to-date information.

An idea struck me, though:  How about using some sort of checksum of the
data passed to IP (perhaps with the protocol and port number appended
to prevent aliasing) as the identification?  This would seem to be a
simple way of getting the reassembly automatically whenever it was
possible, without making an arbitrary upper layer concern itself with IP
internals.  I know, this is easy for me to say, with the processor all
to myself, but...

jbvb@ai.ai.mit.edu
James B. VanBokkelen
FTP Software Inc.

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Mar-87 21:02:43 EST
From:      dms@HERMES.AI.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Black Art: sendmail.cf files

I have a sendmail.cf file that works fairly well. It has extra stuff
in it for our local chaosnet hosts, and I think it does a few things
incorrectly here and there, but it would be a good starting point for
someone who might want to tune it up a bit. It uses the domain system
and I've stripped out all the Berkeley specific cruft that most people
have. It's much less confusing than the standard distribution file.

It's in the public ftp area on hermes.ai.mit.edu.

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Mar-87 22:17:32 EST
From:      bzs@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   A defense of GOSIP


>Does this mean that one should not "go ISO".  Perhaps, if you are
>measuring costs over a short term.  But, if you take a long view, and
>believe that ISO will, in fact, mature, then perhaps you ought to
>invest now, grow-up with the technology, and avoid a conversion
>expense.

Fine, send me implementations for my SUNs, Encores, IBM/3090, Xerox
and Symbolics Lisp machines, Vaxes (UNIX and VMS), ATT/3B (SYSV),
IBM/PCs and Celerities. I am running some version of Internet
protocols on all of those right now and it is critical to our campus'
operation, research and educational business.

I await the software or list of vendors from you.

(maybe we should continue this argument on INFO-OSI which no doubt
everyone reads on their X.400/OSI systems anyhow.)

	-Barry Shein, Boston University

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Mar-87 01:04:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

Please ask Steve what he does about X.25 resets in the absence of
an end/end reliable protocol such as TCP or TP4?

I thought a significant commercial acceptance of TCP was in evidence
from the PC and LAN vendors.?

Vint

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1987 01:04-EST
From:      CERF@A.ISI.EDU
To:        mckee@MITRE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: GOSIP vs TCP/IP
Please ask Steve what he does about X.25 resets in the absence of
an end/end reliable protocol such as TCP or TP4?

I thought a significant commercial acceptance of TCP was in evidence
from the PC and LAN vendors.?

Vint
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Mar-87 12:40:48 EST
From:      sra@MITRE-BEDFORD.ARPA (Stan Ames)
To:        mod.protocols.tcp-ip
Subject:   ULANA RFP INFO

The documents related to the upcoming ULANA rfp are again on the host
ULANA.

To get a copy ftp to ULANA (192.12.120.30) and do a dir

The account is guest
the passward is anonymous

A file called status is also in this account and contains current information.

These files are being placed on this host for general info only.

Official copies can be had by visiting the ULANA library at ESD.



Questions can be sent to ulana at mitre-bedford.arpa

Stan Ames

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Mar-87 13:26:15 EST
From:      mrose@NRTC-GREMLIN.ARPA (Marshall Rose)
To:        mod.protocols.tcp-ip
Subject:   Re: A defense of GOSIP

>	(maybe we should continue this argument on INFO-OSI which no doubt
>	everyone reads on their X.400/OSI systems anyhow.)

    Nah.  As has been pointed out in the past by Jon, these guys don't
    even use computers.  Seriously, it's the stupidest catch-22 I've
    ever heard of:  you can't start an electronic mail
    interest group for use by OSI zealots because either:

	- they don't have working X.400 systems

	- their systems don't talk to each other yet

	- they won't agree to use one organization's system for
	  political reasons

	- they won't use the ARPAnet mailsystem (even though they
	  probably all could get legitimate access) because even though
	  it works it's not OSI and they can't use it 'cause that would
	  be admitting that the ARPAnet stuff works 

    You think I'm kidding, I'm not!  This has happened to two or three
    times to my knowledge, and quite frankly I'm not even tied in that
    well to the OSI bunch.  Of course the gag is that any of these four
    problems can be "fixed" easily:

	- you can now get X.400 systems on just about every machine you
	  listed (true!) except perhaps the lisp engines

	- they could connect up to a common carrier

	- they could grow up

	- they could grow up and admit that, for the moment, TCP/IP and
 	  the ARPAnet works much better than OSI does.

 Croissants or donuts?  I'd settle for hot water!

/mtr

    ps:  I'm out the door for the Monterey conference, so my responses
    to everyone's flames/cheers will be delayed by a few days...

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Mar-87 21:00:42 EST
From:      CORRIGAN@SRI-NIC.ARPA (Mike Corrigan)
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP






      As I mentioned previously, the concerns which have been raised
  with respect to the applicability statement will be addressed in DOD
  comments on GOSIP.  I think, however, it may be useful to quote all
  the relevant portions of the current applicability statement, and
  give an alternate (I might add, the intended, but as Mike Padlipsky
  says, you have to read the words) interpretation of what is there
  now from either of the two views given to date (Mike Padlipsky's and
  WBD.MDC's).  The fact that there can be (at least) three views
  argues that the current wording is unacceptably ambiguous, but I
  don't think Marshall Rose, et al. should continue to think they were
  dreaming when they interpreted it differently.  There are three
  important statements.  I will abridge, but not paraphrase (Those who
  want the missing words can get them from the NIC):
  
    "It [GOSIP] is mandatory for all new network implementations..."
  
    "Although GOSIP mandates OSI implementations in products, it does
  not preclude the acquisition of additional (perhaps vendor specific)
  networking capabilities in that same equipment."
  
    "For a period of two years,  agencies are permitted to procure
  alternative interoperable protocols, but they must provide a
  mechanism for those protocols to interoperate with OSI protocols as
  well." 
  
     Statement 1 says that new acquisitions must include GOSIP
  protocols.
     Statement 2 says that any additional protocols which are needed
  may also be acquired.
     Statement 3 is a partial waiver of statement 1, that is, if an
  agency already has an interoperable set of protocols (for example,
  DOD with TCP/IP),
  then it can buy the current suite in lieu of GOSIP protocols for a
  period of two years.  After this time, GOSIP protocols are mandatory
  for such agencies as well, but, under statement 2, they can continue
  to acquire their current set of interoperable protocols
  indefinitely.
  
     Please let me repeat that I agree that other interpretations can
  easily be made of the current statements, and that even if no other
  changes were made to the applicability statement, changes to avoid
  the existing massive ambiguity would be essential.  This is why
  GOSIP is out for comment, but I think there is enough material on
  this particular point to assist in the rewrite.
  
-------

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Mar-87 22:10:28 EST
From:      tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya)
To:        mod.protocols.tcp-ip
Subject:   Re: A defense of GOSIP


As per your comments about ISO people and their not using thier own
technology for mailing lists.

I won't speak for other ISO groups, but the group I'm in
(ANSI X3S3.3, aka Transport and Network Layer, the folks that
brought you IP (ISO) and TP4) does use the ARPANET and TCP/IP
for its mailing.  Granted, it's not X.400, but we are more
interested in doing our jobs than showing off our own stuff.
We are also more that happy to consider what is
good (and what is not so good) in the DoD protocol world.

By the way, our hot items right now are routing and other
management functions, and YES we have looked at EGP and GGP etc.,
and YES we find some problems there.

Also, we are meeting jointly from time to time (actually the first such
time will be this April) with the INENG folks (yup, fuzzballs, swamps, etc.).

If anyone is interested in getting in on our mailing list, send
request to x3s33-interest@mitre-gateway.arpa.

(To be honest, I have met many of the folks that give ISO a bad name.
But there are SOME good people in standards).

Paul Tsuchiya

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Mar-87 06:25:05 EST
From:      PERRY@VAX.DARPA.MIL (Dennis G. Perry)
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

Steve, you made an interesting statement in your note: "The cost of running the
Arpanet is comparable to running the Telenet public network which carries
ten times as many user packets."

Two questions. (1) How much does it cost to run Telenet?  I know how much
it cost to run the Arpanet.  (2)  How many packets does Telenet carry?
If you will send me those data, I will put both the Arpanet figures
and the Telenet figures on the net.  If your statements are true, then
it will help us in future designs.

dennis
-------

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Mon 16 Mar 87 06:25:05-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        mckee@mitre.arpa
Cc:        karn@flash.bellcore.com, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: GOSIP vs TCP/IP
Steve, you made an interesting statement in your note: "The cost of running the
Arpanet is comparable to running the Telenet public network which carries
ten times as many user packets."

Two questions. (1) How much does it cost to run Telenet?  I know how much
it cost to run the Arpanet.  (2)  How many packets does Telenet carry?
If you will send me those data, I will put both the Arpanet figures
and the Telenet figures on the net.  If your statements are true, then
it will help us in future designs.

dennis
-------
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Mar-87 07:53:49 EST
From:      scott@GATEWAY.MITRE.ORG
To:        mod.protocols.tcp-ip
Subject:   GOSIP


	I just read the mail from Mike Corrigan giving the definitive(?)
interpretation of GOSIP.

	I am reminded of when the government had a requirement that 
all computers acquired after a certain grace period have an ASCII processing 
mode (exacting when this was I can't remember).  This hit alot of computer 
users hard since they were locked into machines produced by a well known 
manufacturer that used EBCDIC.  This well known manufacturer, seeing his market 
being yanked away from him, provided machines that had an ASCII mode.  No one 
ever used this mode but it was there in case the bean counters asked.

	Now I'm not saying that GOSIP is heading down the same road,
but if it is this is a good way for software houses to pick up a quick
buck for software that may never be used and therefore not that
good.

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Mar-87 10:09:00 EST
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   Re: TCP/IP header question


    Date: Tue, 10 Mar 87 23:09:57 est
    From: jbvb@BORAX.LCS.MIT.EDU (James B. VanBokkelen)

    I don't see any reason to send obsolete information; our
    implementation updates both ACKs and Window to the values current at
    the instant the packet is sent.  Of course, this does mean we have to
    re-checksum the packet, but we have to do this anyway if a packet gets
    partially ack'ed (which you'd better be prepared for...)  
Nit: Indeed, you'd better be prepared for it, but you don't have to
rechecksum if you don't reshuffle the data around.  Not reshuffling is
paramount to sending old+new data, which the spec allows.
							      Note that it
    *does* seem like a good idea (not mine) to retain the IP
    'identification' so that fragments can be assembled from any instance
    of (re)transmission of a given packet.

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Mar-87 11:12:45 EST
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        mod.protocols.tcp-ip
Subject:   Re: A defense of GOSIP

The way some people are attracted by picutres of cars-of-the-future
makes me wonder whether there isn't a third term to the classic
"a pessimist sees the glass as half empty, an optimist sees the
glass as half full" routine: what kind of -ist thinks the glass
runneth over?  (Don't try "futurist," I've got too nasty a retort
for that one in storage.)

Getting back to what we're supposed to be talking about, however
(i.e., the December, 1986 GOSIP Draft, NOT what OSI "will" be),
let the record show that I don't even see a half-empty glass,
I see a centipede named Achilles.  (And I thank the sender of
the Subj: msg for exposing a few extra heels.)

cheers, map
-------

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1987 11:12:45 EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        Karl Auerbach <AUERBACH@CSL.SRI.COM>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: A defense of GOSIP
The way some people are attracted by picutres of cars-of-the-future
makes me wonder whether there isn't a third term to the classic
"a pessimist sees the glass as half empty, an optimist sees the
glass as half full" routine: what kind of -ist thinks the glass
runneth over?  (Don't try "futurist," I've got too nasty a retort
for that one in storage.)

Getting back to what we're supposed to be talking about, however
(i.e., the December, 1986 GOSIP Draft, NOT what OSI "will" be),
let the record show that I don't even see a half-empty glass,
I see a centipede named Achilles.  (And I thank the sender of
the Subj: msg for exposing a few extra heels.)

cheers, map
-------
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Mar-87 11:28:05 EST
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

It's "apples and eggplants" to compare TCP/IP header sizes
with X.25's, as a rudimentary knowledge of Layering should
show.  Rather than be coy and make Marshall Rose or Mike
Corrigan do the explaining, I'll accept the risk that Steve
Silverman won't believe me and try to save time by pointing
out that X.25 is at the "bottom" of L3 whereas IP is
at the "top" of L3 and TCP is L4 (and subsumes some of the
functionality of L5).  Or, as I'd prefer to express it, X.25
is L I, TCP/IP L II.  So any inference that going X.25 saves
bits is fallacious (unless the argument is that we should
go with the CCITT Suite, which isn't OSI and hence isn't what
the argument is about).

Aside to Dennis Perry: if you want the ARPANET to carry ten
times as many packets as it does at the same (subnet) cost,
you could always make the maximum packet size be .1 of what
it is and come pretty close, especially if you ban character-
at-a-time Telnet.   (This one might be artichokes and brussels
sprouts, actually, given all the possible differentiae--though
maybe not, since it's still in essence attempting to compare
the incommensurate.)

cheers, map
-------

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1987 11:28:05 EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        H. Craig McKee <mckee@MITRE.ARPA>
Cc:        karn@FLASH.BELLCORE.COM (Phil R. Karn), tcp-ip@SRI-NIC.ARPA
Subject:   Re: GOSIP vs TCP/IP
It's "apples and eggplants" to compare TCP/IP header sizes
with X.25's, as a rudimentary knowledge of Layering should
show.  Rather than be coy and make Marshall Rose or Mike
Corrigan do the explaining, I'll accept the risk that Steve
Silverman won't believe me and try to save time by pointing
out that X.25 is at the "bottom" of L3 whereas IP is
at the "top" of L3 and TCP is L4 (and subsumes some of the
functionality of L5).  Or, as I'd prefer to express it, X.25
is L I, TCP/IP L II.  So any inference that going X.25 saves
bits is fallacious (unless the argument is that we should
go with the CCITT Suite, which isn't OSI and hence isn't what
the argument is about).

Aside to Dennis Perry: if you want the ARPANET to carry ten
times as many packets as it does at the same (subnet) cost,
you could always make the maximum packet size be .1 of what
it is and come pretty close, especially if you ban character-
at-a-time Telnet.   (This one might be artichokes and brussels
sprouts, actually, given all the possible differentiae--though
maybe not, since it's still in essence attempting to compare
the incommensurate.)

cheers, map
-------
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Mar-87 12:27:45 EST
From:      gross@GATEWAY.MITRE.ORG (Phill Gross)
To:        mod.protocols.tcp-ip
Subject:   Re: A defense of GOSIP

Marshall,

I set up Arpanet mail access for several very appreciative folks on the
ANSI X3S3.3 Network Layer Group.  I also started a mailing list for their
group, which they most definitely use.  I've found X3S3.3 to be a very 
strong technical group which stays tuned into Internet developments, as 
they should be for their work.  In fact, we have scheduled a joint day with 
S3.3 at the next DARPA Internet Engineering Task Force to discuss our common 
interests.  It doesn't always need to be Us and Them.

Phill Gross
Mitre 

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Mar-87 14:49:53 EST
From:      tsuchiya@GATEWAY.MITRE.ORG
To:        mod.protocols.tcp-ip
Subject:   (none)

Amidst all of the flaming about the scope and applicability statements
of GOSIP, I would like to throw in a quick technical suggestion.

With regards to the NSAP Address formats.

I am concerned that the single format is too narrow.
It implies a single type of hierarchy (org.net.net-address)
which may or may not reflect organizations real routing structures.
For instance, what if an organization is physically seperated into
several locations.  Then either that organization must have several
organization ids (in which case it is no longer an organization id),
or they must split up their subnet ID field to reflect the seperate
locations.  Unfortunately, if manufacturers boxes are not able to
parse elements in the subnet ID field.................

Also, while GOSIP does let DoD define its own address space, there
is still a potential problem with economics.  What if 15 vendors
decide to implement GOSIP, and 10 of them set up their NSAP
parsing code and routing tables to look like what is in GOSIP.
Suddenly, if DoD people want their own address format, they must
either go to one of the leftover vendors (less "multi-vendor")
or have a special development from one or more of the 10 vendors.
Both ways cost dollars.

The real fear here, though, is future interoperability (what's that, right?).
It is concievable to me that static routing could be made to work
with dynamic routing if one were very careful how they did things.
However, I don't see how it could work if the dynamic routing
parsed their NSAP Addresses differently than the static routing
(or indeed, if two dynamic routing schemes parsed them differently).

What I have in mind is very simple, and is essentially the
ARPA subnet-addressing scheme applied to the full address.

Have the vendors set up their routing tables, routines, and
software that downloads tables into the routers so that
every entry in the table has a mask associated with it which
says "if the NSAP to be routed matches this routing table entry
after the mask is applied, then route this way".  There should
also be a second mask which tells where the SNPA is imbedded in the
NSAP, if there is one.  The NSAP structure in GOSIP could even be
the default if someone didn't wanted to get involved in defining
their own NSAP structure.

This is a very easy way to provide a lot of generality at a very
low cost.

By the way, this idea is very much in line with the ANSI X3S3.3
(network and transport layer) philosophy on addresses and routing.

Paul Tsuchiya
tsuchiya@mitre-gateway.arpa

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Mar-87 03:49:43 EST
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   (none)

I was surprised by the address structure in GOSIP as well.  Some of it
could be fixed by changing the commentary, rather than the actual
spec.  E.g. there are two-byte codes for organization and "subnet".
The commentary suggests that the organization will be a Department and
the subnet a particular installation.  The problem with that is that
many installations are large enough to need more than one Ethernet,
and therefore they will need subnetting.  I have to believe that 32
bits of address is enough.  But I think it would be good to suggest
that at least part of the subnet should be available for use within
large sites.

I was also somewhat surprised to see the Ethernet address (in some
IEEE incarnation) used as the lowest level piece of the address.  I
thought there was a concensus that this is a bad idea.  Without
careful management, changing a bad Ethernet controller card is going
to change your protocol address.  Yes, I know there are solutions to
this, but I think a separate protocol address would be cleaner.

I sure hope there is good name server technology behind this proposal.
Even if we ignore the prefix that says "this is a U.S. Govt address",
we have 10 bytes of address, the last 6 of which are essentially a
random number.  I sure wouldn't want to have to remember this.  I find
that I remember the Internet addresses of lots of my machines, and
that this is very useful for all sorts of testing and debugging
situations.  I'm trying to think what the design of the GOSIP version
of netwatch is going to look like.

Finally, have you given any thought to non-governmental applications?
I mean, the whole point of ISO is supposed to be that commercially-
supported implementations will exist.  So it seems counter-productive
to have a standard that doesn't allow for non-governmental uses.  As
far as I can see, the address format only allows for government
agencies.  I think you might want to reserve some address space for
compatible commercial or educational users, and define a way for
allocating it within the GOSIP structure, much as DoD reserved address
space for commercial and educational uses within the Internet addressscho'\an

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Mar-87 06:09:21 EST
From:      PERRY@VAX.DARPA.MIL (Dennis G. Perry)
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

Mike, I like artichokes, but cannot stand brussels sprouts. :-)

Actually, aside from the packet size question, which is a real variable
left out of many of the off the cuff remarks about performance, I would
like to know how the Arpanet compares to commercial offerings.  My experience
is that it fares well (present limited capacity in the net excepted).

dennis
-------

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Mar-87 12:42:25 EST
From:      whna@cgcha.UUCP (Heinz Naef)
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: cgcha!whna
From: whna@cgcha.UUCP (Heinz Naef)
Newsgroups: mod.protocols.tcp-ip,comp.dcom.lans
Subject: TCP/IP software for HyperChannel II (HyperBus) on IBM mainframes
Keywords: TCP/IP, Hyperchannel, Hyperbus, IBM
Message-ID: <314@cgcha.UUCP>
Date: 17 Mar 87 17:42:23 GMT
Organization: CIBA-GEIGY AG, FO/WIRZ/WRZ, CH-4002 Basel, Switzerland
Lines: 10

Does anyone know about a TCP/IP protocol package and the appropriate driver
for IBM 30xx mainframes to interface to Network Systems Corp.'s HyperChannel II
controller/media without using NETEX? As far as we know, this type of
attachment exists for Cray's UNICOS operating system and for VME-Bus based
systems using the IKON board set.

Any hints - via e-mail whna@cgcha.UUCP - will be highly appreciated.
Thanks,
Heinz.

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Mar-87 15:16:47 EST
From:      tsuchiya@GATEWAY.MITRE.ORG
To:        mod.protocols.tcp-ip
Subject:   x3s33 requests


I made a boo-boo.  Would people please send their requests to get
on the x3s33-interest list to: x3s33-request@mitre-gateway.arpa.

Thanks.

PT

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Mar-87 16:24:46 EST
From:      gnu@hoptoad.UUCP (John Gilmore)
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP and required features that are never used

scott@GATEWAY.MITRE.ORG writes:
> 	I am reminded of when the government had a requirement that 
> all computers acquired after a certain grace period have an ASCII processing 
> mode (exacting when this was I can't remember).  This hit alot of computer 
> users hard since they were locked into machines produced by a well known 
> manufacturer that used EBCDIC.  This well known manufacturer, seeing his market 
> being yanked away from him, provided machines that had an ASCII mode.  No one 
> ever used this mode but it was there in case the bean counters asked.

My memory may be faulty, but I recall that a good part of the reason that
Sun started supporting bisync and X.25 and all that other jazz was because
many government buyers couldn't buy Suns unless they supported all that stuff,
even if they never used it.  I have no doubt that the well-intentioned
clods pushing GOSIP will have the same effect.  More tax money wasted.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Mar-87 17:07:33 EST
From:      mfidelma@CC5.BBN.COM ("Miles R. Fidelman")
To:        mod.protocols.tcp-ip
Subject:   ISO ES to IS Info Sought

Does anyone know which working group is working on the End System to 
Intermediate System protocols, and who a contact would be. For that matter,
does anyone know where I can obtain copies of any draft materials?

Thanks much,

Miles Fidelman
BBN Communications Corp.
(mfidelman@bbn.com)

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 87 17:07:33 EST (Wed)
From:      "Miles R. Fidelman" <mfidelma@cc5.bbn.com>
To:        tcp-ip@sri-nic.ARPA
Subject:   ISO ES to IS Info Sought
Does anyone know which working group is working on the End System to 
Intermediate System protocols, and who a contact would be. For that matter,
does anyone know where I can obtain copies of any draft materials?

Thanks much,

Miles Fidelman
BBN Communications Corp.
(mfidelman@bbn.com)
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Mar-87 18:53:11 EST
From:      john@xanth.cs.odu.EDU (John Owens)
To:        mod.protocols.tcp-ip
Subject:   Re: Black Art: sendmail.cf files

[This failed the first time at SRI-NIC:
 tcp-ip@SRI-NIC.ARPA: Forwarding error:
	Cannot find indirect file - No such device
 ?!]

> one proven sendmail.cf file for each of the major environments:
> Internet only, UUCP only, a combination of the two
> --Frank <WANCHO@SIMTEL20.ARPA>

For the combination internet/uucp sendmail.cf file, it would be good
if someone could come up with a general, automated, way of sending
mail destined for domains primarily under UUCP via UUCP, and others
via the Internet.  For those that would prefer UUCP when a site is on
both, some massaging of the first part of the pathalias output might
be in order.  I imagine, though, that most Internet sites would prefer
Internet, but would rather send mail that will eventually end up on
UUCP themselves, rather than forwarding it to seismo.  Maybe if the
UUCP Project would put out a simple list of the second level domains
that are registered with them and not on the Internet or csnet, in the
form:

ADELIE.COM
AMD.COM
ATT.COM
...
VORTEX.COM

it would be usable as a sendmail class....  (This would be especially
good for those UUCP Zone domains that don't have an Internet forwarder!)

I'd love to help, but as I'm not physically on the Internet....

John Owens		Old Dominion University - Norfolk, Virginia, USA
john@ODU.EDU		old arpa: john%odu.edu@RELAY.CS.NET
+1 804 440 3915		old uucp: {seismo,harvard,sun,hoptoad}!xanth!john

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Mar-87 02:39:24 EST
From:      gross@GATEWAY.MITRE.ORG (Phill Gross)
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP and required features that are never used

> From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)
> 
> ... the well-intentioned clods pushing GOSIP ...
> 

I'd appreciate it if the comments on this list remained at a technical level.  
A well founded technical argument would have no need for this type of personal 
attack.

Phill Gross
Mitre Corp.

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Mar-87 16:31:11 EST
From:      jerry@oliveb.ATC.OLIVETTI.COM (Jerry F Aguirre)
To:        mod.protocols.tcp-ip
Subject:   (none)

Newsgroups: mod.protocols.tcp-ip
Subject: Connecting two ethernet segments
References: <8703031250.AA05275@topaz.rutgers.edu>
Reply-To: jerry@oliveb.UUCP (Jerry F Aguirre)
Distribution: world
Organization: Olivetti ATC; Cupertino, Ca

In article <8703031250.AA05275@topaz.rutgers.edu> hedrick@seismo.CSS.GOV@topaz.rutgers.edu (Charles Hedrick) writes:
>Let us suppose that you have the following configuration:
>
>--------- network 192.1.1
>   |
 router, with addresses 192.1.1.1 and 192.1.2.2
>   |
 --------- network 192.1.2
>   |
 router, with addresses 192.1.2.1 and 192.1.3.1
>   |
>--------- network 192.1.3
>
>Now suppose you have a 4.2 machine on network 192.1.2, whose own
>address is 192.1.2.10.  Here is the way I would set up routing.

If this is referring to the article about the Bridge GS/3-M then it is
wrong.  Unlike protocol dependent routers the GS/3-M routes at the
ethernet address level.  It doesn't know TCP/IP from Decnet and therefor
doesn't have an IP network address.  Thus you can not specify it in a
routing table.

Logically the Bridge GS/3-M acts as a repeater allowing you to extend
an ethernet beyond the single segment limits.  The difference is that it
is a selective repeater so it filters out ethernet addresses that don't
need to go to the other segment.  (It also allows the other segment to
be a LOT further away than a standard repeater would.)

Segments connected by a repeater are logically on the same network.  I
spoke to a Bridge representative about this and he said that we would
have to re-address the two networks we were planning to connect so that
they all had the same network number.  He suggested going to a type A
address instead of a type C to allow more than 254 hosts/network.

Is this a real requirement?  Ignoring the Bridge product, suppose that
two departments each set up independent ethernets.  They properly
register their IP addresses so there is no conflict.  Later they decide
to attach the two segments together either directly or thru a repeater.

This seems a common enough occurrence to me.  If TCP/IP requires that
they renumber all their hosts then this sounds like a significant
flaw in the addressing and routing scheme.

Would it be enough to specify routing to the network via itself?  There
is an local entry automatically added that is equivalent to:

	route add net mynet myhostname

Would something like:

	route add net othernet myhostname

be enough to tell it that "othernet" is actually available via the same
interface?  Someone out there must have had to connect two previously
independent ethernet segments.

					Jerry Aguirre
					Systems Administration
					Olivetti ATC

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Mar-87 17:17:47 EST
From:      Mills@UDEL.EDU
To:        mod.protocols.tcp-ip
Subject:   Re:  ISO ES to IS Info Sought

Miles,

ANSI X3S3.3 committee. Contact Lyman Chapin (chapin@a.isi.edu).

Dave

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Mar-87 00:09:53 EST
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   (none)

Yes, your theory is correct.  You can make any network be treated as
local by doing
  route add <net> <yourhost> 0
(in 4.2.  In 4.3 I think there is some minor difference, like omitting the
0.)  I thought somebody had explained this before.  4.2 works like this:

   route-packet (destination-address)
	lookup destination-address as a host in host routing table
		[entries that show with "H" in flags field of netstat -r]
	if that fails, lookup network(destination-address) as a network
		in network routing table [entries without an "H"]
	if that fails, look for default route
	if that fails, say destination unreachable
	now we have a route.  
	If the metric is 1 or larger [metric is the last field in the
		"route add" comment.  You can tell from the route
		command because routes with a metric >= 1 will show
		a "G" in the flags field], this is a normal gateway
		entry.  Send packet to the host listed in the
		gateway field.
	If the metric is 0 [route add command ended in zero, or in
		some versions, the metric was omitted.  netstat -r
		does not show "G" in the flags field], this is a
		"route to the interface".  Send packet out the
		interface listed in the interface column.  If
		interface is an Ethernet, use ARP.

Note that the gateway address (gateway field in netstat -r) is
irrelevant in the case of a route to the interface.  The route add
command uses that address only to figure out which interface to
associate with the route.  So when setting up a route to an interface,
the simplest approach is to use your own address on that network.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Mar-87 09:33:21 EST
From:      tsuchiya@GATEWAY.MITRE.ORG.UUCP
To:        mod.protocols.tcp-ip
Subject:   routing and bridges


Per you query about connecting two ethernet segments with different
IP network numbers with bridges which route on ethernet address....

It seems you have two problems.

First, getting your own IP-level gateways to know about the other net,
and second, getting other boxes in the world to know that both nets
are available through one interface.  If you can solve the first
problem, then the second problem is easy because you can address both
nets via EGP (maybe I shouldn't assume EGP here, but I am guessing
that RIP et al. can also do this).

In solving the first problem, I would first ask whether the Bridges
pass on broadcast ethernet addresses.  If they do, then ARP can be
used by the IP-level gateway to pass messages on to hosts irregardless
of the IP-network number.  If not, then somehow the IP-gateway has
to have a local list of ethernet-address/IP-address tuples.  Either
way, the problem is a local one, and shouldn't REQUIRE both ethernets
to have different network addresses (REQUIRE in the sense that the
IP routing architecture breaks if you don't have one address).

Also, if you want more that 254 hosts, to to a type B rather than a
type A address.  Type B will give you 65534 addresses.  Type A
network numbers are reserved for those REALLY BIG networks.


Paul F. Tsuchiya

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Mar-87 11:06:19 EST
From:      gds@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   breakdown of SMTP traffic

I'm sorry to interrupt this useful discussion of GOSIP, but I have a
brief question regarding arpanet/milnet congestion.

Does anyone have any figures (even ballpark figures) for:

* the % of TCP packets that are SMTP packets that cross the
  arpanet/milnet
* the % of those packets which are going to arpanet list-of-lists
  mailing list recipients, or to the list itself
* the % of those packets which are going to non list-of-lists mailing
  lists which have sizable readerships (e.g. egp-people, gwmon)
* the % of those packets which are "conversational" (ie. don't fall
  into the previous two categories)

I am assuming that the last two categories are contributing to
congestion to a larger degree than the second category.

--gregbo

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Mar-87 11:33:42 EST
From:      AI.CLIVE@MCC.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Is it just me, or...

... are other people getting two copies of many of the messages
to TCP-IP?  Is there a problem with a mailer somewhere?  Sounds
like the classic case of a fatal error aborting delivery midway
through the list, and the mailer starting over without eliminating
the addresses that were already successful.

Clive
-------

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Mar-87 12:15:45 EST
From:      jmainini@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)

Jerry,
	Here at SRI on our floor we have 4 DEC LAN 100's.  They cost
around 8K, and build thier own routing tables.  You don't have to 
renumber any nets, as they don't care.  They just know who is on either
side and will send where ever is appropriate.  They are a store, filter,
and forward device that will pass any protocol or net number if that node
exists on the other side.  We have had these bridges around a year, and
havn't had any trouble so far.

John Mainini

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Mar-87 12:52:39 EST
From:      matt@ODDJOB.UCHICAGO.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: (none)

jerry@oliveb.ATC.OLIVETTI.COM (Jerry F Aguirre) writes:
)                         ...  Ignoring the Bridge product, suppose that
) two departments each set up independent ethernets.  They properly
) register their IP addresses so there is no conflict.  Later they decide
) to attach the two segments together either directly or thru a repeater.
) ...
) Would it be enough to specify routing to the network via itself?
) Would something like:
) 
) 	route add net othernet myhostname
) 
) be enough to tell it that "othernet" is actually available via the same
) interface?  Someone out there must have had to connect two previously
) independent ethernet segments.

You bet someone has.  As I told Charles in private ail, the
"USAN" satellite network links many networks around the country
using Bridge/Vitalink filtering forwarders.

It does suffice in 4.2 and 4.3 to do

	route add othernet myname 0

where the final number, commonly believed to be a hopcount, is
actually for the flags field.  Zero means "not a route to a
gateway".

Trouble comes, however, if there is a host on othernet that you
want to use as a gateway to some more distant destination.  The
kernel cannot be convinced that the gateway is reachable, even
though it can communicate with the gateway.  If, as Charles
pointed out in his replies to me, the gateway will do
promiscuous arp, or if some other host on the net will do proxy
arp for the gateways, the day is saved and you can make a
default route to your own interface with

	route add default myname 0

An alternative which I used in the early days of USAN was to add
a pseudo-interface driver for each net reachable by bridges.
This driver just put its output packets on the queue of the real
eternet interface, while serving as a marker to the routing
ioctl code that gateways on those nets were indeed reachable.

Because of the net hassle of trying to solve this problem all
around the country, the final answer wound up being to connect
each bridge to a stub ethernet that linked it only with an IP
level forwarder.
________________________________________________________
Matt	     University		matt@oddjob.uchicago.edu
Crawford     of Chicago     {astrovax,ihnp4}!oddjob!matt

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Mar-87 15:35:40 EST
From:      braden@ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Garden Implements


    Is this a real requirement?  Ignoring the Bridge product, suppose that
    two departments each set up independent ethernets.  They properly
    register their IP addresses so there is no conflict.  Later they decide
    to attach the two segments together either directly or thru a repeater.
	
    This seems a common enough occurrence to me.  If TCP/IP requires that
    they renumber all their hosts then this sounds like a significant
    flaw in the addressing and routing scheme.
	
Is it a flaw in the design of a rake that it does not perform very well
as a shovel??  The Internet architecture includes gateways to connect
different networks.  One of the essential advantages of a gateway over a
level-2 bridge is the separation of address spaces.  If you need a
rake, buy a rake, don;t complain that your shovel cannot be adapted.
Perhaps the moral is... beware of the glib tongues of shovel salesmen.

Bob Braden

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Mar-87 16:22:07 EST
From:      don@SRI-LEWIS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Is it just me, or...


> ... are other people getting two copies of many of the messages
> to TCP-IP?  Is there a problem with a mailer somewhere?  Sounds
> like the classic case of a fatal error aborting delivery midway
> through the list, and the mailer starting over without eliminating
> the addresses that were already successful.
 
> Clive
>-------


I am also receiving multiple copies, as are many of my office mates
here!

Don Holman
SRI International

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Mar-87 17:28:43 EST
From:      robert@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Is it just me, or...


To quote a recently heard personage "Me too! Me too!"

You bet I am getting duplicate messages.  I think it is one (or more)
particular mailer(s) which is/are doing it, but so far I have no
hard facts.  I'm keeping an eye on it though, so I can get
some hard facts and get the problem fixed.

Robert Allen,
robert@spam.istc.sri.com

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Mar-87 22:49:54 EST
From:      Vince.Fuller@C.CS.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   DEC LANbridge query...

Has anyone managed to decode the protocol used to talk to these things to the
point of being able to write a program to query them? We are using them to tie
together the various segments of our departmental network and would like to be
able to query them to help locate errant hosts. We have the RBMS software for
VMS but really need to develop some application code of our own. Unfortunately,
the (DEC Proprietary) documentation we have is worse than useless, since our
observations of the LANbridge control packets look almost nothing like what
the documentation claims. The documentation claims that the "Bridge Management
Protocol" is built on top of the Maintenance Operations Protocol (MOP), but no
where in the DEC/DNA MOP documentation can I find an obvious place where this
might be wedged in (and observations of the control packets again bear show
little resemblance to any MOP packets). Has anyone else been down this path or
can suggest documentation I might reference? We'd like to find out what all of
these funny packet values actually mean, rather than just brute-force using
the binary values in our monitoring programs.

	Thanks in advance,
	Vince Fuller, CMU-CSD
-------

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Mar-87 12:28:09 EST
From:      jon@CS.UCL.AC.UK.UUCP
To:        mod.protocols.tcp-ip
Subject:   talking of and to gateways and bridges

We at UCL witness an interesting problem. Because it is
regarded as AOK for gateways to talk to each other using unreliable IP,
and gateways don't reassemble, only a minimal amount of info
can get between gateways at any one go.

The internet has got so large now, that when a reasonable percentage
of sites are up, we disappear off the end of routing updates,  and go
unreachable.

Why not get the gateways to reassemble packets destined for them (ie when
they are acting as hosts/end points after all),
I hear you cry? Nope, cos thats just a short term
fix til there are more than (say) 1500 bytes worth of update.

Why not use a transport protocol between IP and EGP/GGP/IGP/RIP etc? Yes,
but which one. Well, there's TCP/RDP/ and who knows how many transaction
protocols out there waiting to pounce. [This may also make your
routing algorithms cleaner.]

Well, use the same one as you use for talking management to your gateway from
your hosts for now, like TCP. Surely it's not beyond the wit of
gatewayfarers to put TCP into their boxes, since half of them
build TCP terminal concentrators already.

Our attitude to manageing MAC Bridges ~like~ the DEC LAN Bridge
100, is to put a separate management network (eg V24 or V35/
RS422 lines or whatever) in the ether/coax/fibre bundle, and use that
to talk telnet/tcp blah into the Bridge. That's no solace to
people with proprietry stuff in the Bridge, but I think it's
the way things will go.

Next years answer is: use ECMA ROS
over REX, because it's gonna be a standard, and I am
a biased European.

Jon

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Mar 87 19:54 CST
From:      <CONLEY%UKANVAX.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   addition to mailing list
Please add me to your mailing list. If possible, I would prefer that
digests be sent to "csvax1@ukanvax.bitnet".

        Thanks,

        Dennis R. Conley
        Systems Programmer
        Computer Science Dept
        University of Kansas

        CSNET:  conley@csvax.cs.ukans.edu

        BITNET: conley@ukanvax

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Mar-87 20:54:00 EST
From:      CONLEY@UKANVAX.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   addition to mailing list

Please add me to your mailing list. If possible, I would prefer that
digests be sent to "csvax1@ukanvax.bitnet".

        Thanks,

        Dennis R. Conley
        Systems Programmer
        Computer Science Dept
        University of Kansas

        CSNET:  conley@csvax.cs.ukans.edu

        BITNET: conley@ukanvax

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Mar 87 17:12:29 +0000
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   talking of and to gateways and bridges
We at UCL witness an interesting problem. Because it is
regarded as AOK for gateways to talk to each other using unreliable IP,
and gateways don't reassemble, only a minimal amount of info
can get between gateways at any one go.

The internet has got so large now, that when a reasonable percentage
of sites are up, we disappear off the end of routing updates,  and go
unreachable.

Why not get the gateways to reassemble packets destined for them (ie when
they are acting as hosts/end points after all),
I hear you cry? Nope, cos thats just a short term
fix til there are more than (say) 1500 bytes worth of update.

Why not use a transport protocol between IP and EGP/GGP/IGP/RIP etc? Yes,
but which one. Well, there's TCP/RDP/ and who knows how many transaction
protocols out there waiting to pounce. [This may also make your
routing algorithms cleaner.]

Well, use the same one as you use for talking management to your gateway from
your hosts for now, like TCP. Surely it's not beyond the wit of
gatewayfarers to put TCP into their boxes, since half of them
build TCP terminal concentrators already.

Our attitude to manageing MAC Bridges ~like~ the DEC LAN Bridge
100, is to put a separate management network (eg V24 or V35/
RS422 lines or whatever) in the ether/coax/fibre bundle, and use that
to talk telnet/tcp blah into the Bridge. That's no solace to
people with proprietry stuff in the Bridge, but I think it's
the way things will go.

Next years answer is: use ECMA ROS
over REX, because it's gonna be a standard, and I am
a biased European.

Jon
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Mar-87 23:22:02 EST
From:      jsol@buit1.bu.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story]


This won't be news to any of you who are bitnet people, but I think
it will be to some others.

Bitnet has a routing system based on static lookup tables (hey, IBM
software rules!).  Updated versions of these tables are generated once
a month and sent all over bitnet...

One problem with this is that the huge amount of data swamps several
major network links (like PSUVM<->OHSTVMA).  Recent mail from our
fearless leaders at BITNIC follows:

        From LINKFAIL@BITNIC.BITNET Tue Mar 17 09:23:08 1987
        Received: by psuvax1.UUCP (4.12/4.7)
                id AA18551; Tue, 17 Mar 87 09:22:57 est
        Message-Id: <8703171422.AA18551@psuvax1.UUCP>
        Received: From bitnic.bitnet By psuvax1.bitnet ; 17 Mar 87 14:22:37 GMT
        Received: by BITNIC (Mailer X1.23b) id 6139; Tue, 17 Mar 87 09:08:23 EST
        Date:         Tue, 17 Mar 87 09:01:39 EST
        Reply-To:     Scott Earley <EARLEY@BITNIC>
        Sender: BITNIC LINKFAIL List <LINKFAIL@BITNIC>
        From: Scott Earley <EARLEY@BITNIC>
        Subject:      "March" routing tables
        To: "Dave Eckhardt (Penn SU Comp Sci VLSI Dev" <DAE@PSUVAX1>

        What were once known as the "March routing tables" have been
        twice delayed from delivery -- both irregular circumstances.
        The proposed solution to the immediate dilemma is as follows:

        Tables for all sites on the Penn State side of the PSU-Ohio link
        will be sent through the UCBCMSA--CUNYVM link as usual.  Tables
        for all sites on the Ohio side of the PSU-Ohio link will be put
        on tape and mailed overnight to a pre-appointed individual who
        will reintroduce them into the network from there.  This will
        eliminate sending about 200 tables through the PSUVM--OHSTVMA
        link.  In the future, those tables will be generated by a site
        on the far side, as a more permanent solution.

        ...

That's right.  Mag tape.

--Daemon

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Mar-87 09:51:45 EST
From:      dpk@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  GOSIP (Re)action?

[Disclaimer:  The following represent my personal professional opinion
 and does not necessarily represent the opinions of BRL or the DoD.]

Concerning Connections between TCP/IP and PC's
----------------------------------------------

There are several possible connections between TCP/IP and PC's.

There are several implementations of the DOD protocol suite
for PC, both public domain (MIT & by Phil Karn for HAM packet radio)
and vendor supported (FTP Software in Mass., maybe others as well, check
with the NIC's vendor list).  In addition there is TCP/IP support
for PC's by means of smart interface cards that put TCP/IP into
firmware.  I believe there are several of these as well, 3Com being
the one that comes immediately to mind.  More details can be be
dragged out of the NIC and the industry magazines.  Try looking
at Ungerman-Bass, Micom/Interlan, CMC, Network Solutions?

PC's are now fairly easily tied into a network of Super-Mini's to
Supercomputers using TCP/IP from any of these sources.  This can even
include true remote file systems using the Sun Microsystems NFS software
for the PC (it uses the 3Com hardware as a base).

A variety of vendors now make TCP/IP virtual terminal servers which
provide a means to easily access other hosts via RS232 as a terminal.
While this does not make a PC a real host on the network, it can be
a cheap way for several PC's to access the network by sharing a terminal
server and using it much like a modem.

UNIX is becoming the second operating system of the PC and most versions
of UNIX already support the TCP/IP protocol suite.

Opinion and Caveat
------------------

[in the following read "ISO" to mean protocols referenced in the GOSIP]

My position on this is a pragmatic one.  I feel there is undoubtedly
potential benefit to migration to (a possibly modified or amended) ISO
protocol suite in the future.  However, now is not the time to be purchasing
ISO protocols for production use as the GOSIP is indicating.  There is
at least a decade of research in the TCP/IP protocol suite.  This includes
not only the investigation of the architectural features, but also the
algorithms used in the actual operation of a large internet.  These are
lessons that are not necessarily transferable to the ISO protocol suite
due to differences in design.  These kinds of lessons can only be learned
over time with controlled introduction, first into an experienced research
community and then into larger communities as the specifications and
unspecified algorithms solidify.  You must keep the initial communities
small because there will changes necessary, and you need fast turnaround
between recommendation and implementation.  I work in a research lab, and
I expect us to start experimentation and testing of the ISO protocols to
start this year at our institution.  I don't expect them to work or to be
complete.  My gut feeling is that five years from now is the earliest
time to expect reasonably robust and complete ISO protocol suite
implementations.

The government cannot afford to turn itself into an alpha or beta test
site which is what would undoubtedly happen.  As any consumer can tell
you there is always a danger in buying the first units of a new product.
If you are interested in reliability and predictable performance, you
wait for the second printing, the next model year, or the later revision
of the product.

In short, I am not anti-ISO, but adoption of ISO on large scale at this
time is a costly mistake.  It will prove to be buggy, incomplete, and
there will be unforseen incompatablities, and since its never been
used on a large scale it will have scaling problems as systems are
interconnected for the first time.  The government should hold off
widespread usage in production usage until the ISO suite has had a chance
to mature, stabilize, and "prove itself" in the R&D community.

I would be happy to talk to you further by phone or mail, and to help
review your article for correctness regarding the TCP/IP suite.  I feel
its critical that people get the correct information about this.

Cheers,
	-Doug-


(301)-278-6678
  AV  298-6678
  FTS 939-6678

Internet:  <DPK @ BRL.ARPA>
Postal:
  Douglas P. Kingston III
  Advanced Computer Systems Team
  Systems Engineering and Concepts Analysis Division
  U.S. Army Ballistic Research Laboratory
  Attn: SLCBR-SECAD (Kingston)
  APG, MD  21005

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Mar-87 10:36:51 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story]

"on the far side" conjures up visions of Gary Larson's delightful
creatures manipulating that huge database in the sky.  Actually
the folks in BITNET are experiencing a wonderful thing:  success.
They pay for it by having to mail magtapes around once in a while.
The Arpanauts also have success and pay for it by byzantine dynamic
behavior.  The pain we all go through to get network services must
be worth the gain, eh?  We all need more money and bright ideas
to make the networks work better.  A dose of money could help
to give our brains a rest...

Dan
-------

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1987 10:36:51 EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story]
"on the far side" conjures up visions of Gary Larson's delightful
creatures manipulating that huge database in the sky.  Actually
the folks in BITNET are experiencing a wonderful thing:  success.
They pay for it by having to mail magtapes around once in a while.
The Arpanauts also have success and pay for it by byzantine dynamic
behavior.  The pain we all go through to get network services must
be worth the gain, eh?  We all need more money and bright ideas
to make the networks work better.  A dose of money could help
to give our brains a rest...

Dan
-------
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Mar-87 16:07:25 EST
From:      PERRY@VAX.DARPA.MIL (Dennis G. Perry)
To:        mod.protocols.tcp-ip
Subject:   Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story]

I would like to counter Dan's suggestion that money is a solution.  In fact
I think we have too much money chasing too few brains.  If we would use
our brains to figure out what is 'right', we could probably do with the
money we have.  Unfortunately, as is often the case in economics, it it not
the amount of money available, it is the improper distribution of same.
Brains and money have at least one thing in common, they should both be
put to work, and if left idle, will both lead to mischief!

dennis
-------

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Sun 22 Mar 87 16:07:25-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        LYNCH@a.isi.edu
Cc:        TCP-IP@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story]
I would like to counter Dan's suggestion that money is a solution.  In fact
I think we have too much money chasing too few brains.  If we would use
our brains to figure out what is 'right', we could probably do with the
money we have.  Unfortunately, as is often the case in economics, it it not
the amount of money available, it is the improper distribution of same.
Brains and money have at least one thing in common, they should both be
put to work, and if left idle, will both lead to mischief!

dennis
-------
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Mar-87 17:40:03 EST
From:      hinden@ccv.bbn.COM (Robert Hinden)
To:        mod.protocols.tcp-ip
Subject:   Re: talking of and to gateways and bridges

Jon,

I don't think it OK for gateways to not do IP reassembly.  They should
be able to reassemble datagrams addressed directly to them.  We are
currently working to add this to the Butterfly and LSI-11 gateways.

In principal I agree with you that we should think about using a
transport protocol to carry our routing data.  The problem I see is
that most of our current protocols try very hard to deliver the old
data before the new data.  This is less than optimum for routing
data, where it is important the deliver the new data and
forget about delivering the old data.

I hope we will never get to the point where we send our routing
around by magtape like BITNET.

Bob

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 87 17:40:03 EST (Sun)
From:      Robert Hinden <hinden@ccv.bbn.com>
To:        Jon Crowcroft <jon@cs.ucl.ac.uk>
Cc:        tcp-ip@sri-nic.ARPA, hinden@ccv.bbn.com
Subject:   Re: talking of and to gateways and bridges
Jon,

I don't think it OK for gateways to not do IP reassembly.  They should
be able to reassemble datagrams addressed directly to them.  We are
currently working to add this to the Butterfly and LSI-11 gateways.

In principal I agree with you that we should think about using a
transport protocol to carry our routing data.  The problem I see is
that most of our current protocols try very hard to deliver the old
data before the new data.  This is less than optimum for routing
data, where it is important the deliver the new data and
forget about delivering the old data.

I hope we will never get to the point where we send our routing
around by magtape like BITNET.

Bob
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Mar-87 19:25:30 EST
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        mod.protocols.tcp-ip
Subject:   Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story]

Dennis,  My (unspoken) use for the money was not for more research,
but for more simple capacity.  As a matter of fact, depending on what
your goal is, you should be able to create a model of allocating
your dollar budget that maximizes "happiness" by giving some
to research and some to capacity.  When you see lots of good research
ideas you fund research, else just pump the money into capacity.
If that is the model you have been implementing inthe past then 
there must have been a lot of great research going on in the past
few years...

Dan
-------

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1987 19:25:30 EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        Dennis G. Perry <PERRY@VAX.DARPA.MIL>
Cc:        LYNCH@A.ISI.EDU, TCP-IP@SRI-NIC.ARPA
Subject:   Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story]
Dennis,  My (unspoken) use for the money was not for more research,
but for more simple capacity.  As a matter of fact, depending on what
your goal is, you should be able to create a model of allocating
your dollar budget that maximizes "happiness" by giving some
to research and some to capacity.  When you see lots of good research
ideas you fund research, else just pump the money into capacity.
If that is the model you have been implementing inthe past then 
there must have been a lot of great research going on in the past
few years...

Dan
-------
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Mar-87 07:15:18 EST
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story]

Dan, not sure there has been any model, or any great research either.

dennis
-------

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Mon 23 Mar 87 07:15:18-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        LYNCH@a.isi.edu
Cc:        PERRY@vax.darpa.mil, TCP-IP@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story]
Dan, not sure there has been any model, or any great research either.

dennis
-------
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Mar-87 14:41:30 EST
From:      karn@FLASH.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  GOSIP (Re)action?

A correction: my TCP/IP code for the IBM PC is NOT in the public domain; I
have copyrighted it. However, I grant blanket permission for NONprofit,
NONcommercial, NONgovernmental, NONmilitary copying and use ONLY.  Amateur
radio, educational and public service applications (e.g., Red Cross) are
fine.

(I really got a kick out of taking something originally developed for the
military and subverting and perverting it for constructive purposes... :-)

Otherwise I agree with Doug's posting.

Phil

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Mar-87 17:18:21 EST
From:      henry@utzoo.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP/IP cookbook?

Does anybody know of a good book on the nitty-gritty of implementing TCP/IP?
(If there's an obvious choice, sorry about that, I'm a relative newcomer to
this stuff.)  I'm not after history and philosophy, which I gather is the
main thrust of Padlipsky's book (which I haven't had a chance to read yet),
and I want something deeper than a ten-page paper.  I'm aware of the Protocol
Handbook, and have it on order, but my impression is that it's more of a
collection of standards than a unified discussion.  I have Comer's book
"Internetworking with XINU", but it leaves too many things out (and worse,
doesn't tell you that it's doing so).  Suggestions?

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Mar-87 17:21:07 EST
From:      swb@DEVVAX.TN.CORNELL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   HP9000/550

Wollongong is the only vendor listed in the Vendors List as supplying
TCP/IP for an HP9000 model 550.  Does anyone know of any others?
						Thanks ... Scott

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Mar 87 17:43:18 EST
From:      Bob Hoffman <hoffman%pitt@RELAY.CS.NET>
To:        mod.protocols.tcp-ip
Subject:   Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story]
In article <8703220422.AA13307@buita.bu.edu> jsol@buit1.bu.EDU writes:
>        From: Scott Earley <EARLEY@BITNIC>
>
>        ... Tables
>        for all sites on the Ohio side of the PSU-Ohio link will be put
>        on tape and mailed overnight to a pre-appointed individual who
>        will reintroduce them into the network from there.
>        ...
>
>That's right.  Mag tape.
>
>--Daemon

Never underestimate the bandwidth of a station wagon full of magtapes!

-- 
Bob Hoffman, N3CVL       {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman
Pitt Computer Science    hoffman%pitt@relay.cs.net

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Mar-87 18:09:59 EST
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  GOSIP (Re)action?

Seems to me you are taking good advantage also of the Arpanet, which was
developed for militray purposes, why do you deny your obligations to it.

dennis
-------

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Mon 23 Mar 87 18:09:59-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        karn@flash.bellcore.com
Cc:        dpk@brl.arpa, well!slf@lll-lcc.arpa, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re:  GOSIP (Re)action?
Seems to me you are taking good advantage also of the Arpanet, which was
developed for militray purposes, why do you deny your obligations to it.

dennis
-------
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Mar-87 18:51:10 EST
From:      michael@labtam.OZ.AU.UUCP
To:        mod.protocols.tcp-ip
Subject:   PC LANs, NETBIOS and UNIX


	Could someone let be know the status of the NETBIOS over TCP/IP
	working group, and how to contact them? I last saw a reference to this
	group late last year.

	Also has anyone linked a decent PC LAN, such as Novell Netware, to
	a Unix computer as a file-server, or know of any such planned links?
	All that I have heard so far suggests that the Novell and 3Com
	software can co-exist with TCP/IP for TELNET and FTP but thats it. Is
	there nothing better and more integrated out there?

	thanks

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Mar-87 23:55:01 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: PC LANs, NETBIOS and UNIX

Michael,  Perhaps the best way to get in touch with the NETBIOS
activity is to contact Lee LeBarre at Mitre.  (CEL@mitre-bedford.arpa)

Dan
-------

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1987 23:55:01 EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        Michael Podhorodecki <munnari!labtam.oz!michael@SEISMO.CSS.GOV>
Cc:        tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU, cel@MITRE-BEDFORD.ARPA
Subject:   Re: PC LANs, NETBIOS and UNIX
Michael,  Perhaps the best way to get in touch with the NETBIOS
activity is to contact Lee LeBarre at Mitre.  (CEL@mitre-bedford.arpa)

Dan
-------
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 05:10:52 EST
From:      jon@CS.UCL.AC.UK.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: [dae%psuvax1.bitnet@jade.Berkeley.E

/* Written  2:08 pm  Mar 23, 1987 by tcp-ip@pyr1 in pyr1:tcp-ip */
/* ---------- "Re: [dae%psuvax1.bitnet@jade.Berkeley.E" ---------- */
Received: from ucl-cs-nss by pyr1.Cs.Ucl.AC.UK   with SMTP  id aa16134;
          23 Mar 87 14:06 WET
Received: from sri-nic.arpa by mv1.Cs.Ucl.AC.UK   via Satnet with SMTP
           id aa05875; 23 Mar 87 14:00 WET
Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Mon 23 Mar 87 04:16:01-PST
Posted-Date: Mon 23 Mar 87 07:15:18-EST
Received: by vax.darpa.mil (5.54/5.51)
        id AA01929; Mon, 23 Mar 87 07:15:21 EST
Date: Mon 23 Mar 87 07:15:18-EST
From: "Dennis G. Perry" <PERRY@mil.darpa.vax>
Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story]
To: LYNCH@edu.isi.a
Cc: PERRY@mil.darpa.vax, TCP-IP@arpa.sri-nic, perry@mil.darpa.vax
Message-Id: <VAX-MM(195)+TOPSLIB(124) 23-Mar-87 07:15:18.VAX.DARPA.MIL>
In-Reply-To: Message from "Dan Lynch <LYNCH@A.ISI.EDU>" of 22 Mar 1987 19:25:30 EST

Dan, not sure there has been any model, or any great research either.

dennis
-------
/* End of text from pyr1:tcp-ip */

If you look at the original Internet design issues, the idea of
fate sharing and a tactical network, and
so on, determined gateway/routers were connectionless.

A bit like the old CSMA versus token arguments, in a WAN context,
the consequence of this design decision is
that (without resource reservation a la
X.25) you HAVE to over-engineer for bandwidth and delay, or it
just doesn't work.

Witness the UK Academic X.25 network availability under extreme
load is 99% plus, with MTTR in the minutes, and MTBFs in the
days range, compared with the Internet under extreme load,
where we were seeing availabilities of 20-30% and MTTRs of
hours and MTBFs in the hour range.

I look forward to seeing some intermediate scheme
("connectionish networks") for the tactical+low-congestion
internet.

Jon

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 08:37:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: PC LANs, NETBIOS and UNIX

NETBIOS group has completed its work and produced two RFCs (1001 and 1002)
which are available from the NIC or by FTP (I think).

Stan Ames was the stimulus for this group's founding. sra@Mitre-bedford.arpa

Vint

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1987 08:37-EST
From:      CERF@A.ISI.EDU
To:        munnari!labtam.oz!michael@SEISMO.CSS.GOV
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: PC LANs, NETBIOS and UNIX
NETBIOS group has completed its work and produced two RFCs (1001 and 1002)
which are available from the NIC or by FTP (I think).

Stan Ames was the stimulus for this group's founding. sra@Mitre-bedford.arpa

Vint
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 08:39:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: TCP/IP cookbook?

Henry,

there isn't a book of the type you desire, so far as I know. 

there is an opportunity for some author out there...

Vint

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1987 08:39-EST
From:      CERF@A.ISI.EDU
To:        mnetor!utzoo!henry@SEISMO.CSS.GOV
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP/IP cookbook?
Henry,

there isn't a book of the type you desire, so far as I know. 

there is an opportunity for some author out there...

Vint
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 08:53:06 EST
From:      mckee@MITRE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

The reply from Steve Silverman to Vint Cerf concerning X.25 resets follows:


 *** Reply to note of 03/22/87 12:25
 From:    Steve Silverman
 Subject: Re: GOSIP vs TCP/IP
 Re: X.25 reset:  If the endpoint processor running one side of the X.25 session
  fails, then info is lost.  The same is true if the processor running TCP or TP
 -4 fails.  Hopefully, the user is notified in either case.   Steve.
 *
 *        Steve

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 08:59:50 EST
From:      mckee@MITRE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

The reply from Steve Silverman to Dennis Perry concerning the cost of,
and traffic over, Telenet follows:


 *** Reply to note of 03/22/87 12:28
 From:    Steve Silverman
 Subject: Re: GOSIP vs TCP/IP
 Response to Dennis Perry:
         In 1983 the Telenet public network cost in the neighborhood of 85 -
 100 million dollars/year.  This included development, PAD support, and
 interest on debt.
         About a year ago the Telenet public net handled about 1.5 billion
 user data packets /month.  This does not include layer 3RR packets, which would
 be the equivalent of TCP acknowledgments, retransmittals of dropped packets,
 or network maintenance (GGP packets).
 *
 *        Steve

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 87 10:06:00 CST
From:      "CALVIN R GEORGE" <george@eglin-vax>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Need Info on SMTP
E G L I N   A F B
                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      24-Mar-1987 09:30am CST
                                        From:      CALVIN R GEORGE 
                                                   GEORGE 
                                        Dept:      
                                        Tel No:    882-5498

TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC] )

CC:  FRANK M WOODALL                      ( WOODALL )
CC:  BRIAN C. BRAZIEL                     ( BRAZIEL )
CC:  BARBARA J LINN                       ( LINN )
CC:  HERBERT SPIES                        ( SPIES )

Subject: Need Info on SMTP

Is there a Public Domain version of SMTP ( both Client and Server ) 
available?

As you can tell by the headers on this message, we are using DEC's
ALL-IN-1 and Wollongong's WIN/VX. The interface between ALL-IN-1 and
WIN/VX is a local mod to an ALL-IN-1 script. All of the ALL-IN-1
mail features such as FORWARD, AUTOANSWER, READ RECEIPT, etc. are not
supported, or should I say, do not work. After some investigation,
we have decided that the best way to provide these services is to
write SMTP servers/clients that know about ALL-IN-1. 

Has any work been done in this area? 

Any knowledge/source for SMTP code would at least prevent us from having
to write SMTP code from scratch. 

Please reply to me directly. I will provide any responses to interested 
parties upon request.

Calvin George
AD/KRSSD
Eglin AFB, FL


------
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 09:34:57 EST
From:      dorl@uwmacc.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: uwmacc!dorl
From: dorl@uwmacc.UUCP (Michael Dorl)
Newsgroups: mod.protocols.tcp-ip,comp.dcom.lans
Subject: Bruknet Protocols
Message-ID: <1282@uwmacc.UUCP>
Date: 24 Mar 87 14:34:56 GMT
Organization: UWisconsin-Madison Academic Comp Center
Lines: 14

I have a Ethernet supporting both the TCP/IP and DECNet protocols.
A user in Biochemistry wishes to attach some German machinery using
something called Bruknet to this network.  The manual seems to
indicate that it coexists with DECNet.  It appears to use Ethernet
type 10-10 or 4112 (base 10).  This type number does not conflict with
IP but its not listed in the Assigned Numbers section of the
DDN Protocol Handbook.

Has anyone used this product?  Is it known to coexist with both
DECNet and TCP/IP?

Michael Dorl
dorl@unix.macc.wisc.edu
dorl@wiscmacc.bitnet

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 10:07:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

Steve (Silverman),

Thanks for the reply on X.25 resets. My experiences with
public or private data nets using X.25 is that under 
congestion conditions, X.25 does NOT recover from the
problems causing resets while TCP and other end/end transport
protocols often do recover. Consequently, most inter-computer
applications use some kind of end/end protocol with retransmission
(and, of course duplicate detection) above X.25. 

I took the earlier comments on X.25 to imply that raw X.25 is
sufficient. I would have to say that my experience has been
otherwise, except for terminal to host applications in which the user
recovers from problems by re-typing his input (which behavior is also
appropriate for noisy, unprotected dial-up access to PADs...).

Do we have a difference of opinion?

Vint

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1987 10:07-EST
From:      CERF@A.ISI.EDU
To:        mckee@MITRE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, m15368%mwvm@MITRE.ARPA
Subject:   Re: GOSIP vs TCP/IP
Steve (Silverman),

Thanks for the reply on X.25 resets. My experiences with
public or private data nets using X.25 is that under 
congestion conditions, X.25 does NOT recover from the
problems causing resets while TCP and other end/end transport
protocols often do recover. Consequently, most inter-computer
applications use some kind of end/end protocol with retransmission
(and, of course duplicate detection) above X.25. 

I took the earlier comments on X.25 to imply that raw X.25 is
sufficient. I would have to say that my experience has been
otherwise, except for terminal to host applications in which the user
recovers from problems by re-typing his input (which behavior is also
appropriate for noisy, unprotected dial-up access to PADs...).

Do we have a difference of opinion?

Vint
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 10:10:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

Seems to me that the Telenet costs are comparable to ARPANET costs
since there is a factor of 10 difference in traffic and costs in both
systems.

Several years ago, we estimated that the PRICE of telenet service
would be something like 3 times higher than the cost of ARPANET
service. It would be very interesting to make the comparison again.

Vint

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1987 10:10-EST
From:      CERF@A.ISI.EDU
To:        mckee@MITRE.ARPA
Cc:        PERRY@VAX.DARPA.MIL, m15368%mwvm@MITRE.ARPA tcp-ip@SRI-NIC.ARPA
Subject:   Re: GOSIP vs TCP/IP
Seems to me that the Telenet costs are comparable to ARPANET costs
since there is a factor of 10 difference in traffic and costs in both
systems.

Several years ago, we estimated that the PRICE of telenet service
would be something like 3 times higher than the cost of ARPANET
service. It would be very interesting to make the comparison again.

Vint
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 11:06:00 EST
From:      george@EGLIN-VAX.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Need Info on SMTP

E G L I N   A F B
                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      24-Mar-1987 09:30am CST
                                        From:      CALVIN R GEORGE 
                                                   GEORGE 
                                        Dept:      
                                        Tel No:    882-5498

TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC] )

CC:  FRANK M WOODALL                      ( WOODALL )
CC:  BRIAN C. BRAZIEL                     ( BRAZIEL )
CC:  BARBARA J LINN                       ( LINN )
CC:  HERBERT SPIES                        ( SPIES )

Subject: Need Info on SMTP

Is there a Public Domain version of SMTP ( both Client and Server ) 
available?

As you can tell by the headers on this message, we are using DEC's
ALL-IN-1 and Wollongong's WIN/VX. The interface between ALL-IN-1 and
WIN/VX is a local mod to an ALL-IN-1 script. All of the ALL-IN-1
mail features such as FORWARD, AUTOANSWER, READ RECEIPT, etc. are not
supported, or should I say, do not work. After some investigation,
we have decided that the best way to provide these services is to
write SMTP servers/clients that know about ALL-IN-1. 

Has any work been done in this area? 

Any knowledge/source for SMTP code would at least prevent us from having
to write SMTP code from scratch. 

Please reply to me directly. I will provide any responses to interested 
parties upon request.

Calvin George
AD/KRSSD
Eglin AFB, FL


------

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1987 12:32:39 CST
From:      AFDDN.TCP-IP@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Fact or fiction
Comments (especially corrections) welcome,

  DDN X.25 has always been a source of confusion to a lot of people.  I want
to get the record straight for once.

There are two types of X.25 service in DDN; Basic and Standard.  I don't want
to get into the details of X.25, except where the DDN does interesting things.

Basic X.25---This is the easy one.  Hosts can use the DDN as if it was PDN.  
The D-bit, Q-bit, and M-bit are passed transparently through the network.  The
PSN End-to-end modules set up the the internal End-to-end connection to
establish the X.25 virtual circuit.  Each X.25 packet is viewed as a "meesage"
by the End-to-End module.  Multiple virtual circuits are allowed between a
given host pair.  What I would like to know is:  Does the End-to-End module
set up multiple End-to-End connections?  If not, how does End-to-End sort
which "messages" go with which virtual circuit.

Standard X.25---This is the interesting one, available in PSN 6.0 initially.
I assume here that if you use the Standard Service facilities field then the
node "assumes" you to be placing an interoperable call and "all" the packets
get passed to the IOP module.  The IOP mudule is a logical 1822 host created
in software.  The user data is extracted from X.25 packets and used to form
1822 messages which are then passed to the End-to-End module for transmission
through the network.  The Q-bit and D-bit are not passed through the network.
All X.25 acks are only locally significant.  Each packet, or complete packet
sequence is assumed to be an IP datagram.  Therefore the M-bit is used locally
to send a datagram larger than 1 packet as a complete packet sequence.  The
user data portions of the complete packet sequence are agregated into a single
"message" which is then passed to the End-to-End module.  A datagram, sent as
a single packet or a complete sequence, cannot be longer than the 1822 maximum
message length.  Only one End-to- End connection can be established between
any two host pairs at a given precedence level (let's leave precedence out now).
Question:  What will the node do if you try to set up a second virtual circuit
between a host pair already having one End-to-End connection established?  Will
the node simply clear the call?  

A related IOP question:  The 1822 spec call for the hardware to pad messages
out to specific length boundaries (16 or 32 bits, I don't remember at the 
moment).  If an 1822 host sends a message to another 1822 host, the hardware
on the receiving end strips the padding.  What happens if an 1822 host sends
a message to a Standard X.25 host.  The padding added by the hardware of the
sending host is added to the user data in the X.25 packet (or sequence) that
gets sent to the receiving host.  The IP module of that host will then be
passed a buffer of data as a datagram that's longer than the length field
in the IP header says it should  really be.  This shouldn't be a problem, but
I know of one host that got confused by this.  It took the guy debugging the
interface a couple of days to figure out the problem.
Is all this really accurate or have I glitched a bit somewhere?

A lot of this stuff will change with the advent of PSN 7.0.  Anybody know 
exactly what's gonna change?

Darrel B.
-------
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 12:30:56 EST
From:      AI.CLIVE@MCC.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Duplicate messages

Judging from the number of repsonses I received, I'm certainly
not the only one receiving multiple copies of TCP-IP messages.
I believe the problem can be isolated to SRI-NIC's mailer.  Header
info seems to indicate that SRI-NIC is receiving a single copy of
each message, but for unknown reasons transmits two.  This situation
has existed for the better part of a year, at least.  It is ironic
that the mailing list which is most used to discuss the current
state of net congestion is a contributor to it as well.

Clive

P.S.  For the benefit of anybody who might (please!) be able to look
into this, here is one recent example:

Message 1 -- ************************
Return-Path: <tcp-ip-RELAY@SRI-NIC.ARPA>
Received: from SRI-NIC.ARPA by MCC.COM with TCP; Mon 23 Mar 87 23:24:58-CST
Received: from seismo.CSS.GOV by SRI-NIC.ARPA with TCP; Mon 23 Mar 87 15:27:27-PST
Received: from munnari.oz by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA18131; Mon, 23 Mar 87 18:26:22 EST
Message-Id: <8703232326.AA18131@seismo.CSS.GOV>
Received: from labtam (via mulga) by munnari with SunIII (5.5)
	id AA03707; Tue, 24 Mar 87 00:54:01 EST
Received: by labtam (4.12/1.7)
	id AA07943; Mon, 23 Mar 87 23:55:31 +1000
Date: Mon, 23 Mar 87 23:55:31 +1000
From: Michael Podhorodecki <munnari!labtam.oz!michael@seismo.CSS.GOV>
To: tcp-ip@sri-nic.arpa
Subject: PC LANs, NETBIOS and UNIX

	...

Message 2 -- ************************
Return-Path: <tcp-ip-RELAY@SRI-NIC.ARPA>
Received: from SRI-NIC.ARPA by MCC.COM with TCP; Tue 24 Mar 87 02:04:22-CST
Received: from seismo.CSS.GOV by SRI-NIC.ARPA with TCP; Mon 23 Mar 87 15:27:27-PST
Received: from munnari.oz by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA18131; Mon, 23 Mar 87 18:26:22 EST
Message-Id: <8703232326.AA18131@seismo.CSS.GOV>
Received: from labtam (via mulga) by munnari with SunIII (5.5)
	id AA03707; Tue, 24 Mar 87 00:54:01 EST
Received: by labtam (4.12/1.7)
	id AA07943; Mon, 23 Mar 87 23:55:31 +1000
Date: Mon, 23 Mar 87 23:55:31 +1000
From: Michael Podhorodecki <munnari!labtam.oz!michael@seismo.CSS.GOV>
To: tcp-ip@sri-nic.arpa
Subject: PC LANs, NETBIOS and UNIX

	...

-------

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 13:32:39 EST
From:      AFDDN.TCP-IP@GUNTER-ADAM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Fact or fiction

Comments (especially corrections) welcome,

  DDN X.25 has always been a source of confusion to a lot of people.  I want
to get the record straight for once.

There are two types of X.25 service in DDN; Basic and Standard.  I don't want
to get into the details of X.25, except where the DDN does interesting things.

Basic X.25---This is the easy one.  Hosts can use the DDN as if it was PDN.  
The D-bit, Q-bit, and M-bit are passed transparently through the network.  The
PSN End-to-end modules set up the the internal End-to-end connection to
establish the X.25 virtual circuit.  Each X.25 packet is viewed as a "meesage"
by the End-to-End module.  Multiple virtual circuits are allowed between a
given host pair.  What I would like to know is:  Does the End-to-End module
set up multiple End-to-End connections?  If not, how does End-to-End sort
which "messages" go with which virtual circuit.

Standard X.25---This is the interesting one, available in PSN 6.0 initially.
I assume here that if you use the Standard Service facilities field then the
node "assumes" you to be placing an interoperable call and "all" the packets
get passed to the IOP module.  The IOP mudule is a logical 1822 host created
in software.  The user data is extracted from X.25 packets and used to form
1822 messages which are then passed to the End-to-End module for transmission
through the network.  The Q-bit and D-bit are not passed through the network.
All X.25 acks are only locally significant.  Each packet, or complete packet
sequence is assumed to be an IP datagram.  Therefore the M-bit is used locally
to send a datagram larger than 1 packet as a complete packet sequence.  The
user data portions of the complete packet sequence are agregated into a single
"message" which is then passed to the End-to-End module.  A datagram, sent as
a single packet or a complete sequence, cannot be longer than the 1822 maximum
message length.  Only one End-to- End connection can be established between
any two host pairs at a given precedence level (let's leave precedence out now).
Question:  What will the node do if you try to set up a second virtual circuit
between a host pair already having one End-to-End connection established?  Will
the node simply clear the call?  

A related IOP question:  The 1822 spec call for the hardware to pad messages
out to specific length boundaries (16 or 32 bits, I don't remember at the 
moment).  If an 1822 host sends a message to another 1822 host, the hardware
on the receiving end strips the padding.  What happens if an 1822 host sends
a message to a Standard X.25 host.  The padding added by the hardware of the
sending host is added to the user data in the X.25 packet (or sequence) that
gets sent to the receiving host.  The IP module of that host will then be
passed a buffer of data as a datagram that's longer than the length field
in the IP header says it should  really be.  This shouldn't be a problem, but
I know of one host that got confused by this.  It took the guy debugging the
interface a couple of days to figure out the problem.
Is all this really accurate or have I glitched a bit somewhere?

A lot of this stuff will change with the advent of PSN 7.0.  Anybody know 
exactly what's gonna change?

Darrel B.
-------

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 13:52:10 EST
From:      karn@FLASH.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: network horror stories

Anyone who believes that connection-oriented networks are inherently immune
to congestion should consider one of the following events:

1. The US phone network on the night of the Carter-Reagan debates in 1980.
AT&T conducted their first large-scale trial of their 900 DIAL-IT service
which was used to poll viewers on their opinions regarding the debate. Although
AT&T  placed strict limits on the number of long distance trunks that could be
used for 900 service, there were so many people attempting to call it that in
most places in the country there were delays of at least 2 minutes in getting
dial tone from the local office.

2. The phone system in the state of Arizona the day the Tucson Amateur Packet
Radio group decided to take phone orders (one day only!) for their new packet
radio controller box. They only had one phone line. Not only was Tucson
cut off from the rest of the world for several hours, but most of the rest of
the state as well.

3. The ticket-buying frenzy accompanying any Bruce Springsteen concert.

The problem isn't connectionless vs connection-oriented, it's that the network
is a shared resource. If there aren't enough facilities to go around in times
of peak demand, some people are going to be denied service. The only difference
is in the details of how that's done.  The real issue when trying to assure
network stability is how the users react to being denied service. If they
use Demon Dialers to hammer away at the phone network, you're going to have
trouble. The Internet is in trouble because there are so many broken TCPs
out there that do the equivalent thing when the network load picks up.
I wouldn't be surprised if a few nodes could bring down an X.25 network
pretty easily by just pummeling it with CALL REQUEST packets to unreachable
addresses.

The solution is more likely economic than technical. Since failed attempts
still use network resources, one answer is to charge for them.  I suspect
charging for failed phone calls would put a stop to the abuse of demon dialers.
Since the Internet doesn't charge for each packet, the solution here would
be to require certification of a host's TCP retransmission behavior before
it attached to the network in the same way that a radio transmitter has to
be type certified before it can be placed in operation.

Phil

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 16:39:06 EST
From:      geof@apolling.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Station wagon full of bits


 > In article <8703220422.AA13307@buita.bu.edu> jsol@buit1.bu.EDU writes:
 > >        From: Scott Earley <EARLEY@BITNIC>
 > >
 > >        ... Tables
 > >        for all sites on the Ohio side of the PSU-Ohio link will be put
 > >        on tape and mailed overnight to a pre-appointed individual who
 > >        will reintroduce them into the network from there.
 > >        ...
 > >
 > >That's right.  Mag tape.
 > >
 > >--Daemon
 > 
 > Never underestimate the bandwidth of a station wagon full of magtapes!
 > 

Well, we can't resist this, can we.  Back of the envelope calculations
for a station wagon full of bits transmitted from the east coast to the
west coast follow.  Apologies for any naivitee about magtapes -- I don't
use them often and never learned all the sordid details.

    Station wagon: 5' X 5' X 3' trunk
    Transit time: 4 days = 345 600 s
     (might add a day on each side to copy the data to & from tape)
    Data:
        1 magtape, 12"X1" reel, 1000' of tape, 9600 bpi, 9 tracks
            => 12*1000*9600*9 = 129.6 E 6 bits
        5*5*36 = 875 magtapes in trunk

        => 875*129.6 = 113.4 E 9 bits

    Throughput:
        113.4e9 b / 345600 s = 328,125 b/s

Hmm.... better than the arpanet.... how much does a station wagon
cost these days, anyway...

Corrections welcome (they might as well be, I'm sure there will
be some!),

- Geof

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Tue 24 Mar 87 19:51:44-PST
From:      Karl Auerbach <AUERBACH@CSL.SRI.COM>
To:        munnari!labtam.oz!michael@SEISMO.CSS.GOV
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: PC LANs, NETBIOS and UNIX
The NetBIOS-over-TCP group is alive and well.  Two RFCs have been written.
RFC 1001 is an overview of the operation of the protocols.  RFC 1002
describes the packet representations and gives pseudo-code for the
various protocol engines.

I have not yet seen the notice announcing that the documents are available
on the NIC.

The protocols were expressly designed so that one could implement them on
a Un*x system without kernel mods.

The "SMB" protocol is the most common NetBIOS-based application for
doing remote virtual disks and printers.  This is what the IBM PC
network program uses.  Hearsay has it that Novell does not conform to
either NetBIOS or SMB, based on an assertion that NetBIOS or SMB would
lead to sub-optimal performance.

There ARE SMB server products available for Un*x.  Unfortunately, I
can't remember the vendors.

Until images are posted to the NIC, copies may be a bit hard to come by.
I believe you can get a paper copy from Amatzia Ben-Artzi at Sytek.

When you do get a copy, please read it and send comments to either the
editor (me) or the chairman, as listed in the RFCs.

			--karl--  (Karl Auerbach, Epilogue Technology Corp.)
-------
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Mar 87 12:10:52 WET
From:      jon@Cs.Ucl.AC.UK
To:        tcp-ip@Cs.Ucl.AC.UK
Subject:   Re: [dae%psuvax1.bitnet@jade.Berkeley.E
/* Written  2:08 pm  Mar 23, 1987 by tcp-ip@pyr1 in pyr1:tcp-ip */
/* ---------- "Re: [dae%psuvax1.bitnet@jade.Berkeley.E" ---------- */
Received: from ucl-cs-nss by pyr1.Cs.Ucl.AC.UK   with SMTP  id aa16134;
          23 Mar 87 14:06 WET
Received: from sri-nic.arpa by mv1.Cs.Ucl.AC.UK   via Satnet with SMTP
           id aa05875; 23 Mar 87 14:00 WET
Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Mon 23 Mar 87 04:16:01-PST
Posted-Date: Mon 23 Mar 87 07:15:18-EST
Received: by vax.darpa.mil (5.54/5.51)
        id AA01929; Mon, 23 Mar 87 07:15:21 EST
Date: Mon 23 Mar 87 07:15:18-EST
From: "Dennis G. Perry" <PERRY@mil.darpa.vax>
Subject: Re: [dae%psuvax1.bitnet@jade.Berkeley.EDU: Network horror story]
To: LYNCH@edu.isi.a
Cc: PERRY@mil.darpa.vax, TCP-IP@arpa.sri-nic, perry@mil.darpa.vax
Message-Id: <VAX-MM(195)+TOPSLIB(124) 23-Mar-87 07:15:18.VAX.DARPA.MIL>
In-Reply-To: Message from "Dan Lynch <LYNCH@A.ISI.EDU>" of 22 Mar 1987 19:25:30 EST

Dan, not sure there has been any model, or any great research either.

dennis
-------
/* End of text from pyr1:tcp-ip */

If you look at the original Internet design issues, the idea of
fate sharing and a tactical network, and
so on, determined gateway/routers were connectionless.

A bit like the old CSMA versus token arguments, in a WAN context,
the consequence of this design decision is
that (without resource reservation a la
X.25) you HAVE to over-engineer for bandwidth and delay, or it
just doesn't work.

Witness the UK Academic X.25 network availability under extreme
load is 99% plus, with MTTR in the minutes, and MTBFs in the
days range, compared with the Internet under extreme load,
where we were seeing availabilities of 20-30% and MTTRs of
hours and MTBFs in the hour range.

I look forward to seeing some intermediate scheme
("connectionish networks") for the tactical+low-congestion
internet.

Jon
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 21:01:57 EST
From:      karn@FLASH.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

This is misleading. In "unlayered virtual circuit" networks, connection
state information is kept not only in the end-point switches, but also in
every intermediate switch along the path.  For example, I understand that
each GTE Telenet node speaks X.75 to its neighbors, making it an unlayered
VC network.  Because of this, a node or link failure ANYWHERE along the
connection path causes an X.25 VC reset, not just failures at the end nodes.

Only in "layered VC" networks such as the DDN (where datagrams are used
internally) can intermediate node and link failures occur without resetting
virtual circuits.  Since it is my understanding that the DDN is used
almost exclusively for passing Internet datagrams around, I never could
understand the reason for forcing IP gateways to deal with the gratuitous
complexity of X.25.  I can only speculate that the reasons were political
and not technical. However, I am thankful that we will be able to come up on
the ARPANET with HDH instead of X.25.

Phil

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 22:45:50 EST
From:      ddp#@ANDREW.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   danger of bridges


I've been hearing alot about people creating large networks using level 2
bridges (i.e. the DEC LANBridge).  People are talking about connecting 1000's
of hosts' to ethernet's connected via them.  In Monterey I even heard about a
3 university consortium planning on using them to connect all their nets
together!  This is extremely dangerous!  It really scares me.  DEC, IBM and
other companies promoting these boxes are being incredibly short sighted and
are leading their customers down a dead-end road!

These boxes are just great for small networks and connecting multiple nets
together where repeaters won't work, but for large net's (greater than 100's
of hosts) they are not efficient.  The reason is because of broadcasts and
multicasts which are passed through the boxes, as they must be.  For example,
ARP request broadcasts are passed through all bridges on the network so that
they reach all hosts on all connected nets.  If you have 1000's of hosts on
your network that tend to talk to a large number of other hosts, you wind up
with an incredible amount of arp traffic.  For example, the CMU network is
composed of >2000 hosts and >50 networks.  Some of these nets are connected
using LANBridges, but most of them are connected via CMU routers (gateways)
which operate on a scheme similar to the extended arp black boxes propsed by
John Postel in RFC 925 (although we had it first :-)).  This scheme
effectively operates as a level 2 bridge system for ARP packets but as a
level 3 gateway for IP packets.  I.e. routing is done via arp, sort of like
as in "promiscuous arp" or the "arp hack".  I say similar because we've put a
lot of additional work into this scheme in order to suppress the number of
arps.  According to our statistics, we do limit a significant amount of arp
to a single network rather than being forwarded through all connected nets.
However, we still have an average rate of 20 arp's per second on all nets in
the system!  Yes, I typed that right, twenty.  And of course every time
someone's program goes crazy you wind up with even higher rates.  Once a
student hacking on a UNIX system wrote a program to send a UDP datagram to
every host in the host table (since only setuid programs can send broadcasts
in 4.2).  It was truly amazing seeing 100 arp's/sec...  That's the price paid
for not having subnet's and level 3 routing with IP.  We are definitely not
going to reach our goal of 7000 hosts this way...

And then there's DECnet.  I won't claim to be a DECnet expert, but from my
observations it appears to me that all Phase IV DECnet hosts connected to an
ethernet transmit HELLO multicast messages every 15 seconds.  These of course
all pass through the bridge or else intra-area routing wouldn't work.  We
have somewhere around 100 DECnet hosts connected to our backbone ethernet
system.  Dividing these two numbers I expect to see about 6 HELLO's a second
on the net.  Using PCIP NETWATCH I indeed measured 5 per second.  Of course,
this is with only 100 hosts.  Doing the same calculation with 1000 hosts one
would see 66 HELLO's/sec.  2000 hosts would yield 133/sec, 4000 hosts would
give 266/sec.  Can you imagine EVERY DECnet machine on a network processing
266 routing packets/sec?  I sure wouldn't want to try to get work done on
such a machine.

To summarize, level 2 bridges are very useful, but you have realize that they
are not the perfect solution.  You have to keep their limitations in mind.
There are very good reasons for having level 3 routing.

Drew

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Mar-87 22:51:44 EST
From:      AUERBACH@CSL.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: PC LANs, NETBIOS and UNIX

The NetBIOS-over-TCP group is alive and well.  Two RFCs have been written.
RFC 1001 is an overview of the operation of the protocols.  RFC 1002
describes the packet representations and gives pseudo-code for the
various protocol engines.

I have not yet seen the notice announcing that the documents are available
on the NIC.

The protocols were expressly designed so that one could implement them on
a Un*x system without kernel mods.

The "SMB" protocol is the most common NetBIOS-based application for
doing remote virtual disks and printers.  This is what the IBM PC
network program uses.  Hearsay has it that Novell does not conform to
either NetBIOS or SMB, based on an assertion that NetBIOS or SMB would
lead to sub-optimal performance.

There ARE SMB server products available for Un*x.  Unfortunately, I
can't remember the vendors.

Until images are posted to the NIC, copies may be a bit hard to come by.
I believe you can get a paper copy from Amatzia Ben-Artzi at Sytek.

When you do get a copy, please read it and send comments to either the
editor (me) or the chairman, as listed in the RFCs.

			--karl--  (Karl Auerbach, Epilogue Technology Corp.)
-------

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Mar-87 06:41:07 EST
From:      jon@CS.UCL.AC.UK.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: network horror stories


Exactly my point. TCP can be made to work fine. IP can be made
to work fine, but currently has no (workable) mechanism for
congestion control. If the internet is overengineered in terms
of bandwidth, this works OK. If some congestion control
mechanism is put in the gateways, it can be made to work better.
Just fixing everyone's TCP does not fix things, because they
can not make optimal use of the paths.

X.25 networks give you a (one particular kind of) handle
to control the hop by hop congestion
control if you implement it right, whilst TP4/TCP (especially with
selacks) buys you efficient end to end control. JANET happens
to do this, which is why it  works well.

The resource reservation explicit in X.25 means you don't get
hit by misbehaving end points - it's fair. A DTE that floods
the DCE with CALL REQUEST packets just gets ignored by any
reasonable DCE, and does not impinge on the network at all,
after all X.25 is an interface spec more than a protocol.

Asking people to certify TCPs before attaching to a research
network like the internet is like asking your friend to certify
that the car he's selling you cheap is going to run trouble
free.

We can't prove programs yet.

jon

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Mar-87 08:08:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

Never confuse bandwidth with timeliness and utility.

For example, take the highest density storage medium you can think
of - say the 10**10 bits per square inch optical storage disks,
put a stack of them in a knapsack. Walk from east coast to west
coast:

The 14" disk has about pi*(5)**2 sq inches and you can put about
100 of these disks into the sack (at 1/2 pound each that would be
a reasonable 50 lbs). At an average speed of 3 mph for 10 hours a 
day, it would take 100 days or 100*86,400 seconds.

So you have roughly:

(22/7)*25*10**10 bits per disk = 7.86 * 10**10 bits per disk

100 disks = 7.8 * 10**12 bits

At 3 mph for 10 hrs/day it takes 100 days to go 3000 miles.

100 days at 86,400 seconds/24 hr day = 8.6 * 10**6 seconds

So the coast to coast data rate for Johnny Appleseed is:

7.8/8.6 * 10**5 = about .9 * 10**5 = 90 kb/s which is about
double the bandwidth you can get out of an unloaded ARPANET
with today's 56 kb/s backbone.

But few applications can deal with 100 day transmisstion/propagation
delay.

If people want to pursue this line of reasoning, I suggest that
we invent a new unit of transmission: Appleseeds which are
measured in Megabytes per Fortnight. Since a Megabyte per Fortnight
is about a Megabyte in 14 days which works out to close to 1 byte per 
second, it is easy to see that the optical disk/Adidas method yields
roughly 90 kiloAppleseeds.

Vint

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 1987 08:08-EST
From:      CERF@A.ISI.EDU
To:        imagen!apolling!geof@DECWRL.DEC.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Station wagon full of bits
Never confuse bandwidth with timeliness and utility.

For example, take the highest density storage medium you can think
of - say the 10**10 bits per square inch optical storage disks,
put a stack of them in a knapsack. Walk from east coast to west
coast:

The 14" disk has about pi*(5)**2 sq inches and you can put about
100 of these disks into the sack (at 1/2 pound each that would be
a reasonable 50 lbs). At an average speed of 3 mph for 10 hours a 
day, it would take 100 days or 100*86,400 seconds.

So you have roughly:

(22/7)*25*10**10 bits per disk = 7.86 * 10**10 bits per disk

100 disks = 7.8 * 10**12 bits

At 3 mph for 10 hrs/day it takes 100 days to go 3000 miles.

100 days at 86,400 seconds/24 hr day = 8.6 * 10**6 seconds

So the coast to coast data rate for Johnny Appleseed is:

7.8/8.6 * 10**5 = about .9 * 10**5 = 90 kb/s which is about
double the bandwidth you can get out of an unloaded ARPANET
with today's 56 kb/s backbone.

But few applications can deal with 100 day transmisstion/propagation
delay.

If people want to pursue this line of reasoning, I suggest that
we invent a new unit of transmission: Appleseeds which are
measured in Megabytes per Fortnight. Since a Megabyte per Fortnight
is about a Megabyte in 14 days which works out to close to 1 byte per 
second, it is easy to see that the optical disk/Adidas method yields
roughly 90 kiloAppleseeds.

Vint
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Mar-87 08:25:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP




The X.25 interface to DDN was pursued for at least two reasons:

First, there are more X.25 interfaces available commercially than
1822 or just pure HDLC. Second, these interfaces can be used on public
data nets which gives the potential for commercial back-up in case of
emergencies.

Vint

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 1987 08:25-EST
From:      CERF@A.ISI.EDU
To:        karn@FLASH.BELLCORE.COM
Cc:        mckee@MITRE.ARPA, m15368%mwvm@MITRE.ARPA tcp-ip@SRI-NIC.ARPA
Subject:   Re: GOSIP vs TCP/IP



The X.25 interface to DDN was pursued for at least two reasons:

First, there are more X.25 interfaces available commercially than
1822 or just pure HDLC. Second, these interfaces can be used on public
data nets which gives the potential for commercial back-up in case of
emergencies.

Vint
-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Mar-87 08:45:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits


OOPS.


The Appleseed is 1 MB/1.2 Msec = 8 Mb/1.2 Msec = 6.7 bps

So 90 Kbps is about 13.5 K Appleseeds


Vint

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 1987 08:45-EST
From:      CERF@A.ISI.EDU
To:        CERF@A.ISI.EDU
Cc:        imagen!apolling!geof@DECWRL.DEC.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Station wagon full of bits

OOPS.


The Appleseed is 1 MB/1.2 Msec = 8 Mb/1.2 Msec = 6.7 bps

So 90 Kbps is about 13.5 K Appleseeds


Vint
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Mar-87 09:06:28 EST
From:      hinden@CCV.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

Geof,

Just think of the bandwidth of a  747 full of magtapes!

Bob

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 87 09:06:28 EST (Wed)
From:      Robert Hinden <hinden@ccv.bbn.com>
To:        Geof Cooper <imagen!apolling!geof@decwrl.dec.com>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Station wagon full of bits
Geof,

Just think of the bandwidth of a  747 full of magtapes!

Bob
-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Mar-87 09:23:41 EST
From:      ahill@CC7.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits


	Back in the early 70's when the ARPANET was a little zippier than
it is today, SDAC tried to send full 1600bpi 9 track tape contents from
Virginia to UCLA using a very highly tuned block transfer FTP that got
roughly 18KB continuous across the network.  We needed to transfer six
tapes a day and rapidly learned (the hard way) that the US Snail could
outperform the network in bandwidth and cost.  

	I don't suggest that the network is not efficient or useful but
it easy to misuse particularly with bulk data transfers.

Alan

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Mar 87  9:23:41 EST
From:      "Alan R. Hill" <ahill@cc7.bbn.com>
To:        imagen!apolling!geof@decwrl.dec.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Station wagon full of bits
	Back in the early 70's when the ARPANET was a little zippier than
it is today, SDAC tried to send full 1600bpi 9 track tape contents from
Virginia to UCLA using a very highly tuned block transfer FTP that got
roughly 18KB continuous across the network.  We needed to transfer six
tapes a day and rapidly learned (the hard way) that the US Snail could
outperform the network in bandwidth and cost.  

	I don't suggest that the network is not efficient or useful but
it easy to misuse particularly with bulk data transfers.

Alan

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Mar-87 12:22:06 EST
From:      OLE@SRI-NIC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: PC LANs, NETBIOS and UNIX


I got the RFC announcement yesterday and just checked now: RFC 1001 and RFC 1002
are now online at the NIC, go get 'em!

Ole
-------

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Mar-87 16:01:03 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Fact or fiction

Darrel,

While I can't speak to all the points in your message, I can confirm that
the tailing bits you impute to the 1822-X.25 message occur on ordinary
1822-1822 messages as well. It is well known that the padding bits will
always add up to 16 bits to the length of the message. I would suspect,
so far unverified, that this can happen on a Standard X.25-X.25 message
as well. From an implementor's point of view, this bug seldom bites more
than once.

Dave

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Mar 87 11:26:09 +0000
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        "Phil R. Karn" <karn@flash.bellcore.com>
Cc:        tcp-ip@sri-nic.arpa, jon@Cs.Ucl.AC.UK
Subject:   Re: network horror stories

Exactly my point. TCP can be made to work fine. IP can be made
to work fine, but currently has no (workable) mechanism for
congestion control. If the internet is overengineered in terms
of bandwidth, this works OK. If some congestion control
mechanism is put in the gateways, it can be made to work better.
Just fixing everyone's TCP does not fix things, because they
can not make optimal use of the paths.

X.25 networks give you a (one particular kind of) handle
to control the hop by hop congestion
control if you implement it right, whilst TP4/TCP (especially with
selacks) buys you efficient end to end control. JANET happens
to do this, which is why it  works well.

The resource reservation explicit in X.25 means you don't get
hit by misbehaving end points - it's fair. A DTE that floods
the DCE with CALL REQUEST packets just gets ignored by any
reasonable DCE, and does not impinge on the network at all,
after all X.25 is an interface spec more than a protocol.

Asking people to certify TCPs before attaching to a research
network like the internet is like asking your friend to certify
that the car he's selling you cheap is going to run trouble
free.

We can't prove programs yet.

jon
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Mar-87 20:55:50 EST
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

Geof, suggest you use 2400 feet for a standard mag tape.  At about 40 Mbytes
per tape or 320 E 6 bits instead of 129.6 E 6 bits.  Gives you roughly
a factor of 3 better thru put.

Last time I checked a station wagon cost about a fouth the cost of a
butterfly gateway.

Or about four months of 56 kbit/s cross country line from ATT.

dennis
-------

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Wed 25 Mar 87 20:55:50-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        imagen!apolling!geof@decwrl.dec.com
Cc:        tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: Station wagon full of bits
Geof, suggest you use 2400 feet for a standard mag tape.  At about 40 Mbytes
per tape or 320 E 6 bits instead of 129.6 E 6 bits.  Gives you roughly
a factor of 3 better thru put.

Last time I checked a station wagon cost about a fouth the cost of a
butterfly gateway.

Or about four months of 56 kbit/s cross country line from ATT.

dennis
-------
-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Mar-87 22:16:29 EST
From:      karn@flash.bellcore.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Station wagon full of bits

You really should update this old idea to use more up-to-date technologies.
To wit: 

What is the bandwidth of a B-747 (DC-10, L-1011, A-300) loaded with Compact
Discs or CD Roms?

(To be fair, we should compare this to a fiber link covering the same path.)

With fiber, the economies of scale in transmission are enormous.  However,
the ARPANET has been around a long time. Its internal routing algorithms
were built to squeeze the most out of the slow and expensive leased lines
available in 1969. Its internal protocols and congestion control techniques
were designed to squeeze the most out of the expensive, memory-poor
computers available in 1969.  It was an excellent computer network -- for
1969.  Unfortunately, much of this simply can't scale in its present form to
where it can effectively utilize the new economies of scale in transmission.

Making decisions about the future of networking by comparing the "operating
costs" of ARPANET and MILNET to GTE Telenet is dangerous. For one thing,
Telenet was also built on 1970's technology and protocols.  Also, its users
pay *real money* depending on how much traffic they send.  Unlike the
ARPANET/MILNET, Telenet's primary use is as a nationwide "remote terminal
concentrator", with the vast majority of users dialing into X.3/28/29 PADs
with dumb terminals and connecting to timesharing hosts. Their only
alternative is to dial a direct long distance call using AT&T or MCI or
whatever, and Telenet is well aware of this;  they price their service
accordingly.  Anyone who tries to use it for computer-to-computer
internetworking (as we do through CSNET/X.25NET) finds out VERY quickly just
how expensive this can be. The circuit-switched mentality is deeply
ingrained in Telenet's internal design; at least with the DDN, X.25 is kept
on the edges, making it at least theoretically possible to escape its
braindamage.

In deciding where to spend future bucks, I think it would make a lot more
sense to look at newer technologies.   Because the transmission guys have
leapfrogged so far over the switching guys, a radical change in mindset is
in order.  It simply doesn't pay anymore to worry about efficient PSN buffer
utilization, 100% delivery reliability, packet header overhead, finding the
most optimal routes, or load splitting if doing so takes so much CPU time
that you can't drive fast links at full speed.  At present, only link-level
bridges like the Vitalink Translan III seem able to switch packets quickly
enough to drive a T-1 link to 100% utilization on small packets; if somebody
can do this with an X.25 switch or IP gateway I would like to know about it.

Phil

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Mar-87 23:09:53 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Station wagon full of bits

Geof,

Recalculate using compact-disk ROMs and Federal Express. The ARPAfolks
calculated back in the late sixties that it would be cheaper to send
a pagefull of text via the ARPANET than as a first-class letter. On
the other hand, for bulk data larger than a megabit, the cheapest way
was an airmailed magtape. Maybe one of the original Buzzards might
certify and maybe update my recollections.

Dave

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Mar-87 01:14:24 EST
From:      jbvb@BORAX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   UCLA TN3270 negotiation

Could someone familiar with the UCLA ACP tell me at what point in
the connection/login sequence it first negotiates 3270 mode (Term
Type, EOR and Binary)?  I have tried connecting to an UCLA MVS
Arpanet machine, but negotiation didn't seem to take place on
connection open (unlike WISCNET), and I didn't have an account,
so I haven't been able to proceed further.  Is my code broken,
or do I have to log in to really test it?

jbvb@ai.ai.mit.edu
James B. VanBokkelen
FTP Software Inc.
(617) 868-4878

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Mar 87 08:54:54 EST
From:      tsuchiya@mitre-gateway.arpa
To:        ddp#@andrew.cmu.edu, tcp-ip@sri-nic.arpa
Cc:        x3s33-interest
Subject:   Re:  danger of bridges
>  Date: Tue, 24 Mar 87 22:45:50 est
>  From: ddp#@andrew.cmu.edu (Drew Daniel Perkins)
>  To: tcp-ip@sri-nic.arpa
>  Subject: danger of bridges
>  Status: R
>  
>  
>  
>  And then there's DECnet.  I won't claim to be a DECnet expert, but from my
>  observations it appears to me that all Phase IV DECnet hosts connected to an
>  ethernet transmit HELLO multicast messages every 15 seconds.  These of course
>  all pass through the bridge or else intra-area routing wouldn't work.  We
>  have somewhere around 100 DECnet hosts connected to our backbone ethernet
>  system.  Dividing these two numbers I expect to see about 6 HELLO's a second
>  on the net.  Using PCIP NETWATCH I indeed measured 5 per second.  Of course,
>  this is with only 100 hosts.  Doing the same calculation with 1000 hosts one
>  would see 66 HELLO's/sec.  2000 hosts would yield 133/sec, 4000 hosts would
>  give 266/sec.  Can you imagine EVERY DECnet machine on a network processing
>  266 routing packets/sec?  I sure wouldn't want to try to get work done on
>  such a machine.
>  
>  To summarize, level 2 bridges are very useful, but you have realize that they
>  are not the perfect solution.  You have to keep their limitations in mind.
>  There are very good reasons for having level 3 routing.
>  
>  Drew
>  
>  
>  

I should hope that the situation is not this bad, especially since x3s33
ES-IS (host-gateway) routing protocol uses a similar HELLO scheme.  Although
I am also not a DECNET expert (or even novice, for that matter), I'm would
be EXTREMELY suprized if the HELLO timer was not settable, meaning that
for crowded networks, it could and I assume normally would be set
to greater than 15 seconds.  Second, host HELLO's typically go to gateways,
not other hosts, so every host doesn't need to process every host
HELLO, just gateway HELLO's.  There should be much fewer gateways than
hosts.

Paul (no I don't work for DEC) Tsuchiya

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Mar-87 10:51:09 EST
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        mod.protocols.tcp-ip
Subject:   appelseeds/fortnight

Marvelous!!

dennis
-------

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Thu 26 Mar 87 10:51:09-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        CERF@a.isi.edu
Cc:        imagen!apolling!geof@decwrl.dec.com, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   appelseeds/fortnight
Marvelous!!

dennis
-------
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Mar-87 11:39:17 EST
From:      Rudy.Nedved@H.CS.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: network horror stories

Phil,

I agree with your points alas certification seems to be something like
program verification, it only works on small test cases. With comments
from things like Jan 1987 ACM SIGOPS section on MIT Project Athena,
"Firewalls in gateways are neccessary" and my own experiences, I believe
it is up to the routers, bridges and gateways to control congestion and
ignore brain damaged hosts.

I would suggest that an implementation be beat on for some type of
certification before being released but experience has shown that the
imagination of the attackers/testers is more conservative then the ever
changing network enviroment....something always shows up later. Therefore,
the two prong approach of doing constructive/definitive tests and putting
firewalls into gateways is the way to go.

For firewalls, adding hysteresis to gateways, bridges and routers tied
in with the volume of datagrams from a host or network should help even
though it would penalize highly used paths...these paths are having
severe problems as it is...this will encourage more efficient use of those
paths....especially if every relaying agent does it. For relay agents on
"dedicated" networks the hysteresis would be very heavy for datagrams not
to or from dedicated network clients.

When congestion occurs, the clients that want to send the once and a while
important message would succeed but the clients that generally send lots
of communication in an inefficient manner would be penalized....this is a
more desirable behaviour then everyone who tries gets penalized.

Lastly, communicating back to entry gateways that some client is being nasty
and should be ignore would reduce gateway to gateway congestion just like most
of the telephone companies have the prefix for remote areas stored locally to
reduce trunk line usage from wrong numbers...if you dial 412 333 XXXX in 201
area then 201 area will not even try the connection, it will indicate that
number is incorrect and a telephone book should be consulted. Alas,
propagation of this information has the same problems as propagating routing
information....sigh.

Cheers,
-Rudy

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Mar-87 12:19:24 EST
From:      solomon@CRYS.WISC.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: crystal!solomon
From: solomon@crys.WISC.EDU (Marvin Solomon)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Station wagon full of bits
Summary: There's more to data communication than bits/second.
Message-ID: <291@crys.WISC.EDU>
Date: 26 Mar 87 17:19:24 GMT
References: <VAX-MM(195)+TOPSLIB(124).25-Mar-87.20:55:50.VAX.DARPA.MIL>
Organization: U of Wisconsin CS Dept
Lines: 31


Vint Cerf has pointed out one pitfall in trying to use a single number
to compare very different technologies:  One must consider not only
bandwidth, but also latency.  But all the discussion on this topic so
far has failed to note that the information-carrying capacity of a
station wagon full of tapes (or a knapsack full of CS's, or whatever) and a
56Kbps leased line have different dimensions!  Vint's "Johnny Appleseed"
has units capacity*velocity = bits*length/time, whereas a communications line
is measured in bits/time.  Thus, to compare the two, one has to mention the
distance.  The problem we are considering was posed by Jon Bentley in his
delightful Programming Pearls column, "The Back of the Envelope" in the March
1984 issue of "Communications of the ACM":

	At what distances can a courier on a bicycle with a reel of magnetic tape
	be a more rapid carrier of information than a 56-kilobaud [sic] telephone
	line? Than a 1200-baud line? [op cit, p. 182]

The answers (based on considerably more realistic estimates about magnetic
tape than have been bandied about in this forum, by the way) are,
respectively, 20 miles and the distance the cyclist can travel in a week.
The point is that a communication line can beat ANY bulk transfer over
sufficiently long distances.  Of course, we can effectively cut off discussion
at (say) the diameter of the earth.

To summarize:   The advantages of networking are both low latency and
distance-independence.
-- 
	Marvin Solomon
	Computer Sciences Department
	University of Wisconsin, Madison WI
	solomon@gjetost.wisc.edu or seismo!uwvax!solomon

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Mar-87 12:29:41 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Station wagon full of bits

Vint,

Yeah, that's the kind of model I was fishing for. But, now you have to consider
the energy input to the system, which depends on the weight of the knapsack.
Ordinarily, we don't worry about that in the ARPANET, since the total energy
input (watts and bucks?) is first-order independent of the bits carried.
Therefore, I submit a more relevant measure might be microjoules/appleseed.
At least Johnny left some trees in his wake.

A long time ago while working my way through school as a disk jockey, I
tossed off a calculation on the total length of the record grooves played
throughout the day (about 100 miles). The station manager liked it so much
he asked me to work the idea into a promo spot, which I did. The idea
caught on and was copied by other local stations as well. It seems the
issues can often be exposed effectively by outrageous changes in the
assumptions and then working through the logic anyway to see if it all
fits.

Okay, I promise to shut up.

Dave

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Mar-87 14:43:12 EST
From:      GROSSMAN@SIERRA.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

I did a few calculations of the bandwidth of Wagonnet, and heres what I
came up with:

The most readily available magtape technology happens to be 2400' reels.
These have a common maximum density of 6250 bytes/inch.  This results in
a value of 6250*12 = 75000 bytes/foot, and therefore we get 75000*2400*8 =
1.44e9 bits/tape.  Now, your average 2400 foot reel is about 10.75 inches
in diameter by 1 inch high, so (squaring off the corners) you get a volume
of 115.6 cu inches/tape, and therefore you can get 12^3/115.6 = 14.98 tapes
per cubic foot.  This amounts to (rounding up to whole magtapes) 15*1.44e9=
21.6e9 bits/cu ft.  Now, your typical station wagon holds anywhere from
30 to 65 cubic feet of stuff.  I'll presume that this station wagon is
large, since it has to deal with Bitnet.  Therefore it holds 65*21.6e9=
1.404e12 bits/station wagon.

Now, at a rate of 55 mph (I don't want to break the law), this station
wagon can get across the country in 3000/55 * 3600 +10% = 216000 seconds.
The 10% is for dealing with changing drivers, food amd gas stops, etc....

This results in a baud rate of 1.404e12/216000 = 6.5e6 bits/sec.  This is
comparable to typical Ethernet thoughput with a good controller and few
collisions.  Of course, this network has the advantage that congestion
doesn't make it lose data.  It just gets there kinda slowly.  However,
the RTTs are rather long (on the order of 216000*2= 5 days.

But despair not, there's some hope!  If congress raises the speed limit to
65mph, then the typical RTT will be reduced to a mere 3.8 days.  You could
probably convince congress that it would be in the best interests of national
defense to do this!

Note that a speed limit of 216 million mph would result in a much more
reasonable RTT on the order of .1 seconds!

			Stu Grossman
-------

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Mar-87 14:51:36 EST
From:      gross@GATEWAY.MITRE.ORG.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

Bob,

You've been scooped.  There has already been a proposal involving a 747.
Naturally, it's called....  Jumbo-net.

Phill

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Mar-87 15:20:26 EST
From:      karn@FLASH.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Response to anti-bridge comments

As one who has just helped construct a "large" bridged network, I think a
few comments based on actual experience might be useful.

First, a description. Bellcore has five major locations in north central New
Jersey.  We lease T1 circuits organized as a star with the hub at
Piscataway, the geographically central location.  These circuits are divided
down with synchronous multiplexors into various sized channels for things
like Micom terminal switch trunks and IBM RJE links.  At the moment, 256
kbps of this capacity connects a set of five Vitalink Translan IIIs as a
star with the hub at Piscataway.  Each of these boxes also connects to the
building-wide backbone Ethernet at its location, thus bridging the locations
together at the link level. Within each location almost all of our Ethernets
are bridged with DEC LanBridge 100s, with the fiber version interconnecting
multiple buildings at a location.  At last count, the routing tables on the
Translans showed something like 600 active hosts. Virtually all of these
hosts speak DoD IP; most are 4.2BSD derivatives. A few Symbolics machines
speak Chaosnet.  As far as I'm aware we have no DECNET or XNS traffic, other
than that spoken by the Translans and LanBridges themselves.

And it all works, and works well!  I hardly ever look at the boxes anymore.
We had one infant mortality after we installed them in late December: a
power supply died after 24 hours in operation. Vitalink immediately shipped
out a replacement which arrived a day later, and the boxes have all been
solid since.  Two other outages were due to people kicking out Ethernet
cables, but this is a generic Ethernet problem and isn't Vitalink's fault (I
do hope they'll come out with screw-on connectors, though).  With our switch
to bridging, the reliability and availability of intra-company networking
has improved enormously over what it was when we used general purpose UNIX
machines (VAXes and Sun fileservers) as IP gateways.  True, it's a bit
unfair to compare standalone boxes with general purpose systems with disks
that must also do other things.  But there were enough RIP/routed screwups
that once I seriously considered running everything with static routing.
Even now our remaining IP routers get screwed up occasionally and they have
to be restarted.  But at least when this happens it doesn't affect our
intra-company communications, which are most important.  And nobody has to
renumber their hosts when they move from one physical cable to another,
which is an ENORMOUS practical advantage in a place as big as this one.

All this is not to say we haven't had our problems.  I do monitor the ARP
broadcast traffic from time to time.  We generally see 1-2 per second, which
is expected and entirely acceptable. If you see 20 per second, then you've
got something wrong somewhere.  I've found that bursts of ARP requests are
usually caused by hosts who respond inappropriately to UDP broadcasts to
bogus IP addresses. The trigger is generally a Microvax, since Ultrix 1.2
allows you to set the net mask and the broadcast address, thereby allowing
you to get it wrong.  (I just can't wait until Sun also supports subnetting
and broadcast address selection).  Although the problem clearly gets worse
as you build larger bridged networks, YOU CAN'T BLAME IT ON BRIDGING!!!  If
there weren't so many broken TCP/IP implementations out there the problem
wouldn't exist in the first place.  Nevertheless, my usual tactic has been
to place an entry in the appropriate Translan to isolate the offending host
until the user can fix it; this "twit listing" feature is very helpful.

You discover other interesting things when you build a large bridged
network.  For example:

1. It seems that every CCI Power 6 machine as shipped comes with the same
Ethernet address. We didn't notice until we started bridging networks
together, but you can't exactly blame it on the use of bridging.

2. Some older 4.2 machines seem to respond inappropriately with wrong
answers to RARPs from Sun workstations, keeping them from booting.

3. We made an aggressive effort to turn off rwho daemons, bringing UDP
broadcasting to an acceptable level. (Many people find this necessary even
when bridges aren't used). With fewer IP gateways, the amount of RIP traffic
has stayed fairly modest.

4. Pyramids seem to respond to every ARP request they hear, regardless of
whether they were the target or not. Fortunately they respond with correct
(but irrelevant) information, so this is just a minor annoyance.

You can just as easily have antisocial machines with these problems on the
same physical cable; the solution is to FIX them, not throw up your hands
and say "bridges are terrible" because they force you to confront the
software vendors.

Overall, our experience with bridging has been quite positive.  There are
some valid arguments against large-scale bridging, but they have to do more
with vulnerability to spoofing than with any inherent technical weaknesses
in a "friendly" environment such as ours.  Even in a heterogeneous
environment, though, Vitalink boxes are useful as simple, fast packet
switches because they can be configured to filter out broadcasts and to use
static routing tables. I understand that NASA Ames uses them in this way.

I'm a big believer in TCP/IP.  IP does the job of interconnecting dissimilar
networks so well that some people forget that there are easier ways to
connect networks of the same type.  The Internet has grown so large that the
job needs to be broken down hierarchically into more manageable pieces; you
can't (and shouldn't try to) do EVERYTHING with IP gateways.

Phil

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Mar-87 20:25:57 EST
From:      gds@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

Instead of using wagons, why not contract a moving company (e.g. Allied,
NorthAmerican) to do this?  We might be able to get cheaper rates with
the moving companies than to contract out a set of drivers and their
wagons.  I would imagine the lifetimes of these wagons would be small
relative to the lifetimes of moving vans (not many cars last through
extensive heavy moving).  Plus, the routes the van lines use are already
set up, and probably parallel the cross-country trunks.

We will be able to get much better bandwidth (I'm assuming the capacity
of a moving van to be at least 10 times that of a station wagon), less
overhead involved in switching drivers (they make a living out of doing
this so they know how to switch with minimum delay), more bits/driver
(they are trained so they need less sleep).

Let's use planes to fly the transcontinental links.  They're not quite
so good for transmission within a continent (case in point:  you can't
land one at an imp :-).

--gregbo

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Mar-87 20:31:35 EST
From:      martillo@ATHENA.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   X.25, X.31 vs Q.921/Q.921 and Networking Style in General


I have received a suggestion to move a discussion from a UUCP netnews
to this mailing list.  I am also not on this mailing list and would
like to be added.


Path: bacchus!martillo
From: martillo@athena.mit.edu (Yakim Martillo)
Newsgroups: comp.dcom.lans,comp.dcom.modems
Subject: X.25, X.31 vs Q.921/Q.921 and Networking Style in General
Message-ID: <363@bacchus.MIT.EDU>
Date: 23 Mar 87 02:00:13 GMT
Sender: daemon@bacchus.MIT.EDU
Reply-To: martillo@athena.mit.edu (Yakim Martillo)
Distribution: net
Organization: MIT Project Athena
Lines: 136
Xref: bacchus comp.dcom.lans:180 comp.dcom.modems:269

I am working on getting a proprietary data communications system to
work over ISDN primary and basic rate interfaces.  The system was
originally designed to use only PSDN (PDNs) as the communications
subnet.  An end to end protocol was never designed so that individual
applications have their own end to end protocols.  Eventually, the
developers put the communications system over a proprietary token
ring and ethernet, as well as point to point leased lines.  

Since they wanted to modify the networking software as little as
possible, they basically used a slightly modified version of X.25
level 2 for the token ring (running on top of the token rings datagram
protocol) and ran X.25 level 3 on top of it.  On ethernet they
substituted 802.3 for X.25 level 2 and ran X.25 level 3 on top of
that.  And for point to point leased lines they run straight X.25.  Of
course, they had some sort of procedure whereby one party becomes the
DCE and the other party becomes the DTE.  Thus X.25 has basically
become the end to end transport protocol in the network unless a PSDN
is the communications subnet.

Now they want to put their network over ISDN using LAPD, LAPB, X.25
level 3, X.31 with Q.931/Q.921 signaling and I see problems with how
people use the X.25 family of protocols and what Q.931/Q.921 seems to
provide.  

Full Q.931 seems to allow for "hold" (via hold, suspend resume
signaling messages) on a given CSC (Circuit-Switched Circuit), and in
fact I think I really want to do this because I could easily see an
individual user using 3 CSCs or more for a given session (e.g. remote
terminal session from A to B, while on B doing a remote copy from C to
B -- the user could easily be taking up 3 CSCs).  With an average of
40 users on the machine with a full-blown remote file system and RPCs
(Remote procedure calls), I think it is fairly easy for even a PRI to
get fully loaded really fast, and I would want the PBX to send
indication of incoming calls even when there are no available
channels, so that the controller could put one call on-hold and then
accept the new call.  For outgoing, if there are no channels available
I would like to put one call on hold and then place the new outgoing
call, and then round-robin (with prioritization for calls which have
outgoing data) the calls on the available channels.

In the case of a (2B+D or 1B+D) BRI on a workstation, the scenario
described above becomes even more problematic.

The problem comes in with X.25 restart and rest procedures as outlined
in the redbook and as typically implemented.

Deasington says in X.25 Explained (p.52) says:

The restart procedure is used to ensure that both the DCE and DTE
consider that all the PVCs and SVCs are in a known state.  A restart
causes all PVCs to be reset and all SVCs to be cleared and free to be
used.  The Network level will need to be restarted if the Link level
has failed for some reason, for example the line between the DTE and
DCE was disconnected.  If the Link level has timed out and has been
restarted by the exchange of SABM, UA, etc., as previously described,
the Network level will be restarted by the DCE sending to the DTE a
Network level Restart Indication frame; in PSS the Restart Indication
frame will be sent to the DTE  at intervals of six seconds until a
Restart Confirmation is received.  The DTE may at any time transmit a
Restart Indication to the DCE if it needs to restart the Network level
completely, for example if it has completely lost track of the state
of the active SVCs.

According to the X.25 specification, resets should be generated on VCs
if data has been lost or a protocol error has occurred.

I have no problems with either restart or reset procedures as long as
disconnection of level 2 is not considered a protocol error because I
don't intend for my hosts to loose data in this case and I can set up
the following scenario:

1) non-alien host (i.e one of my hosts which form a part of my
   contractee's proprietary network) connects to non-alien host.

2) calling party exchanges XID with called party,
   establishes calling party as DCE and establishes
   automatic call-back in the event of disconnections while
   VCs are still active (sometimes CSCs just drop).

3) Level 2 gets connected.  DCE does a network level restart.

4) VCs get started and normal data communications proceeds.

5) Called or calling party interface fills and incoming call arrives,
   Called or calling party interface selects channel to put on-hold 
   (probably least-recently used algorithm), and stat muxes the active
   calls among physical channels.  

6) Possibly, the level 2 of one of the calls on hold times out and
   becomes disconnected, when the call goes off-hold.

Now from the above in Deasington, apparently many PSPDNs automatically
restart the interface upon disconnection of the logical link under the
assumption this means the foreign interface had been turned off.  I
think in the case of hold this should be utterly unnecessary and the
level 2 should just be reconnected transparently to the level 3.

6) Alternatively, the call drops for unspecified reason, the DCE
replaces the call, reconnects the link-layer, but does not restart the
network interface.

7) Eventually the number of VCs on the link goes to zero.  Level three
on both hosts requests to controller to disconnect the logical level 2
and then to disconnect the call.

In the case of alien hosts who do not understand the proprietary
protocols, the alien host is always the DTE and the non-alien host is
always the DCE.  Hold and auto-redial could be negotiated in the XID
but I would tend to make the default to disallow hold and neither
expect nor perform auto-redial in case of disconnect but rather inform
level 3 of termination of level 2 so that the VCs could be abnormally
terminated from the host point of view.

When one of my hosts calls a PSDN or is called by a PSDN, the PSDN
would of course be the DCE while my (non-alien) host would be the DCE.
Procedures about hold and auto-redial would be negotiated with the
PSDN at subscription time and could be exchanged in the XID.

To me this all seems like a perfectly reasonable way to do data
communications via ISDN (I mean real resource sharing not kermit)
however all the network "experts" at my employer totally freaked at my
suggest and scenarios.

I would like opinions.  If you comment, I would be interested in your
background and experience because I guess I am conducting a survey and
I would like to have some sort of guide to weight opinions.  If you
prefer, you may send your comments to me by private mail at
		
			martillo@athena.mit.edu
			..!ihnp4!mit-eddie!athena!martillo

If there is desire, I can post the results to the net.

Yaqim Martillo


Path: bacchus!mit-eddie!rutgers!ames!ucbcad!ucbvax!ucbarpa.Berkeley.EDU!fair
From: fair@ucbarpa.Berkeley.EDU (Erik E. Fair)
Newsgroups: comp.dcom.lans,comp.dcom.modems
Subject: Re: X.25, X.31 vs Q.921/Q.921 and Networking Style in General
Message-ID: <17977@ucbvax.BERKELEY.EDU>
Date: 23 Mar 87 13:20:42 GMT
References: <363@bacchus.MIT.EDU>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Michael A. Padlipsky Fan Club
Lines: 6
Xref: bacchus comp.dcom.lans:182 comp.dcom.modems:270

Do the obvious thing: chuck it all and use the DoD Internet Protocol
suite for this application. It is certainly clear that you need some
sort of transport that makes no assumption about the reliability of
the data link layers, and the X.* stuff doesn't seem to qualify.

	Erik E. Fair	ucbvax!fair	fair@ucbarpa.berkeley.edu

Path: bacchus!martillo
From: martillo@athena.mit.edu (Yakim Martillo)
Newsgroups: comp.dcom.lans,comp.dcom.modems
Subject: Re: X.25, X.31 vs Q.921/Q.921 and Networking Style in General
Message-ID: <366@bacchus.MIT.EDU>
Date: 25 Mar 87 02:40:13 GMT
References: <363@bacchus.MIT.EDU> <17977@ucbvax.BERKELEY.EDU>
Sender: daemon@bacchus.MIT.EDU
Reply-To: martillo@athena.mit.edu (Yaqim Martillo)
Organization: MIT Project Athena
Lines: 77
Xref: bacchus comp.dcom.lans:189 comp.dcom.modems:277

In article <17977@ucbvax.BERKELEY.EDU> fair@ucbarpa.Berkeley.EDU (Erik E. Fair) writes:
>Do the obvious thing: chuck it all and use the DoD Internet Protocol
>suite for this application. It is certainly clear that you need some
>sort of transport that makes no assumption about the reliability of
>the data link layers, and the X.* stuff doesn't seem to qualify.

While I have enjoy Padlipsky's writing, you have missed the point (or
I have accidentally mislead you), the X.25, X.31, LAPD, Q.921/Q.931
suite of protocols is not comparable to TCP/IP but is rather
comparable to 1822. The ISDN switch is basically comparable to an IMP
(or PSN nowadays I guess).  One might argue about the virtual circuit
orientation of the X.25 but in fact an ISDN switch is much more
complicated than an IMP and you really need something more complex
than 1822.  As for the circuit orientation, from personal experience
in dealing with the FCC, I believe tariffing a reliable virtual
circuit access protocol in which the remote end point is specified is
much easier than tariffing an access protocol like 1822.  Of course,
the existence of a level 3 reset is relatively stupid in a virtual
circuit oriented access protocol, but the level 3 reset was *demanded*
by the PDNs because of the limitations of their switches.

Running TCP/IP on top of X.25 is just as reasonable as running TCP/IP
on top of 1822 but as far as the PTTs and the private long distance
carriers are concerned, they have no interest in an internetting layer
or a transport layer built on top of it.  A true internetting layer
makes tail-end-hop-off (popping in and out between public and private 
networks where the two end point are accessing the catenet via public
phone lines in order to decrease phone bills) and such a specification
will never come out of CCITT.  

Now the proprietary network on which I am working was developed before
the modern TCP/IP based Arpanet came into existence.  As I understand
it the pre-TCP/IP Arpanet basically used a predecessor of 1822 as an
end to end protocol, so that my contractee's decision to go with X.25
as the network communications protocol was not unreasonable especially
given that the major portion of their business is overseas where until
recently no one did TCP/IP.  Of course not learning anything from the
Arpanet experience is pretty close to criminal but the company is
being punished in its sales, so justice is being served.

Granted, there is no real reason to run X.25 on an unrestricted
digital 64kbps CSC bearer channel except that the CSC may equally
probably be going to a PSDN as to one of the proprietary network hosts
where one of the network hosts is acting as the DCE and pretends to be
a PSDN.  This is reasonable because if some other manufacturer
supports some service via a PSDN, my contractee can directly offer
that service to the other manufacturer's equipment because my
contractee's equipment can pretend to be a PSDN.

But my contractee is also trying to sell real data communications via
a ISDN-PBX-LAN and my feeling is that while the network hosts can
pretend to be PSDNs, among friends (non-alien hosts), the host that
pretends to be a DCE does not have to imitate the non-obligatory
procedures which PSDNs use like VC reset, some of the network-level
restarts, the various worthless level 3 DCE timers.

If they do complete imitation of the PSDN non-obligatory procedures, a
CSC based ISDN-PBX-LAN running the proprietary data communications
network should quite quickly become fragmented into topologically
disconnected islands of network connectivity with evil consequences
like dead-lock, loss of network services and inability to use to use
some of the niftier features of Q.921/Q.931 [of course maybe they are
trying to prevent the ultimate convergence of phone and computer
hacking :)].

I would really like some genuine X.25/PSDN expert to tell me my
suggestion is perfectly reasonable and is in fact the right way to do
data communications in the environment of a CSC based ISDN-PBX-LAN
using the X.25 suite of protocols.  Of course, if I am wrong I would
like to be told and be told why.  The network-expert at my
contractee's has yet to show any understanding of data communications
at a level more sophisticated than that of a PAD.

Yaqim Martillo

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Mar-87 02:33:23 EST
From:      rpw3@amdcad.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

If you use 6250 fci, 2400' tape, and long records, you can get
about 80% use of the tape, or 144 Mbytes. Adds ANOTHER factor
of 3, so the original posting was about an order of magnitude low.

Incidently, given the volume of stuff that is seen on USENET (over
1 Mbyte/day, now), and the size of some of the phone bills, the
typical transport delay, and the fact that priority (2-day) mail
is fairly cheap, mailed magtapes (small ones) or floppies really
SHOULD be considered as a way of distributing netnews!


Rob Warnock
Consultant

UUCP:	{amdcad,fortune,sun,attmail}!redwood!rpw3
ATT:	attmail!rpw3
DDD:	(415)572-2607
USPS:	627 26th Ave, San Mateo, CA  94403

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Mar-87 08:24:08 EST
From:      DYOUNG@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP/IP/IBM/Pronet

Does anyone have any experience using TCP/IP on an IBM 4381 connected to
a Proteon ProNET?  Any pointers would be useful.

David
-------

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 1987 08:24:08 EST
From:      C. David Young <DYOUNG@A.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        DYOUNG@A.ISI.EDU
Subject:   TCP/IP/IBM/Pronet
Does anyone have any experience using TCP/IP on an IBM 4381 connected to
a Proteon ProNET?  Any pointers would be useful.

David
-------
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Mar-87 10:56:11 EST
From:      ahill@CC7.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Fact or fiction

Darrel,
	I'll take a crack at answering your knowledgable inquiries.

Basic X.25 allows multiple VCs between a given host pair.  Each VC gets its
own connection at level 3.  X.25 traffic is encapslated in 1822 and delivered
to the subnet.  The traffic is subject to 1822 restrictions.  All traffic
between host pairs is on one dynamic subnet connection.  X.25 acts like
a software host so 1822 delivers the encapslated data to X.25 which handles
the L3 connection control.

Your understanding of Standard X.25 is correct.  The answer to your question
is Yes.

	IOP strives to do the reasonable thing about hardware padding on
messages.  BBN believes that there was a problem during the early days
of IOP but the software has been corrected.  If this is not the case I
hope people will speak up and let us know.

	PSN 7.0 will make significant changes in the way X.25 traffic
is handled as well as major modifications to the subnet E-E.  X.25 and
AHIP (1822) will be handled as peer protocols thus elimnating the
need for IOP and significantly improving X.25 performance.  RFC978 might
help you understand some of the features of PSN 7.0.

Regards,
Alan

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Mar 87 10:56:11 EST
From:      "Alan R. Hill" <ahill@cc7.bbn.com>
To:        AFDDN.TCP-IP@gunter-adam.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Fact or fiction
Darrel,
	I'll take a crack at answering your knowledgable inquiries.

Basic X.25 allows multiple VCs between a given host pair.  Each VC gets its
own connection at level 3.  X.25 traffic is encapslated in 1822 and delivered
to the subnet.  The traffic is subject to 1822 restrictions.  All traffic
between host pairs is on one dynamic subnet connection.  X.25 acts like
a software host so 1822 delivers the encapslated data to X.25 which handles
the L3 connection control.

Your understanding of Standard X.25 is correct.  The answer to your question
is Yes.

	IOP strives to do the reasonable thing about hardware padding on
messages.  BBN believes that there was a problem during the early days
of IOP but the software has been corrected.  If this is not the case I
hope people will speak up and let us know.

	PSN 7.0 will make significant changes in the way X.25 traffic
is handled as well as major modifications to the subnet E-E.  X.25 and
AHIP (1822) will be handled as peer protocols thus elimnating the
need for IOP and significantly improving X.25 performance.  RFC978 might
help you understand some of the features of PSN 7.0.

Regards,
Alan

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Mar-87 11:38:45 EST
From:      ms6b#@ANDREW.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Station wagon full of bits

In their classic article published in 1970*, Roberts and Wessler compare the
cost per megabit for a variety of transmission media including mailing an IBM
tape.  (Which was lower by an order of magnitude than any
other medium.)

*"Computer network development of achive resource sharing," Proceedings of
the AFIPS Spring Joint Computer Conference, vol 36, May 5-7, 1970 pp.
543-549.

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Mar-87 12:36:12 EST
From:      braden@ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  UCLA TN3270 negotiation


	
	Could someone familiar with the UCLA ACP tell me at what point in
	the connection/login sequence it first negotiates 3270 mode (Term
	Type, EOR and Binary)?  I have tried connecting to an UCLA MVS
	Arpanet machine, but negotiation didn't seem to take place on
	connection open (unlike WISCNET), and I didn't have an account,
	so I haven't been able to proceed further.  Is my code broken,
	or do I have to log in to really test it?


James,
	
Well, yes, I can tell you.  Too bad you did not go to the TCP/IP
Interoperability Workshop in Monterey last week; Greg Minshall
gave a whole session on IBM 3270 support, and I described the rules for
negotiation into fullscreen mode.

Basically, VM uses a less-than-general approach to fullscreen
negotiation because of restrictions in that operating system's virtual
terminal machinery.  If you simply connect to a UCLA MVS system with a
normal Telnet NVT, you will understand the problem.  It does not
negotiate fullscreen mode until it is able to determine that the
particular service subsystem of the host to which you actually want to talk
handles fullscreen mode.  EG, if you "logon" to TSO, it will then
try to negotiate full screen; when you logoff TSO, it will return you
to NVT mode, etc.

Since this topic is probably not of general interest, and has been
somewhat beaten to death in the past, I suggest we take any further
discussion on this off the mailing list.

Bob Braden

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Mar-87 12:53:49 EST
From:      HOSTMASTER@SRI-NIC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Wollongong VMS V4.2

To all those running Wollongong VMS V4.2 which does not handle
domain-style naming:

All customers under support can get a copy of the fixed mailer
(tape) from Wollongong.  The product manager at Wollongong
has said that all DDN customers have been "automatically identified."

TCP/IP customers should have or will get a letter from Wollongong 
about the fixed mailer.

If you are not under support, have not been notified either by letter or
other means, and need to get a copy of the tape, please call (415)
962-7140 for assistance.  This number is the Wollongong support line.

-NIC hostmaster
-------

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Mar-87 13:45:10 EST
From:      mckee@MITRE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

This note is from Steve Silverman "m15368%mwvm@mitre.arpa"
He's not on the tcp-ip mailing list.  We have some kind of weird
lash-up here at MITRE with a curious lack of transitivity:
Steve can send to me; you and I can send to Steve, but Steve can't
send to you.  Anyway .....
________________________________


To: KARN%FLASH.BELLCORE.COM     
From: Steve Silverman
Subject: future networks
I just received a copy of your message of 3/25 on future nets.  I agree
with you and the current direction of network evolution as developing
in T1D1 and SG XVIII supports what you said.
     
Frame relay uses LAPD on each end with the transit switches just relaying
the frames.   This allows very low transit delay and high capacity switches.
AT&T is supposedly testing a megapacket/second switch.  The Bellcore
contingent at T1D1 is fairly active in this.  Do you know Kaj Tesink?
(I don't know how to spell his name but I think he works for Joan LaBanca.)
(Kaj rhymes with sky.)
     
Frame Relay is a complete violation of the OSI model but nobody wants to
admit it.  In my view, the fiber-optic explosion has invalidated the
details of the OSI model.  The FO error rate is low enough that it no longer
pays to do error checking and retransmission on a link by link basis.
     
I think that the deployment of ISDN equipment in the 88-91 timeframe will
will be a major shock to the current networking world.  Running layer 2
end to end will make layer 3 redundant.  (Except we are moving some of the
layer 3 functionality into Q.931 (the call control protocol).)
     
Most of the data networking world is oblivious to ISDN.  I still hear
statements that it won't happen until the next century.  I think that
by 1990, ISDN will be in serious use in many places.
     
Steve Silverman 

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Mar-87 16:20:58 EST
From:      haas%utah-gr@UTAH-CS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

In article <8703250201.AA06443@flash.bellcore.com>,
karn@FLASH.BELLCORE.COM (Phil R. Karn) writes:
> ... I understand that
> each GTE Telenet node speaks X.75 to its neighbors, making it an unlayered
> VC network.  Because of this, a node or link failure ANYWHERE along the
> connection path causes an X.25 VC reset, not just failures at the end nodes.

Not entirely correct.  The interface protocol X.25 is not affected if
an intermediate TCO fails, since the endpoint TCOs will reestablish the VC
(if possible) via an alternative route.  The hosts will see a VC reset
only if one of the two endpoint TCOs fails.  Tymnet does the same thing
by a similar mechanism.

Cheers  -- Walt

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Mar-87 16:38:38 EST
From:      haas%utah-gr@UTAH-CS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: network horror stories

One of the more interesting but little-discussed events in the
history of network engineering occured when Telenet converted
from unreliable-datagram internal architecture to VC internally.
For a good discussion of the whys and wherefores of Telenet internal
architecture see a paper entitled "An X.75 Based Network Architecture"
by D. F Weir, J. B. Holmblad and A. C. Rothberg published in the
"Proceedings of the Fifth International Conference on Computer
Communications", 1980.  If you don't feel like chasing the Proceedings
around the library Telenet will probably give you a free copy of the
paper.

The justification for ripping out the datagram code and replacing it
with VC code was economic.  There is less waste and better management
of the resource in a VC network.  I quote from the cited paper:

 "... in the late 70's it became economically attractive to incur
  additional processing and storage costs in order to reduce
  communications costs...

  ... By establishing fixed paths, virtual circuit routing can
  better balance load as compared with routing in a datagram based
  network ... congestion at a transit point in a virtual circuit
  network can be reflected back to the endpoint nodes to restrict
  flow into the network.  This capability results from access to
  the virtual circuit at transit nodes using the logical channel
  number.  In a datagram network, knowledge of virtual calls does
  not exist at transit nodes and flow control cannot easily be
  applied to the virtual circuits at the endpoints."

Cheers  -- Walt

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Mar-87 20:58:56 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  network horror stories

Rudy,

You are referring to what are called "hard-to-reach" (HTR) numbers. Clever
switches remember HTR prefixes in order to back congestion up towards the
source. Now consider doing the same thing in an IP gateway. All it has to
do is wiretap ICMP messages on the way back to the sender and cache the
information for awhile. You may remember the general reaction (horror)
in response to this suggestion some time back. Many consider wiretapping
ICMP messages something only a little less sinful than forwarding
redirects across gateways. Considering the almost universal practice
of ignoring ICMP error messages, perhaps your comment may spark a minor
change in that thinking.

Dave

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Mar-87 23:21:51 EST
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Need Info on SMTP

Calvin, you might check with Los Alamos.  They have an All-in-one 
connection to unix mail which seems to work.

dennis
-------

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Fri 27 Mar 87 23:21:51-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        george@eglin-vax.arpa
Cc:        tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: Need Info on SMTP
Calvin, you might check with Los Alamos.  They have an All-in-one 
connection to unix mail which seems to work.

dennis
-------
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Mar-87 10:08:11 EST
From:      hinden@CCV.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

Stu,

A collision in Wagonnet is, of course, much more serious than on an
Ethernet.  Retransmissions might be more difficult to arrange.  You do
have all of your "bits" in one "Wagon" :-).

Bob

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 87 10:08:11 EST (Sat)
From:      Robert Hinden <hinden@ccv.bbn.com>
To:        Stu Grossman <GROSSMAN@sierra.stanford.edu>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Station wagon full of bits
Stu,

A collision in Wagonnet is, of course, much more serious than on an
Ethernet.  Retransmissions might be more difficult to arrange.  You do
have all of your "bits" in one "Wagon" :-).

Bob

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Mar-87 11:01:35 EST
From:      MAB@CORNELLC.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

Stu, in comparing Wagonnet with Ethernet, you mentioned that for Wagonnet,
congestion is not as much of a problem.  What you neglected to mention,
though, is that for our now well-discussed station wagon, collisions are
much more serious!  (Sorry, couldn't resist. :-)

Mark Bodenstein

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28 Mar 87 11:01:35 EST
From:      Mark Bodenstein <MAB%CORNELLC.BITNET@wiscvm.wisc.edu>
To:        Stu Grossman <GROSSMAN%sierra.stanford.edu@crnlvax2.BITNET>
Cc:        TCP-IP@sri-nic.arpa
Subject:   Re: Station wagon full of bits
Stu, in comparing Wagonnet with Ethernet, you mentioned that for Wagonnet,
congestion is not as much of a problem.  What you neglected to mention,
though, is that for our now well-discussed station wagon, collisions are
much more serious!  (Sorry, couldn't resist. :-)

Mark Bodenstein
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Mar-87 12:27:39 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Routing hold-downs

Folks,

Yesterday I happened to watch the EGP tables in one gateway just after another
gateway crashed. The intent was to see how long old information about nets
serviced by that gateway persisted and whether naughty things might be happening
as it dissipated in the various caches. The old information persisted well over
an hour.

Shocked out of my socks, I started digging further. The gateway that crashed
represented the only path to two innocent networks; however, reachability
was being advertised via EGP to the core and also along a different path to
the NSFNET swamps, a situation typical of many universities these days.
Therefore, I looked for route loops, cache relatches and other phenomena
characteristic of the algorithms used on these wetlands. I can't speak for
all implementations and in fact can speak authoritatively only for the ones
used by the fuzzballs, which are scattered all over the swamps.

The routing algorithms used by the fuzzballs (sometimes called "hello")
are very careful about dissipating old information and avoiding loops, at
least between neighbors. A two-minute hold-down interval is enforced once
a previously reachable path goes down, during which reachability claims
are ignored. This mechanism, used at various times in other algorthms,
including ARPANET, is designed to avoid re-introduction of old, now bogus
information. The interval is selected to be at leat as long as the
maximum time to spread routing information throughout the system, which
can be a pretty long time.

Obviously, in the present case we have to look beyond the fuzzballs to find
where the old information is being stashed. Note that this can happen
anywhere in the world and it only takes one rogue who innocently may
have a funny idea how long this information should live in its cache and
then re-introduce it into the system, finding its way back to the fuzzballs,
core gateways or whatever, and start the whole process all over again.

Why should we care about the problem? It is typical of such phenomena that
route loops form; thus, traffic to the now-unreachable destinations must
circulate somewhere until the TTL fields expire. The key indicator of
that is the ICMP Time Exceeded message. If these are popping up at your
host, the problem is also yours. My observations might suggest a hold-
down should be in the order of an hour, but I don't think this is the
case. More likely one or more implementations have no hold-down at all.

Lessons learned: Operations people (this includes both the INOC, NSF and
related monitoring centers) must do more than react to reported problems
and go out looking for them. This comment is not meant in any way to
detract from their excellent service and prompt response given for a
long time, but might suggest additional, specialized staff might be
necessary. The lookers might start by periodically rummaging over the
data bases at strategic spots looking for excessive "churn" (entries
changing very often) and inconsistencies. Occasional tests should be
done involving a net being turned off, watching the systemic response
and so forth. I've been doing thee things informally for some years
now and occasionally reporting the results to this list. Now the system
has grown to big for me to do that.

The important implementor's lesson is that a coordinated hold-down (or
equivalent) is absolutely necessary. My guess is that two minutes is
not enough and maybe twice that is more appropriate. We also need to
examine those cases where, for various reasons, information must be
cached for much longer than this interval, such as when public networks
are involved. One rule might be that, if you have to cache something for
longer than the hold-down interval, you can't ever tell anybody else
about it. And so forth.

As hinted recently, it might be time to re-examine the "wiretapping"
issue, where a gateway observing an ICMP error message wandering
by to a host on one of its connected networks is examined for possible
hints that might be useful in its forwarding and routing functions.
A sufficient number of these for the same destination within some
time should be grounds to declare the destination unreachable, thus
avoiding needless congestion, looping and other antisocial behavior.

Yes, I know the layer violations implicit in the above may drive many
up the wall. Please show this message to them the next time their
TCP/TELNET connection times out. At least two readers of this list will
notice this could be the first toenail in the "fair-queueing" closet.

Dave

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Mar-87 15:14:56 EST
From:      bzs@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits


While at Harvard in the mid-70's we in fact used a similar method of
transferring things. We had a research group in Ohio and occasionally
the (semi-portable home-brewed) computer broke down. We simply ran to
the airport with a spare, bought it a seat on the next flight and had
someone meet it at the airport gate at the other end (a similar method
is often used to transfer children around the country.) We did the
same sort of thing with (large) boxes of floppies occasionally to
start up data analysis, it worked well enough (plus or minus traffic
jams at Logan Airport.) The broken computer was returned similarly.
The cost was very reasonable compared to other options, we were under
heavy time pressure to keep the data collection rolling.

While we're on the subject of using planes, why not rockets laden with
CDs and launched in parabolic arcs, much faster. We can refer to it as
the Strategic Data Initiative, perhaps a proposal is in order.

	-Barry Shein, Boston University

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Mar-87 08:48:42 EST
From:      HANK@BARILVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Tcp/Ip vs a store & forward network

All the calculations about the bandwidth of a station wagon got me thinking.
Why was Tcp/Ip not designed as a store and forward network (in addition to
the protocols it does support)?  Let me explain why I am asking this.  In
Bitnet, you might have as many as 20 9.6Kb lines separating you from the
place you wish to send a file to.  The probably that all 20 lines are
working and that all 20 intermediate machines are up (yup - no IMPs)
simaltaneously becomes quite small.

(Imagine if the probability of any machine being up and working is 98% and
that the probablility that any leased phone line is working is 99.5% - after
10 machines - 77.7% successful connection).

Well you can say alternate paths and better reliability make the connection
rate closer to 95%.  I would perhaps doubt that when the two nodes are
separated by a number of physical links and that the data has to pass thru
a couple of hardware boxes that will not work if there is a power outage
in the building or other "things" that can cause a hardware box to not
respond.

So, a S&F network would alleviate much of the problem.  Try to get the data
as close to the destination node and then spool it.  Instead SMTP makes
a valiant attempt to emulate S&F by spooling the mail locally and occassionally
trying to establish a connection to the destination.  After 'n' of days
SMTP gives up and sends mail to the sender.  I think it would have been nicer
that SMTP try to get it as close to the down node as possible and then let
that node try polling the down node for 'n' number of days.

But FTP is even worse.  FTP is basically an interactive process.  You want
a file you gotta establish a connection and suck it off or slap it into place.
Transferring files should really be a batch orientated feat - you say what
file you want to store or retrieve and you type in all the necessary
options and parameters and you don't hear about it until it completes (with
appropriate return codes of course).

Bitnet uses BSMTP (Batch SMTP).  Is there such a thing as BFTP (Batch FTP)?
Is there a very strong technical reason why S&F was not part of the design
of Tcp/Ip??  I have a lot of questions but very few answers.

Hank

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Mar-87 09:28:50 EST
From:      steve@BRILLIG.UMD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   ICMP message caching


   Recently, I've been considering wedging some code into the 4.3 kernel
that would let me do some ICMP message caching both in individual hosts
and in gateways.  It seems to me that intelligent use of such a feature
could cut down on extra packet sends, especially in terms of behavior like
the recent mess with ISIB and domain name serving.  After all, if one
"connection" discovers that a host is down, there is no need for everything
else to find that information out for itself.  This would also fix the
problems with getting errors back on unconnected UDP sockets; a packet
to a down site would elicit an unreachability message which would
not be reported to the user, but the next send to that site would
result in an immediate error without ever going to the net.  It also
seems to me that doing this sort of caching in a gateway might not
be a bad idea, but Dave Mills' recent message seems to indicate that
people think this is an evil idea.

   It was suggested to me that ICMP messages should get delivered
(via raw ICMP socket, perhaps) to a user-level process, which has
more smarts to it than the kernel can reasonably have and which
uses ioctls to stick information into the kernel's cache.  That way,
it's relatively easy to change policies to ignore, for example, single
ICMP errors (a single ICMP unreachability error might be due to routing
changes, perhaps), but to add entries to the cache if it sees the
same error a number of times.  Also, it might be possible to associate
error information with routes so that a host trying to reach another
host and which has two different ways to get there can take note of
the error and try to send via a different route.

   It seems that this issue has been discussed before, and while I
don't remember what brought this idea to mind, I doubt that it is
at all original.  If this has been beaten to death publicly and
someone could give me some pointers to RFCs or into the archives,
I would appreciate it.  Otherwise, maybe we can discuss it here.

	-Steve

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Mar-87 15:27:00 EST
From:      Kodinsky@MIT-MULTICS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Telnet Option Negotiation to IBMish Hosts

I wish to first apologize for not reading and responding to this note
earlier.  It obviously has great importance to the KNET telnet programs
(both client and server).

The KNET telnet client and server operate almost identically to the
procedure laid out in Marvin's note (at least that is the way they
should operate).  There are a few exceptions -

FIRST:  we will renegotiate the terminal type at any time - though in ]
the "No change" mode.  As a matter of fact, if the terminal type were to
be changed (within telnet server storage) there would be no effect - the
logical device already exists.

SECOND:  we do not, as best as I can tell, require an EOR option to be
negotiated.  If we are in "3270" mode then we automatically assume that
EOR is going to be understood by the other end.

I think that an RFC would be a good thing for this.  It should address
two issues:  the details of 3270 telnet AND (more importantly) the
issues involved in tying together interdependent options (as Marvin
Pointed out).  We at Spartacus would be glad to work with the community
on this RFC.  We do not feel that we can take a lead in this effort
since we have been on the net for only a few months.

Regards, Frank Kastenholz - Manager KNET/VM Development -
Spartacus/Fibronics

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Mar-87 18:31:15 EST
From:      bzs@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Tcp/Ip vs a store & forward network


Hank,

Your questions mostly focus on design trade-offs.

Trying to get the data as close to to the destination node and then
spooling might not be defineable in many cases. What does closer mean
when routing can be changed? The very notion implies that a route
calculated at transmission time remains static (perhaps for days) as
the file moves from host to host through the network. This is not
always a reasonable assumption.

I do think a Batch FTP is a fine idea, many people accomplish this
anyhow by backgrounding transfer jobs, others by sending files through
the mail networks.

One major issue, of course is security. FTP is designed to demand a
password before a file transfer begins. Not sure how this is
accomplished in batch mode without sending passwords around the net
(store and forward exacerbates this problem as passwords may lie on
intermediate hosts for long periods of time.) Bitnet basically takes
the attitude that it is similar to mail and files are simply put on a
spool for a target user, no password to send a file is required.  How
*does* a user fetch a file within the Bitnet sendfile paradigm?  Other
than specialized servers for certain files, of course.

Another problem with S&F networks at the higher (that is file or mail
message) level are the failure modes presented. Clogging of hosts'
disks receiving these as intermediaries becomes a problem (I believe
WISCVM fell as much as 3 weeks behind in file transfers recently due
to this type of clogging? correct me if I'm wrong, I mean no malice.)
Packets are much more ephemeral things. There, of course, is also the
problem of getting an error or success back to the originator from an
intermediate node who decides the file's fate has been sealed.

For another extreme, try MAIL-11 on VMS in a DECNET network. You can't
send a message unless it is immediately deliverable, very annoying to
me to end a message (typically a reply) and have it immediately
rejected because the host happens to be down at the moment. This is a
place where some kind of store and forward seems essential, I hate
"busy signals" in mail networks.

I think my conclusion is that it would probably be interesting to see
someone propose and design a store and forward file transfer protocol
and get it accepted by the community. There are several design
problems but I don't think the concept is flawed, why have a human sit
and wait on a slow link? Or not be able to initiate a transfer just
because a host is down at the moment? I don't think, however, Bitnet
is a great model for this at all layers if for no other reason than
the fact that the routing is so well defined in Bitnet for where to
store and where to forward while in the Internet things get a bit more
nebulous. But, hey, that's what the designer will have to solve.

	-Barry Shein, Boston University

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Mar-87 20:16:58 EST
From:      narten@PURDUE.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Tcp/Ip vs a store & forward network

One big problem with S&F networks is the lack of end-to-end acks. Once you
drop a "transaction" (e.g. batch ftp or piece of mail) in the queue of
one of the intermediate nodes, it is out of your hands. You don't know
where it is, and you can't find out. How many times have you sent mail
into a black hole? It happens much more often in store and forward
networks than in the TCP world.

Based on my experience, when I send mail over TCP to a user, I feel
very confident that it gets to them. If the mail gets lost, its almost
always because the mail subsystem at the receiving site is messed up.
Sending mail through mail lists (which puts in an extra S&F hop) is
also pretty reliably, though not as much. On the other hand, when
mailing via one of the S&F networks, my confidence falls rapidly as
the number of hops increases.

You might argue that the reliability of S&F networks could be
improved. No matter how reliable you make them, you will still be left
with a system where everything you drop in disappears, and there is
no way of finding out where it is until it comes out at the other end
(if it does). Not too good when you just sent an important message.

Thomas

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Mar-87 23:47:58 EST
From:      sy.Ken@CU20B.COLUMBIA.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits


  Stu, in comparing Wagonnet with Ethernet, you mentioned that for Wagonnet,
  congestion is not as much of a problem.  What you neglected to mention,
  though, is that for our now well-discussed station wagon, collisions are
  much more serious!  (Sorry, couldn't resist. :-)

I would also hope that the driver would not "back off and retry"...  :-)
-------

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Mar-87 23:58:42 EST
From:      karn@KA9Q.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Tcp/Ip vs a store & forward network

Actually, I thought the Internet WAS a store-and-forward network. Gateways
store up packets as they are received and forward them after a queueing
delay.  I think you really meant "message switching" as opposed to "packet
switching".

But even this distinction is rather artificial.  One of the most popular
message switching networks is UUCP. Like the Internet, each UUCP node also
stores up a block of information, makes a routing decision (sometimes
specified in a source route) and sends it on its way.   The only real
differences are quantitative, i.e., the maximum allowable message size and
the typical end-to-end delivery delay, although admittedly they heavily
influence the way end-user nodes make use of the service.  You *could* run
TCP on top of UUCP (encapsulating one segment per message) as long as it is
prepared to deal with RTTs of several days.  On the other hand UDP
query-response applications use the Internet as though it were a message
switching network, since messages fit neatly into Internet datagrams.

Perhaps the only real qualitative distinction is whether the network is
useful for "real time" communications, however you define them. Nobody runs
SMTP/TCP/IP on UUCP because few are willing to wait several days for a TCP
3-way handshake to complete.  Instead UUCP mail consists of single, large,
self-contained "datagrams" with no end-to-end protocol other than the
implicit human-to-human one.  Of course this means you have no real
guarantee that the message will get there, so everyone puts in lots of
low-level reliability enhancing mechanisms.  I prefer SMTP across the
Internet over UUCP whenever available, not only because it's usually faster,
but because I *want* that end-to-end reliability provided by TCP.  Assuming
a fully connected Internet, I can feel pretty confident that if my mail
disappears from the spool then it has safely reached its destination and
isn't stuck in some unknown place halfway across the path.

I think the distinction between message and packet switching will blur
further as very high speed transmission facilities become available and RAMs
get even cheaper. You can allow very large packets on a high speed fiber
link without sacrificing "real time" performance. Chopping up a data stream
into tiny packets will no longer be necessary or even desirable: the packet
rate would get completely out of hand.  For example, if each packet could
hold an entire NTSC video frame, real time packet video would only be 30
packets per second, well within the capability of even a Z-80 as long as
data paths are kept separate.

An interesting project would be to see just how applications might make use
of "megapackets".  Interactive timesharing probably can't make use of much
more than a few K (a screenful of text) but clearly file transfers could use
much more. (Think of an entire magtape occupying a single packet.  At
gigabit rates it would still only take a second or so to transmit).

Phil

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29 Mar 87 15:48:42 O
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Tcp/Ip vs a store & forward network
All the calculations about the bandwidth of a station wagon got me thinking.
Why was Tcp/Ip not designed as a store and forward network (in addition to
the protocols it does support)?  Let me explain why I am asking this.  In
Bitnet, you might have as many as 20 9.6Kb lines separating you from the
place you wish to send a file to.  The probably that all 20 lines are
working and that all 20 intermediate machines are up (yup - no IMPs)
simaltaneously becomes quite small.

(Imagine if the probability of any machine being up and working is 98% and
that the probablility that any leased phone line is working is 99.5% - after
10 machines - 77.7% successful connection).

Well you can say alternate paths and better reliability make the connection
rate closer to 95%.  I would perhaps doubt that when the two nodes are
separated by a number of physical links and that the data has to pass thru
a couple of hardware boxes that will not work if there is a power outage
in the building or other "things" that can cause a hardware box to not
respond.

So, a S&F network would alleviate much of the problem.  Try to get the data
as close to the destination node and then spool it.  Instead SMTP makes
a valiant attempt to emulate S&F by spooling the mail locally and occassionally
trying to establish a connection to the destination.  After 'n' of days
SMTP gives up and sends mail to the sender.  I think it would have been nicer
that SMTP try to get it as close to the down node as possible and then let
that node try polling the down node for 'n' number of days.

But FTP is even worse.  FTP is basically an interactive process.  You want
a file you gotta establish a connection and suck it off or slap it into place.
Transferring files should really be a batch orientated feat - you say what
file you want to store or retrieve and you type in all the necessary
options and parameters and you don't hear about it until it completes (with
appropriate return codes of course).

Bitnet uses BSMTP (Batch SMTP).  Is there such a thing as BFTP (Batch FTP)?
Is there a very strong technical reason why S&F was not part of the design
of Tcp/Ip??  I have a lot of questions but very few answers.

Hank
-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 07:32:28 EST
From:      HANK@BARILVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Tcp/Ip vs a store & forward network

Barry,

Which brings me to something I would like to get created:  FTP to spool so that
no pswds need to make their way around the network.  If Bitnet can transfer
files to/from Unix, VMS, VM, MVS, CDC, etc machines - WITHOUT passwords
then Tcp/Ip should be able to send files around to local spool systems so
that the entire concept of FTP pswds can be eliminated.

Hank

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 08:05:27 EST
From:      HANK@BARILVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   TcpIp vs S&F

I am more than well aware of all the drawbacks of S&F and what RSCS can't
do (by the way - there is a PVM version that was developed at U of Maine
that piggybacks on RSCS).  It leaves a lot to be desired and that is why
I want to see if Tcp/Ip can do the same type of functions that RSCS does
(i.e. send a file to someone w/o transmitting a password).

Thanks for all the replies.

Hank

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 09:28:07 EST
From:      ron@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Station wagon full of bits

A friend of mine who formerly worked at CCI implemented their network
by running around the building with an armful of floppy disks...coined
			"Adidas Net"

-Ron

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 09:58:07 EST
From:      martillo@ATHENA.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Station wagon full of bits (Frame-Relay)



I confess to not having thought about it too much, but my impression
is frame relay simply permits the passage of level 2 packets on the
basis of level 2 address through the switch to some place in the phone
network where full level 2 processing can be handled.  This means that
the switch can basically concentrate on tdm switching problems while
the level 2 termination point can concentrate statistical muxing
switching problems.  Such a division makes sense as a way to optimise
CSC switch or packet switch performance.

In the asynchronous world LAPD could per passed on a 64 KBPS
unrestricted data circuit to a terminal concentrator and each LAPD
virtual level 2 could correspond to an asynchronous terminal.  While I
consider asynchronous terminal concentrators a backward-looking
technology, in the business world lots of firm want such devices.
Obviously this is not an OSI application, but the separation of the
problem into a physical channel, multiple virtual level 2s, and a flow
control layer on top of this has clearly been influenced by concepts
of layering, and LAPD terminal multiplexing seems more sensible than
the PAD protocols.

Yaqim Martillo

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 10:11:31 EST
From:      mckee@MITRE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Tcp/Ip vs a store & forward network


You were concerned about the reliability of S&F.  There are a variety of
tradeoffs to consider.  The DoD has an ancient but vigorous system
called AUTODIN.  It has the following characteristics:

    - It is a message switching system; messages are limited to 40,000
characters; each message may have as many as 500 addresses.

    - The "switching" part of the system is fairly small; there are 8
AUTODIN Switching Centers in the US, and a few more in Europe and the
Far East.

    - AUTODIN is EXTREMELY reliable; however, duplicate messages may
occur during recovery from a failure.  The AUTODIN design philosophy is
that it is better to send several messages twice than to drop any
message once.

    - Also, during failure recovery, delivery transposition may occur;
i.e., an older message will be delivered before a newer message.

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 11:48:26 EST
From:      mckee@MITRE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

Phil asked, "What is the bandwidth of a 747 ..."

I talked to the Boeing folks here in DC.  A B747-200F
(cargo config.) has:  gross take-off wt. 416 tons
                      operating wt.      171
the difference being fuel and cargo wt.  245

Allowing 45 tons of fuel for 6 hours enroute plus reserve 
leaves 200 tons of compact disks.  According to Cerf, 

100 disks  equals  50 pounds  equals  7.8*10**12 bits; therefore,
multiplying by 8,000,
800,000 disks  - 200 tons - 6.2*10**16 bits
dividing by (6*3600)  21,600 seconds equals 2.9*10**12 bps.

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 13:03:00 EST
From:      NS-DDN@DDN3.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Subject: Re: Tcp/Ip vs a store & forward network


 
 
But, Hank, that is already provided for in the FTP specs. The PASS command is
not a required command (for that matter, neither is USER). The possibilities
are:
 
  USER, Reply 2xx
  USER, Reply 331, PASS, Reply 2xx
  USER, Reply 332, ACNT, Reply 2xx
  USER, Reply 331, PASS, Reply 332, ACNT, Reply 2xx
 
If you want to use SPOOL for a USER name which requires no password, but does
need a user id via the ACNT command, then that "user" (service, really) can
simply DISK DUMP the resultant file into the target virtual machine's reader
queue. If a USER name convention is used throughout the net, it will greatly
simplify the "interactive" script to permit brainless automatons to manage the
process.
 
Dave Craig
Network Solutions, Inc.

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 87 13:03 EST
From:      NS-DDN @ DDN3.arpa
To:        To: HANK%BARILVM.BITNET @ WISCVM.WISC.EDU, tcp-ip @ SRI-NIC.ARPA
Cc:        
Subject:   Subject: Re: Tcp/Ip vs a store & forward network
 
 
But, Hank, that is already provided for in the FTP specs. The PASS command is
not a required command (for that matter, neither is USER). The possibilities
are:
 
  USER, Reply 2xx
  USER, Reply 331, PASS, Reply 2xx
  USER, Reply 332, ACNT, Reply 2xx
  USER, Reply 331, PASS, Reply 332, ACNT, Reply 2xx
 
If you want to use SPOOL for a USER name which requires no password, but does
need a user id via the ACNT command, then that "user" (service, really) can
simply DISK DUMP the resultant file into the target virtual machine's reader
queue. If a USER name convention is used throughout the net, it will greatly
simplify the "interactive" script to permit brainless automatons to manage the
process.
 
Dave Craig
Network Solutions, Inc.

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 13:26:11 EST
From:      bzs@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Tcp/Ip vs a store & forward network


>Barry,
>
>Which brings me to something I would like to get created:  FTP to spool so that
>no pswds need to make their way around the network.  If Bitnet can transfer
>files to/from Unix, VMS, VM, MVS, CDC, etc machines - WITHOUT passwords
>then Tcp/Ip should be able to send files around to local spool systems so
>that the entire concept of FTP pswds can be eliminated.
>Hank

I'm not sure there's much difference between bitnet's SENDFILE and
just sending a file via mail. Most of the differences between SENDFILE
and Bitnet/Mail (and, actually, SMTP) are simply to accommodate spool
record length restrictions within IBM's filing system. This is not
particularly a problem when an heterogeneous environment is accounted
for and files have to be in some "reasonable" ASCII text format
anyhow.

Even record length restrictions and binary images can be transferred
in more generic ways (eg. UUENCODE/UUDECODE which I've ported to my
3090) than DISKDUMP formats which appear to be limited in function and
very much designed with IBM's filing system in mind. I suppose VMS's
jnet (bitnet) product accommodates this, but I assume only by being
subservient to IBM file formats (and a very, very limited subset at
that, as far as I know there is still no way to send, eg, a PDS
between even two IBM systems via Bitnet without some user hackery.)

The other half of the difference would be accomplished by adopting
some convention that files are sent to, say, user-fxfr@host so it
appears in a different spool or just marking the header so mail user
agents could pluck out "file transfers" from the mail when they start
up. I think this is a minor need, the Subject: line can get you 98% of
the way there without changing anything.

The "entire concept" of FTP passwords is useful in that it allows a
user to get at files either destructively (in a positive sense) or
past normal security (that is, files not publicly readable.) I don't
think getting rid of this feature is a step forward.

There are already passwordless protocols in use (eg. TFTP in the
internet world and transferring via uucppublic in the UUCP world.) For
obvious reasons they seem to have limited acceptance when FTP is
available. They're mostly a security botch, especially when fetching
of files is needed.

	-Barry Shein, Boston University

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 13:29:13 EST
From:      kincl%hplnmk@HPLABS.HP.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Response to anti-bridge comments



                                                         At the moment, 256
   kbps of this capacity connects a set of five Vitalink Translan IIIs as a
   star with the hub at Piscataway.  Each of these boxes also connects to the
   building-wide backbone Ethernet at its location, thus bridging the locations
   together at the link level. Within each location almost all of our Ethernets
   are bridged with DEC LanBridge 100s, with the fiber version interconnecting
   multiple buildings at a location.  At last count, the routing tables on the
   Translans showed something like 600 active hosts.

Question:  How well would all this work if you decided that you need
redundant routes or if you decided that you do not want a start topology
but have an arbitrary topology?  Can you have a configuration like the
following:

        ---------------Ethernet-----------------
               |                       |
               |                       |
             Bridge                  Bridge
               |                       |
               |                       |
        ---------------Ethernet-----------------
               |                       |
               |                       |
             Bridge                  Bridge
               |                       |
               |                       |
        ---------------Ethernet-----------------


We currently have about 40-50 Ethernets connected with about 20 IP
gateway boxes.  The gateways are connected via Ethernet, Broadband, 56Kb
land lines, 9.6Kb land lines, and soon T1 and 64Kb satelite links.
The gateways we use (cisco Systems) are both fast (we have measured
them at 1000 large packets per second between Ethernets) as well as
have reasonable routing algorithms (though they will speak RIP they
talk amongst themselves with IGRP).  We have not seen any problems with
the routing (or anything else related to the gateways).

You are right---it is unfair to compare standalone level 2 bridges with
general purpose systems (especially when they are runing RIP).

-Norm Kincl
 HP Labs

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Mar 87 16:29:24 PST
From:      Dave Crocker <dcrocker%engr.ub.com@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   NetBios over TCP
In article <8703232326.AA18131@seismo.CSS.GOV> michael@labtam.OZ.AU (Michael Podhorodecki) writes:
>
>       Could someone let be know the status of the NETBIOS over TCP/IP...

I am slowly working my way through some backlog messages and others
may already have responded.  But your query seemed important enough
to be worth a redundant response...

The NetBios/TCP effort has produced an initial specification which is
documented as two Arpa Internet RFC (Requests for Comments):

	Protocol Standard for a NetBios Service on a TCP/UDP
	Transport:  Concepts and Methods; RFC #1001

	Protocol Standard for a NetBios Service on a TCP/UDP
	Transport:  Detailed Specifications; RFC #1002

They are available for distribution from the Network Information Center,
at SRI International.  You may order them by calling 800-235-3155.

The text is about 150 pages, combined, so you can have many hours of
fun reading, understanding, commenting upon it.

The spec cites online and postal address to which you may send
comments.  You might also consider sending online comments to

	netbios@mitre-bedford.arpa

Good luck.

Dave
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 13:30:38 EST
From:      geof@imagen.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Re: Tcp/Ip vs a store & forward network


 >      Which brings me to something I would like to get created:  FTP to spool so that
 >      no pswds need to make their way around the network.  

[sorry for not answering directly, I don't have a reliable path from USENET
 to bitnet -- my packets always go into a black hole :-]

I think that you are arguing for new conventions, not new protocols.  Queuing
of FTP requests is something you can program on your local machine.  
As pointed out, in the internet, a host has no concept of "closer", so it
is impossible for a store and forward FTP to do anything other than what
SMTP does now.  Unless you do manual routing.  Augh.

Similarly, who says that Arpanet mail has end-to-end ACKs?  It just depends
on where you put the "end."  I put it at the user, and I want to see explicit
acks from users, too (well, I flame so much that it actually doesn't matter
to me if some of my typed jewels drop on the floor -- but when I care, I ask
for an explicit response).  For example, I recently looked over the shoulder
of another user, and discovered that he didn't realize that MM would only
show him the messages as "NEW" once -- after that they were only marked UNSEEN.
About three weeks before he had been cut off by a bad phone connection, and
thus missed reading 2 important messages for three weeks - until I showed
him that MM still had those messages marked UNSEEN (he didn't know what the
U was for).  So what good was Arpanet's ~100% reliable delivery there!

On USENET it is normal to keep a copy of a sent message until you receive
an ACK for it, manually sent by the recipient.  It is reasonable etiquette
to ACK a message when you receive it (unless you want to be able to claim that
you didn't receive it :-)) with a small message that says "I got your message"
or even just "ack".  My opinion is that mail reading software should
encourage this behavior by suggesting such a reply and having an automatic
way of generating it.

- Geof

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 13:43:22 EST
From:      karn@FLASH.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Response to anti-bridge comments

DEC LanBridge 100's have a loop detection algorithm.  When a bridge is
turned on, it sends out test packets on each interface and checks if they
come back in on the other side. If so, the bridge will remain offline and
not forward traffic.  An offline bridge will continue to test the path and
will go online within a few seconds should the existing path fail.

It is my understanding that while the Vitalink Translans have a similar loop
detection algorithm, not every combination of DEC and Vitalink bridges will
do what you want. If there are parallel paths via LanBridges and Translans,
it's possible to have a LanBridge go offline in favor of a Translan, which
is decidedly suboptimal.  I understand Vitalink is working on a new software
release that will "do the right things" in combination with LanBridge 100s.
Fortunately the situation is rather rare (it doesn't occur in our network).
For further info you should call Vitalink.

Phil

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Mar 87 14:15:03 est
From:      ms6b#@andrew.cmu.edu (Marvin Sirbu)
To:        karn@flash.bellcore.com (Phil R. Karn), Rudy.Nedved@h.cs.cmu.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: network horror stories
>most of the telephone companies have the prefix for remote areas stored
locally to

>reduce trunk line usage from wrong numbers...if you dial 412 333 XXXX in 201

>area then 201 area will not even try the connection, it will indicate that

>number is incorrect and a telephone book should be consulted. Alas,

>propagation of this information has the same problems as propagating routing

>information....sigh.


When CMU's exchange code was changed last year (to 268= CMU) that fact was

not properly propogated to the CCSA switches used by the FTS network.  As a

consequence, for two days after the change, no one at NSF, DoD, etc. could
call 

CMU over the FTS network!  They were told 268 was not a working exchange.


Marvin Sirbu

CMU





-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 14:59:22 EST
From:      Steve.Kille@CS.UCL.AC.UK.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP



 >From:  CERF@edu.isi.a
 >Subject: Re: GOSIP vs TCP/IP
 >Date:  15 Mar 1987 01:04-EST
 
 >Please ask Steve what he does about X.25 resets in the absence of
 >an end/end reliable protocol such as TCP or TP4?

Well, I'm the wrong Steve, but will comment anyhow!    The TCP
Implementor's conference has made it very clear to me that the X.25
oriented solutions are very poorly understood in the TCP/IP
community.

There are two basic ways of handling resets.   The first is at
the application level, and will certainly be done by those
applications which need to handle large quantities of data, and
do not wish to incur the cost of retransmission.  This can be
done by use of CCR (Comit Concurrency + Recovery) for FTAM and
JTM (Job Transfer and Manipulation).  For X.400, the RTS
(Reliable Transfer Service) resumption mechanisms can be used.

In many cases, these will be sufficient, and so a very
lightweight transport (viz TP0) is sensible to make best
utilisation of the X.25.   However, for some applications (e.g.
Terminal Access) it would be very desirable to have resumption
over the same transport connection.  Therfore, TP1 (viz error
recovery class) is a sensible choice.

There is absolutely no need for the heavyweight overkill of TP4.
X.25 will keep data in sequence, and prevent data corruption.


Steve

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 16:39:49 EST
From:      Rudy.Nedved@H.CS.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: network horror stories

I am not aware of the details behind the transition from one exchange to
another...maybe it could have been done over a longer time period with
some type of exchange forwarding at the local TelCo...

As far as I know, the major users were not affected only private and small
telephone companies. This is a problem in the ARPA Internet and is an issue of
managerial inertia not a technical problem. If you don't play the game
correctly then what can you do.

Anyhow, two days once every few years is not a major reason to not do what
they do.

-Rudy

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 17:15:03 EST
From:      gds@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Tcp/Ip vs a store & forward network


     Which brings me to something I would like to get created:  FTP to
     spool so that no pswds need to make their way around the network.
     If Bitnet can transfer files to/from Unix, VMS, VM, MVS, CDC, etc
     machines - WITHOUT passwords then Tcp/Ip should be able to send
     files around to local spool systems so that the entire concept of
     FTP pswds can be eliminated.

     Hank

I would like to know what sorts of access controls are used in Bitnet to
allow or deny a user access to

* a remote file they own
* a remote file they don't own, but is not protected
* a remote file they don't own, but is protected

and how such users are prevented from sabotaging remote disks ...

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 19:29:24 EST
From:      dcrocker@engr.ub.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   NetBios over TCP

In article <8703232326.AA18131@seismo.CSS.GOV> michael@labtam.OZ.AU (Michael Podhorodecki) writes:
>
>       Could someone let be know the status of the NETBIOS over TCP/IP...

I am slowly working my way through some backlog messages and others
may already have responded.  But your query seemed important enough
to be worth a redundant response...

The NetBios/TCP effort has produced an initial specification which is
documented as two Arpa Internet RFC (Requests for Comments):

	Protocol Standard for a NetBios Service on a TCP/UDP
	Transport:  Concepts and Methods; RFC #1001

	Protocol Standard for a NetBios Service on a TCP/UDP
	Transport:  Detailed Specifications; RFC #1002

They are available for distribution from the Network Information Center,
at SRI International.  You may order them by calling 800-235-3155.

The text is about 150 pages, combined, so you can have many hours of
fun reading, understanding, commenting upon it.

The spec cites online and postal address to which you may send
comments.  You might also consider sending online comments to

	netbios@mitre-bedford.arpa

Good luck.

Dave

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 20:18:18 EST
From:      starner@burdvax.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   FTP and 4.3BSD


Since converting to 4.3BSD I have been having problems using ftp to
parcvax.xerox.com (i have discovered this problem at no other
sites, yet). I can connect to the site fine, login anonymous,
ls works -- but "dir" and the "*get" functions hang, finally timeout
with the message "connection reset by peer". This behaviour is
exhibited on all hosts on our internal network also.

Here is a sample:

<burdvax:2> 101% ftp parcvax.xerox.com
Connected to parcvax.xerox.com.
220 parcvax.xerox.com FTP server (Version 4.105 Mon Jun 2 17:55:28 PDT 1986) ready.
Name (parcvax.xerox.com:starner): anonym,ous               mous
331 Guest login ok, send ident as password.
Password:
230 Guest login ok, access restrictions apply.
ftp> ls
200 PORT command successful.
150 Opening data connection for /bin/ls (10.5.0.96,1133) (0 bytes).
.cshrc
.login
.plan
  .
  .
  .
xns
226 Transfer complete.
143 bytes received in 1.9 seconds (0.072 Kbytes/s)
ftp> dir
200 PORT command successful.
150 Opening data connection for /bin/ls (10.5.0.96,1134) (0 bytes).
netin: Connection reset by peer
226 Transfer complete.
ftp> quit
221 Goodbye.
<burdvax:2> 102% 

Does this problem seem familiar to anyone? I can ftp to other 4.3 sites,
4.2 sites, TENEX, etc.... with no problem.

Also, I can get files using a Xerox 1109 using TCP/IP from parcvax.
But not from any of my unix hosts on my network.

Any hints anyone can give would be appreciated.


-- 
Mark Starner					starner@burdvax.prc.unisys.com
Unisys Corporation/Paoli Research Center	{seismo,sdcrdcf}!burdvax!starner
Paoli, PA

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Mar 87 14:32:28 O
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        Barry Shein <bzs@bu-cs.bu.edu>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Tcp/Ip vs a store & forward network
Barry,

Which brings me to something I would like to get created:  FTP to spool so that
no pswds need to make their way around the network.  If Bitnet can transfer
files to/from Unix, VMS, VM, MVS, CDC, etc machines - WITHOUT passwords
then Tcp/Ip should be able to send files around to local spool systems so
that the entire concept of FTP pswds can be eliminated.

Hank
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Mar-87 23:16:02 EST
From:      martillo@ATHENA.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Station wagon full of bits


Is frame-forwarding really more of a violation of the OSI model
than an ethernet bridge.  A frame-forwarding switch does not strike
me as a great deal different in concept or functionality than an
ethernet bridge.

Yakim Martillo

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Mar 87 15:05:27 O
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   TcpIp vs S&F
I am more than well aware of all the drawbacks of S&F and what RSCS can't
do (by the way - there is a PVM version that was developed at U of Maine
that piggybacks on RSCS).  It leaves a lot to be desired and that is why
I want to see if Tcp/Ip can do the same type of functions that RSCS does
(i.e. send a file to someone w/o transmitting a password).

Thanks for all the replies.

Hank
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 00:26:47 EST
From:      ddp#@ANDREW.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  danger of bridges

>I should hope that the situation is not this bad, especially since x3s33
 
>ES-IS (host-gateway) routing protocol uses a similar HELLO scheme.  Although
 
>I am also not a DECNET expert (or even novice, for that matter), I'm would
 
>be EXTREMELY suprized if the HELLO timer was not settable, meaning that
 
>for crowded networks, it could and I assume normally would be set
 
>to greater than 15 seconds.

I've asked a local DECnet wizard who tells me that the timer is indeed
settable (almost everything is in DECnet).  Of course the problem is that it
must be set on every host and we don't have direct control over them all...


>Second, host HELLO's typically go to gateways,
 
>not other hosts, so every host doesn't need to process every host
 
>HELLO, just gateway HELLO's.  There should be much fewer gateways than
 
>hosts.

In DECnet atleast, the HELLO is just a multicast and therefore goes to all
hosts  receiving on that multicast address.


Drew

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 01:07:28 EST
From:      ddp#@ANDREW.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Response to anti-bridge comments


 >At last count, the routing tables on the Translans showed something like
600 active hosts. 

I'm not sure this is quite a large enough net for my statements to apply.
It's probably the case that your's is a network where level 2 bridges are
appropriate for your current needs.  I wouldn't agree that they will be
appropriate for future needs though.


>We generally see 1-2 per second, which is expected and entirely acceptable.

The arp rate a particular net sees is probably going to be quite dependent on
the type of applications being used on it.  Over 60% of the IP traffic on our
network is from the Andrew distributed file system (something like NFS in
functionality).  Each workstation on the network regularly communicates with
quite a few different servers and other hosts.  I would suspect that the ARP
rate from distributed applications like this is much higher from networks
with your basic telnets, ftp's and smtps.


>If you see 20 per second, then you've got something wrong somewhere.
 
>I've found that bursts of ARP requests are usually caused by hosts who
 
>respond inappropriately to UDP broadcasts to bogus IP addresses.

Luckily I think we have the bad UDP broadcast problem under control.  That
definitely is not what causes the majority of our ARP's.  There's nothing
really wrong (that we've been able to find) besides the problems with 4.2
UNIX itself.  Actually most of our arps seem to be from hosts that
relentlessly try to open connections to machines which are down.  It
especially get's bad when an important server goes down.  When 500 hosts are
trying to talk to a file server that has been down for a while...  Luckily
the file system knows about exponential backoff.


One of the problems we found a while ago is that the default size of an arp
cache in 4.2 is not at all appropriate for a server machine which
communicates with LOTS of machines.  The default is for a cache of 5x19
entries, i.e. there are 19 possible hash values and only 5 hosts can hash to
each one.  In the worst case, if you are trying to communicate sequentially
with 6 hosts which all hash to the same value, you can end up sending one ARP
req packet per IP packet/transaction.  For our file servers which regularly
communicate with 300 hosts in a 10 minute period this is definitely not
appropriate...  I think we made the cache 10x99 instead.


The crux of the problem though is that with level 2 biridges, your arp rate
(or any kind of multicast/broadcast) rises LINEARLY with the number of hosts
connected on ANY subnet of the network.  However using level 3 routers, the
rate only rises linearly with the number of hosts connected to your
particular subnet.


Drew

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Mar 87 7:14:33 PST
From:      Dave Crocker <dcrocker%engr.ub.com@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Packet network reliability
In article <8703250201.AA06443@flash.bellcore.com>
	karn@FLASH.BELLCORE.COM (Phil R. Karn) writes:

>... In "unlayered virtual circuit" networks, connection
>state information is kept not only in the end-point switches, but also in
>every intermediate switch along the path.
>... Because of this, a node or link failure ANYWHERE along the
>connection path causes an X.25 VC reset, not just failures at the end nodes.
>
>Only in "layered VC" networks such as the DDN (where datagrams are used
>internally) can intermediate node and link failures occur without resetting
>virtual circuits.  ...

Don't know how much this will contribute to the discussion, but you pushed
one of my buttons:

There are two issues often treated as one:  Virtual Circuit vs. Datagram
underlying architecture, and Robust vs. Fragile handling of major network
anomolies.

It is common for VC-oriented nets to be relatively more Fragile than
the DG-oriented ones, but that definitely is not necessary.  It has more
to do with certain economies that are perceived by the implementors.

X.25 vendors are excellent examples of the VC/Fragile orientation.  By
virtue of being very cost-conscious, they pay very close attention
to such things as packet-handling "efficiencies" and buffer management.
The handling efficiency question walks them down the path of internal
VC orientation.  (Common belief:  The processing overhead to forward a
packet in a VC-oriented system is lower than in a DG-oriented one.)

The buffer management question makes them give up a buffer as soon as the
"next" hop has acknowledged it.  That is, the only copy of the data
exists at the latest node to have accepted it.  If that node goes down,
the copy is lost.

Your note used the term "end to end reliability".  That is exactly the
issue.  The sending node must hold onto a copy of the data until the
receiving node acknowledges deliverying it to the destination host.
If it does this, than an internal X.25 Reset (for example) could be
transparently recovered from, by re-routing the circuit automatically.

A few years ago, I tried to get Databit (Siemens) to modify their
X.25 packet switches to permit holding on to the packet at the sending
node, until a final ack was received.  They were not willing to consume
buffers for that long.

By the same token, BBN could modify their switches NOT to hold on to
packets at the source PSN.  At that point, a number of problems internal
to the net would become highly visible to users.

Dave
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 05:01:22 EST
From:      jon@CS.UCL.AC.UK.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Response to anti-bridge comment

/* Written  8:22 am  Mar 31, 1987 by kincl%hplnmk@com.hp.hplabs in pyr1:tcp-ip */
/* ---------- "Re: Response to anti-bridge comment" ---------- */
Received: from ucl-cs-nss by pyr1.Cs.Ucl.AC.UK   with SMTP  id aa05565;
          31 Mar 87 8:21 WET
Received: from sri-nic.arpa by mv1.Cs.Ucl.AC.UK   via Satnet with SMTP
           id aa05190; 31 Mar 87 8:20 WET
Received: from hplabs.HP.COM by SRI-NIC.ARPA with TCP; Mon 30 Mar 87 10:27:05-PST
Received: from hplms1 by hplabs.HP.COM with TCP ; Mon, 30 Mar 87 10:25:06 pst
Received: from hplnmk (hplnmk) by hplms1; Mon, 30 Mar 87 10:24:38 pst
Return-Path: <kincl@hplnmk>
Received: from hplnmk.hpl.hp.com by hplnmk ; Mon, 30 Mar 87 10:29:16 pst
Message-Id: <8703301829.AA06404@hplnmk>
To: "Phil R. Karn" <karn@com.bellcore.flash>
Cc: tcp-ip@arpa.sri-nic
Subject: Re: Response to anti-bridge comments
In-Reply-To: Your message of Thu, 26 Mar 87 15:20:26 -0500.
             <8703262020.AA27749@flash.bellcore.com>
Date: Mon, 30 Mar 87 10:29:13 PST




Question:  How well would all this work if you decided that you need
redundant routes or if you decided that you do not want a start topology
but have an arbitrary topology?  Can you have a configuration like the
following:

        ---------------Ethernet-----------------
               |                       |
               |                       |
             Bridge                  Bridge
               |                       |
               |                       |
        ---------------Ethernet-----------------
               |                       |
               |                       |
             Bridge                  Bridge
               |                       |
               |                       |
        ---------------Ethernet-----------------

Yes, but.

At UCL we run a mini internet with 5 sites interconnected by
Megastream (thats 2.Mbps not T1) lines. We also run a lot of
LAN technology, mostly ethernet. We reckon that it's swings and
roundabouts whether we use MAC Bridges or Network Level relays
(to use ISO jargon). TYhere is an emerging (ISO!) standard for MAC
bridges, and the only thing it is waiting on is how to do loop
resolution and access control (ie the things most people think
are network level things, but ISO are beginning to concede are
different in a LAN/MAN context).

Anyway, its down to
1. performance
2. functionality
   a) traffic control
   b) Fault Isolation
   c) routing/loop resolution
   d) access control
   e) management of all this.

There's absolutely no reason to get layerist about this. if the
addressing and protocols can stand it, there's nothing to
choose between MAC bridges and network lewvel relays if they
happen to do the same job as well. broadcast/multicast limiting
can be done if you use distributed nameservers (and arp klugery
is not a hack, it can be managed properly as a ditributed
multicast system in MAC bridges if you implement it).

two asides:
1. MAC bridges also buy you more trustworthy access control, since
it's harder to spoof physical address without being spotted
than to spoof IP/network level address, specially if you dont
buy the wrong LAN.
2. MAC bridges usually perform, better - eg NFS works through
them - you have to kludge the silly numbers in the mount
table to get it to go even through a cisco box - one of the
better IP gateways around.

We use network level relays (IP gateways) between sites over
the megastream, and predominantly MAC bridges within sites. The
choice seems to have made sense in terms of managing the
system, but I suspect that we just got good hardware and
software, and that's what counts in the end.

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 06:05:29 EST
From:      jon@CS.UCL.AC.UK.UUCP
To:        mod.protocols.tcp-ip
Subject:   Tcp/Ip vs a store & forward network

Actually, I thought the Internet WAS a store-and-forward network. Gateways
store up packets as they are received and forward them after a queueing
delay.  I think you really meant "message switching" as opposed to "packet
switching".

Yep. In the UK we use a spooled FTP system called NIFTP
(Network independant file transfer protocol). This works over
anything and we have it on 11/44s on Cambridge rings, vaxen and
pyramid, TCP/IP over ethernet. The spec says you can
checkpoint files, so it will work over junk networks without
having to break large files down yourself. It also does binary
etc, and it does some sorts of run-length encoding, for people
with 30bps packet radio nets! It also has sensible
authentication, unlike ftp which seems happy to send LOGIN passwords
around on networks without encryption (try and sell that to a
commercial company with ethernet).

The spec may be got from the Joint Network Team in the UK.
Implementations for ?NIXs exist. Why reinvent the wheel, when
you can get a halftrack for free - or
you could wait for FTAM.

jon

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 07:15:00 EST
From:      JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   computer manuals vs books


     I recently had occasion to order from DEC the data link layer and 
physical layer specs for the ethernet.  What I received was your basic 
standard computer company type manual.

     Last year I ordered some documents from the NTIS* on computer 
security.  Some of what I received from them was similar to the above 
but the rest looks very much like 3 rd generation copier material.  For
the price I paid for the NTIS documents I would have expected better. 

     I recently ordered, from the IEEE, the 802.2 and 802.3 standards.  
What I paid was in line with the rest of the manuals I am talking about 
here or maybe just a bit higher but not much.  What I received floored 
me completely.  The IEEE sent me BOOKS.  They sent me REAL BOOKS.  These 
aren't computer manuals and they certainly are NOT 3 rd generation 
copies.  These are hard cover, very solid BOOKS.  Worth every penny 
just to see a real book again, never mind the content.

     They were done with proper type-setting, an eye catching use of 
bold type, and clean diagrams in general.  I wasn't at all ready for 
this.  The IEEE got Wiley & Sons to do the publishing.  I guess that 
helped.  

     If I were king, I think I would tell the computer companies AND the 
NTIS to either cut there prices or start printing better material.  If 
the IEEE can do it then so can they. (Yes I understand about replacement 
pages, the time value of information, and other things like that.  Many
documents can be well published however.) 

     HOORAY for the IEEE!

     Just thought you might like to know that somebody seems to do 
something right.

NTIS: National Technical Information Service.

USnail:
          Chris Johnson
          Academic Computer Services
          Northeastern University 39RI
          360 Huntington Ave.
          Boston, MA. U.S.A. 02115
AT&T:     (617) 437-2335
CSNET:    johnson@nuhub.acs.northeastern.edu
ARPANET:  johnson%nuhub.acs.northeastern.edu@relay.cs.net
BITNET:   johnson%nuhub.acs.northeastern.edu@csnet-relay

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Mar 87 07:15 EST
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA
Subject:   computer manuals vs books
     I recently had occasion to order from DEC the data link layer and 
physical layer specs for the ethernet.  What I received was your basic 
standard computer company type manual.

     Last year I ordered some documents from the NTIS* on computer 
security.  Some of what I received from them was similar to the above 
but the rest looks very much like 3 rd generation copier material.  For
the price I paid for the NTIS documents I would have expected better. 

     I recently ordered, from the IEEE, the 802.2 and 802.3 standards.  
What I paid was in line with the rest of the manuals I am talking about 
here or maybe just a bit higher but not much.  What I received floored 
me completely.  The IEEE sent me BOOKS.  They sent me REAL BOOKS.  These 
aren't computer manuals and they certainly are NOT 3 rd generation 
copies.  These are hard cover, very solid BOOKS.  Worth every penny 
just to see a real book again, never mind the content.

     They were done with proper type-setting, an eye catching use of 
bold type, and clean diagrams in general.  I wasn't at all ready for 
this.  The IEEE got Wiley & Sons to do the publishing.  I guess that 
helped.  

     If I were king, I think I would tell the computer companies AND the 
NTIS to either cut there prices or start printing better material.  If 
the IEEE can do it then so can they. (Yes I understand about replacement 
pages, the time value of information, and other things like that.  Many
documents can be well published however.) 

     HOORAY for the IEEE!

     Just thought you might like to know that somebody seems to do 
something right.

NTIS: National Technical Information Service.

USnail:
          Chris Johnson
          Academic Computer Services
          Northeastern University 39RI
          360 Huntington Ave.
          Boston, MA. U.S.A. 02115
AT&T:     (617) 437-2335
CSNET:    johnson@nuhub.acs.northeastern.edu
ARPANET:  johnson%nuhub.acs.northeastern.edu@relay.cs.net
BITNET:   johnson%nuhub.acs.northeastern.edu@csnet-relay

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 09:35:16 EST
From:      narten@PURDUE.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Tcp/Ip vs a store & forward network

Geof,

>Similarly, who says that Arpanet mail has end-to-end ACKs?  It just depends
>on where you put the "end."  I put it at the user, and I want to see explicit
>acks from users, too

True, there will never be real end-to-end ACKs if you take things far
enough. An ack for a mail message to some would mean "mail has been
received and READ (and understood :-))". A reasonable compromise would be a
confirmation that the message has been placed in the recipients
mailbox.  Presumably, as domain names get extended, we will be able to
do that.  Any mail you send to a user can go directly to the machine
where the his/her mailbox resides. No forwarding at the site would be
needed.

>On USENET it is normal to keep a copy of a sent message until you receive
>an ACK for it, manually sent by the recipient.  It is reasonable etiquette
>to ACK a message when you receive it

I don't find that acceptable as a *general* way of doing business. This
puts the burden on reliable delivery on the sender and the recipient.
That works for some cases, but requires voluntary compliance of all
users (some who know nothing about mail and networks). Each user has
to think about things such as "Is it time to send the mail again? I
don't have an ACK yet."  It is unworkable when mailing to lists (for
which mail needs to be just as reliable), when the receiver is out of
town, etc. etc.  It is especially a burden for those that send and
receive large quantities of mail.

>My opinion is that mail reading software should encourage this
>behavior by suggesting such a reply and having an automatic way of
>generating it.

This just confirms that most people want reliable mail delivery.
Hence, the burden should be shifted from the user to the software used
for the delivery of mail. It is much easier to do this with a
transport level protocol that connects directly with the destination
machine than over an S&F message switching system.

Thomas

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 10:14:33 EST
From:      dcrocker@engr.ub.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Packet network reliability

In article <8703250201.AA06443@flash.bellcore.com>
	karn@FLASH.BELLCORE.COM (Phil R. Karn) writes:

>... In "unlayered virtual circuit" networks, connection
>state information is kept not only in the end-point switches, but also in
>every intermediate switch along the path.
>... Because of this, a node or link failure ANYWHERE along the
>connection path causes an X.25 VC reset, not just failures at the end nodes.
>
>Only in "layered VC" networks such as the DDN (where datagrams are used
>internally) can intermediate node and link failures occur without resetting
>virtual circuits.  ...

Don't know how much this will contribute to the discussion, but you pushed
one of my buttons:

There are two issues often treated as one:  Virtual Circuit vs. Datagram
underlying architecture, and Robust vs. Fragile handling of major network
anomolies.

It is common for VC-oriented nets to be relatively more Fragile than
the DG-oriented ones, but that definitely is not necessary.  It has more
to do with certain economies that are perceived by the implementors.

X.25 vendors are excellent examples of the VC/Fragile orientation.  By
virtue of being very cost-conscious, they pay very close attention
to such things as packet-handling "efficiencies" and buffer management.
The handling efficiency question walks them down the path of internal
VC orientation.  (Common belief:  The processing overhead to forward a
packet in a VC-oriented system is lower than in a DG-oriented one.)

The buffer management question makes them give up a buffer as soon as the
"next" hop has acknowledged it.  That is, the only copy of the data
exists at the latest node to have accepted it.  If that node goes down,
the copy is lost.

Your note used the term "end to end reliability".  That is exactly the
issue.  The sending node must hold onto a copy of the data until the
receiving node acknowledges deliverying it to the destination host.
If it does this, than an internal X.25 Reset (for example) could be
transparently recovered from, by re-routing the circuit automatically.

A few years ago, I tried to get Databit (Siemens) to modify their
X.25 packet switches to permit holding on to the packet at the sending
node, until a final ack was received.  They were not willing to consume
buffers for that long.

By the same token, BBN could modify their switches NOT to hold on to
packets at the source PSN.  At that point, a number of problems internal
to the net would become highly visible to users.

Dave

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 11:00:00 EST
From:      GBELING@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   tp4 on sun

hello, 
maybe someone can help us*
we are implementing an OSI-transport protocol tp4 under unix systems. 
so far it worked well on a vax 750 under 4.2 bsd. 
now we try to do the same on a sun 2/50 under os 3.2 (there equivalent 
of 4.2 bsd). we encountered problems when trying to access the 
IP raw socket on this sun, especially using the system calls:
SENDTO and RECEIVEFROM which seem not to work. 
has anyone ever tried to use the raw IP socket and encountered a 
similar problem ??????
thanks gerd beling FGAN west-germany
  

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 1987 11:00-EST
From:      GBELING@A.ISI.EDU
To:        paal@NTA-VAX.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        GBELING@A.ISI.EDU
Subject:   tp4 on sun
hello, 
maybe someone can help us*
we are implementing an OSI-transport protocol tp4 under unix systems. 
so far it worked well on a vax 750 under 4.2 bsd. 
now we try to do the same on a sun 2/50 under os 3.2 (there equivalent 
of 4.2 bsd). we encountered problems when trying to access the 
IP raw socket on this sun, especially using the system calls:
SENDTO and RECEIVEFROM which seem not to work. 
has anyone ever tried to use the raw IP socket and encountered a 
similar problem ??????
thanks gerd beling FGAN west-germany
  
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Tue 31 Mar 87 14:19:46-PST
From:      Stu Grossman <GROSSMAN@Sierra.Stanford.EDU>
To:        tsuchiya@GATEWAY.MITRE.ORG
Cc:        ddp#@[128.2.11.131], tcp-ip@SRI-NIC.ARPA, x3s33-interest@GATEWAY.MITRE.ORG
Subject:   Re:  danger of bridges
Regarding DECnet HELLOs:

1) You are correct regarding the settability of the DECnet hello timers.
   These (by default) are 15 seconds, but can be set to any value, as
   timer value is sent out over the network for each host.
2) The hellos are sent to a multicast address that is only enabled by
   DECnet 'routers'.  Non-routers (known as 'endnodes') do not receive
   these messages.

Yes, these messages do eat up some Ethernet bandwidth, but intelligent
controllers pitch them if the host isn't interested.  I think the real
issue here is really "how often do I have to wait to acquire the
Ethernet?"  DEC controllers keep track of this information in a counter
known as "Deferred transmits".  My experience with a cable segment with
over 400 DECnet nodes, a bunch of LAT boxes and some TCP/IP traffic is
that this counter was quite low (well under 1% of all the transmits from
the node in question**).

It would be really interesting to find out the values of things like
deferred transmits, single collision transmits, and multi-collision
transmits vs. total transmits for various host and gateway interfaces.

			Stu Grossman

** Actual mileage may vary.
-------
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 1987 14:01:02 CST
From:      AFDDN.TCP-IP@GUNTER-ADAM.ARPA
To:        Dave Crocker <dcrocker%engr.ub.com@RELAY.CS.NET>, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Packet network reliability
I'm in the same boat with Dave; VC versus datagram is one of my buttons.

I'm much more familiar with the BBN way of doing things than with PDNs.  I can
see where PDNs would want to have very tight control over everything going on
in the network.  Tightly binding resources in a single virtual path through the
network does let you know what resources are going where and for how long.  I
think it also tends to stabilize network delays around some median which might 
be nice.  You can also establish stable (fixed) routing.  Some nets I believe
have a single route source that has global knowledge of the network and returns
routes to the net nodes for every connection request.  The disadvantage I see 
is that every VC will use up a given amount of net resources whether data is
actually being transmitted across the VC or not.  In the cases where static
routing is downloaded from a central site, the survivability of the network as
a whole is only as good as that of the central site.
BBN gets around these two disadvantages at a cost.  The Milnet for instance
is gettingvery large, very fast.   I don't know the formula for computing the
amount of bandwidth required for the internal routing updates, but I would 
suspect it would go up exponentially with the number of nodes(and connectivity
of them).  If anybody knows the numbers I'd like to have them.

The current limit of 256 nodes on one network has already been reached for
Milnet.  They nodes aren't installed and operational yet, but the addresses
have been allocated to future nodes.  And even with the size of the backbone,
there are nodes with 12-18 hosts connected or slated for connection.  Maybe
we need "butter" switches?

Darrel B.
-------
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 15:01:02 EST
From:      AFDDN.TCP-IP@GUNTER-ADAM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Packet network reliability

I'm in the same boat with Dave; VC versus datagram is one of my buttons.

I'm much more familiar with the BBN way of doing things than with PDNs.  I can
see where PDNs would want to have very tight control over everything going on
in the network.  Tightly binding resources in a single virtual path through the
network does let you know what resources are going where and for how long.  I
think it also tends to stabilize network delays around some median which might 
be nice.  You can also establish stable (fixed) routing.  Some nets I believe
have a single route source that has global knowledge of the network and returns
routes to the net nodes for every connection request.  The disadvantage I see 
is that every VC will use up a given amount of net resources whether data is
actually being transmitted across the VC or not.  In the cases where static
routing is downloaded from a central site, the survivability of the network as
a whole is only as good as that of the central site.
BBN gets around these two disadvantages at a cost.  The Milnet for instance
is gettingvery large, very fast.   I don't know the formula for computing the
amount of bandwidth required for the internal routing updates, but I would 
suspect it would go up exponentially with the number of nodes(and connectivity
of them).  If anybody knows the numbers I'd like to have them.

The current limit of 256 nodes on one network has already been reached for
Milnet.  They nodes aren't installed and operational yet, but the addresses
have been allocated to future nodes.  And even with the size of the backbone,
there are nodes with 12-18 hosts connected or slated for connection.  Maybe
we need "butter" switches?

Darrel B.
-------

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 15:33:29 EST
From:      jas@MONK.PROTEON.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Response to anti-bridge comments

Phil, your message does not exactly answer Norman's question.  Most
(not all) bridge vendors have loop detection algorithms that allow you
to have hot-standby bridges.  However, they are only hot-standby
bridges.  The very nature of bridges prevents you from doing load
sharing (unless you manually program the filtering/forwarding
databases, giving up the advantages of adaptive bridges).  Gateways
with multipath internal routing algorithms can do load sharing, look
at BBN's PSN software using SPF on the ARPANET and MILNET.  Sooner or
later, a network gets big enough and complicated enough that one
migrates from bridges to routers.

What the advocates are arguing about is where the line between bridges
and routers is.

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Mar 87 12:01:22 WET
From:      jon@Cs.Ucl.AC.UK
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Response to anti-bridge comment
/* Written  8:22 am  Mar 31, 1987 by kincl%hplnmk@com.hp.hplabs in pyr1:tcp-ip */
/* ---------- "Re: Response to anti-bridge comment" ---------- */
Received: from ucl-cs-nss by pyr1.Cs.Ucl.AC.UK   with SMTP  id aa05565;
          31 Mar 87 8:21 WET
Received: from sri-nic.arpa by mv1.Cs.Ucl.AC.UK   via Satnet with SMTP
           id aa05190; 31 Mar 87 8:20 WET
Received: from hplabs.HP.COM by SRI-NIC.ARPA with TCP; Mon 30 Mar 87 10:27:05-PST
Received: from hplms1 by hplabs.HP.COM with TCP ; Mon, 30 Mar 87 10:25:06 pst
Received: from hplnmk (hplnmk) by hplms1; Mon, 30 Mar 87 10:24:38 pst
Return-Path: <kincl@hplnmk>
Received: from hplnmk.hpl.hp.com by hplnmk ; Mon, 30 Mar 87 10:29:16 pst
Message-Id: <8703301829.AA06404@hplnmk>
To: "Phil R. Karn" <karn@com.bellcore.flash>
Cc: tcp-ip@arpa.sri-nic
Subject: Re: Response to anti-bridge comments
In-Reply-To: Your message of Thu, 26 Mar 87 15:20:26 -0500.
             <8703262020.AA27749@flash.bellcore.com>
Date: Mon, 30 Mar 87 10:29:13 PST




Question:  How well would all this work if you decided that you need
redundant routes or if you decided that you do not want a start topology
but have an arbitrary topology?  Can you have a configuration like the
following:

        ---------------Ethernet-----------------
               |                       |
               |                       |
             Bridge                  Bridge
               |                       |
               |                       |
        ---------------Ethernet-----------------
               |                       |
               |                       |
             Bridge                  Bridge
               |                       |
               |                       |
        ---------------Ethernet-----------------

Yes, but.

At UCL we run a mini internet with 5 sites interconnected by
Megastream (thats 2.Mbps not T1) lines. We also run a lot of
LAN technology, mostly ethernet. We reckon that it's swings and
roundabouts whether we use MAC Bridges or Network Level relays
(to use ISO jargon). TYhere is an emerging (ISO!) standard for MAC
bridges, and the only thing it is waiting on is how to do loop
resolution and access control (ie the things most people think
are network level things, but ISO are beginning to concede are
different in a LAN/MAN context).

Anyway, its down to
1. performance
2. functionality
   a) traffic control
   b) Fault Isolation
   c) routing/loop resolution
   d) access control
   e) management of all this.

There's absolutely no reason to get layerist about this. if the
addressing and protocols can stand it, there's nothing to
choose between MAC bridges and network lewvel relays if they
happen to do the same job as well. broadcast/multicast limiting
can be done if you use distributed nameservers (and arp klugery
is not a hack, it can be managed properly as a ditributed
multicast system in MAC bridges if you implement it).

two asides:
1. MAC bridges also buy you more trustworthy access control, since
it's harder to spoof physical address without being spotted
than to spoof IP/network level address, specially if you dont
buy the wrong LAN.
2. MAC bridges usually perform, better - eg NFS works through
them - you have to kludge the silly numbers in the mount
table to get it to go even through a cisco box - one of the
better IP gateways around.

We use network level relays (IP gateways) between sites over
the megastream, and predominantly MAC bridges within sites. The
choice seems to have made sense in terms of managing the
system, but I suspect that we just got good hardware and
software, and that's what counts in the end.
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Tue 31 Mar EST 1987 17:04
From:      anon@citi.umich.edu
To:        tcp-ip@sri-nic.arpa
Subject:   overloaded station wagon
Forgive my inexperience at these things.
I was just under the impression
that such conversations are usually carried on elsewhere.
I am being forced to filter my mail,
to distill other more useful information on TCP/IP.
This reminds me of my real mailbox,
often stuffed with 5-cent ground beef coupons.
Again, forgive my ignorance.
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 17:19:22 EST
From:      GROSSMAN@SIERRA.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  danger of bridges

Regarding DECnet HELLOs:

1) You are correct regarding the settability of the DECnet hello timers.
   These (by default) are 15 seconds, but can be set to any value, as
   timer value is sent out over the network for each host.
2) The hellos are sent to a multicast address that is only enabled by
   DECnet 'routers'.  Non-routers (known as 'endnodes') do not receive
   these messages.

Yes, these messages do eat up some Ethernet bandwidth, but intelligent
controllers pitch them if the host isn't interested.  I think the real
issue here is really "how often do I have to wait to acquire the
Ethernet?"  DEC controllers keep track of this information in a counter
known as "Deferred transmits".  My experience with a cable segment with
over 400 DECnet nodes, a bunch of LAT boxes and some TCP/IP traffic is
that this counter was quite low (well under 1% of all the transmits from
the node in question**).

It would be really interesting to find out the values of things like
deferred transmits, single collision transmits, and multi-collision
transmits vs. total transmits for various host and gateway interfaces.

			Stu Grossman

** Actual mileage may vary.
-------

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 17:29:14 EST
From:      anon@CITI.UMICH.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   overloaded station wagon

Forgive my inexperience at these things.
I was just under the impression
that such conversations are usually carried on elsewhere.
I am being forced to filter my mail,
to distill other more useful information on TCP/IP.
This reminds me of my real mailbox,
often stuffed with 5-cent ground beef coupons.
Again, forgive my ignorance.

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 17:44:00 EST
From:      honey@CITI.UMICH.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Tcp/Ip vs a store & forward network

a man after my own heart -- reinventing uucp.

i'm with you, bro'.

	peter

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 1987 17:44 EST
From:      honey@citi.umich.edu
To:        HANK@BARILVM.BITNET, tcp-ip@sri-nic.ARPA
Subject:   Re:  Tcp/Ip vs a store & forward network
a man after my own heart -- reinventing uucp.

i'm with you, bro'.

	peter
-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Mar 87 13:05:29 WET
From:      jon@Cs.Ucl.AC.UK
To:        tcp-ip@sri-nic.arpa
Subject:   Tcp/Ip vs a store & forward network
Actually, I thought the Internet WAS a store-and-forward network. Gateways
store up packets as they are received and forward them after a queueing
delay.  I think you really meant "message switching" as opposed to "packet
switching".

Yep. In the UK we use a spooled FTP system called NIFTP
(Network independant file transfer protocol). This works over
anything and we have it on 11/44s on Cambridge rings, vaxen and
pyramid, TCP/IP over ethernet. The spec says you can
checkpoint files, so it will work over junk networks without
having to break large files down yourself. It also does binary
etc, and it does some sorts of run-length encoding, for people
with 30bps packet radio nets! It also has sensible
authentication, unlike ftp which seems happy to send LOGIN passwords
around on networks without encryption (try and sell that to a
commercial company with ethernet).

The spec may be got from the Joint Network Team in the UK.
Implementations for ?NIXs exist. Why reinvent the wheel, when
you can get a halftrack for free - or
you could wait for FTAM.

jon
-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 18:28:41 EST
From:      ddp#@ANDREW.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  danger of bridges

Well that is certainly good news, but I have a question...  If DECnet
endnodes don't enable listening to Hello's, then how do two endnodes
communicate on a network consisting only of themselves?  Seems like they'd
have to be listening on some sort of routing multicast address.

Drew

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 19:08:28 EST
From:      haas%utah-gr@CS.UTAH.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Packet network reliability

In article <8703312012.AA25019@ucbvax.Berkeley.EDU>,
AFDDN.TCP-IP@GUNTER-ADAM.ARPA writes:

> Tightly binding resources in a single virtual path through the
> network does let you know what resources are going where and for how long...

True, this was a major motivation for Telenet's conversion to VC internals.

> Some nets I believe have a single route source that has global knowledge of
> the network and returns routes to the net nodes for every connection
> request.

The earliest version of Tymnet used something like this.  The system did not
scale up, not so much because of the reliability problem but because of the
enormous amount of traffic to and from the Master User Directory.  This
approach is no longer used.

> The disadvantage I see is that every VC will use up a given amount of net
> resources whether data is actually being transmitted across the VC or not.

Only a small table entry is used.  This is in practice less costly than
the communications resources used to convey a complete address in every
packet.

> In the cases where static routing is downloaded from a central site, the
> survivability of the network as a whole is only as good as that of the
> central site.

True.  Tymnet went to four regional sites for routing information, which
helps with robustness and distributes the traffic a little more evenly.
Telenet assigns net addresses geographically, and each TCO routes based
on the implicit geographic information in the Call Request packet.
Thus each TCO can make routing decisions independently of any central
source of routing information.  This is very robust.

Cheers  -- Walt

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 19:56:55 EST
From:      GROSSMAN@SIERRA.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  danger of bridges

Good guesswork!  Endnodes do indeed listen to a special multicast address.

A breif explanation:  When a DECnet endnode wants to send a datagram, it
sends it to a DECnet node known as the 'Designated Router'.  The
designated router is known by the endnode because he periodically emits a
special hello message to say who he is.  Now, theres a little bit more glue
and filler to deal with getting the endnode to use a more direct route if
possible (such as if the dest node is on the same ethernet), and cacheing
of the next hop (ie: best gateway) to get to a specified node.

Just to throw another monkey into the wrenchworks, there is the added
feature that the designated router can move around!  There's a little bit
of protocol and stuff that arbitrates who gets the honor, but theres no
special setup needed to establish the DR.  Oh yeah, just one more thing,
just in case there is NO DR at all, the endnode can still talk to other
systems on the same wire, it just computes the Ethernet address from
the DECnet address, and sends the datagram!

	Stu Grossman
-------

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31-Mar-87 20:05:15 EST
From:      mullen@NRL-MPM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   obnoxious broadcast messages

> broadcast message from temp!root:  This is a test of area coverage. Please send me a nasty indignant flame
> if you get this broadcast.
> 
>                                        Jordan (jkh@violet.berkeley.edu)

I have gotten several of these broadcast messages (equivalent to
a "wall") today on various Unix systems on my local network.

	1.  Who is this person, jkh@violet.berkeley.edu?
	2.  Why are we being bothered with these messages?
	3.  How is it being done?
	4.  How can we stop this nuisance?

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 00:10:51 EST
From:      ROMKEY@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   interesting new product I ran across

This crossed my desk today and I thought some people out there might have
some interest in it. I don't mean to advertise on the net, I mean, after all,
*I* certainly have no connection with "FTAM Hardware, Inc.".
					- john romkey
					FTP Software, Inc.


FTAM Hardware, Inc			Product Announcement PA0000

	The Illudium Q-2 Explosive Network Demodulator

The Illudium Q-2 Explosive Network Demodulator is a must for all network
installations. It eliminates dangerous modulations from your network.
It features a 100Hz low pass filter; now all your hosts will show the
same performance on network operations!

Standard features include Ethernet, IEEE, ARPANET, SATNET, ProNET-10
and synchronous and asynchronous serial line compatability.  TCP/IP,
DECnet, XNS, Chaosnet, SNA and ISO modes available. NETBIOS interface
standard, and the Network Demodulator will attempt to negotiate into
3270 emulation mode when possible. Supports Berkeley Unix protocols.
Converts trailers into Recreational Vehicles.

Microwave, infrared and fiberoptic options are available, though the
standard kit works with phone lines.

The Illudium Q-2 Explosive Network Demodulator includes a network
monitoring feature, with, as a standard feature, a command that will
monitor the network to tell you your choice of Jon Postel's, Vint
Cerf's, Dave Mills' or Richard M. Stallman's password (special
hardware support provided for the latter). Also has facilities for
seeing who IBM, DEC and AT&T are sending packets to, now that they're
all connected to the same network.

Tempest certified. One size fits all. Fully compliant with the ULANA
and GOSIP specifications. Implements full source-routing and security
features. Available in green, red, blue and plaid cases.

Requires GNU Emacs Version 78.90 or later, and 200Mb physical memory
(188 for Emacs, 12 for the Illudium Q-2 Explosive Network Demodulator).

(The Illudium Q-2 Explosive Network Demodulator is also useful for for
handling obstacles which obstruct your satellite link to Venus.)

Order by midnight tonight and receive these free gifts:

The Ginzu ethernet splicer!

The TJ Watson memorial EBCDIC decoder ring!

and

the Vint Cerf Programmable Calculator which takes as input a data
storage medium and a mode of transportation and calculates your bit
rate!

("where's the kaboom? there's supposed to be a network-shattering kaboom!")
-------

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 00:17:12 EST
From:      gds@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Tcp/Ip vs a store & forward network


     A reasonable compromise would be a confirmation that the message
     has been placed in the recipients mailbox.

If you'll allow that the message has been placed in the user's maildrop
(/usr/spool/mail/user), sendmail has a feature such that if it receives
mail with the header Return-Receipt-To:, it will generate an ack to the
address listed there.  (The address must be replyable from the
receiver's context, so it must contain a full reverse path for a
reliable ack.)  You are pretty much guaranteed that the mail has been
committed to stable storage (if not the maildrop, the sendmail spool).

     Presumably, as domain names get extended, we will be able to
     do that.  Any mail you send to a user can go directly to the machine
     where the his/her mailbox resides. No forwarding at the site would be
     needed.

I'm not sure what you mean by this.  In the ARPA Internet, mail goes
directly from the sender's site to the recipient's site unless
forwarding is specified.  UUCP requires forwarding at intermediate
nodes.  Even if the UUCP namespace were entirely mapped out, you
couldn't have mail going directly from sender machine to recipient
machine unless everyone called everyone else, which will never happen.

I think we're mixing concepts here a bit.  "reliable delivery" to
gds@spam.istc.sri.com is accomplished when something has been delivered
to a process on spam.istc.sri.com which will leave the mail where "gds"
can access it.  "reliable delivery" to the human Greg Skinner requires
that he read it.  I think it would be asking too much to modify mail
software to require acks, not to mention a problem for sites which don't
have source.

--gregbo

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 03:31:41 EST
From:      HANK@BARILVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Remote access in Bitnet

(Caveat - This description is primarily for people who have no idea how
 Bitnet works.)

Greg,

The concept of remote access doesn't exist in Bitnet.  The protocols in
Bitnet are as follows:

1) One-way File Transfer - any user is allowed to send a file to any other
   user.  Since the file ends up in the destination users spool system
   (or some emulation thereof) there is no problem with access control.

2) Interactive Message - any user can send a one line message (max 160
   characters) to any other user.  All you need to know is the destination
   user and node.  If the user is not logged on or a link is down you are
   told so.

Based on these two primitives - Bitnet has built various other
pseudo-protocols.  From #1 above - we are able to do mail, list explosion,
computer conferencing, general file transfer.  From #2 above, Bitnet has
developed a CB (Chat) system.

By combined both of the basic primitives above, a file server can be set
up at any node that will trap incoming 'Interactive Messages' - which
contain a command and process the command and send the results back to the
user via the 'One-Way File Transfer' mechanism.  This method allows users
to sit at their machine and issue commands like DIR or LIST to some remote
file server and then issue some SEND commands to retrieve the files they
want.  There is no need in that case to do any sort of remote connect
(anonymous FTP).

Most servers (200+) in Bitnet also accept transactions via files or RFC822
mail.  Lately, various servers in Arpanet have decided that is also a 'clever'
thing to have, so we have things like archive-request@simtel20.arpa and
service@sri-nic.arpa popping up (I expect more before the end of th year).

So to answer your question:

> a remote file they own

They cannot access it.  Yup would be nice and that is just one reason why
Bitnet should convert to Tcp/Ip.  Incidentally, there is a program I
distribute in Bitnet that allows this remote access to a file the person
owns but it is a private convention.  The program runs as a task (and
therefore must be running when the remote user wants access to his/her files).
and the user needs to set up a remote access password.  It uses the
Interactive Message Primitive to send and receive data, and each command
you want executed on the remote host must be prefixed with your remote pswd.
Not as elegent as TELNET but when the entire concept of TELNET doesn't exist
it is the best one can do.

> a remote file they don't own, but is not protected

Only if the file is available via a remote file server can they access it.

> a remote file they don't own, but is protected

They can't access it.

Hope this helps.

Hank

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 04:44:59 EST
From:      jon@CS.UCL.AC.UK.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: talking of and to gateways and bridges


Chris,

ROS stands for Remote OperationS, and REX stands for Remote
EXexcution. They are part of the ECMA (European Computer
Manufacturers Association) input to draft standards work on
distributed computing. REX is a Birrel & Nelson type
'minimum packet' transaction transport protocol, whilst ROS uses
ASN (Abstract Sysntax Notation) as a presentation layer to
to define call/reply/error messages and parameters and
to provide machine independance of call and reply parameter
representation. The ANSA (Advanced Network Systems
Architecture) research group have put a lot of work into their
design. The goal is to provide a system where code for client/server
model interactions may be generated automatically (RPC type
work), but to allow for other types of interaction too.

jon

END OF DOCUMENT