The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      01 Feb 88 13:46:19 EST (Mon)
From:      dm@bfly-vax.bbn.com
To:        ddc@xx.lcs.mit.edu
Cc:        adrion@sh.cs.net, iab@venera.isi.edu, npag@louie.udel.edu, steve@note.nsf.gov, tcp-ip@sri-nic.ARPA, csnet-ec@sh.cs.net, adrion@cs-umass.ARPA, cosepup@postgres.berkeley.edu, dm@bfly-vax.bbn.com
Subject:   Re: Help...looking for network anecdotes

    ``The development of COMMON LISP would most probably not have been
    possible without the electronic message system provided by the
    ARPANET.  Design decisions were made on several hundred distinct
    points, for the most part by consensus, and by simple majority ote
    when necessary.  Except for two one-day face-to-face meetings, all
    of the language design and discussion was done through the ARPANET
    message system, which permitted effortless dissemination of
    messages to dozens of people, and several interchanges per day.
    The message system also provided automatic archiving of the entire
    discussion, which has proved invaluable in preparation of this
    reference manual.  Over the course of thirty months, approximately
    3000 messages were sent (an averabe of three per day), ranging in
    length from one line to twenty pages... It would have been
    substantially more difficult to have conducted this discussion by
    any other means, and would have required much more time.''

		Guy Steele, ``COMMON LISP: the language'' (Digital
		    Press, 1984).  pp xi-xii.



-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 88 12:57:11 GMT
From:      backman@interlan.UUCP (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell

In article <[A.ISI.EDU]26-Jan-88.08:13:44.CERF> CERF@A.ISI.EDU writes:
>NOVELL Netware and TCP/IP have been made to interoperate by Novell.
>
>I do not know any of the details of the software or how one conveys
>the desired IP destination to the TCP/IP server. It may behave like
>TELNET piggybacking (where you log into a host and TELNET back out
>again, specifying where you want to go to the User Telnet).
>


	[]

	Sorry to bang the drum loudly but... Micom-Interlan implemented
	the TCP gateway under Netware with OS support from Novell.
	They know Netware, we know TCP.(or kind of).
	Client programs on the gateway were ported from Bsd4.3, they
	look and act exactly the same.  A user wishing to use TELNET goes
	through the following script:

		ipx		/* load Netware driver in workstation*/
		net3		/* load Netware redirector	     */
		
		f:login server\username

		netbios		/* load NETBIOS emulator             */

		gwattach gatewayname   /*make a NETBIOS connection 
				         between PC and server       */

		Telnet vax4


			.....

	The server and gateway are roughly analogous to a real OS with TCP.
	You log on to a file server, prepare your environment, and then
	use TCP as a service.  We ifconfig addresses just like UNIX, and
	have an /etc/hosts file just like UNIX.  In our next release we
	will have domain name resolution...  Hope I clarified things.


						Larry Backman
						Micom - Interlan

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 88 15:51:36 GMT
From:      hrp@ishmael.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP Verification Suite

The TCP/IP community does not have a strong tradition of formal
testing from specifications.  Historically (see RFC-1025, ``TCP and IP
Bake Off''), testing a TCP/IP implementation has meant structured
plugging it in and trying it, with as many other implementations as
possible.

Over the last few years, there has been a movement toward more formal
testing from within the DCA, and they are currently beta testing
(metatesting?) a suite covering every conceivable aspect of all the
MIL-STD protocols: IP, TCP, FTP, TELNET, and SMTP.  The tests are
comprehensive and do find bugs, but require a significant investment
of time and effort to run.

There was a note on the tcp-ip list last year from Bob Jones
(bobj@kauai.mcl.unisys.com) in which he wrote:

    For those who are interested, the DCA is setting up an administrative
    agreement with the National Bureau of Standards to provide for the
    certification of the TCP/IP suite of protocols.  NBS is expected to
    announce for vendors to participate under the National Voluntary
    Laboratory Accreditation Program (NVLAP).  This program is expected
    to be in place sometime in early 1988.  Any questions please call
    DCEC, Jim Tontonoz, 703-437-2038.

This certification would probably involve passing the aforementioned
DCA test suite.
--
Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN  55120
hrp%hall.CRAY.COM@umn-rei-uc.ARPA	ihnp4!cray!hrp	    (612) 681-5884

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 88 16:51:44 GMT
From:      ddc@LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Help...looking for network anecdotes

Rick,
     In fact, I think E-mail is a great story. What seems mundane to
us is a great leap forward to the rest of the world. A spoecific
example just a few months ago: I am on a security working group
considering the  problem of integrity in data processing systems. This
group has both military and commercial security people. When we
started to plan the followup to a workshop, we found ourselves in two
groups: those that could exchange netmail, and those who could not.
The military folks, by and large, had interconnected mail addresses,
and they started proposing actions and schedules that seemed silly to
those with telephone and postal services. At the end, some of the
commercial security folks asked how they could get netmail, as it
seemed essential if they were to keep up with the others.

     Of course, the first netmail story is the building of the network
itself. The builders of the network were its forst users (as is only
fair; they get both the benefit and the pain). It is cldear to me, as
a member of that group, that the group effort necessary to build the
Internet simply could not have succeeded without netmail.

     Another local example is the Clinical Decision Making group at
the Laboratory for Computer Science. They are concerned with computer
support for doctors. They work with computer professionals and, more
to the point, with doctors. The doctors are not at MIT, but at various
medical schools in Boston and elsewhere. Those folks make heavy use of
networks, and in fact caused some of the local med schools to get
attached to the MIT net. Theu use the net for mail, but also for
remote execution of programs, for exchange of data, and for
distributed program interaction. They assert (I just asked them) that
network technology is critical to the way theyu do their work, and
that the patterns of working with remote colleagues would not be
nearly as effective without nets.

     There is nothing special about these stories; they a similar to
many others. But they are local, and real.

Dave Clark

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 88 18:46:19 GMT
From:      dm@BFLY-VAX.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Help...looking for network anecdotes


    ``The development of COMMON LISP would most probably not have been
    possible without the electronic message system provided by the
    ARPANET.  Design decisions were made on several hundred distinct
    points, for the most part by consensus, and by simple majority ote
    when necessary.  Except for two one-day face-to-face meetings, all
    of the language design and discussion was done through the ARPANET
    message system, which permitted effortless dissemination of
    messages to dozens of people, and several interchanges per day.
    The message system also provided automatic archiving of the entire
    discussion, which has proved invaluable in preparation of this
    reference manual.  Over the course of thirty months, approximately
    3000 messages were sent (an averabe of three per day), ranging in
    length from one line to twenty pages... It would have been
    substantially more difficult to have conducted this discussion by
    any other means, and would have required much more time.''

		Guy Steele, ``COMMON LISP: the language'' (Digital
		    Press, 1984).  pp xi-xii.

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 88 19:35:30 GMT
From:      ddc@LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Help...looking for network anecdotes


"All we know is the phenomenon: we spend our time sending messages to
each other, talking and trying to listen at the same time, exchanging
information. This seems to be our most urgent biological function; it
is what we do with our lives."
		Lewis Thomas, "The Lives of a Cell"

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 88 20:09:07 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN 7 End-to-End question.

Thomas,

Please see: "The NSFNET Backbone Network," Proc. 1987 SIGCOMM Symposium and
also recent Internet Monthly reports from U Delaware.

Dave

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 01:19:26 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Hop problem

> the "packet radio" referenced was not the DARPA packet radio but the
> amateur packet radio. I don't know how those systems handle the TTL
> field...

The "amateur Internet" is much like the real Internet -- a mixture of IP
gateways and "digipeaters". Digipeaters are single frequency
store-and-forward repeaters that operate on the source routing fields in
the "AX.25" amateur link level protocol.  Since digipeaters do not
understand IP, they do not modify TTL fields even though they may
introduce considerable delay.  Most amateur packet radio channels
operate at 1200 bps synchronous, with substantial contention and keyup
delays, plus high collision rates due to hidden transmitters.

In general, the TCP/IP nodes on the amateur Internet are PCs running my
TCP/IP implementation (the "KA9Q" package). This includes end-nodes as
well as IP gateways. At present, my code decrements the TTL field by 1
for each pass through a gateway module, including the end hosts.

One of the interesting observations to come out of our experiments so far is
the interaction between the retransmission algorithms in the TCP
(transport) and AX.25 (link) layers. It definitely does *not* pay to try
"too hard" at the link layer. If it takes several extra retransmissions
to get a packet through, chances are that a TCP retransmission will
occur in the meantime and you'll just have to do the same all over again
with another copy. It may be worthwhile to allow control over the "beta"
constant in TCP, perhaps in combination with the "reliability" bit in the
IP header (my gateway code uses this bit to override the per-link default
setting as to whether to use link level acknowledgements or not).

I think we've shown pretty convincingly, though, that you can't use link
level ARQ to sweep fundamental inadequacies in the lower layers under
the rug. This is especially true with channel access algorithms. Our
experiments are now moving toward multi-frequency full duplex gateways
that will eliminate contention and improve channel utilization markedly.

Phil

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 01:31:41 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Help...looking for network anecdotes

Rick,  I have to add in a story about the benefits of e-mail.  A few years
ago I was talking to a random seatmate on the Washington-to-San Francisco
milk run and got around to asking her what she did.  She was a geologist.
She was on a post doc at Stanford.  I asked how the field was progressing
from her perspective.  She said that the field was making dramatic advances
in the past few years because so many geologists were using this new thing
called electronic mail all over the world and they were using it to find out
what others already knew!  They used the mechanisms of e-mail to raise the
level of common knowledge on the leading edge of the field.  No one wants
to spend years doing research in some part that has already been worked
over and the usual method of writing/reading journals was too slow.

I find that dramatic.  And I find that they were mostly using the Arpanet
without "full permission" to be a sad commentary on those of us who know
how valuable this all is to humanity, because we have not found a way
to fund the intellectual interconnection of all researchers in a straight
forward manner yet.  So, please thke this kind of "evidence" and build
te case.

Thanks,
Dan
-------

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 01:53:34 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: PSN 7 End-to-End question.

> 1) Best effort systems rely totally on hosts for congestion
> management. That is, transport protocols are responsible for
> congestion control and congestion avoidance.

The problem with the existing flow control mechanisms in the ARPANET is
that they add considerable overhead even when the network is otherwise
lightly loaded. As I understand it, the ARPANET links all run at 56kbps;
so in theory they could carry 7 kilobytes/sec. However I've *never* seen
a file transfer throughput of more than 2.5-3.0 kilobytes/sec, even over
a short East Coast path in the middle of the night. My timings are
consistent enough that I can only attribute the difference to the
ARPANET's internal packetizing and flow control overhead. (If there are
other factors at work I'd like to know about them).

Yes, transport protocol behavior is important, but there's no reason why
the "best effort" network can't have defense mechanisms that activate
only when the network is congested.  For example, the network might
normally run in a pure datagram mode, with no network bandwidth wasted
on edge-to-edge acknowledgements. However when the network becomes
congested, the internal equivalent of "source quench" packets are sent
to the entry node, telling it to stop injecting so much traffic into the
network. The entry node might translate that into an access protocol
message telling the host (or gateway) to slow down, but more importantly
the entry node could simply delay or discard additional traffic before
it enters the network. Discarding packets is certainly one way to get
TCP's attention, but the delaying tactic would be more efficient.

There have been theoretical assertions that even infinite buffering is
insufficient to prevent datagram network congestion. However, this
assumes no interaction between the network and the transport protocol,
and this is certainly not true with TCP.  TCP cannot transfer more than
one window's worth of data per round trip time, so to slow it down you
either reduce the window size or increase the round trip time. If you
can't get it to reduce its window size voluntarily (e.g., with a source
quench) then you can certainly increase its round trip time (i.e., with
additional buffering). Given a finite number of TCP connections, enough
buffer space will eventually reduce the offered datagram load to the
capacity of the network, although everyone would be better served if the
TCPs could instead cut their window sizes. NFS and ND are not completely
uncontrolled, rather they are basically stop-and-wait protocols. They
would behave well too if only they did retransmission backoff like TCP.

A lot of effort has gone into tuning TCP round trip time estimates.
Question: has anyone looked into techniques for tuning TCP window sizes?
Intuitively, I expect that increasing the window size for a TCP-based
file transfer would increase throughput until the slowest link in the
path saturates. Beyond this point, throughput would remain constant but
round trip delay would goes up, unnecessarily increasing delay for other
users of the same path. It would be nice to find an algorithm that found
and operated at this optimal operating point automatically. Any ideas?

Phil

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 02:04:48 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Hop problem

In article <919@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes:
> The "amateur Internet" is much like the real Internet -- a mixture of IP
> gateways and "digipeaters"....

Oops, what I meant to say here was that the amateur network is much like
the real Internet in that both consist of a mixture of IP gateways and
lower level entities that don't understand IP. 

The amateur packet radio internet includes its non-IP "digipeaters" in
the same way that the "real" Internet includes X.25 packet switches,
Ethernet repeaters and bridges.  Depending on the specific network
configuration, either the IP-level gateways or the subnetwork level
components may do the bulk of the work.

Phil

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 02:36:43 GMT
From:      greg@vertical.oz (Greg Bond)
To:        comp.protocols.tcp-ip,comp.lang.c
Subject:   Re: C binding interfaces for TCP/IP

In article <610@cresswell.quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes:
> In article <7202@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> > 	[talks about Sun XDR protocol]
> > it up in the Sun reference manual and found that it had FAR too much
> > overhead for my purposes.  I ended up implementing my own scheme that
> > runs much faster.
> 
> How can a program run much faster than a PROTOCOL?
> The protocol is one thing, the source-code implementation of it that
> SUN give away is quite another.

Correct. If the PROTOCOL requires significant overhead of bytes on the wire,
then the IMPLEMENTATION will be limited in the speed it can achieve, no matter 
how good the code implementing it is.

We may say that "standards" are more important than efficiency. In this
case, Doug seems to have made the judgement that the application
required an efficiency un-obtainable with XDR spec, and invented his
own, and assumed the support responsibility etc.

Yes, the protocol is not the implementation. But great implementation may
not save a poor or inappropriate protocol.

[ I make this as a general point; I have no knowledge of XDR per se ]
-- 
#define WHOAMI   Gregory Bond,  Vertical Software, Melbourne, Australia
#define ADDRESS  greg@vertical.oz, uunet!vertical.oz!greg
#define JOKE     Ain't no-one here but us chickens...
#include	<standard/disclaimer>

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 05:06:40 GMT
From:      cscosl!yf@ncsuvx.ncsu.edu  (Yen Fu-Shin)
To:        tcp-ip@sri-nic.arpa
Subject:   Old articles and RFC

	Does anyone know where I can find old articles?
	where I can find RFC-1008, RFC-1007 and RFC-1006.
-------
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 14:27:00 PST
From:      <art@acc.arpa>
To:        "thumper!karn" <thumper!karn@faline.bellcore.com>
Cc:        tcp-ip@sri-nic.arpa
Subject:   TCP window sizing

>A lot of effort has gone into tuning TCP round trip time estimates.
>Question: has anyone looked into techniques for tuning TCP window sizes?
>Intuitively, I expect that increasing the window size for a TCP-based
>file transfer would increase throughput until the slowest link in the
>path saturates. Beyond this point, throughput would remain constant but
>round trip delay would goes up, unnecessarily increasing delay for other
>users of the same path. It would be nice to find an algorithm that found
>and operated at this optimal operating point automatically. Any ideas?

Phil,

Have you seen any of Van Jacobsen's work on TCP?  His algorithms include
dynamically adjusting the TCP window based on Acks and Timeouts in an
attempt to optimize the widow for current congestion levels.  He has
done some very good process control analysis to understand the dynamics
of the system.

						Art Berggreen
						art@acc.arpa

------
-------
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 88 12:26:58 est
From:      Denis Haskin <dhaskin%lucy.wellesley.edu@RELAY.CS.NET>
To:        info-vax@lucy.wellesley.edu, tcp-ip@SRI-NIC.ARPA, big-lan%suvm.bitnet@cunyvm.cuny.edu, dhaskin@lucy.wellesley.edu
Subject:   Xyplex MAXserver 5000
Has anyone had any experience with the Xyplex MAXserver 5000 (in any
configuration), in any kind of environment?  Their glossy and the information
available thus far in the trades is not really very detailed, and I am be
particularly interested in any hands-on experience. 

Please respond directly to me (I cannot regularly read the tcp-ip list because
of the volume of traffic) and I will summarize back to these lists.

Thanks, and apologies if you received duplicates because of the cross-posting.

Denis W. Haskin, Network Manager
Wellesley College                 DHaskin@Lucy.Wellesley.Edu -or-
Wellesley, MA  02181              Denis@Bambam.Wellesley.Edu
617-235-0320 x3123

-------
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 88 12:50:47 est
From:      Denis Haskin <dhaskin%lucy.wellesley.edu@RELAY.CS.NET>
To:        info-vax@lucy.wellesley.edu, tcp-ip@SRI-NIC.ARPA, big-lan%suvm.bitnet@cunyvm.cuny.edu
Subject:   Let me dispel any myths about my illiteracy
> Has anyone had any experience with the Xyplex MAXserver 5000 (in any
> configuration), in any kind of environment?  Their glossy and the information
> available thus far in the trades is not really very detailed, and I am be
> particularly interested in any hands-on experience.               ^^^^^^^^

Sigh.  I really can speak English, although it may not appear that way.
"I am particularly..."

That's embarrassing...

Denis


-------
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 12:08:17 GMT
From:      merlin@hqda-ai.UUCP (David S. Hayes)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   FTP Directory listings under TOPS-20


     I have been having trouble doing FTP to Arpanet hosts using
the TOPS-20 operating system.  They support filenames of the sort

     	  Device:<dir1.dir2...>file.type.version

     I want to find out what legal choices exist for "device" and
the directory heirarchy.  This is easy to do when FTP-ing to a
Unix host, but I don't know how to do it when the host is running
TOPS-20.

     Can anyone enlighten me?  This is particularly important,
because I know there are many good things on the archives at
SIMTEL-20, but I don't know how to get a list of what's available.

     (send *advance* :insert 'thanks)

-- 
David S. Hayes, The Merlin of Avalon	PhoneNet:  (202) 694-6900
UUCP:  *!uunet!cos!hqda-ai!merlin	ARPA:  ai01@hios-pent.arpa

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 13:48:42 GMT
From:      larry@pdn.UUCP (Larry Swift)
To:        comp.protocols.tcp-ip
Subject:   Re: Visa paper draft Finally available

I give up:  what is Visa, and why might I want a copy of the draft?


Larry Swift                     UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1988 19:22-EST
From:      CERF@A.ISI.EDU
To:        cheriton@PESCADERO.STANFORD.EDU
Cc:        pogran@CCQ.BBN.COM, robert@SPAM.ISTC.SRI.COM tcp-ip@SRI-NIC.ARPA
Subject:   Re: PSN 7 End-to-End question.
Dave,

good questions! There was an attempt at a truly datagram network in
the early 1970's. It was developed by Louis Pouzin and Hubert
Zimmermann and, I think, Gerard LeLann. They worked at IRIA which
is now known as INRIA (National Research Institute on automation and
information processing) in France. The network was called CYCLADES.

I am sorry I don't have references at hand (I am on travel using a small
laptop for comm), but my recollection is that they experienced packet
loss rates up to 48% when the network became congested. The ARPANET E-E
protocols are intended to push back towards the source soon enough to 
avoid sustained loss rates of that magnitude, as I understand them.

Lean and mean often applies best when the resources are plentiful, but
can become a liability if the network is permitted to enter a congested
state.

Vint
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 17:06:06 GMT
From:      robert@pvab.UUCP (Robert Claeson)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk,comp.protocols.tcp-ip.ibmpc
Subject:   Advice on TCP-IP/NETBIOS/APPLETALK interconnection sought

Netlanders,

   Assume a company or institution that has a few UNIX file-servers
running NFS or RFS, some workstations running UNIX and a number of
PC's and/or Mac's. The network is based on IEEE 802.3 and uses
TCP/IP as its primary protocol.

I want to be able to use laser printers (PostScript, of course)
from a PC or a Mac, log in to a UNIX machine via the network,
send electronic mail back and forth between the machines and
possibly use the UNIX file servers to store DOS or Mac files.

What would be the best solution to integrate these two or three
environments? Should I use TCP/IP, NFS, TELNET
and SMTP on all computers? (Does it even exist?)
Have I better use TCP/IP, NETBIOS and EtherTalk on the same cable
and some kind of gateway between them? Does such a thing exist?

I would appreciate any comment, suggestion and opinion on
this, since these and related questions will probably arise soon,
not only for me, but for many other as well.

Thanks,
   Robert
-- 
Robert Claeson, System Administrator, PVAB, Box 4040, S-171 04 Solna, Sweden
eunet: robert@pvab
uucp:  sun!enea!pvab!robert

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 17:50:47 GMT
From:      dhaskin@lucy.wellesley.EDU (Denis Haskin)
To:        comp.protocols.tcp-ip
Subject:   Let me dispel any myths about my illiteracy

> Has anyone had any experience with the Xyplex MAXserver 5000 (in any
> configuration), in any kind of environment?  Their glossy and the information
> available thus far in the trades is not really very detailed, and I am be
> particularly interested in any hands-on experience.               ^^^^^^^^

Sigh.  I really can speak English, although it may not appear that way.
"I am particularly..."

That's embarrassing...

Denis

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 19:03:58 GMT
From:      Z3000JD@AWITUW01.BITNET
To:        comp.protocols.tcp-ip
Subject:   'ARP-Server for ULTRIX'

We have a TCP-IP gateway from TCP/IP Ethernet to CDCNET.
This gateway does not support the ARP-Protocol.
On the TCP-Side we have a MicroVAX runnin ULTRIX.
Does anyone now how I can configure the UTRIX machine so it can work
as a ARP-responder for the Internet-address of the TCP-IP Gatway.

Johannes Demel
Technical University Vienna
Z3000JD@AWITUW01.BITNET

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 19:32:51 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP Verification Suite

> The TCP/IP community does not have a strong tradition of formal
> testing from specifications.  Historically (see RFC-1025, ``TCP and IP
> Bake Off''), testing a TCP/IP implementation has meant structured
> plugging it in and trying it, with as many other implementations as
> possible.

Actually, I think there is a lot to be said for this approach.  Formal
verification is difficult, slow and expensive, while the informal
testing of a new implementation on the real Internet quickly shows
whether it's likely to work in actual use.  The real world has a way of
revealing things that remain stubbornly hidden in the lab.

The TCP/IP experience has shown that finding clear-cut protocol
violations is not difficult. The *real* issues are

a) getting rid of gaps and ambiguities in the specs themselves that can
allow different implementations to "conform" yet not be interoperable, and

b) figuring out how to armtwist the vendor of a broken implementation to
fix it once a problem has been identified.

Formal verification suites attack neither of these problems.

Phil

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 22:11:17 GMT
From:      bob@zog.PRC.Unisys.COM
To:        comp.protocols.tcp-ip
Subject:   Performance Data Wanted

Does anyone know of published performance data on TCP/IP for various
hardware?  That is, how many packets per second should a given CPU be
able to send, exclusive of the subnetwork protocol or the
communications medium?

I am particularly interested in data for the VAX 11/785, but will take
data for any CPU.

Please note that I am not interested in simply answering this
question, but in finding public, non-proprietary measurements that can
be publicly cited.

Thank you.

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 22:27:00 GMT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   TCP window sizing


>A lot of effort has gone into tuning TCP round trip time estimates.
>Question: has anyone looked into techniques for tuning TCP window sizes?
>Intuitively, I expect that increasing the window size for a TCP-based
>file transfer would increase throughput until the slowest link in the
>path saturates. Beyond this point, throughput would remain constant but
>round trip delay would goes up, unnecessarily increasing delay for other
>users of the same path. It would be nice to find an algorithm that found
>and operated at this optimal operating point automatically. Any ideas?

Phil,

Have you seen any of Van Jacobsen's work on TCP?  His algorithms include
dynamically adjusting the TCP window based on Acks and Timeouts in an
attempt to optimize the widow for current congestion levels.  He has
done some very good process control analysis to understand the dynamics
of the system.

						Art Berggreen
						art@acc.arpa

------

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 88 23:31:12 GMT
From:      terrell@musky2.EDU (Roger Terrell)
To:        comp.protocols.tcp-ip
Subject:   Who sells TCP/IP for AT&T 3B2/300's?



Does anyone know who (if anyone) sells a version of TCP/IP for
the AT&T 3B2/300?  What hardware does this need if it exists?

Thanks,


Roger


-- 

Roger Terrell
Muskingum College			...cbosgd!musky2!terrell (UUCP)
New Concord, OH  43762

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 00:22:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: PSN 7 End-to-End question.

Dave,

good questions! There was an attempt at a truly datagram network in
the early 1970's. It was developed by Louis Pouzin and Hubert
Zimmermann and, I think, Gerard LeLann. They worked at IRIA which
is now known as INRIA (National Research Institute on automation and
information processing) in France. The network was called CYCLADES.

I am sorry I don't have references at hand (I am on travel using a small
laptop for comm), but my recollection is that they experienced packet
loss rates up to 48% when the network became congested. The ARPANET E-E
protocols are intended to push back towards the source soon enough to 
avoid sustained loss rates of that magnitude, as I understand them.

Lean and mean often applies best when the resources are plentiful, but
can become a liability if the network is permitted to enter a congested
state.

Vint

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 00:45:37 GMT
From:      robert@SPAM.ISTC.SRI.COM (Robert Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: PSN 7 End-to-End question.


>> > 1) Best effort systems rely totally on hosts for congestion
>> > management. That is, transport protocols are responsible for
>> > congestion control and congestion avoidance.
>> 
>> Yes, transport protocol behavior is important, but there's no reason why
>> the "best effort" network can't have defense mechanisms that activate
>> only when the network is congested.  For example, the network might
>> normally run in a pure datagram mode, with no network bandwidth wasted
>> on edge-to-edge acknowledgements. However when the network becomes
>> congested, the internal equivalent of "source quench" packets are sent
>> to the entry node, telling it to stop injecting so much traffic into the
>> network. The entry node might translate that into an access protocol
>> message telling the host (or gateway) to slow down, but more importantly
>> the entry node could simply delay or discard additional traffic before
>> it enters the network. Discarding packets is certainly one way to get
>> TCP's attention, but the delaying tactic would be more efficient.

    This is what was on my mind when I asked if the ETE was used for all
    traffic.  If everything is fine and dandy then there shouldn't be a
    need for ETE.  It should only activate when needed, similar to when
    traffic directing cops are only sent out when the stoplights breakdown
    (hmmm, maybe that's sort of poor metaphor, but...).  As originally
    stated, the Arpanet was designed as an open network, where the hosts
    or gateways were assumed not to overuse the network.  Now however that
    can no longer be assumed.  Perhaps indeed some new protocols need
    to be developed that put a chokehold on gateways, instead of trying to
    choke the traffic at an IMP (via ETE, and assuming that the network
    consists of homogeneous hardware and software) or at a host (which is
    obviously a problem currently, since host behavior is very heterogenous).
    Current routing protocols seem to be very weak at load sharing and con-
    gestion control.  Most metrics are are hops, rather than quality metrics.
    cisco gateways have the administrative distance metric, but for the most
    part this field is in its infancy.

>> Question: has anyone looked into techniques for tuning TCP window sizes?
>> Intuitively, I expect that increasing the window size for a TCP-based
>> file transfer would increase throughput until the slowest link in the
>> path saturates. Beyond this point, throughput would remain constant but
>> round trip delay would goes up, unnecessarily increasing delay for other
>> users of the same path. It would be nice to find an algorithm that found
>> and operated at this optimal operating point automatically. Any ideas?

    I wonder about this.  If the situation were ideal it might be the case
    that throughput would remain the same when saturation occurred, however
    in reality wouldn't the increasing load (over and above the sat. level)
    on the IMP be likely to cause congestion problems, perhaps enough
    to back up the series of links to the transmitting host, or more likely,
    to cause enough of a delay to cause TCP to declare the host/network
    unreachable?

    My understanding of the internal structure of the Arpanet is not what
    it should be, so excuse me this question.  Are all Arpanet (internal)
    links pretty much equal in speed (assumedly their MTU size is constant
    since it is all the same hardware)?  If that is the case perhaps your
    model works, but consider this.  With networking becoming the widespread
    thing that it is, is it fair to design protocols which are designed for
    a relatively homogeneous PSN(etwork)?  The Arpanet seems to me to be
    rather unique in its construction and administration.  Networks of the
    future may not rely on a homogeneous core, but may rather be a series
    of smaller networks which provide routes of varying expense or quality
    of service to each other, on a peer rather than superior basis.  In
    fact, isn't it possible that the current problems encountered in the
    Arpanet with loops and backdoor routes messing up the network could be
    considered to be weaknesses of the existing protocols?  This by the way
    really is a question, and not an assertion.

    Comments welcome.

    Robert Allen, robert@spam.istc.sri.com
    415-859-2143 (work phone, days)

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 02:53:29 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN 7 End-to-End question.

Phil,

At least on paths in the mid-Atlantic region I regularily get 12K-16K
bps between ARPANET hosts and at least 9.6 Kbps fetching gobs from
SRI-NIC, because that's what my home access line speed is and it
runs flat-out. I have seen rates to 23 Kbps on some occasions. Be
advised PSN 96, through which all my packets fly, is one of the
busiest ARPANET spots. Oh, I bet you're connected via X.25. We use
real 1822 here.

Dave

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 04:01:35 GMT
From:      medin@AMES-TITAN.ARPA (Milo S. Medin, NASA ARC Code ED)
To:        comp.protocols.tcp-ip
Subject:   Re: PSN 7 End-to-End question.


Phil, I used to see throughput rates 3-4 years ago as high as 38-39 Kb/s 
moving files with FTP between a DEC-10 system running DEC System-10 (CCC) at
Lawrence Livermore National Lab to a 4.2 BSD VAX 11/750 (P mach.) at Los Alamos
National Lab via the MILNET when I was working at LLNL.  This was after the
ARPANET/MILNET split, and as I recall, there were a couple PSN's in the
path from LLNL to LANL.  This was for a large file (100K or so) in the evening.
Of course, the FTP's could have been lying to me (I didn't use a stopwatch),
but it 'felt' pretty snappy...

True, I don't see that kind of rate these days, but then there is a
lot more traffic on MILNET these days as well.  So I don't think
it's the internal PSN network that is the bottleneck.  True, both
systems were directly attached to MILNET PSN's via 1822 interfaces, and
we were running an older version of PSN software before, but I doubt
things have changed for the worse *that* much since then...  Let's make sure
the bottleneck isn't an extra hop through an EGP neighbor or some X.25
interface before throwing stones at the poor PSN's...

Ah yes, back in the good ol' days, before all the users discovered these 
networks...  I remember it well.

						Milo

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 04:38:29 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip,comp.unix.questions merlin@hqda-ai.UUCP
Subject:   Re: FTP Directory listings under TOPS-20

It is possible to look around in a TOPS-20 directory hierachy just
as you would on Unix.  However some of the tools to do so are not
going to be available via FTP, and I think some sites may place even
more restrictions on anonymous FTP users.

I don't know any way to find all the legal structures, but if
you know a structure, you can find the directories by doing
  dir <root-directory>
You can find subdirectories under foo by doing
  dir <foo>*.directory

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Feb 88 12:56:48 PST
From:      Greg Satz <satz@clash.cisco.com>
To:        iso@nrtc.northrop.com, tcp-ip@sri-nic.arpa
Subject:   X.25 Call User Data for higher level protocols
I am in need of the protocol identifiers used in the CALL USER DATA
field of the X.25 CALL REQUEST packet for various higher level
protocols.  I believe I know the following information but need to be
able to fill in the blanks.  Can anyone help or provide a reference as
to where I might find this data?

Who supplies these numbers?  ISO?  I would like to define an ID for a
virtual circuit that includes an extra 16 bit data field that could be
used like the ethernet type field.  Has something like this already
been defined?  Should I be using 802.2?  Comments?

		Protocol		Call User Data (byte in hex)
		--------		--------------

		    PAD			     0x01
		     IP			     0xCC
		 ISO IP			     0xCD
		    XNS			      ??
		    PUP			      ??
		 DECNET			      ??
		  Chaos			      ??

-------
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 05:09:59 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP window sizing


    Have you seen any of Van Jacobsen's work on TCP?  His algorithms include
    [ ... ]

Is he going to publish any papers on his findings (either simulations
or in-the-field benchmarks)?

-Philip

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1988 13:08-EST
From:      CERF@A.ISI.EDU
To:        cscosl!yf@NCSUVX.NCSU.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Old articles and RFC

1. RFCs are at SRI-NIC. You can use anonymous login with
password guest and FTP from the <NIC> directory. 

2. old articles - if you mean published ones, the NCSU computer
science library, if you have one, should have journal and proceedings.

Vint Cerf
-------
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 09:05:47 GMT
From:      slevy@UC.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN 7 End-to-End question.

We have 1822 here, too, but I've never seen rates over 3.5 KBytes/sec
(i.e. 28 Kbits or half the nominal line speed) on any TCP transfer.
Even talking to other nodes on the same IMP as we are.  Even talking to
our own net-10 address, for that matter.
We have an HDH connection to a remote IMP.  Until recently we were connected
via an ECU (to the same IMP, of course); that did about the same.

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Feb 88 17:34:05 EST
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   ARPANET Throughput
In addition to recounting old war stories, some of you might be interested in
the "calculated" performance of the ARPANET design.  A fairly extensive set of
calculations were published in the Proceedings of the 1972 Fall Joint Computer
Conference in a paper by McQuillan, Crowther, Cosell, Walden, and Heart (all of
BBN) titled "Improvements in the design and performance of the ARPA network" on
pages 741-754.

Alex McKenzie
 
-------
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 15:19:04 GMT
From:      mminnich@UDEL.EDU (Mike Minnich)
To:        comp.protocols.tcp-ip
Subject:   Re: Performance Data Wanted

There is an article "User-Process Communication Performance in Networks of
Computers" in the January '88 issue of IEEE Trans. on Software Engineering,
vol 14, number 1.

It contains some of the performance data you seek.

mike

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 16:31:16 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN 7 End-to-End question.


Phil and Dave,  Just to add to the history of how much data we used to
be able to shove through the old Arpanet:  In the late 70s I used to
FTP (in TCP mode) the huge LISP executable file that was a few megabytes
in size.  I did it from SRI to/from BBN.  Regularly got 40-45 kilobits
out of the throretical limit of 56.  That was on assumed lightly loaded
lines because I did it late at night.  In the daytime I would get
anywahere from 10-30 kilobits per second.  (As Dave pointed out,  it was all
1822 interfaces.)

Lenny Kleinrock told me a magic number in 1966 -- it was 37%.  Anytime
you try to get more than 37% of the capacity out of any shared services
you will start to get unhappy.  When you go over 70% you will be miserable.

Dan
-------

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 18:08:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Old articles and RFC


1. RFCs are at SRI-NIC. You can use anonymous login with
password guest and FTP from the <NIC> directory. 

2. old articles - if you mean published ones, the NCSU computer
science library, if you have one, should have journal and proceedings.

Vint Cerf

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 18:24:56 GMT
From:      karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   Re: Who sells TCP/IP for AT&T 3B2/300's?


terrell@musky2.EDU writes:
   Does anyone know who (if anyone) sells a version of TCP/IP for
   the AT&T 3B2/300?  What hardware does this need if it exists?

We have Enhanced TCP/IP WIN/3B from The Wollongong Group on our
3B2/400s.  AT&T sells it directly.  It does pretty well.  We use it
exclusively for rlogin, telnet, and ftp purposes, though; we continue
to use only smail for a mailer, although this package came with a SysV
version of sendmail.
-=-
Karl

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 19:18:16 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   Zero windows in SUN Unix

I am testing a new terminal server and have run into a problem with 
TCP windows closing.

I have noticed that SUN Unix 4.2 rel3.2 doesn't open its TCP window 
without prompting. If the SUN closes its window, and it stays closed 
long enough for a few "polling" packets to pass by, data flow ceases.
The window stays closed until 
a rather long timer on the terminal server expires and it sends 
another short exploratory packet. This causes aggravating data stoppages.

Is this closed window scenario common? Would it be advisable to reduce the 
terminal server's timer length from 2 minutes to something like 10 seconds?


Thanks in advance
 Bill VerSteeg

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 19:23:49 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN 7 End-to-End question.

Once upon a time, about 1982, I measured 70kbits/sec from my host
looped through the local IMP and back, using max-sized UDP packets.

The IMP was number 1 on the ARPANET (UCLA); the host was an IBM 3033
mainframe; the IMP interface was the ACC IF/370 using an 1822 VDH connection.

We commonly saw 45-48 kbits/sec doing FTP's between two different hosts
via the UCLA IMP; the source was generally a VAX runnning LOCUS
in Computer Science, and the sink was the aforementioned 3033 (Computer
Science sure loved the cheap, fast printing available on the mainframe!).

Bob Braden

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 20:41:31 GMT
From:      wbe@bbn.com (Winston B Edmond)
To:        comp.protocols.tcp-ip
Subject:   Re: PSN 7 End-to-End question.

Robert Allen @ SPAM.ISTC.SRI.COM writes:
>
>> Yes, transport protocol behavior is important, but there's no reason why
>> the "best effort" network can't have defense mechanisms that activate
>> only when the network is congested.  For example, the network might
>> normally run in a pure datagram mode, with no network bandwidth wasted
>> on edge-to-edge acknowledgements. However when the network becomes
>> congested, the internal equivalent of "source quench" packets are sent
>> to the entry node, telling it to stop injecting so much traffic into the
>> network.
>
>    If everything is fine and dandy then there shouldn't be a
>    need for ETE.  It should only activate when needed, ...

   One must be careful about such things.  Maybe for a LAN it makes sense to
say "when *the network* becomes congested", but for a widely distributed
network, such as the ARPANET, with many independent communication paths, the
question should really be rephrased as: Can delay caused by congestion
controls be avoided when all the paths and nodes between the message's source
and destination, including whatever multiple and alternate paths might be
used, are relatively uncongested?  That would require enough timely
information about the path to decide, and the cost of that decision would
have to be weighed against the performance improvement to be gained.

   Once upon a time, the ARPANET had no preallocation of space in the
destination IMP, and still does not use it for short-enough messages.
Suffice it to say that its absence was enough of a problem to be worth
putting it in.

   If performance in the uncongested case is currently a problem, perhaps the
source IMP could estimate the likelihood of congestion along its selected
path and then choose between sending multi-packet messages with or without
preallocation, with the destination accepting either.

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

   I would strongly recommend against building a system that activated and
deactivated a congestion control system, if by that one means sometimes
ceasing to use network processing and communication resources to exchange
congestion information.  Instead, the congestion control system should always
be running, with an option to note that a particular network path is
uncongested at the moment.

   Congestion avoidance requires that information about the state of the
network be propagated throughout the network.  Perfect knowledge would
require that predictions at the source node be accurate for the transit time
of the packet.  Decreasing the amount or timeliness of the information
increases the likelihood of congestion and packet loss.

   If a disableable congestion control system were used, the network nodes
would have to be careful to kick in the congestion controls BEFORE congestion
actually occurs, or else there would be a catastrophe point in the network's
ability to handle traffic.  That point would occur as IMPs switch from
sending just user traffic to sending user traffic PLUS congestion control
traffic.
 -WBE

Disclaimer: these are personal remarks and should not be taken as official
statements of BBN Laboratories Incorporated.

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 20:56:48 GMT
From:      satz@CLASH.CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   X.25 Call User Data for higher level protocols

I am in need of the protocol identifiers used in the CALL USER DATA
field of the X.25 CALL REQUEST packet for various higher level
protocols.  I believe I know the following information but need to be
able to fill in the blanks.  Can anyone help or provide a reference as
to where I might find this data?

Who supplies these numbers?  ISO?  I would like to define an ID for a
virtual circuit that includes an extra 16 bit data field that could be
used like the ethernet type field.  Has something like this already
been defined?  Should I be using 802.2?  Comments?

		Protocol		Call User Data (byte in hex)
		--------		--------------

		    PAD			     0x01
		     IP			     0xCC
		 ISO IP			     0xCD
		    XNS			      ??
		    PUP			      ??
		 DECNET			      ??
		  Chaos			      ??

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 21:33:45 GMT
From:      thad@cup.portal.com
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: FTP Directory listings under TOPS-20


The command "INFORMATION STRUCTURES *" (abbreviated I STR *) will
produce a list of the available structures on a given TOPS-20 system.

To see all available (to you!) directories on a given structure:

     DIR structure:<*>,
     NO FILE

note the comma (putting you into sub-command mode), and note you will
need to enter two RETURNs after the NO FILE.

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 22:11:28 GMT
From:      karn@THUMPER.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN 7 End-to-End question.

We're on a 56Kb/s HDH link to the Columbia IMP, and Stuart's figures are
consistent with mine. I spent some time analyzing the HDLC link level on
our Sun gateway to make sure it's not the bottleneck. As far as I can
tell, it isn't. We're running in message mode (does anybody even bother
with packet mode?), with zero acknowledgement delay and a window size of
7.

Yes, Dave, the tests were done between Columbia and UDel, but I wouldn't
expect such consistent numbers if heavy loading at Delaware was the cause.

While we're on the subject of network throughput, I came across an
interesting statistic the other day. The French national packet network
carries 1,200 billion characters/month, "more than three times the
traffic of Tymnet, Telenet and all other American networks combined...
In fact, France accounts for more data traffic than all the rest of the
world's nations combined..."  ["Tout le Monde! C'est Telematique
Francaise!", US Black Engineer, Winter 1987, p.5].

While this certainly *sounds* impressive, 1.2 terabytes/month is only
3.7 megabits/sec, roughly 40% of a single Ethernet.  We routinely see
cables around here running at such levels for sustained periods (NFS/ND
traffic between Sun-3's, naturally).  Add up all the LANs in the world
and even France's awesome network capacity withers into insignificance. 
Now all we need is a long-haul packet network with a capacity matched to
that of tomorrow's LANs so we can have national NFS server banks...

Phil

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 22:34:05 GMT
From:      mckenzie@LABS-N.BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   ARPANET Throughput

In addition to recounting old war stories, some of you might be interested in
the "calculated" performance of the ARPANET design.  A fairly extensive set of
calculations were published in the Proceedings of the 1972 Fall Joint Computer
Conference in a paper by McQuillan, Crowther, Cosell, Walden, and Heart (all of
BBN) titled "Improvements in the design and performance of the ARPA network" on
pages 741-754.

Alex McKenzie
 

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 88 23:19:00 GMT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   Apollo NCS paper

Natheniel Mishkin was kind enough to send me machine readable copies
of the paper he mentioned a few days ago on NCS (Apollo's Network
Computing Achitecture). For those who are interested, I placed them in
XX:<ANONYMOUS> as NCS-PAPER.INTERLEAF and NCS-PAPER.PS.  They are
available (as you might guess) via anonymous FTP on XX.LCS.MIT.EDU.

--Rob

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 10:17:00 PST
From:      <art@acc.arpa>
To:        "satz" <satz@clash.cisco.com>
Cc:        iso@nrtc.northrop.com,tcp-ip@sri-nic.arpa
Subject:   RE: X.25 Call User Data for higher level protocols

>I am in need of the protocol identifiers used in the CALL USER DATA
>field of the X.25 CALL REQUEST packet for various higher level
>protocols.  I believe I know the following information but need to be
>able to fill in the blanks.  Can anyone help or provide a reference as
>to where I might find this data?
>
>Who supplies these numbers?  ISO?  I would like to define an ID for a
>virtual circuit that includes an extra 16 bit data field that could be
>used like the ethernet type field.  Has something like this already
>been defined?  Should I be using 802.2?  Comments?
>
>		Protocol		Call User Data (byte in hex)
>		--------		--------------
>
>		    PAD			     0x01
>		     IP			     0xCC
>		 ISO IP			     0xCD
>		    XNS			      ??
>		    PUP			      ??
>		 DECNET			      ??
>		  Chaos			      ??

Greg,

CCITT defines the high order two bits of the first octet of call user data
as follows:

	00 - Used for other CCITT recommendations (such as X.29)
	01 - Reserved for use by "national" administrative authorities
	10 - Reserved for use by international administative authorities
	11 - Reserved for arbitrary use between consenting DTEs

I believe (they can correct me if I'm wrong) that BBN chose 0xCC and 0xCD
for use on the DDN.  If you want to establish a standard for use in the
Internet I would suggest contacting both DCA and ANSI to see if there is
interest.

I would appreciate hearing any results you find.

						Art Berggreen
						art@acc.arpa

------
-------
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 04:01:57 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN 7 End-to-End question.

Phil,

Tout l'faire!

Dave

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Thu, 04 Feb 88 11:26:43 CST
From:      Shane Davis <X233SD%TAMVM1.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   TCP/IP for Amdahl UTS System V
Greetings...

We are looking for some way to run TCP/IP from our UTS UN*X system. UTS is
being run as a virtual machine on an Amdahl 5860 under VM/SP HPO Rel. 4.2.
The VM system is connected to Internet via Spartacus K200 Ethernet Controller
and running KNET software. UTS version is System V.2/UTS 1.1.3. We would like
to know what options we have with this setup. Is another Ethernet box required?
Is it possible, impossible, difficult, feasible to make KNET route packets
bound for a pseudo-hardware address to the UTS virtual machine, such as has
been done with RSCS here? What vendors can provide TCP/IP software for UTS and
can that software work under the UTS system which runs as a virtual machine?

We're still in the fact-finding stage and I am only helping a little bit with
this project but as I am already on this list I am making the request for info
for the one who will be responsible for implementing any plans we make toward
setting up UTS for TCP/IP.

Please don't give me too many flames for my use of "UN*X," either...I won't
give any of you any for using "VMess..."

Thanks in advance,

--Shane Davis
  Programming Assistant
  Texas A&M Univ. Computing Svcs. Ctr. Software Systems Group

********************************************************************************
        BITnet             THEnet                       Internet

  XPMAINT@TAMVENUS      THOR::XPMAINT           xpmaint@venus.tamu.edu
  RSD1901@TAMSIGMA       ZAC::RSD1901                   --------
  X233SD@TAMVM1            ------               x233sd@tamvm1.tamu.edu
        ------          CONS::RSD1901           rsd1901@cons.tamu.edu

        SPAN: UTSPAN::UTADNX::(THEnet addr)
********************************************************************************
-------
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 07:17:58 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Zero windows in SUN Unix


Get in touch with Sun software service, they've been distributing a
fix for that for a while now. It exists in 3.4 also. Not all systems
prompt it but we ran right into it with tn3270.

	-Barry Shein, Boston University

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 14:18:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Zero windows in SUN Unix


    Date: 3 Feb 88 19:18:16 GMT
    From: dcatla!dnwcv@gatech.edu  (William C. VerSteeg)

    Is this closed window scenario common? Would it be advisable to reduce the 
    terminal server's timer length from 2 minutes to something like 10 seconds?

My opinion is that the terminal server should know little if anything
that it is talking to a TCP stream as opposed to any other kind of
stream.  It should be the stream's (TCP in this case) responsibility to
let the program (the terminal server in this case) let one more byte
pass through (because that is how TCP works) which will get the flow of
data working again.  Under this scenario, you needn't change the
terminal server, only the variable that controls the timeouts for all of
TCP.

Another opinion is that when the TCP data receiver has acknowledged all
the data yet still offers a zero window, the sender should be allowed to
send the one byte probe immediately, instead of having to wait for a
timer to go off.  Again, this is at the TCP stream level, not at the
level of any program.

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 17:26:43 GMT
From:      X233SD@TAMVM1.BITNET (Shane Davis)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for Amdahl UTS System V

Greetings...

We are looking for some way to run TCP/IP from our UTS UN*X system. UTS is
being run as a virtual machine on an Amdahl 5860 under VM/SP HPO Rel. 4.2.
The VM system is connected to Internet via Spartacus K200 Ethernet Controller
and running KNET software. UTS version is System V.2/UTS 1.1.3. We would like
to know what options we have with this setup. Is another Ethernet box required?
Is it possible, impossible, difficult, feasible to make KNET route packets
bound for a pseudo-hardware address to the UTS virtual machine, such as has
been done with RSCS here? What vendors can provide TCP/IP software for UTS and
can that software work under the UTS system which runs as a virtual machine?

We're still in the fact-finding stage and I am only helping a little bit with
this project but as I am already on this list I am making the request for info
for the one who will be responsible for implementing any plans we make toward
setting up UTS for TCP/IP.

Please don't give me too many flames for my use of "UN*X," either...I won't
give any of you any for using "VMess..."

Thanks in advance,

--Shane Davis
  Programming Assistant
  Texas A&M Univ. Computing Svcs. Ctr. Software Systems Group

********************************************************************************
        BITnet             THEnet                       Internet

  XPMAINT@TAMVENUS      THOR::XPMAINT           xpmaint@venus.tamu.edu
  RSD1901@TAMSIGMA       ZAC::RSD1901                   --------
  X233SD@TAMVM1            ------               x233sd@tamvm1.tamu.edu
        ------          CONS::RSD1901           rsd1901@cons.tamu.edu

        SPAN: UTSPAN::UTADNX::(THEnet addr)
********************************************************************************

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Thu,  4 Feb 88 23:05:33 EST
From:      "Philip A. Prindeville" <PAP4@AI.AI.MIT.EDU>
To:        timk%ncsa.uiuc.edu@EDDIE.MIT.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: question about /etc/route
    Am I right that the following entry is taken as a host entry and not
    a network entry?

    # route add 128.174.22 mygateway 3

    produces a netstat -r -n output:

    128.174.0.22  128.174.20.77   UGH  

    Seems that route isn't using the subnet mask (8 bit subnet on Class B) to
    determine that the 128.174.22 is a separate subnet instead of a host.

    A bug?  Fixed in later release?

Actually, it's minor brain-death in the way BSD parses addreses.  If you
leave dotted numbers out, all but the last set of digits get left
justified in the address, whereas the last digit gets right justified.
Therefore, 10.51 == 10.0.0.51, and 128.174.22 == 128.174.0.22.
If you try:

# route add 128.174.22.0 mygateway 3

you will find this nastiness goes away.  And I thought that standard
notation for internet addresses was four dotted digits...

-Philip

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Thu, 04 Feb 88 17:09:37 CET
From:      HAUPTMAN%DMRHRZ11.BITNET@CUNYVM.CUNY.EDU
To:        tcp-ip@sri-nic.ARPA
Subject:   Who knows this Ethernet-board?

Here at University Marburg, Germany we have a bunch of
Siemens PCD (MS-DOS -) computers. Some have a Ethernetboard installed.
We are a bit confused about these Boards. Perhaps these cards
were manufactured by 3COM.

Description:
    The boards are labeld: Siemens Ethenet Rev. 2 0
    Outside is a sticker by 3COM stating the Ethernetaddress
    e.g. 026080-151019. Some of the Chips on the board:
      DI 0755-01 8607
      SEEQ D0 8001 85344
      Sony 5H06 CXK5816P
    I've no idea whether these are the relevant chips, they just look most
    impressive to me.
    On the board is one switch and a chunt block to select between Thinwire
    and Tranceiver.

Questions:

1) Where can we get more information about these cards? Low level
   interfaces, addreses, registers, interrupts and such.

2) Is this board (software-)compatible to any "well known" card, like
   3C501, 3C505, WD8003?

3) We would like to run Novell Netware. Where can we get the drivers?

Thanks,

Klaus Hauptmann        HAUPTMAN@DMRHRZ11.BITNET
                       BIX-Id: msommer

-------
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 18:17:00 GMT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   RE: X.25 Call User Data for higher level protocols


>I am in need of the protocol identifiers used in the CALL USER DATA
>field of the X.25 CALL REQUEST packet for various higher level
>protocols.  I believe I know the following information but need to be
>able to fill in the blanks.  Can anyone help or provide a reference as
>to where I might find this data?
>
>Who supplies these numbers?  ISO?  I would like to define an ID for a
>virtual circuit that includes an extra 16 bit data field that could be
>used like the ethernet type field.  Has something like this already
>been defined?  Should I be using 802.2?  Comments?
>
>		Protocol		Call User Data (byte in hex)
>		--------		--------------
>
>		    PAD			     0x01
>		     IP			     0xCC
>		 ISO IP			     0xCD
>		    XNS			      ??
>		    PUP			      ??
>		 DECNET			      ??
>		  Chaos			      ??

Greg,

CCITT defines the high order two bits of the first octet of call user data
as follows:

	00 - Used for other CCITT recommendations (such as X.29)
	01 - Reserved for use by "national" administrative authorities
	10 - Reserved for use by international administative authorities
	11 - Reserved for arbitrary use between consenting DTEs

I believe (they can correct me if I'm wrong) that BBN chose 0xCC and 0xCD
for use on the DDN.  If you want to establish a standard for use in the
Internet I would suggest contacting both DCA and ANSI to see if there is
interest.

I would appreciate hearing any results you find.

						Art Berggreen
						art@acc.arpa

------

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 18:21:52 GMT
From:      karels@OKEEFFE.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: PSN 7 End-to-End question.

Out of curiosity, I just timed an ftp transfer through our 1822 IMP
connection (10AM PST, load average 2.5 on a VAX 11/785) and got 9.6Kbytes/s.
The same transfer through software loopback ran up to 68Kbytes/s (with more
variance due to process scheduling).

Note that even when timing TCP transfers on an idle ARPANET over short
hops, the round-trip time is higher than when using most local-area networks.
Depending on the ack strategy, the TCP transfer rate is limited to
something on the order of one window per round-trip time.  Thus, failure
to reach 56 kb/s through the ARPANET using TCP is not necessarily due
only to internal overhead.

		Mike

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 18:51:34 GMT
From:      bill@tifsil.UUCP (Bill Stoltz)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms
Subject:   Pass an open socket to another process????



HELP! 

I am looking for information on the feasibility of the following
design on Un*x and other operating systems.  I need ideas (how to do this
on _____), comments (you must be nuts, neat idea), or suggestions on how
to solve this problem.  I also have a very tight schedule, in that I need
this information by the middle of next week (2/10/88), so I can make a
decision by 2/15/88.  

We want to make a decision that is not going to hurt us in the future.
If we move this to a new protocols, or a new operating systems will we 
still have the basic functionality to continue with the proposed design,
or will we be stuck with this decision forever.

The need:

We have a server application that handles all incoming requests.  The
server needs to pass off these requests to another process to complete 
the transaction.  The data will come in over the network through something
that works like Berkeley Sockets.  We are using an internally developed
protocol and we do not have the option of changing any of the requester
code.  It may be possible to change the socket code on the Un*x system.


Current design:

The server currently receives data into shared memory, then sends a short
message to the appropriate application telling in where the data is in shared
memory and lets the application process the data.

This is fine for this application, but it is felt that adding this new 
functionality to the server would make it a bottleneck, and it would not be 
able to handle new requests.

Trying fork/exec:

Using fork/exec was suggested to handle this problem, but this was 
quickly rejected.  The reasons given are maintainability of all the pieces, 
changes the current design, lack of control and coordination if several 
of the same functions are requested at the same time.

The designers plan:

The design that is being pushed is to have the server pass off the
connection (socket) to a non-related, already running process to finish 
the transaction. The server must read the first part of the data to determine
which application is to receive the connection.  The connection must be
passed off to the non-related process without closing the connection.
The application process must be able to continue communications
with very little interaction between itself and the server, except to say 
"here is a new connection, you handle it".  The server is then out of the 
picture.  The application then sends down the data and terminates the 
connection.  This gives them the control they need and does not make the 
server a bottleneck. 

The problem:

Can I provide this functionality under Un*x?
What do I need to hack to do this?
Is this supported under other socket implementations? 
Is this possible on other operating systems?
Is this going to be available in future products?


I have posted this to several boards, so please send your comments by e-mail.

Thanks for any help or comments.  The life you save may be mine.



Bill Stoltz
Texas Instruments
Process Automation Center
P.O. Box 655012, M/S 3635
Dallas, TX 75243

UUCP: 	{uiucdcs!convex!smu, {rice, sun!texsun}!ti-csl}!tifsie!bill
DECNET: TIFSIE::bill
Voice:	(214) 995-2786

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 19:14:51 GMT
From:      cheriton@PESCADERO.STANFORD.EDU ("David Cheriton")
To:        comp.protocols.tcp-ip
Subject:   More PSN 7 End-to-end Comments

I was referred to the 1975 AFIPS NCC paper by Crowthers et al. to understand
better the reasoning behind the current E2E protocol in the ARPAnet.
Here are a few reactions to this paper.
1. The paper argues in several places for something more than imp-to-imp
   protocol and concludes that a network-level end-to-end protocol is needed.
   However, it seems to me that a higher-level protocol (such as TCP)
   would satisfy the reasons for the e2e protocol.
2. The paper is concerned with buffering allocation in the dst. node as
   an important feature.  However, this concern seems to be based on the
   model of reliable comm. from IMP to host and the host being able to flow
   control (block) messages/packets from the network.  In the current common
  environment of IMP connecting to IP gateways which are in turn connected to
  much higher-speed local area networks, one might observe that:
  i) the IMP/gateway should have no trouble emptying its incoming packets
    onto the local network (56Kb to 10Mb).
  ii) the communication to the gateway may be reliable, X.25 etc. but
   the packet is then typically just tossed out on the Ethernet for
   delivery to the host, with some possibility of loss.
   This the reliable delivery and flow control to the destination IMP
   seems to buy very little, if anything.
3. The paper mentions some discussions of the time suggesting that
   some other people felt that end-to-end protocols would be best done in 
    the hosts, and argues against this.  However, most of the arguments seem
   to be objecting to TCP/IP style processing in the hosts.
   From the current perspective, it seems like unless we want to throw out
   TCP style transport-level processing the host, one should really
   rethink the value of the network-level e2e protocol.

In general, I conclude that we are carrying a lot of history here.  I would
conjecture that a best-efforts network with perhaps some rate-control
mechanism for congestion avoidance would be simpler and faster.

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 19:40:11 GMT
From:      timk@NCSA.UIUC.EDU (Tim Krauskopf)
To:        comp.protocols.tcp-ip
Subject:   question about /etc/route


/etc/route on SunOS 3.3

Am I right that the following entry is taken as a host entry and not
a network entry?

# route add 128.174.22 mygateway 3

produces a netstat -r -n output:

128.174.0.22  128.174.20.77   UGH  

Seems that route isn't using the subnet mask (8 bit subnet on Class B) to
determine that the 128.174.22 is a separate subnet instead of a host.

A bug?  Fixed in later release?

 Tim Krauskopf                                        timk@ncsa.uiuc.edu (ARPA)
 National Center for Supercomputing Applications      14013@ncsavmsa (BITNET)

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 21:06:23 GMT
From:      rfox@AMES-NAS.ARPA (Richard Fox)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP for Amdahl UTS System V

We currently run a Wollongong package that should meet your needs. I believe
the package is a basic bsd 4.2 implementation. We some work we were able to 
upgrade the software to bsd4.3.


rich

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 21:55:10 GMT
From:      slevy@UC.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re: PSN 7 End-to-End question.

I did try running two TCP connections to our own interface as well as one.
If round trip time is the limiting factor, then two TCPs should give 
better total throughput.  But (in the one case I tried, sending 50K bytes
to our own net-10 address at 3 AM local time) the total rate actually
decreased -- ~ 31 kilobits/s on one connection, ~ 12 kb/s for each of two.

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 22:09:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP Verification Suite


    Date: 2 Feb 88 19:32:51 GMT
    From: thumper!karn@faline.bellcore.com  (Phil R. Karn)

    a) getting rid of gaps and ambiguities in the specs themselves that can
    allow different implementations to "conform" yet not be interoperable, and

You forgot (that goes between a and b):
Convincing a vendor that his implementation is broken.  

I remember when I was testing the TCP I wrote for Symbolics LispMs.  We
were one of the first to use segments with overlapping sequence numbers
in a big way (mostly for telnet).  It didn't work with Unix machines.
The response was "Well, Unix is right, so you must be doing something
wrong."  We still have this problem with Unix TCP/FTP giving a reply
code for some operation, DELETE I think, that is not what the FTP spec
says it should be.  The typical answer from Unix people is "You should
only look at the first digit; the others are secondary information."
And we respond with "The spec says it should return <xyz>."  And it goes
'round and 'round.

    b) figuring out how to armtwist the vendor of a broken implementation to
    fix it once a problem has been identified.

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 22:12:02 GMT
From:      HAL@SRI-NIC.ARPA (Hal Huntley)
To:        comp.protocols.tcp-ip
Subject:   Re: Old articles and RFC

Vint,

The RFCs are now kept in their own directory <RFC> and a person can
get them by either one of two forms:

a) RFC:RFCnnn.TXT
b) <RFC>RFCnnn.TXT

Where "nnn" is the number of the RFC that you are trying to get
(they now go up to four digits long).

We think the first way is easier to remember.

Hal Huntley/NIC
-------

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 22:15:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP Verification Suite


    Date: 2 Feb 88 19:32:51 GMT
    From: thumper!karn@faline.bellcore.com  (Phil R. Karn)

    a) getting rid of gaps and ambiguities in the specs themselves that can
    allow different implementations to "conform" yet not be interoperable, and

You forgot (that goes between a and b):
Convincing a vendor that his implementation is broken.  

I remember when I was testing the TCP I wrote for Symbolics LispMs.  We
were one of the first to use segments with overlapping sequence numbers
in a big way (mostly for telnet).  It didn't work with Unix machines.
The response was "Well, Unix is right, so you must be doing something
wrong."  

We then got calls from people trying to communicate between our machines
and Apollo.  Apollo said "We have no trouble talking to Unix machines."

We still have a similar problem with Unix TCP/FTP giving a reply code
for some operation, DELETE I think, that is not what the FTP spec says
it should be.  The typical answer from Unix people is "You should only
look at the first digit; the others are secondary information."  And we
respond with "The spec says it should return <xyz>."  And it goes 'round
and 'round.

I'm not saying we don't occaisionally pass the buck without looking; I'm
just relaying anecdotes of how difficult things can be.

    b) figuring out how to armtwist the vendor of a broken implementation to
    fix it once a problem has been identified.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 88 22:21:54 GMT
From:      zjat02@apctrc.UUCP (Jon A. Tankersley)
To:        comp.protocols.tcp-ip
Subject:   Re: Who sells TCP/IP for AT&T 3B2/300's?

Wollagong sells some or AT&T does.  It's expensive.  ($6500 over a year
ago.)

It works.

-tank-

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 01:08:58 GMT
From:      philipp@GMUVAX2.GMU.EDU (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   MX/Sendmail on Ultrix

Has anyone had any experience with porting the MX/sendmail to Ultrix?
I'm using it with the BIND 4.7.2 resolver, and I'm getting some
funky core dumps.  Any ideas?

-Philip

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 01:16:19 GMT
From:      HAUPTMAN@DMRHRZ11.BITNET
To:        comp.protocols.tcp-ip
Subject:   Who knows this Ethernet-board?



Here at University Marburg, Germany we have a bunch of
Siemens PCD (MS-DOS -) computers. Some have a Ethernetboard installed.
We are a bit confused about these Boards. Perhaps these cards
were manufactured by 3COM.

Description:
    The boards are labeld: Siemens Ethenet Rev. 2 0
    Outside is a sticker by 3COM stating the Ethernetaddress
    e.g. 026080-151019. Some of the Chips on the board:
      DI 0755-01 8607
      SEEQ D0 8001 85344
      Sony 5H06 CXK5816P
    I've no idea whether these are the relevant chips, they just look most
    impressive to me.
    On the board is one switch and a chunt block to select between Thinwire
    and Tranceiver.

Questions:

1) Where can we get more information about these cards? Low level
   interfaces, addreses, registers, interrupts and such.

2) Is this board (software-)compatible to any "well known" card, like
   3C501, 3C505, WD8003?

3) We would like to run Novell Netware. Where can we get the drivers?

Thanks,

Klaus Hauptmann        HAUPTMAN@DMRHRZ11.BITNET
                       BIX-Id: msommer

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Feb 88 09:47:12 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        slevy@uc.msc.umn.edu
Cc:        mills@udel.edu, tcp-ip@sri-nic.ARPA
Subject:   re: PSN 7 End-to-End question

Stuart,

    Two TCP connections run in parallel are not guaranteed not to affect
each other.  Van Jacobson can show you interesting graphs which show
TCP connections fighting with each other for bandwidth.

Craig
-------
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 02:49:23 GMT
From:      slevy@UC.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re:  question about /etc/route

You seem to need to say
	route -n add ...
in which case it's forced to consider it a network route.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 03:10:35 GMT
From:      karn@THUMPER.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP Verification Suite

I agree with you except for the part where you place all of the blame
for the FTP problem on UNIX. The specs say that you should be
conservative in what you send, liberal in what you accept. So in the
case of the FTP reply code, you're *both* at fault -- UNIX for not
generating the correct code, your code for not looking at just the first
digit.

Phil

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 88 09:14:38 CST
From:      timk@ncsa.uiuc.edu (Tim Krauskopf)
To:        tcp-ip@sri-nic.arpa
Subject:   answer about /etc/route

Thanks to all who replied.  I received several messages which
reminded me that 128.174.22 is interpreted as 128.174.0.22 if you
don't specify that the last part is 0 or use a trailing period.

This doesn't help.  Entering 128.174.22.0 produces a UGH (host) entry
in the table because it still doesn't take it as a network address,
only a host address.  True for SunOS 3.3, I don't know about 4.3BSD.

Stuart Levy wins the prize for the correct answer -- Special thanks.

# route -n add 128.174.22.0 mygate 3

works because the undocumented (not on my man page) option of -n
forces the address to be a network entry.  Maybe the documentation is
buried in the update pages for SunOS 3.3 or is in the 4.3 documentation.  

 Tim Krauskopf                                        timk@ncsa.uiuc.edu (ARPA)
 National Center for Supercomputing Applications      14013@ncsavmsa (BITNET)
-------
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 03:28:52 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   question about /etc/route


I think you want to change:

# route add 128.174.22 mygateway 3

to

# route add 128.174.22.0 mygateway 3

The parsing routine is pretty dumb, give it all four octets. Also,
last I looked it doesn't matter what you pass for that last integer
(3), it's just checked for 0 or not 0 (or if it's not there at all.) I
assume this may change in the future (note: the original question was
specific to Sun/OS, your mileage may vary.)

	-Barry Shein, Boston University

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 04:04:48 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: question about /etc/route


    Am I right that the following entry is taken as a host entry and not
    a network entry?

    # route add 128.174.22 mygateway 3

    produces a netstat -r -n output:

    128.174.0.22  128.174.20.77   UGH  

    Seems that route isn't using the subnet mask (8 bit subnet on Class B) to
    determine that the 128.174.22 is a separate subnet instead of a host.

    A bug?  Fixed in later release?

Actually, it's minor brain-death in the way BSD parses addreses.  If you
leave dotted numbers out, all but the last set of digits get left
justified in the address, whereas the last digit gets right justified.
Therefore, 10.51 == 10.0.0.51, and 128.174.22 == 128.174.0.22.
If you try:

# route add 128.174.22.0 mygateway 3

you will find this nastiness goes away.  And I thought that standard
notation for internet addresses was four dotted digits...

-Philip

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 04:07:56 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   (none)

Mumble.  Sorry about that.  Mailer burped on the first try...

-Philip

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 04:14:37 GMT
From:      guyton%condor@RAND-UNIX.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: question about /etc/route

> # route add 128.174.22 mygateway 3
>
> produces a netstat -r -n output:
>
> 128.174.0.22  128.174.20.77   UGH

You need to add the trailing zero:

 # route add 128.174.22.0 mygateway 3


-- Jim

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 1988 10:39:57 CST
From:      AFDDN.TCP-IP@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        AFDDN.TCP-IP@GUNTER-ADAM.ARPA
Subject:   SLIP for Ultrix
  Forgive if this was posted and I missed it.  

We have a uVAX running Ultrix that I would "like" to have SLIP on.  Is such 
a beastie available?  I saw the postings for UNIX, but not being a
Unix or Ultrix wizard, I don't know how compatible the two really are.
Any Ultrix wizards out there know about SLIP??
Thanks in advance,
Darrel Beach
-------
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 88 10:16:54 est
From:      John Swanson <swanson@EDN-VAX.ARPA>
To:        tcp-ip@sri-nic.arpa, thumper!karn@faline.bellcore.com
Subject:   Re: TCP-IP Verification Suite
Phil,

Having helped produce the verification suite for DoD I can't
keep quiet any longer.  I think you are confusing the tools
with their usage.  First I wonder how much detailed thought went 
into the ad-hoc testing you are talking about.  Are the authors
concerned with compliance to the standards or "getting their
Problem fixed".  When we examined the specifications for each
protocols we documented those descrepancies for DCA and
asked for clarification and factored any response into the 
test suite.  Obviously since the verification suite is a
tool I doubt if it can twist anyones arm.  However, if a vendor
is required to pass the verification suite of tests perhaps
there would not be as many "broken" implementations.  Therefore
I would think those people who really want testing would be
trying to support the NVLAP process the Government is trying
to start up, rather than reinvent the testing wheel.

John
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 06:13:40 GMT
From:      nomad@mist.cs.orst.edu (Lee Vincent Damon)
To:        comp.protocols.tcp-ip
Subject:   Re: Help...looking for network anecdotes


 Here's one. Someone was looking for anecdotes on how the I-net was
used, so they posted a message to a group called comp.protocols.tcp-ip
asking for them. With in days they had 5 very good responces (6?).

I know of lots of cases like that. Mailing lists and news, while they
could all be UseNet/UUCPed, are helped tremendously by the I-net, and they
in turn help speed the flow of information.  Comp. Sci. at Oregon State 
(CS.ORST.EDU) would be very much hampered w/o them, that is for sure.

nomad
---------------------
Lee Damon            	Internet:  nomad@cs.orst.edu
nomad			UUCP :  {hp-pcd,tektronix}!orstcs!nomad
         		FidoNet: 152/201 (The Castle) - (503) 757-8841
			Alt. UUCP: ...!orstcs!castle!nomad (A FidoNet gateway)
			aliases: hostmaster, hpsysop, support, root

     "Say what you like, the bicycle has a great past ahead of it!"

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 88 16:21:47 EST
From:      beh@monk.proteon.com (Brian Hackley)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP Support for VRTX Operating System
HELP!  One of our customers has been asking for support of TCP/IP under the VRTX Operating System (A modular operating system for VME/68020 systems).  If you know of a source for TCP/IP under VRTX, please respond as soon as you can.

Also, anyone hear of an outfit in Edinburgh, Scotland called Spider Systems?


Brian E. Hackley
Proteon Inc.
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 1988 17:04-EST
From:      CERF@A.ISI.EDU
To:        LYNCH@A.ISI.EDU
Cc:        Mills@LOUIE.UDEL.EDU, thumper!karn@FALINE.BELLCORE.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  PSN 7 End-to-End question.
Dan,

Bob Kahn and I got about 42 kb/s on stress tests of the ARPANET
in its early stages. In later years, there was more code in the
IMP and it slowed down some. But then came end/end protocols like
TCP and, depending on the delay, I seem to recall we managed ony
about 35 kb/s through a single IMP, less if many hops were involved.

As to Lenny Kleinrock's 37%, that is 1/e and is the kind of result
you get with multi-access links - and even then, that number did not
guarantee stability (the packet satellite protocols demonstrated
that when running ALOHA style).

Vint
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 13:24:54 GMT
From:      brian@ucsd.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   X.25 to Milnet PSN problems - the continuing saga

A few weeks ago I mentioned here that we're having a problem with the
Milnet IMP we're connected to being completely unable to open X.25
virtual circuits to us, so only those VCs that we open to it will allow
data to pass to mailbridges and other hosts on the milnet.

We're still having the problem, and I wonder if anyone else has seen
this happening on their host?  Misery loves company, maybe?

Our interface is an ACC6250 board (in a VAX780 4.3BSD), and the
people at ACC (especially Lars Poulson) have been extremely helpful
in attempting to get this problem resolved, but so far it isn't.

I'm told that a trace in the PSN code shows that the IMP wasn't even
trying to open the circuit to us, so it's probably in or related to the
PSN code and not the interface - especially since it just started
happening without us making and hardware or software changes.  It DID
start around the time the Arpanet cut over to PSN-7, but we're on the
Milnet.

We're currently running a process that sends a single ping packet to
each of the Milnet mailbridges once every 45 seconds to ensure that the
X.25 VC stays open so that traffic will find an already-open VC instead of
blocking because it can't open one of its own.

Now that I've finished crying on your collective shoulders (waah), I'm
wondering if anyone else has seen any evidence of this happening to
them?  I have trouble believing we've been singled out for this dubious
honor.

	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			UCSD B-028, La Jolla, CA 92093 USA
			brian@ucsd.edu ucsd!brian BRIAN@UCSD

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 13:55:52 GMT
From:      sanand@radha.UUCP (Sanand Patel)
To:        comp.protocols.tcp-ip
Subject:   RE: TCP/IP Performance

For the gentleman, and others who may be interested in published papers:

"User-Process Communication Performance in Networks of Computers",
Cabrera, Hunter, Karels, Mosher.
in: IEEE Transactions on Software Engineering, Jan 1988, pg 38.

--- sanand@HUB.TORONTO.EDU
--- {uunet!mnetor, lsuc, dciem}!radha!sanand
--- 416-756-4100
-- 
---
--- sanand@hub.toronto.edu
--- UUCP: {uunet!mnetor, lsuc, dciem}!radha!sanand
--- 416-756-4100

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 14:47:08 GMT
From:      mminnich@UDEL.EDU (Mike Minnich)
To:        comp.protocols.tcp-ip
Subject:   Re: question about /etc/route

> # route add 128.174.22 mygateway 3
> produces a netstat -r -n output:
> 128.174.0.22  128.174.20.77   UGH  

You need to force the interpretation of 128.174.22 as a network address 
rather than as a host address.  Do this by using the keyword "net" in front
of 128.174.22:

route add net 128.174.22 mygateway 3

The manual page in Sun/OS 3.4 (and I suspect 3.3 as well) for /etc/route 
does not explain this -- it seems to be out of sync with the installed binary.

mike

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 14:47:12 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: PSN 7 End-to-End question


Stuart,

    Two TCP connections run in parallel are not guaranteed not to affect
each other.  Van Jacobson can show you interesting graphs which show
TCP connections fighting with each other for bandwidth.

Craig

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 15:16:54 GMT
From:      swanson@EDN-VAX.ARPA (John Swanson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP Verification Suite

Phil,

Having helped produce the verification suite for DoD I can't
keep quiet any longer.  I think you are confusing the tools
with their usage.  First I wonder how much detailed thought went 
into the ad-hoc testing you are talking about.  Are the authors
concerned with compliance to the standards or "getting their
Problem fixed".  When we examined the specifications for each
protocols we documented those descrepancies for DCA and
asked for clarification and factored any response into the 
test suite.  Obviously since the verification suite is a
tool I doubt if it can twist anyones arm.  However, if a vendor
is required to pass the verification suite of tests perhaps
there would not be as many "broken" implementations.  Therefore
I would think those people who really want testing would be
trying to support the NVLAP process the Government is trying
to start up, rather than reinvent the testing wheel.

John

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 15:54:12 GMT
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   question about /etc/route

Classically, /etc/route (in most implmentations I have dealt with)
discerns the difference between hosts and routes not on the basis of
address, but on the basis of whether the NAME you give is in the file
/etc/networks.  This is a rather tricky little gotcha, and barely
documented.

This may not be the case anymore in SunOS 3.3.  (It certainly caught
be with WIN/VX 2.3.)  Also, I beleive Sun has noted problems with
subnet routes with /etc/routed in 3.3, as noted in the Sun Technical
Bulletin.  There may be a patch tape, or it may be fixed in a higher
release.

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 16:39:57 GMT
From:      AFDDN.TCP-IP@GUNTER-ADAM.ARPA
To:        comp.protocols.tcp-ip
Subject:   SLIP for Ultrix


  Forgive if this was posted and I missed it.  

We have a uVAX running Ultrix that I would "like" to have SLIP on.  Is such 
a beastie available?  I saw the postings for UNIX, but not being a
Unix or Ultrix wizard, I don't know how compatible the two really are.
Any Ultrix wizards out there know about SLIP??
Thanks in advance,
Darrel Beach
-------

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 18:54:32 GMT
From:      sma@GVAX.CS.CORNELL.EDU (Susan Armstrong)
To:        comp.protocols.tcp-ip
Subject:   Re: C binding interfaces for TCP/IP

Uh, Sun RPC may be widespread, and it may be a peachy protocol, but it was not "first".  Xerox's Courier was published and used before Sun RPC was ever conceived.  

Cheers,
    Susie Armstrong

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 18:59:37 GMT
From:      jru@etn-rad.UUCP (John Unekis)
To:        comp.protocols.tcp-ip
Subject:   XE520 tcp-ip


 Has anyone seen or heard of tcp-ip for the UNISYS (formerly burroughs)
 megaframe (XE520) . Does it run under BTOS or UNIX? Where can I get it ?
 Any help is appreciated.

 Thanks in advance    ihnp4 or voder!wlbr!etn-rad!jru

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 20:18:28 GMT
From:      rcoltun@GATEWAY.MITRE.ORG (Robert Coltun)
To:        comp.protocols.tcp-ip
Subject:   Re: PSN 7 End-to-End question.


   We have a version of ping that transmits packets based on the ARPANET
1822 interface considerations: number of outstanding rfnms for the
destination and the total in the output queue.  Ping (in its original
form) is excellent for looking at IP delays but it is difficult to get
to actual throughput using it. With the interface scanner, which is based
on netstat -h, we can send packets out as fast as the net can take them;
the transmitter can be throttled by a rfnm high-water mark and a high-water
mark of total packets in the output queue. 
	 Our definition of throughput is:
	   total # bits sent/(time of last received - time of first received)

   Our previous delay tests showed delay and variance of delays increasing
as the number of PSN hops increase. We tried the new tests for 3, 4, and
5 (minimum) PSN hops sending bursts of 30 512 byte packets out.

   The results of these test are preliminary and much work is still
need to draw any real conclusions. The results of the 3 hop case ranged
from 35Kb to 16Kb averaging around 23Kb. A rfnm high-water mark of <= 2
seemed to give us the best throughput values as well as the lowest rtt 
delays for this case. The 4 hop case worked well with a 2 rfnm high-water
mark (best throughput was around 28Kb); 5 PSN hop case worked well with a
5 rfnm high-water mark (best throughput was around 22KB).

    I too have seen low FTP transmission times. If these tests are
an indication of subnet throughput, where has all the throughput gone? 

--- Rob Coltun
    The MITRE Corporation
    rcoltun@gateway.mitre.org

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 22:04:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN 7 End-to-End question.

Dan,

Bob Kahn and I got about 42 kb/s on stress tests of the ARPANET
in its early stages. In later years, there was more code in the
IMP and it slowed down some. But then came end/end protocols like
TCP and, depending on the delay, I seem to recall we managed ony
about 35 kb/s through a single IMP, less if many hops were involved.

As to Lenny Kleinrock's 37%, that is 1/e and is the kind of result
you get with multi-access links - and even then, that number did not
guarantee stability (the packet satellite protocols demonstrated
that when running ALOHA style).

Vint

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 88 22:17:18 GMT
From:      Z3000JD@AWITUW01.BITNET
To:        comp.protocols.tcp-ip
Subject:   Installation of an Excelan EXOS 225 Card on Toshiba AT

I have an Excelan EXOS 225 Card (LanAnalyser) which I want to install
on a Toshiba T3200 AT.
When I jumper the Cache-Memory of the EXOS-Board to Addresses
  8000, 9000   it does not work, because there is the normal memory
  B000         it does not work, because there is the Display memory
  A000         I get a PARITY ERROR 2 during Power-on Selftest of
               the Toshiba.
Does anyone now,
  what the PARITY ERROR 2 on the Toshiba means,
  has already installed such a board on a Toshiba PC (this one?)
      and what jumper-setting he has used,
  has any Idea what to do.

Johannes Demel,
Technical University Vienna
Z3000jd@awituw01.bitnet

P.S. The card works on a XT-clone and another AT-clone.
     I have already tested using IRQ 2 and 3, and different
     IO-Base-addresses (300,310,320,360). Nothing helps
     to remove the Parity Error.

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 88 05:06:24 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP Verification Suite

Phil,

Although a protocol test suite is not perfect, it will tend to catch
errors before the software is released (hopefully).  Perhaps this will
reduce the amount of ad-hoc testing required.  I agree with you that
there is no test like trial-by-fire but perhaps the VS can shake out the
more flagrant bugs ahead of time.

In any case, I have a feeling that your stuff will get tested against
the suite anyway.

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 88 10:11:20 GMT
From:      sunny@hoptoad.uucp (Sunny Kirsten)
To:        comp.protocols.tcp-ip
Subject:   Re: Who knows this Ethernet-board?

These sound very much like the original 3-Com Ethernet board for
IBM-PC... so I'd suggest contacting 3-Com, who are on the uucp net.
If you can't find them in your uucp maps, let me know and I'll 
chase down an e-mail address, a physical address, or phone number
for you.

The SEEQ 8001 chip was not used in very many designs, but it was
one of the earliest available.  I don't know if 3-Com has a newer
design out (they probably do), but their original IBM-PC board
was the first to use the SEEQ-8001.

		Sunny
-- 
Sunny Kirsten, Astral Consultants			(415)457-7555 (voice)
233 Humboldt St., San Rafael, CA 94901	GEnie: astral	(415)457-7705 (modem)
USENET: {amdahl,frog,ihnp4,lll-crg,nsc,ptsfa,pyramid,sun,ucsfcgl,well}
	!hoptoad!astral!sunny

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 88 19:24:13 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Support for VRTX Operating System

Spider Systems has been around a while, but I don't know exactly how
long.  Products that I know they offer include a Sys V Streams TCP/IP
in source form, the "SpiderMonitor", a hardware-based Ethernet analyzer
which is (or at least was) sold in the US by CMC, and a version of our
TCP/IP for the IBM PC.  I believe they have also done contract development
of code in the U.K. and Europe.

Their address is:

Spider Systems
65 Bonnington Rd.
Edinburgh  EH6 5JQ

tel: 031-554 9197

I believe they also can be reached via UUCP as ...mcvax!spider!...

James B.VanBokkelen
FTP Software Inc.

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 88 19:36:59 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   SLIP for Ultrix

We got binary modules from a co-operative DEC support office (of course,
we're on our own for setup and if it breaks).  It is going to be quite
difficult, if not impossible, for you to add it without either source,
or help from someone who has source.  We are using Ultrix 2.0 on a
Microvax, and the SLIP line is our link to the ARPAnet.  Seems to work
ok, even when used as a router from our local ether to the wide world.

James VanBokkelen
FTP Software Inc.
jbvb@vax.ftp.com

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 88 19:54:33 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   SUN Serial Line Interface

With all the discussions in this forum concerning Sun Workstations, perhaps
someone can answer a question concerning serial line interfaces for the Sun.

We have a LAN with, among other workstations, Sun Workstations which must be
interfaced to a secure network over a synchronous serial channel using DDCMP
4.0 as the data link protocol which must be capable of supporting, at least,
a 9600 baud circuit.  We would like to use a Sun Workstation to interface to
the secure network.

Sun marketing types indicate that there is no such interface available.  Is
this an accurate statement?  Are there any synchronous serial line interfaces
that can be used and are there drivers available?  It would be preferable to
have the DDCMP 4.0 implementation on the board and to be compatible with the
DEC DMR11 implementation but not absolutely necessary.

Thanks in advance,

Merton Campbell Crockett
EATON Information Management Systems
AN/GYQ-21(V) Program

mcc@etn-wlv.EATON.COM

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 88 20:30:46 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Protocol Testing Laboratory Program

Well,  It looks like there is a chance that we will get to have
some official testing labs for the TCP/IP protocols suite if those
interested in seeing it come about read the following information
carefully and supply their comments to the appropriate parties named
below.  It is important that users and vendors make their desires
known to those who are empowered to establish this testing program.
We all know it is " bit late in coming" but as TCP/IP spreads
even farther into the world it is important to many that those
implementations be wrung out against some test before the
products are brought to market.  

I have extracted the following from the Federal Register (what ever that is!)
and urge you to "vote".

Dan

Federal Register/ Vol 52, No. 232/ Thursday December 3, 1987

National Bureau of Standards
(Docket No. 71156-7256)

National Voluntary Laboratory Accreditation Program:  Defense
Department Communications Protocols

AGENCY:  National Bureau of Standards, Commerce.

Action:  Notice: Request for Comments

SUMMARY:  The National Bureau of Standards (NBS) has received a request
to establish a laboratory accreditation program under the procedures of the
National Voluntary Accreditation Program (NVLAP) (15 CFR Part 7).  In a
letter dated October 27, 1987, the Defense Communications Agency (DCA)
Defense Communications Engineering Center requests NBS to establish a 
program to accredit laboratories that test the computer industry's 
implementations of communications protocols used by the Department of
Defense.  A copy of the DCA letter is appended to this notice.
Announcement of this request and of the NBS request for comments with
respect to the need for this program is being made under para 7.13(d)
of the referenced procedures.
DATE:  Comments should be received at the addresses below on or before
February 1, 1988. (They will still take comments, no sweat...)
ADDRESSES: Persons desiring to comment on the need for such a program
are invited to submit their comments in writing to Captain Steven Skipper,
DCEC, Code R620, 1860 Wiehle Avenue, Reston, Va. 22090.  A copy of such
comments should be sent to the Associate Director for Industry and Standards,
National Bureau of Standards, ADMIN A603, Gaithersburg, Md. 20899.

For Further Information Contact: Harvey W. Berger, Manager Laboratory
Accreditation, National Bureau of Standards, ADMIN A527, Gaithersburg,
Md. 20899 (301) 975-4017.

Supplementary Information:

NVLAP Accreditation

 NVLAP is a voluntary system for accrediting laboratories found competent
to perform specific testing operations.  Competence is defined as a 
laboratories ability to meet the NVLAP criteria and technical requirements
of the test methods for which it seeks accreditation.  NVLAP accreditation
does not confer or imply certification of products or test date.

Scope of LAP

 The scope of this program is set forth in the [un]appended letter from the 
Defense Communications Agency (DCA).  The program will address (A) Defense
Data Network (DDN) X.25 Link and Network Layer protocols as specified in
the DCA DDN X.25 Host Interface Specification; (B) the five DoD packet
switching High Level protocols (HLP): (1) Internet Protocol (IP), MIL_STD
1777; (2) Transmission Control Protocol (TCP), MIL-STD 1778; (3) File
Transfer Protocol (FTP), MIL-STD 1780; (4) Simple Mail Transfer Protocol
(SMTP), MIL-STD 1781; and (5) TELNET, MIL-STD 1782, and (C) the AUTODIN
Mode I protocol testing.  Laboratories may be accredited for testing one
or more of the protocol types.

Procedures Following Receipt of Comments:  After 60 days comment period,
DCA will evaluate
all comments pertaining to the need for the proposed program.  Upon
completion of that evaluation and further consultation with NBS, interested 
persons (those who submit comments or request to be placed on the NVLAP
mailing list) will be notified of the decision by the Director of NBS
whether NBS will proceed with the development of this program.  NBS plans
to coordinate this matter with DCA.

Documents in Public Record

  All comments in response to this notice will be made part of the public
record and will be available for inspection and copying at the NBS NVLAP
office.  Administration Building, Room A531.  Gathersburg, Maryland.


-------

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 88 22:23:13 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP Verification Suite

>Although a protocol test suite is not perfect, it will tend to catch
>errors before the software is released (hopefully).

On the other hand, it can also induce the `well we passed the protocol
test suite so if it fails to work it must be your fault' syndrome.  I
think the only cure for this is to state clearly that an implementation
must not only pass the verification tests, but also interoperate with
other such implementations, and that the end users reserve the right
to change the test suite as needed and retest.

>Brian Lloyd, President
>Sirius Systems, Inc.

Share and enjoy,
Share and enjoy,
Journey though life with a plastic boy
Or girl by your side,
Let your pal be your guide. . . .

(sorry)

Chris

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 88 02:08:39 GMT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: SUN Serial Line Interface

Sun sells no such interface; we support DECnet as an Ethernet end-node
only, and the sync drivers we sell do HDLC, SLDC, and Bisync using
the Sun CPU serial port, or optionally a Sunlink comm processor board.

Assuming you are planning on doing DDCMP with a DEC host of some kind,
I would imagine that it is possible to get a DMR11 driver from DEC
that supports HDLC (probably with X.25). I would think you would find
it easier to talk to many systems (including Suns) if you used
industry standard sync protocols such as HDLC.

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 88 03:03:23 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   SUN Serial Line Interface


I think I went around that circle a few years ago with DMR-11s. As I
remember they support DDCMP in on-board microcode and only DDCMP (it
starts doing it as soon as you enable.) You could only hook the other
end of a DMR up to either another DMR or a DUP-11 (truly raw sync
port) which had software pumping DDCMP through it, or possibly a
similar hookup using the sync port on a DMF32, same difference, ya
gotta have DDCMP.

I suppose that's the answer for that person, get something like a
DMF32, DUP-11 or a DV-11 (no, no, you don't really want one of those)
and some HDLC software etc but I can't tell from their posting what
their real situation is, are they committed to a DMR11 or was that an
idle comment about a possible board to purchase? What are they
*really* trying to do etc.? Sounds like they'd be better off locating
a SLIP implementation for both ends if they're only after a 9600b
hookup, a DMR is mostly overkill (unless you happen to have one.)

	-Barry Shein, Boston University

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 88 16:04:38 GMT
From:      hassler@NAP1.ARPA (Barry D. Hassler)
To:        comp.protocols.tcp-ip
Subject:   Dynamic routing support for Wollongong WIN/TCP



Is anyone aware of any dynamic routing programs for  Wollongong's
WIN/TCP  running  under  VAX/VMS?   According to Wollongong, they
will support something like the UNIX 'routed' (RIP  protocol)  in
release  3.2  (due  out  "in a couple of months"), but until that
time, I'm out of luck. We have  several  networks  with  multiple
redundant  gateways  and  LOTS  of VMS machines running  the Wol-
longong software. Unfortunately, right now these  machines  don't
have  any  way to fall back to alternate  routes should  one die.

Any leads anyone can offer would be greatly appreciated.

Thanks,

Barry D. Hassler
Control Data Corp

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 88 16:07:13 GMT
From:      bobj@MCL.UNISYS.COM (Bob Jones)
To:        comp.protocols.tcp-ip
Subject:   DCA Protocol Lab Test Tools


I recently saw a message from Hal Peterson at Cray (hrp%ishmael.cray.com
@uc.msc.umn.edu) regarding the DCA protocol laboratory test tools
which were being beta tested and Cray submitted to those tests.

I have just one rebuttal to a comment made by Hal.

The tests themselves do not take a significant amount of time to run.
On the contrary, the complete protocol suite can be tested fully in
one or two days - providing the remote drivers are working properly
and the network is not giving us problems.  We do have direct dial up
to the facility also.  The problem that Hal alluded to in terms of
time is really that of trying to correct the bugs found and being
retested.  That is what took so long.  If the drivers are working
and net is ok, the following times are generally common for testing
the protocols:

TCP - 2 hours
IP - 6 hours (this is being reduced to approx 2 hours)
FTP - 1 hour
Telnet - 1 hour
SMTP - 1 hour

I want to reiterate that this is the actual testing time and not the
attempts to go off and correct problems and come back up for testing.

bobj

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 88 18:46:21 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  DCA Protocol Lab Test Tools

Bob,

Holy Cow. If the network is okay almost anything will work, even ISOspeak.
What you want to know is how the implementations work when the net ISN'T
okay, when the remote drivers are buggy and at arbitrary times during
the day when packets are falling off the Earth and so forth. I would give
the okay-network test only a Journeyman Certificate, hardly more worthy
that an Ethernet Certificate. The heavy dudes claim Mailbridge Certificates
and the real wowsers claim the most exclusive of all, the NSFNET Medal.

Dave

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 88 19:25:53 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  SUN Serial Line Interface

Barry, Bill, et. al.:

You're recollection of the operational characteristics of the DMR11 is accu-
rate.  It starts transmitting START messages as soon as it is initialized at
either 1 or 3 second intervals depending upon the initialization parameters.

The basic problem is that a DIA approved "black box" will be inserted into
the serial link between the network node and the LAN which was developed,
unfortunately, with the assumption that a DMR11 would be present at both ends
of the serial link.  The "black box" uses a Simpact IPC 1622 to interface to
the communication link using a DMR11 DDCMP 4.0 compatible prtocol implement-
ation.

Merton Campbell Crockett
EATON Information Management Systems
AN/GYQ-21(V) Program

mcc@etn-wlv.EATON.COM

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 88 20:18:06 GMT
From:      bobj@MCL.UNISYS.COM (Bob Jones)
To:        comp.protocols.tcp-ip
Subject:   Re:  DCA Protocol Lab Test Tools

Dave,  thanks for comments.  The test system is robust enough to recover
from net-induced perturbations.  Thats not a real problem.  What has
happened from our experience is that we spend a lot, (lots!) of time
doing recoveries and not getting on with real testing.  Also the test
system has a rather extensive corruption capability to test the
implementations without the network adding to the pot.  I believe we
can claim the Mailbridge Certificate.  The NSFNET Medal?  I refuse to
die on my sword.

bobj

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 88 20:50:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: C binding interfaces for TCP/IP


    Date: Fri, 5 Feb 88 13:54:32 EST
    From: sma@gvax.cs.cornell.edu (Susan Armstrong)

    Uh, Sun RPC may be widespread, and it may be a peachy protocol, but it
    was not "first".  Xerox's Courier was published and used before Sun RPC
    was ever conceived.

Not only was it not first, it wasn't even third: The ITS MLDEV protocol
is an RPC-like protocol (MIT AI lab, late 60's or early 70's), and it
existed before there were 68000s, let alone companies building products
based on 68Ks.  Chaos QFILE is a richer RPC protocol (MIT AI lab, late
70's?).

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 88 23:29:48 GMT
From:      torben@dorsai.ics.hawaii.edu (Prof. Torben N. Nielsen)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for Ultrix

In article <8802060858.AA08978@ucbvax.Berkeley.EDU> AFDDN.TCP-IP@GUNTER-ADAM.ARPA writes:
>We have a uVAX running Ultrix that I would "like" to have SLIP on.  Is such 
>a beastie available?  I saw the postings for UNIX, but not being a
>Unix or Ultrix wizard, I don't know how compatible the two really are.
>Any Ultrix wizards out there know about SLIP??

Can't claim to be an Ultrix wizard, but I seem to recall Fred Avolio of
the Ultirx Group at DEC posting a message saying that he did have SLIP
for Ultrix. I took a look at an Ultrix system at one time and kind of
came to the conclusion that trying to do it yourself to a binary Ultrix
distribution was no fun.

						---Torben

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 13:41:00 PST
From:      "Jerry Scott" <jerry@twg.arpa>
To:        "hassler" <hassler@nap1.arpa>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   RE: Dynamic routing support for Wollongong WIN/TCP
Release 3.2, due in March or April will support GATED version 1.3.1.
It is currently being beta tested at several sites.  Once we feel the
version is solid it will be made available via anonymous ftp to host
twg.arpa.

Regards,
Jerry

-------
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 13:59:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   protocol verification


With the recent discussion about TCP testing and verification, I thought
that I would pass on an observation.  I don't know if this reflects on
just the specific instances or protocol testing in general.

I was involved with GM in testing of MAP protocols for Autofact '84 and '85.
Both times, all of the vendors eventually were able to successfully pass
the conformance test suite.  When interoperability testing began, MOST of
the vendors found problems affecting interoperability.  On other occasions,
I have seen systems working on real networks fail conformance tests and
systems which passed the conformance tests fail on the real network.

I feel that this probably stems from a tendency by the test writer(s)
to concentrate more on the protocol details (such as which diagnostic
error code should be returned), than on the basic functionality of the
protocol.  The protocol writer may then end up spending effort just trying
to make the test suite happy at the expense of a robust design.

						Art Berggreen
						art@acc.arpa

------
-------
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 11:32:54 GMT
From:      hd@philtis.UUCP (Henk D. Davids @ MSD)
To:        comp.protocols.tcp-ip
Subject:   telnet performance


At our site we have serious performance problems when using
telnet - character echo sometimes takes more than 20 seconds
even when the cpus involved are lightly loaded. Is there
anyone who has the same experience, or maybe even an explanation?

Our situation is as follows: we are running Excelan TCP/IP on VAX/VMS,
to Scald workstations running Unix. These are stations for circuit
design made by Valid. Telnet from one of the Scalds to another one is
not that fast either, but not nearly as slow as from the VAX to a Scald.

Any input will be appreciated.

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 13:33:25 GMT
From:      mtune!codas!usfvax2!pdn!larry@rutgers.edu  (Larry Swift)
To:        tcp-ip@sri-nic.arpa
Subject:   bounced mail to Jim Baldo
Jim:  I tried to respond to your last e-mail, but it got bounced and I
no longer have your original address.  Please send again.

Larry Swift                     UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981
-------
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 14:11:22 GMT
From:      LYMAN_CHAPIN@ICE9.CEO.DG.COM
To:        comp.protocols.tcp-ip
Subject:   IP-level echo/ping

In <[A.ISI.EDU] 2-Feb-88 21:23:38.CERF>, Vint Cerf writes:

> In the absence of anything else, your proposal seems the only option;
> is there really no thinking in the ISO standards for some kind of
> echo packet capability at the IP level?

Vint, DG brought a proposal for just such a beast to the joint ANSI/IETF
meeting at BB&N last April (or thereabouts), at which it received a cool
(silent) reception.  We intend to re-introduce it at an ANSI meeting in
three weeks.  We're proposing to put pinging at the IP level, but not IN
the IP (making IP more complicated - read "more prone to break" - so that
you can poke around diagnostically when you suspect that something IS broken
has never impressed me as a great idea).  A separate ECHO protocol, which
looks a lot like IP (similar packet format;  packets are processed by gateways
[almost] exactly like IP packets), gives you the diagnostic tool without
piggybacking stuff onto IP that doesn't belong there.  ECHO can also
contain more elaborate diagnostic functions that you would probably not want
to add to IP source routing, such as having each gateway along the path return
a diagnostic packet to the source (I would have said "NEVER want to add"
rather than "probably not want to add", but have recently talked with two
people who think that adding this capability to source routing would be
really neat.....).

If the ECHO proposal finds favor at the ANSI meeting, I'll distribute it
to the list for comment.

-----------------------------------------------------------------------------
Lyman Chapin                  lyman@ice9.ceo.dg.com
Data General Corp.            [lyman%ice9.ceo.dg.com@relay.cs.net]
(617) 870-6056
-----------------------------------------------------------------------------

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 14:16:28 GMT
From:      larry@pdn.UUCP (Larry Swift)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms
Subject:   Re: Pass an open socket to another process????

In article <291@tifsil.UUCP> bill@tifsil.UUCP (Bill Stoltz) writes:
>I have posted this to several boards, so please send your comments by e-mail.

Bill,

I, and I suspect many others, are interested in any replies you get.
Could you post a summary?


Larry Swift                     UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 15:24:40 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for Unisys (Burroughs) XE-520

We have TCP/IP for the B-20 and XE-500 product lines.  Please contact me
for further information.

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 17:31:09 GMT
From:      jbeard@quintus.UUCP (Jeff Beard)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms
Subject:   Re: Pass an open socket to another process????



Your problem is of interest to anyone concerned with nested servers.
I for one would appreciate a posting of the summary of your findings.

Tnx.

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 17:59:48 GMT
From:      lekash@ORVILLE.NAS.NASA.GOV (John Lekashman)
To:        comp.protocols.tcp-ip
Subject:   Subnet support in SunOS 3.3


   Some more esoteric configurations with multiple (DIFFERENT)
   non-standard netmasks on the same machine are supported in a 
   release that is currently in Beta test.

Any comment on when this might make it out of beta test?  We
have these suns about to become cray gateways, and there will
be two different subnetted networks connected to them.  One to two
months is the time frame in which I have to figure out some 
workaround to deal with this subnet problem.

					thanks,
					john

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 20:53:52 GMT
From:      tpmsph@ecsvax.UUCP (Thomas P. Morris)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   TCP-IP processor boards for BI VAXen?

Are there any companies producing "intelligent" TCP-IP
communications boards for BI-bus VAXen?  By `intelligent
TCP-IP communications board,' I mean something like the 
Bridge Communications IVECS or Micom NPxxx boards: these
beasts have their own ethernet interface, and microprocessor
and memory, and handle TCP-IP, TELNET and FTP protocols
on the board, freeing up the VAX from the overhead of 
managing the communications protocol. All t he boards of
this type with which I am familiar are Q-bus or UNIBUS
boards. We have no interest in retrofitting our 8530 with
a UBA, and want to know if there is anyone out there who
makes a BI-bus version of such a product.

Thanx in advance. Reply by mail: if there are enough 
responses, I'll summarize to the net.

Tom Morris, UNC School of Public Health

BITNET:	TOM@UNCSPHVX
USENET: ...!mcnc!ecsvax!tpmsph

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 21:05:20 GMT
From:      tpmsph@ecsvax.UUCP (Thomas P. Morris)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Need info on TWG TCP-IP processor overhead

Our site is looking into the purchase of some TCP-IP
terminal servers, to be connected to our VAX VMS 8530,
using the Wollongong TCP-IP (if we cannot find any
IVECS-type BI-bus processor board).

We have heard from other sites that there is `some'
overhead in running TCP-IP terminal server connections
using the TWG software. Claims about CPU overhead have
varied wildly. Can anyone who is actually using TWG
TCP-IP and VMS with BRIDGE or Micom or XYPLEX or DEVELNET
servers please comment? 

	"Hard" data would be much preferred. Something like
"The cpu overhead is x%/connected process" or "we find that
xx connections use yy% cpu just for communications via TCP-IP".

Thanx in advance. Please reply via mail. I'll summarize and
post back to the net.

Tom Morris UNC School of Public Health

BITNET:	TOM@UNCSPHVX
USENET: ...!mcnc!ecsvax!tpmsph

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 21:07:11 GMT
From:      kleonard@PRC.Unisys.COM (Ken Leonard --> kleonard@gvlv2@prc.unisys.com)
To:        comp.protocols.tcp-ip
Subject:   Re:  DCA Protocol Lab Test Tools

In article <8802071346.aa05817@Huey.UDEL.EDU> Mills@UDEL.EDU writes:
>Bob,
>
>Holy Cow. If the network is okay almost anything will work, even ISOspeak.
>...

What Bob meant by "network OK" was the simple ability to keep ANY
connection open, for the test-control channel, for even 10 minutes or so!

You ain't seen nuthin, in the way of netcrap, until you've been on the
wrong side of an imp with experimental (pre-alpha grade) code working
thru a gate with equivalent code.

Otherwise, the point is correct, and the test tools in question not only
work thru garbage--they can make garbage when it is needful.

Regardz,
Ken

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 21:41:00 GMT
From:      jerry@TWG.ARPA ("Jerry Scott")
To:        comp.protocols.tcp-ip
Subject:   RE: Dynamic routing support for Wollongong WIN/TCP

Release 3.2, due in March or April will support GATED version 1.3.1.
It is currently being beta tested at several sites.  Once we feel the
version is solid it will be made available via anonymous ftp to host
twg.arpa.

Regards,
Jerry

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 88 21:59:00 GMT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   protocol verification



With the recent discussion about TCP testing and verification, I thought
that I would pass on an observation.  I don't know if this reflects on
just the specific instances or protocol testing in general.

I was involved with GM in testing of MAP protocols for Autofact '84 and '85.
Both times, all of the vendors eventually were able to successfully pass
the conformance test suite.  When interoperability testing began, MOST of
the vendors found problems affecting interoperability.  On other occasions,
I have seen systems working on real networks fail conformance tests and
systems which passed the conformance tests fail on the real network.

I feel that this probably stems from a tendency by the test writer(s)
to concentrate more on the protocol details (such as which diagnostic
error code should be returned), than on the basic functionality of the
protocol.  The protocol writer may then end up spending effort just trying
to make the test suite happy at the expense of a robust design.

						Art Berggreen
						art@acc.arpa

------

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 88 05:11:31 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  DCA Protocol Lab Test Tools

Ken,

Point taken, with the exception of your comment on the depth of excrement in the
swamp. Having swept the alligators from the wrong end of the IMP, you are
cordially invited to swat the lizards on the NSFNET Backbone and dependent
tributaries. It's much like a municipal waterworks system going out to the
users, but also like a municipal sewer system coming back. Soon you may
apply for a Merit Badge Gongfermer Grade for demonstrated competence in
reptile extermination, which would seem a lot more fun than creepy-crawling
on the ARPANET and EIN.

Dave

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 88 14:57:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   DDCMP Implementations

Does anyone know of any synchronous DDCMP implementations written in C
which are available in source form (I know about TCI)? 
	
						art@acc.arpa

------
-------
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 88 17:53:10 EST
From:      "Alan R. Hill" <ahill@cc7.bbn.com>
To:        <art@acc.arpa>
Cc:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Re: protocol verification
Art,
	My experience in providing support to host subscribers trying to
bring new software products onto the DDN indicates that the biggest
oversight of protocol testing is imparement testing.  Sure, products
obey all the rules if the operating or test environment is perfect and
also obeys the rules but products routinely mis-behave or fail if the
environment is degraded or the communicating partner is not obeying protocol.

Regards,
Alan

-------
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 88 15:44:13 GMT
From:      MKG@PSUVM.BITNET
To:        comp.protocols.tcp-ip
Subject:   Guidelines to write Subject

Will the persons making use of the net please follow the guidelines
below to write subject of their posting which is more intelligent
and reflect some percentage of the contents.
     
1. If the posting is an enquiry or a question, then at least follow
   the subject line with a question mark. ( For those who are not aware
   of this, "?" key on the keyboard used for q.m.)
     
2. If its a humor article and you want more people to read your posting
   then you should follow the subject line with a bang !
     
3. If the posting is supposed to be for serious netters, then I think
   just a period (".") is enough.
     
Please direct any/all comments to  mkg@psuvm.BITNET
     
Enjoy posting intelligently..
     
Kamal Maheshwari.
     

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 88 18:32:20 GMT
From:      scott@scirtp.UUCP (Scott Crenshaw)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI and Sockets

> 
> Now, if you question really was: "I have a program written to use
> Berkeley sockets but I want to run it on a SVR3 machine which only
> has streams, what can I do?"  Then the answer is that some people
> who are "heavy into Streams/TLI" have written libraries on top of
> TLI which make it look like sockets.  The inverse operation,
> making sockets look like TLI is probably not possible without adding a
> bit of functionality to sockets.
>
Incidentally, System V Release 4 will integrate sockets,
as well as other goodies from Sun's OS, into the AT&T product.
 
-- 
	   Scott Crenshaw		{akgua,decvax}!mcnc!rti-sel!scirtp!scott
	   SCI Systems , Inc. 		Research Triangle Park, NC 

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 88 19:05:21 GMT
From:      kozel@SPAM.ISTC.SRI.COM (Edward R. Kozel)
To:        comp.protocols.tcp-ip
Subject:   Re:  protocol verification

Art,
	I could not agree more with you.  Validation of a protocol
based on the formal specification is certainly fundamental but does
not ensure either proper operation or interoperability.  As another
observation, I know of one officially validated DDN X.25 
implementation which broke when put into actual operation, yet it
passed the DCA protocol tests.  "Bake offs", while perhaps colloquial,
serve a very useful and important function.

Ed Kozel

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 88 22:06:21 GMT
From:      scott@scirtp.UUCP (Scott Crenshaw)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP-NETBIOS Info Wanted

I'd appreciate any information you can give me concerning
TCP/IP-NETBIOS. Thanks very much.

-- 
	   Scott Crenshaw		{akgua,decvax}!mcnc!rti-sel!scirtp!scott
	   SCI Systems , Inc. 		Research Triangle Park, NC 

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 88 22:53:10 GMT
From:      ahill@CC7.BBN.COM ("Alan R. Hill")
To:        comp.protocols.tcp-ip
Subject:   Re: protocol verification

Art,
	My experience in providing support to host subscribers trying to
bring new software products onto the DDN indicates that the biggest
oversight of protocol testing is imparement testing.  Sure, products
obey all the rules if the operating or test environment is perfect and
also obeys the rules but products routinely mis-behave or fail if the
environment is degraded or the communicating partner is not obeying protocol.

Regards,
Alan

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 88 22:57:00 GMT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   DDCMP Implementations


Does anyone know of any synchronous DDCMP implementations written in C
which are available in source form (I know about TCI)? 
	
						art@acc.arpa

------

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 88 00:26:51 GMT
From:      eric@otc.oz (Eric Dutkiewicz)
To:        aus.general,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   fast line coders/decoders


We are looking for an encoder/decoder chip(set) capable of supporting data
rates of at least 150Mbit/s. An example is the AMD TAXI chipset Am7968 & 
Am7969 which uses NRZI, 4B/5B coding, runs at 100Mbit/s, and complies with 
FDDI standard. 

While a faster version of this chipset would be ideal, what we're
looking for doesn't necessarily have to use 4B/5B coding etc, but would have 
to be fast (i.e. 150Mbit/s).

E-mail replies direct to myself, and I will summarise and release to the net.

			    Eric Dutkiewicz
			    |||| OTC ||

			ACSnet:  eric@otc.oz
			  UUCP:  {uunet,mcvax}!otc.oz!eric
			 Snail:  GPO Box 7000, Sydney 2001, Australia
			 Fax  :  +33 2 287 4990

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 88 02:33:40 GMT
From:      lamaster@ames.arpa (Hugh LaMaster)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: Need info on TWG TCP-IP processor overhead

In article <4582@ecsvax.UUCP> tpmsph@ecsvax.UUCP (Thomas P. Morris) writes:
>Our site is looking into the purchase of some TCP-IP
>terminal servers, to be connected to our VAX VMS 8530,
>using the Wollongong TCP-IP (if we cannot find any
>IVECS-type BI-bus processor board).

I'm not sure what an IVECS board is.  The following tests were
done on an 8650, VMS 4.5, recent Wollongong (Not sure of version, but
it is much improved over the earlier, much maligned, versions.)
I'm not sure which DEC Ethernet board we are using either.  BUT ...

>
>We have heard from other sites that there is `some'
>overhead in running TCP-IP terminal server connections
>using the TWG software. Claims about CPU overhead have
>varied wildly. Can anyone who is actually using TWG
>TCP-IP and VMS with BRIDGE or Micom or XYPLEX or DEVELNET
>servers please comment? 
>
>	"Hard" data would be much preferred. Something like
>"The cpu overhead is x%/connected process" or "we find that
>xx connections use yy% cpu just for communications via TCP-IP".

I have measured CPU overhead to: Ultrix, SunOS 3.2, and 
Annex Terminal Servers (X2.1.8).  Unlike in the past, before TWG
was so much improved, I am now unable to discern
ANY difference in CPU overhead between a TWG Telnet Connection
and a DM- type connection.  Recent measurements showed that
a TYPE of a large file on a machine with few interactive users
and some idle time (batch jobs off and on, which didn't seem
to have an effect on the test) produced about the same total
usage whether going to the network or to a terminal.  (Speed
scaled appropriately).

I haven't 
observed horrendous overheads due to terminals since we got rid of
our DZ-11's (I think that is what the interrupt per character
boards were).  If you have many many low CPU usage terminals
connected, and every last CPU cycle counts, you should probably do
a formal study.   If, on the other hand, you just want to make sure
that you won't lose half the machine because of terminal servers,
it doesn't look like an issue anymore (yes, it was in the past).
The total throughput of an 8650 appears to be about 12-14KBytes/sec
from TYPE, which may be doing line at a time output - 2KBytes/sec/MIPS.
In either case, there is substantial overhead from doing terminal
output, but it is about the same in either case.

If most of your usage is in EDT (or its successors) there may be
special efficiency issues- the Annex is supposed to put multiple
characters from cursor control in one packet.  Does a DMZ produce
only one interrupt in that case?  I suspect you get three, so
potentially the terminal server could be more efficient.  etc. etc.

(By the way, the Annex has been up for 112 days -probably our last
power outage.  It has been reliable.)

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Feb 88 12:55:44 EST
From:      Carol_Feder@um.cc.umich.edu
To:        Dan Lynch <LYNCH@A.ISI.EDU>
Subject:   Summary of MCA Ethernet Cards
   Subject: Re:  MCA Ethernet Cards
   To: BIG-LAN@SUVM.BITNET
   From: Carol_Feder@um.cc.umich.edu

   > I'm interested in finding out what Ethernet Cards exist
   > for the Micro Channel.  I'm most interested in finding
   > some that will run with Banyan Vines, 3Com's 3Plus, and Novell's
   > Netware.  I know a few exist out there.  If you know of any,
   > I'd be interested in finding out which card you're using and
   > what kind of performance you're experiencing for your network.


Here's a summary of the responses I received:
 - - - - -

   We've had several 3Com Etherlink/MC (3c523) cards in PS/2-60s
   for a few weeks now. No problems. We're using 3Com 3PLus. 150
   stations, mostly PCs, but not all.
 - - - - -

   Here at Virginia Tech we have used the Ungermann-Bass Nic/ps2
   card in a PS/2 model 60. We are running the IBM PC/IP code
   version 1.1 without any problems.
 - - - - -

   Ungermann-Bass have already released their PC-NIC for the
   Micro-Channel. The device is known as the NICps/2. It hasnt
   got a local processor like the PC-NIU but the price is very
   favourable. I just received a piece but have not tested it.
   Still trying to beg, borrow or steal a PS/2.

 - - - - -

   I'm not using any, but I know of the following two which are
   currently available: 3COM 3C523, which I believe 3Plus will
   support; and Ungermann-Bass NIC/2 (or something like that).
   Other vendors like Micom-Interlan and Western Digital have
   announced that they are working on MCA interfaces but have not
   delivered anything yet.
 - - - - -

   Hi. I know of only two MCA ether cards out now. The
   Ungermann-Bass NIC PS/2 and the 3Com Etherlink/MC. I've done
   drivers for both for pc/ip here and get comprable throughput
   from both. I would prefer the 3Com card as for less price one
   gets the thin transceiver onboard. I also doubt that the UB
   board would work with 3Plus, but can not comment on support of
   Vines or Netware for either card.
 ------------------------------

If anyone finds out anything new or different on this topic, send
a message to me and I'll be glad to summarize to the network.
Thanks everyone for your input!


Carol Ann Feder
LAN Consultant
The University of Michigan
Computing Center User Services

Bitnet Address:  carol_feder@um.cc.umich.edu
-------
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 88 14:26:30 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP books

There have been a couple of books about TCP/IP announced recently. I have
been asked by some support people at my site which one would be a good 
one to read. I have not read any of the new ones. Please give me your
impressions of the available books. A pointer to a book review would be
also appreciated. Reply to me. I will summarize to the net.

Thanks in Advance

Bill VerSteeg
Digital Communications Associates

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 88 15:03:41 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  SGMP support

Hans-Werner writes:

> ...       SGMP information should also get translated into Netview/PC
> information somewhere to stage it up to the NOC machine (an IBM 4381).

What does it mean translate SGMP to Netview/PC to "stage it up"?  What's
a NOC machine?  Is the NOC on the Internet?  Why would one want to "translate"
a protocol to another protocol, and "stage" it to a some machine having
nothing to do with the Internet?

Phil Wood
Los Alamos National Laboratory

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 88 17:55:44 GMT
From:      Carol_Feder@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Summary of MCA Ethernet Cards


   Subject: Re:  MCA Ethernet Cards
   To: BIG-LAN@SUVM.BITNET
   From: Carol_Feder@um.cc.umich.edu

   > I'm interested in finding out what Ethernet Cards exist
   > for the Micro Channel.  I'm most interested in finding
   > some that will run with Banyan Vines, 3Com's 3Plus, and Novell's
   > Netware.  I know a few exist out there.  If you know of any,
   > I'd be interested in finding out which card you're using and
   > what kind of performance you're experiencing for your network.


Here's a summary of the responses I received:
 - - - - -

   We've had several 3Com Etherlink/MC (3c523) cards in PS/2-60s
   for a few weeks now. No problems. We're using 3Com 3PLus. 150
   stations, mostly PCs, but not all.
 - - - - -

   Here at Virginia Tech we have used the Ungermann-Bass Nic/ps2
   card in a PS/2 model 60. We are running the IBM PC/IP code
   version 1.1 without any problems.
 - - - - -

   Ungermann-Bass have already released their PC-NIC for the
   Micro-Channel. The device is known as the NICps/2. It hasnt
   got a local processor like the PC-NIU but the price is very
   favourable. I just received a piece but have not tested it.
   Still trying to beg, borrow or steal a PS/2.

 - - - - -

   I'm not using any, but I know of the following two which are
   currently available: 3COM 3C523, which I believe 3Plus will
   support; and Ungermann-Bass NIC/2 (or something like that).
   Other vendors like Micom-Interlan and Western Digital have
   announced that they are working on MCA interfaces but have not
   delivered anything yet.
 - - - - -

   Hi. I know of only two MCA ether cards out now. The
   Ungermann-Bass NIC PS/2 and the 3Com Etherlink/MC. I've done
   drivers for both for pc/ip here and get comprable throughput
   from both. I would prefer the 3Com card as for less price one
   gets the thin transceiver onboard. I also doubt that the UB
   board would work with 3Plus, but can not comment on support of
   Vines or Netware for either card.
 ------------------------------

If anyone finds out anything new or different on this topic, send
a message to me and I'll be glad to summarize to the network.
Thanks everyone for your input!


Carol Ann Feder
LAN Consultant
The University of Michigan
Computing Center User Services

Bitnet Address:  carol_feder@um.cc.umich.edu

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 88 18:17:52 GMT
From:      ks@pur-ee.UUCP (Kirk Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: DDCMP Implementations

In article <8802100151.AA10942@ucbvax.Berkeley.EDU> <art@acc.arpa> writes:
>
>Does anyone know of any synchronous DDCMP implementations written in C
>which are available in source form (I know about TCI)? 
>	
>						art@acc.arpa

I wrote a DDCMP interface in C for our robots.  It is complete
enough to talk to both a Cincinnatti Milacron and a Unimate robot.
It is not overly efficient, but should work for 4.2BSD or 4.3BSD.
It includes a tty line discipline to form incoming characters into
packets for increased efficiency.  It seems to be able to recover properly
from unplugging the cable in the middle of communications.
It does not do all the maintenance mode stuff, and has no documentation
or support.  It only does async I/O lines (no synchronous stuff).
It has been in use without problems for about 2 years.
I can make it available via ftp.

				Kirk Smith
				ks@ee.ecn.purdue.edu

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 1988 07:42-EST
From:      GBELING@A.ISI.EDU
To:        tcp-ip-request@SRI-NIC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Guidelines to write Subject, BANG = !
hi, 
sometimes nice ideas come over the net. 
yours has 2 disadvatages:
1.) you forgot to mark your subject - 
   therefore i suppose a big bang is missing following your own text
2.) most mail-access programs shorten the subject line randomly - 
   so the marker HAS to be at the beginning of the subject line
regrads gerd beling
-------
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 05:51:51 GMT
From:      halls@boulder.Colorado.EDU (Andy Halls)
To:        comp.protocols.tcp-ip
Subject:   What is SLIP?

Excuse me, do I unserstand it right.  Is Serial Line IP (SLIP) a
protocol that works over serial lines that supports tcp stuff, like
ftp and rlogin  ???

Would someone be so kind as to educate me.  Also how can I get my hands
on such a thing.  

Andy Halls
phone: home (303) 455-9139  work (303) 282-2166
uucp: {cires | hao | nbires}boulder!halls
internet: halls@boulder.colorado.edu

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 12:36:00 EST
From:      <enger@bluto.scc.com>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        <@ucbvax.berkeley.edu:mkg@psuvm.bitnet>
Subject:   Subject Field policy  "."  "?"  "!"  ":-)"

Discussion has taken place on the need for a "protocol police", but I never
thought it would come to controlling the content of the Subject: line..

The message that sparked this response has a From: field containing
@psuvm.bitnet  .

Repair of the From: field should take precedence over commenting on the
Subject: field.

Bob Enger



-------
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 12:42:00 GMT
From:      GBELING@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Guidelines to write Subject

hi, 
sometimes nice ideas come over the net. 
yours has 2 disadvatages:
1.) you forgot to mark your subject - 
   therefore i suppose a big bang is missing following your own text
2.) most mail-access programs shorten the subject line randomly - 
   so the marker HAS to be at the beginning of the subject line
regrads gerd beling

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 13:24:23 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Guidelines to write Subject

Due to the absence of any appropriate terminator on your subject line, I am
not entirely sure how I should treat your comments.  Could you please provide
a Bachus-Naur Form description of the subject line syntax you wish to see
implemented?  Could you also provide a category for levity?

Merton Campbell Crockett

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 13:52:26 GMT
From:      symchych@SKL-CRC.ARPA (Tim Symchych)
To:        comp.protocols.tcp-ip
Subject:   Add one to the rules. or ? or !



If we make rules, and do not follow them, then
perhaps we should add a bang (#) to the subject
line.
tim

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 14:07:32 GMT
From:      symchych@SKL-CRC.ARPA (Tim Symchych)
To:        comp.protocols.tcp-ip
Subject:   !Add one more

Sorry about the bang. A crunch (#) for not
following the rules.
tim

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 15:52:16 GMT
From:      Peter_Cutting@newcastle.ac.uk (P. G. Cutting)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Ethernet Monitoring/Management and Planning Information

This is the first posting that we have put  on  usenet,  so  bare
with us.

We are 9 students on a  Computing  Science  advanced  MSc  course
(Computing  Softwareand  Systems Design) at Newcastle University,
England. We have been assigned a  group  project  concerning  the
monitoring/management  and  planning  of an ethernet network. The
project has been set because the Computing Lab wishes  to  expand
its ethernet  to the whole campus.

Departments linked by the new Ethernet will be allowed to connect
what ever hardware they desire so it is likely that a hetrogenous
network will develop.

At present we have a Spider ethernet monitoring tool, and a  Nest
network simulator (from Columbia University) . We hope to use the
first to provide us  with  quantative  load  information  on  the
current  ethernet,  and  the  second to help us predict the loads
that will occur on the future ethernet. Obviously we will have to
consult  each  university  department about how they will use the
future ethernet to achieve this.

One of the tasks specified in the project is to produce a set  of
network management tools. Some of which are noted below :-

* a broadcast facility which allows the manager  to send a message
  to some or all users on the network.

* a fault  monitor  which can tell the manager of any faults (both
  physical and software) that occur on the network.

* a load  monitor which  can  tell  the  manager  what  load  each
  device is putting on the network, etc.

If anyone has anything they think might be useful, be they tools,
references, reports, problems encountered or advice then we would
be more then pleased to hear from you.

The project must be completed by  the  end  of  April  so  it  is
important that replies be sent as soon as possible to -

CSSD@UK.AC.NEWCASTLE

We will post our results  including an annotated bibliography  to
the net if there is sufficient demand.

Thanks in advance.

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 21:30:00 EST
From:      <enger@bluto.scc.com>
To:        "mcc" <mcc@etn-wlv.eaton.com>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   RE Subject field policy.!@#$%^&*()_+  (that should cover everything)
Merton:
True to your message, I have already received a mail failure notice
from some place off in the land of the big blue machines.
(probably sent by printing to a virtual card punch, or worse).

In reading the exploded copy of my own mail, I realized that some
might missinterpret my comment about the Subject field.
It was meant to suggest that the original author should fix his own mailer
before critiquing the subject field content of others.

The new End to End has turned up some strange things:  I regularly found
two subnet VCs used to talk to an MIT host.  I wrote and asked them why; they 
told me they didn't know.  I asked them what they had their 1822 handling 
type set to.  They told me 7.

Best wishes,
Bob

-------
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 17:36:00 GMT
From:      enger@BLUTO.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   Subject Field policy  "."  "?"  "!"  ":-)"


Discussion has taken place on the need for a "protocol police", but I never
thought it would come to controlling the content of the Subject: line..

The message that sparked this response has a From: field containing
@psuvm.bitnet  .

Repair of the From: field should take precedence over commenting on the
Subject: field.

Bob Enger

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 18:57:06 GMT
From:      fedor@NISC.NYSER.NET (Mark Fedor)
To:        comp.protocols.tcp-ip
Subject:   Re:  Guidelines to write Subject


	kamal,

	since your subject neither contained a "?", ".", or "!"
	what category does it fall under?

	couldn't resist.... :^)

	Mark

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 19:32:13 GMT
From:      hrp@windsor.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   DCA Protocol Lab Test Tools

Bob,

You are correct and I was being too flip with my wording: the tests
are indeed quickly RUN.  What I meant to say is that it takes a long
time TO BE ABLE TO RUN the tests, because of the time necessary to
develop a ``remote driver'' program to run on the machine under test.
[The remote driver sits on top of the protocol under test and responds
to commands and data from the central test site, opening and closing
connections, echoing data, and so forth.]  Our experience indicates
that anyone who wants to run these tests should allocate several
people and several months to the task.  On a machine for which remote
drivers are available, that time would be shortened to a couple of
weeks for one person.

We've been at this for a year and a half now and we have yet to run
all of the tests.  This has happened for a number of reasons:  some
are unique to Cray, some are political, and some are a result of
working with a system in progress, whose specifications have been
changing while we work.  I am still convinced that our time is being
well spent, that this is a worthy effort, and that users of the
production version of the test suite will have a much easier time of
it than we have.

--
Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN  55120
hrp%hall.CRAY.COM@umn-rei-uc.ARPA	ihnp4!cray!hrp	    (612) 681-3145

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 19:40:36 GMT
From:      hrp@windsor.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   ``If the network is okay . . .''

Dave,

The suite includes tests for things like dropped packets, garbled
packets, and out of order packets.  But the testing machine and the
machine under test are separated by a network, and the testing machine
has to be able to check the results of the tests.  If the network is
dropping packets on its own, then the testing machine will be
wildered.

Does that make you willing to upgrade the certificate?  Mailbridge
second class, at least!

--
Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN  55120
hrp%hall.CRAY.COM@umn-rei-uc.ARPA	ihnp4!cray!hrp	    (612) 681-3145

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 19:50:15 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: What is SLIP?

SLIP is a primitive encapsulation for IP on serial lines (usually
asynchronous).  IP using it works the same way as IP using Ethernet,
or IP over X.25, or IP over Token Ring.

I have been told that SLIP has its roots in an old serial protocol 3Com
came up with for communicating between fileservers, and was adopted for
use with IP and asynchronous serial lines some time later, initially for
use between gateways (IP routers).  Rick Adams did a public domain
implementation for 4.2 Unix, and now one is distributed with 4.3.  It is
only relatively recently that SLIP has been supported by any commercial
vendors.

Commercial implementations that I know of include ours, for the IBM PC,
and cisco Systems' SLIP port concentrator/terminal concentrator/IP router.
I have heard that Sun will support it soon, if not already, and that
Encore has or will have something for their Annex.

James B. VanBokkelen
FTP Software Inc.

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 20:14:55 GMT
From:      MKG@PSUVM.BITNET
To:        comp.protocols.tcp-ip
Subject:   Response to "Guidelines to write Subjects" !

Hi,
Thank you everyone for the hearty comments and corrections.
I realized (after I posted my article) that I myself forgot
to observe those Guidelines but that, by no means, should
affect the suggestion. In any case, I'm sorry about the faux-pas.
I assure you all that in future I'll be more careful.
     
Thanks once again.
     
Kamal Maheshwari.
     
     
" Code of *Subject* makes the contents Artificially Intelligent!!"
     
     

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 20:33:51 GMT
From:      hrp@windsor.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   protocol verification

Alan,

You wrote that

   Sure, products obey all the rules if the operating or test
   environment is perfect and also obeys the rules but products
   routinely mis-behave or fail if the environment is degraded or the
   communicating partner is not obeying protocol.

This is absolutely correct, and is a widespread problem in the testing
of ANY software:  most programmers don't think to try invalid inputs.
For an excellent treatment of the topic read the first chapter of
``The Art of Software Testing'' by Glenford J. Myers; then read the
rest of the book, which is well worth the time of anyone who tests,
builds, or otherwise copes with software.

On the matter at hand:  the DCA Protocol Laboratory Suite includes
lots of tests which deliberately violate the protocols.

This points up a couple of arguments in favor of having a verification
suite as a part of comprehensive testing.  First, the test procedure
can create arbitrary errors at arbitrary intervals, taking into
account known implementation mistakes of the past and anticipating
tomorrow's buggy code.  Second, once such violations are in the suite,
they are there for good; with bake-off testing, implementors fix their
bugs as they go along and some flakinesses become extinct, so some of
everyone's error detection code goes untested.  A good (and
well-maintained!) verification suite can give you the effect of
talking to every dumb mistake that's been made plus a few still
waiting to be made.

I should stress, though, that a verification suite is only part of a
comprehensive testing strategy, and that bake-offs can be extremely
valuable for finding bugs.  A verification suite is software, and like
all software it is imperfect.  It is entirely possible that two
implementations both pass the suite but don't interoperate.  Bake-offs
can catch that, and when they do they have found as many as FOUR bugs:

1.  a bug in one of the implementations.
2.  a bug in the other implementations; after all, they could both be
    at fault.
3.  a bug in the specification.  It may be unclear or inconsistent or
    incomplete and so have misled the implementors.
4.  a bug in the verification suite.  It should have caught the
    problem, and next time it will, since it's a simple matter to add
    a test to a well-designed suite.  The suite gets better as time
    goes on.

--
Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN  55120
hrp%hall.CRAY.COM@umn-rei-uc.ARPA	ihnp4!cray!hrp	    (612) 681-3145

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 20:44:51 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP-NETBIOS Info Wanted

The details of the protocol are in RFCs 1001 and 1002.  There is a
write-up of the history  of NETBIOS and its implementation over TCP/IP
in the most recent issue of the Connexions newsletter (from Advanced
Computing Environments), written by John Romkey.

Basically, what it is is the use of TCP and UDP to transport data
between pairs of programs which make Int 5C calls on PCs, or something
similar (but not yet standardized) on non-DOS systems.  The programs
that call Int 5C are either LAN programs (like Microsoft Networks or
the IBM PC LAN Program), which redirect the DOS filesystem via the
network, or applications like central SNA gateways, or shared databases
where a more user-level application makes the calls.  The TCP is just
substituting for proprietary protocols (XNS-derived in the case of 3Com,
Banyan or Novell), or incompatible subsets of OSI transport protocols,
or whatever else.  The major benefit conformance to the TCP standard
brings is the ability to interoperate between different vendors'
implementations.

A couple of commercial versions are available now, for PCs, and more
should be (for some other systems, too) within 30 to 90 days.

James B. VanBokkelen
FTP Software Inc.

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 21:41:23 GMT
From:      bill@tifsil.UUCP (Bill Stoltz)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms
Subject:   SUMMARY - Re: Pass an open socket to another process???



Thanks to everyone who sent me mail on the passing an open socket
request.

A quick summary is that this capability does exist on 4.[23] BSD
systems, and in a more restricted environment on AT&T V.3.
We are running Ultrix 2.0 (a 4.[23] derivative) here, and I have
tested this capability and it does work.  I did not hear any
thing from anyone else (no VMS or Xenix systems) so I don't know if 
this will work on any of these system. (Maybe someone can post 
something on whether these systems support this type of system call).

The following is a summary of the responses that I received during
the last week. Again thanks to everyone who sent in a response.
At the end I will give an account of the day and a half I spent 
getting a test case working.

Most of the responses were to use sendmsg/recvmsg in 4.[23] BSD.
These calls are defined in the recv(2) and send(2) man pages.
Thanks to the explanation by several people, I was informed that the
accessrights field is actually an array of file descriptors.

Doug McCallum <ti-csl!im4u!ut-sally!violet.ico.isc.com!dougm>, explained it
the best when he said: 

> On a 4.2/4.3 BSD system, there is the concept of access rights
> passing.  It only works in the AF_UNIX domain but could be made to
> work with other protocols given a little work.  Basically, it lets you
> pass any file descriptor to another process.  It uses the AF_UNIX
> SOCK_DGRAM mechanism and is an array of int's in the structure used in
> recvmsg/sendmsg.  I've used this as a way to implement a file password
> server to allow opening a restricted access file if you knew the
> password.
> 
> It works like a "dup" across process boundaries.

Doug went on to say that this capability is a standard feature of AT&T V.3. 

> On V.3, the Streams mechanism allows a process to send a stream
> descriptor over a connected stream pipe (a stream pipe is a stream
> that connects two processes on the same machine).  Since Streams is
> protocol independent, you could implement any protocol underneath and
> have the same capability.  Note that Streams by itself isn't a
> protocol and V.3 may come with Streams but no protocols.  V.3 does
> have a stream pipe which is very simple minded and appears to exist
> solely as a way to get other streams descriptors to an unrelated
> process.
> 
> Streams is the abstraction that AT&T is using for future network
> support.
> 
> The big difference between the two mechanisms is that BSD allows any
> file descriptor and V.3 only allows streams file descriptors.

A couple people also mentioned the "inetd" or Sun inet program.  They
felt that this also provided this type of cabability.  I did not spend
much time looking into this option,  The Ultrix 2.0 inetd did not
use the sendmsg/recvmsg calls so I stopped looking at it.

Once I received all this information, I decided that I could put together 
a simple test case in a matter of hours.  Well, I found a few stumbling 
blocks along the way that I would like to let everyone know about.  Hopefully
I can help some people and save them some time.

First the send(2) and recv(2) man pages that describe the sendmsg/recvmsg
calls are VERY cryptic.  They briefly mention the parameters by name but
give you very little information on what to put in them.

To get started I took an already working program and hacked it into 
2 programs.  The first process was the main server and the second process
was basically one of the subroutines from the old server that only
sent back a datetime string.

At this point I now had to add a socket(2) and a bind(2) call to both
processes.  The socket used AF_UNIX and SOCK_DGRAM parameters.  The bind
call was a little tricky.  You have to give bind a valid Unix file name.
So, I set up both processes the same way, except for different file names.


	struct	sockaddr_un sktname;

	sc = socket(AF_UNIX, SOCK_DGRAM, 0);
	sktname.sun_family = AF_UNIX;
	unlink(path);
	strcpy(sktname.sun_path, "/tmp/test.serv");
	err = bind(sc, &sktname, sizeof(sktname));

The bind actually creates a file on the system.  The unlink is there to 
remove the socket if it already exists, so the bind can create a new one.
I don't know if this is necessary, but I noticed this in the elcsd(8) program.

The next step was to modify the server process to send the file descriptor
to the datetime process, instead of calling this subroutine to send back
the response.  The following is the code I inserted to send over the 
connection.

struct	msghdr	sktmsg;
struct	sockaddr_un sktname;
struct	iovec 	iov;
	char	buf[80];
	int	rights[1];
	int	socket2pass;

	sktname.sun_family = AF_UNIX;
	strcpy(sktname.sun_path, "/tmp/test.dt");
	iov.iov_base = buf;
	iov.iov_len = 0;
	rights[0] = socket2pass;

	sktmsg.msg_name = (caddr_t) &sktname;
	sktmsg.msg_namelen = sizeof(sktname);
	sktmsg.msg_iov = &iov;
	sktmsg.msg_iovlen = 1;
	sktmsg.msg_accrights = rights;
	sktmsg.msg_accrightslen = sizeof(rights);

	sendmsg(sc, &sktmsg, 0);

Notice several things that are not clear in the man pages.  First, you must
pass in a sockaddr structure for the name of the socket to send this too,
and the size is the size of the structure, not the length of the string name.
If you just pass in the path name and length of the string you will get errors
like "No such file or directory".  Second the iovlen is the number of iovec
structures passed in.  Also, on a send, you must provide at least one iovec
structure.  I also filled in the buffer address, but left the length at 0,
I have not tried it to see if a buffer is required, my guess is yes.

Last is the accrights.  I made the assumption that the rights worked like the
iovec structures, WRONG.  For this you give the total number of bytes
you want the kernel to read in.  You must also be sure that every value you
put into the rights array is a valid file descriptor for the sending process
or you will get back an EBADF error.

Once I got all the parameters straight it worked great.

I then changed the new datetime process to block on a recvmsg call waiting
for this new connection so I could send back the datetime string.
The following is what I added to the datetime program.


struct	iovec 	iov;
	int	rights[5];
struct	msghdr	sktmsg;
	char	buf[80];

	iov.iov_base = buf;
	iov.iov_len = sizeof(buf);
	sktmsg.msg_name = 0;
	sktmsg.msg_namelen = 0;
	sktmsg.msg_iov = iov;
	sktmsg.msg_iovlen = 1;
	sktmsg.msg_accrights = rights;
	sktmsg.msg_accrightslen = sizeof(rights);

	recvmsg(sc, &sktmsg, 0);

Since this was a test program I ignored the name on the receive side.
I setup the iovec buffer, even though I knew there was no data coming in.

The last step was to retrieve the new file descriptor and issue the
send of the datetime string.  The file descriptor was now converted to
a new unused descriptor for the datetime process.  After sending out the
string, I just closed the new file descriptor and went back to wait for the
next message.  The server also closed the connection right after the
sendmsg call.

	new_fd = rights[0];
	dt_send(new_fd);
	close(new_fd);


This has been a rather long summary of the responses I got and the
work that I have done.  I hope this helps some of the people that asked 
me for a response.

I feel very comfortable with this solution.  I am recommending to the
other people in our group to use the sendmsg/recvmsg calls as a way
to implement the passing of a socket to a non-related process.  I hope 
this will help someone, I know it has helped me.

Thanks again for the responses.

bill

-----------
Bill Stoltz
Texas Instruments
Process Automation Center
P.O. Box 655012, M/S 3635
Dallas, TX 75243

UUCP: 	{uiucdcs!convex!smu, {rice, sun!texsun}!ti-csl}!tifsie!bill
DECNET: TIFSIE::bill
Voice:	(214) 995-2786

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 22:37:10 GMT
From:      sklower@sequoia.Berkeley.EDU.berkeley.edu (Keith Sklower)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms
Subject:   Re: Pass an open socket to another process????

In article <633@eden.quintus.UUCP> jbeard@quintus.UUCP (Jeff Beard) writes:
>
>
>Your problem is of interest to anyone concerned with nested servers.
>I for one would appreciate a posting of the summary of your findings.
>
>Tnx.

4.2 and 4.3 BSD provide a means of passing an open file descriptor
of any sort (including sockets) between two co-operating processes
by means of the sendmsg system call.

In fact, I am presently engaged in reducing the latency in providing
XNS courier services under UNIX by use of this mechanism.  The Courier
RPC protocol imbeds requests for services as part of the data of a stream,
so one would like to pass the stream between processes, and fork + exec
is a relatively slow way to do it.

For greatest speed, you want to establish an additional UNIX-domain
socket connection between the two processes prior to when the "passing
of the baton" will occur.  You can do this with either a stream or datagram
connection (but if you use a datagram connection you must be careful
to check that the sendmsg system call doesn't fail due to lack of buffer
space; if it does, don't close the socket you are handing off, but try
the sendmsg() system call over again later).

Here is a code fragment to send the file descriptor:
(You can pass data in addition to the socket, like any excess
data you may have drained from it by mistake).

pass_fd_rights(s, fd, buf, buflen)
        int s, fd, buflen;
        char *buf;
{
        static struct   msghdr msg;
        static struct   iovec iov[1];

        iov->iov_base = buf;
        iov->iov_len = buflen;
        msg.msg_iov = iov;
        msg.msg_iovlen = 1;
        msg.msg_accrights = (caddr_t)&fd;
        msg.msg_accrightslen = sizeof (fd);
        sendmsg(s, &msg, 0);
}

recvmsg() is the system call you use to collect the passed file descriptor.

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 88 23:18:09 GMT
From:      hrp@windsor.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   Life in the Swamps / Testing

Dave,

In view of your remark

   Having swept the alligators from the wrong end of the IMP, you are
   cordially invited to swat the lizards on the NSFNET Backbone and
   dependent tributaries. It's much like a municipal waterworks system
   going out to the users, but also like a municipal sewer system
   coming back.

I (as a tester of TCP/IP and user of the Internet) hope that somebody
out there is collecting the gooiest, scaliest monsters for eventual
domestication in a test suite.  If there is bizarre behavior that
uncovers bugs and happens out there in the swamps, then we must have
samples with which to inoculate our implementations.

	``Those who cannot remember the past are condemned to repeat
	it.''			- George Santyana

--
Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN  55120
hrp%hall.CRAY.COM@umn-rei-uc.ARPA	ihnp4!cray!hrp	    (612) 681-3145

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 01:05:55 GMT
From:      jonab@CAM.UNISYS.COM (Jonathan P. Biggar)
To:        comp.protocols.tcp-ip
Subject:   Bug in Sun OS 3.4 tcp?

Does anyone know about a problem with tcp under Sun OS 3.4 where receiving
a packet with the maximum segment size option messes up the window?
Our Suns can talk find to each other, but when they receive data from
a machine that uses the MSS option, the connection eventually hangs
because the Sun never updates the window.  I have tried using diff on
the 3.4 source and the 4.3bsd tcp and have found no substantial differences,
so this bug might exist in 4.3bsd also.

Thanks,

Jon Biggar

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 01:13:34 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Subject Field policy  "."  "?"  "!"  ":-)"

Bob:

Thank you for the remark about the "From:" field.  It may not be relevant but
it does seem that since the implementation of the new End/End Protocol that
there has been a marked increase of comments/suggestions in this forum from
interested parties without valid return addresses.  Belay that remark, it
probably started with the change to "name servers" from "host tables", it
just got worse.

Perhaps its a problem with my view of electronic mail, particularly mail
that is for forwarded to "tcp-ip@sri-nic.arpa"; it is irrelevant to me whether
a subscriber to this service from "bangland" failed to leave his PC powered-up
to receive my comment or retort of questionable significance.  Why should
I be inundated with "unable to deliver to xxx" messages?  Its "tcp-ip" that
needs the knowledge as it may signify some network problem!

It does raise some questions about SMTP and its interpretation of "From:"
and "Forwarded by:".  The reporting of delivery errors should always be
delivered to the "Forwarded by:" individual not the "From:" individual who
may not have authorized the dissemination of the message.

Merton Campbell Crockett

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 01:32:30 GMT
From:      jtn@potomac.ads.com (John T. Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 to Milnet PSN problems - the continuing saga

In article <7@ucsd.EDU>, brian@ucsd.EDU (Brian Kantor) writes:
> 
> I'm told that a trace in the PSN code shows that the IMP wasn't even
> trying to open the circuit to us, so it's probably in or related to the
> PSN code and not the interface - especially since it just started
> happening without us making and hardware or software changes.  It DID
> start around the time the Arpanet cut over to PSN-7, but we're on the
> Milnet.
> 
> We're currently running a process that sends a single ping packet to
> each of the Milnet mailbridges once every 45 seconds to ensure that the
> X.25 VC stays open so that traffic will find an already-open VC instead of
> blocking because it can't open one of its own.

Well aside from you being on the Milnet this sounds just like our
experiences.  However we have a Sun III/180 running 3.4 of their
operating system with the Sun X.25 DDN software and an SCP board.  Our
PSN is running 7.0 and we talk to it only via HDH (although we are
configured to talk via X.25 "extended").

I run a ping on a host that we peer with every second.

We are still talking to BBN about these problems.



-- 


John T. Nelson			UUCP: sun!sundc!potomac!jtn
Advanced Decision Systems	Internet:  jtn@potomac.ads.com
1500 Wilson Blvd #512; Arlington, VA 22209-2401		(703) 243-1611

"Hi... My name is Hobbes.  I'm the product of a malicious 5-year old's
twisted and destructive imagination.  Would YOU like to be my friend?"

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 02:30:00 GMT
From:      enger@BLUTO.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   RE Subject field policy.!@#$%^&*()_+  (that should cover everything)

Merton:
True to your message, I have already received a mail failure notice
from some place off in the land of the big blue machines.
(probably sent by printing to a virtual card punch, or worse).

In reading the exploded copy of my own mail, I realized that some
might missinterpret my comment about the Subject field.
It was meant to suggest that the original author should fix his own mailer
before critiquing the subject field content of others.

The new End to End has turned up some strange things:  I regularly found
two subnet VCs used to talk to an MIT host.  I wrote and asked them why; they 
told me they didn't know.  I asked them what they had their 1822 handling 
type set to.  They told me 7.

Best wishes,
Bob

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 02:33:49 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Life in the Swamps / Testing

Hal,

Once upon a time Vint Cerf was keeper of the alligators and even Bob Braden
collected a few. I've got a backyard full of the critters myself. However,
the point of my remark was that we don't need to invent bizarre test suites,
just how well it works in the current environment. What may be more useful
for you would be to find out what the current environment really is (loss
rates, mangle angles, quench characteristiccs, etc., then build a flakeway
(broken network simulator) with similar characteristics and do war with it.
That's in fact how we did the initial IP testing (with credit to Bob Braden)
in the bakeoffs of antiquity.

I'll rephrase my homily: We have met the enemy and he is us. Now you may
understand my preocupation with swamps. Pass the stogies, Albert.

Dave

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 04:29:51 GMT
From:      chris@trantor.umd.edu (Chris Torek)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms
Subject:   Re: Pass an open socket to another process????

In article <22952@ucbvax.BERKELEY.EDU> sklower@sequoia.Berkeley.EDU.UUCP
								    ----?
(Keith Sklower) writes:

>4.2 and 4.3 BSD provide a means of passing an open file descriptor
>of any sort (including sockets) between two co-operating processes
>by means of the sendmsg system call.

Beware, however, of some rather serious bugs in the implementation
in 4.2BSD.  For instance, using MSG_PEEK with recvmsg() on a message
with rights can cause multiple acceptance of the passed file
descriptor, resulting in eventual file system corruption (without
the closef firewall) or a panic (with the firewall).

All of this is fixed in 4.3BSD (with the possible exception of the
fd garbage collection code---try not to send pipe descriptors to
yourself over those pipe descriptors, please).  Which SunOS releases
may have which bugs I cannot say.
-- 
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
(hiding out on trantor.umd.edu until mimsy is reassembled in its new home)
Domain: chris@mimsy.umd.edu		Path: not easily reachable

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Feb-88 10:41:10 EST
From:      lamy@ai.toronto.edu (Jean-Francois Lamy)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip.domains
Subject:   Re: What is SLIP?


On a related note: I'm curious to know how an asynchronous SLIP (is there such
a beast?) would fare on high-speed Telebit style modems.  Anybody tried such a
setup?

Jean-Francois Lamy
AI Group, Department of Computer Science           lamy@ai.toronto.edu
University of Toronto, Canada M5S 1A4              uunet!ai.toronto.edu!lamy 


-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 06:17:04 GMT
From:      van@LBL-CSAM.ARPA (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   Dynamic Congestion Avoidance / Control (long message)

A dozen people forwarded Phil Karn's question about TCP
congestion control to me, usually with pithy subject lines like
"how much longer till you publish something?".  I do have three
RFCs and two papers in various stages of preparation, but innate
laziness combined with this semester's unexpectedly large
teaching load means it will probably be late spring before
anything gets finished.  In the interim, here's a sort-of
overview of our congestion control work.

I should point out these algorithms are joint work with Mike
Karels of UC Berkeley (I guess my name got stuck on things
because I make the presentations while Mike is off fighting the
battles on EGP or routing or domains or ...).  I should also
mention that there's not a whole lot that's original.  In
particular, the two most important algorithms are quite close to
(prior) work done by DEC's Raj Jain.  This was by accident in
one case and deliberate in the other.

This stuff has been discussed on the ietf and end2end lists
(Phil participated in some of those discussions and was, in
fact, one of the early beta testers for our new tcp --  I have
this nagging suspicion I was set up).  I've appended a couple of
those mail messages.


Mike and I have put a number (six, actually) of new algorithms
into the 4bsd tcp.  Our own measurements and the reports of our
beta testers suggest that the result is quite good at dealing
with current, congested conditions on the Internet.  The various
algorithms were developed and presented at different times over
the past year and it may not be clear to anyone but the
developers how, or if, the pieces relate.

Most of the changes spring from one observation:  The flow on a
TCP connection (or ISO TP-4 or XNS SPP connection) should, by
the design of the protocol, obey a `conservation of packets'
principle.  And, if this principle were obeyed, congestion
collapse would become the exception rather than the rule.
Thus congestion control turns into finding places where
conservation is violated and fixing them.

By `conservation of packets' I mean the following:
If you look at the connection "in equilibrium", i.e., running
stably with a full window of data in transit, you notice that
the flow is what a physicist would call "conservative":  A new
packet isn't put into the network until an old packet leaves.
Two scientific disciplines that deal with flow, hydrodynamics
and thermodynamics, predict that systems with this conservation
property should be extremely robust in the face of congestion.
Observation of the Arpanet or NSFNet suggests that they were not
particularly robust in the face of congestion.  From whence
comes the discrepancy?

[Someone asked me for a simple explanation of why a conservative
flow system should be stable under load.  I've been trying to
come up with one, thus far without success -- absolutely nothing
in hydrodynamics admits to simple explanations.  The shortest
explanation is that the inhomogenous forcing terms in the
Fokker-Planck equation vanish and the remaining terms are highly
damped.  But I don't suppose this means much to anyone (it
doesn't mean much to me).  My intuition is that conservation
means there's never an `energy difference' between the outside
world and the system that the system could use to `pump up' an
instability to a state of collapse.  Thus the only mechanism the
system can use for self-destruction is to re-arrange its
internal energy and create a difference large enough to break
something.  But entropy (or diffusion) always trys to erase
large internal energy differences so collapse via these
mechanisms is improbable.  Possible, but improbable, at least
until the load gets so outrageous that collective, non-ergodic
effects start to dominate the overall behavior.]

Packet conservation can fail three ways:

  1) the connection doesn't get to equilibrium, or

  2) a sender injects a packet before an old packet has exited, or

  3) the equilibrium can't be reached because of resource
     limits along the path.

(1) has to be from a connection starting or restarting after a
packet loss.  Another way to look at the conservation property
is to say that the sender uses acks as a "clock" to strobe new
packets into the network.  Since the receiver can generate acks
no faster than data packets can get through the network, the
protocol is "self clocking" (an ack can't go in until a packet
comes out, a packet can't go in until an ack comes out).  Self
clocking systems automatically adjust to bandwidth and delay
variations and have a wide dynamic range (an important issue
when you realize that TCP spans everything from 800 Mbit/sec
Cray channels to 1200 bit/sec packet radio links).  But the same
thing that makes a self-clocked system stable when it's running
makes it hard to get started -- to get data flowing you want acks
to clock packets out but to get acks you have to have data flowing.

To get the `clock' started, we came up with an algorithm called
slow-start that gradually increases the amount of data flowing.
Although we flatter ourselves that the design of this algorithm
is quite subtle, the implementation is trivial -- 3 lines of
code and one new state variable in the sender:

    1) whenever you're starting or restarting after a loss,
       set your "congestion window" to 1 packet.
    2) when you get an ack for new data, increase the
       congestion window by one packet.
    3) when you send, send the minimum of the receiver's
       advertised window and the congestion window.

(This is quite similar to Raj Jain's CUTE algorithm described in
IEEE Transactions on Communications, Oct, '86, although we didn't
know about CUTE at the time we were developing slowstart). 

Actually, the slow-start window increase isn't all that gradual:
The window opening takes time proportional to log2(W) where W is
the window size in packets.  This opens the window fast enough
to have a negligible effect on performance, even on links that
require a very large window.  And the algorithm guarantees that
a connection will source data at a rate at most twice the
maximum possible on the path.  (Without slow-start, by contrast,
when 10Mb ethernet hosts talk over the 56Kb Arpanet via IP
gateways, the gateways see a window's worth of packets (8-16)
delivered at 200 times the path bandwidth.)

Once you can reliably start data flowing, problems (2) and (3)
have to be addressed.  Assuming that the protocol implementation
is correct, (2) must represent a failure of sender's retransmit
timer.  A good round trip time estimator (the core of the
retransmit timer) is the single most important feature of any
protocol implementation that expects to survive heavy load.  And
it almost always gets botched.

One mistake seems to be not estimating the variance of the rtt.
From queuing theory we know that rtt and rtt variation increase
very quickly with load.  Measuring the load by rho (the ratio of
average arrival rate to average departure rate), the rtt goes up
like 1/(1-rho) and the variation in rtt goes like 1/(1-rho)^2.
To make this concrete, if the network is running at 75% of
capacity (as the Arpanet was in last April's collapse), you
should expect rtt to vary by a factor of 16 around its mean
value.  The RFC793 parameter "beta" accounts for rtt variation.
The suggested value of "2" can adapt to loads of at most 30%.
Above this point, a connection will respond to load increases by
retransmitting packets that have only been delayed in transit.
This makes the network do useless work (wasting bandwidth on
duplicates of packets that have been or will be delivered) at a
time when it's known to be having trouble with useful work.
I.e., this is the network equivalent of pouring gasoline on a
fire.

We came up a cheap method for estimating variation (see first of
attached msgs) and the resulting retransmit timer essentially
eliminates spurious retransmissions.  A pleasant side effect of
estimating "beta" rather than using a fixed value is that low
load as well as high load performance improves, particularly
over high delay paths such as satellite links.

Another timer mistake seems to be in the backoff after a
retransmit:  If we have to retransmit a packet more than once,
how should the retransmits be spaced?  It turns out there's only
one scheme that's likely to work, exponential backoff, but
proving this is a bit involved (one of the two papers alluded to
in to opening goes through a proof).  We might finesse a proof
by noting that a network is, to a very good approximation, a
linear system.  (That is, it is composed of elements that behave
like linear operators -- integrators, delays, gain stages,
etc.).  Linear system theory says that if a system is stable,
the stability is exponential.  This suggests that if we have a
system that is unstable (a network subject to random load shocks
and prone to congestive collapse), the way to stabilize it is to
add some exponential damping (read: exponential timer backoff)
to its primary excitation (read: senders, traffic sources).

Once the timers are in good shape, you can state with some
confidence that a timeout really means a lost packet and not a
busted timer.  At this point you can do something about (3).
Packets can get lost for two reasons: they are damaged in
transit or the network is congested and somewhere on the path
there was insufficient buffer capacity.  On most of the network
paths we use, loss due to damage is rare (<<1%) so it is very
probable that a packet loss is due to congestion in the network.

Say we try to develop a `congestion avoidance' strategy like the
one Raj Jain, et.al., propose in DEC TR506 and ISO 8473.  It
must have two components:  The network must be able to signal
the transport endpoints that congestion is occurring (or about
to occur).  And the endpoints must have a policy that decreases
utilization if this signal is received and increases utilization
if the signal isn't received.

If packet loss is (almost) always due to congestion and if a
timeout is (almost) always due to a lost packet, we have a good
candidate for the `network is congested' signal.  Particularly
since this signal is delivered automatically by all existing
networks, without special modification (as opposed to, say, ISO
8473 which requires a new bit in the packet headers and a mod to
*all* existing gateways to set this bit).

[As a (lengthy) aside:
Using `lost packets' to communicate information seems to bother
people.  The second of the two papers mentioned above is devoted
to analytic and simulation investigations of our algorithm under
various network conditions.  I'll briefly mention some of the
objections we've heard and, I think, addressed.

There have been claims that signaling congestion via dropping
packets will adversely affect total throughput (it's easily
proved that the opposite is true) or that this signal will be
`too slow' compared to alternatives (The fundamental frequency
of the system is set by its average round trip time.  From
control theory and Nyquist's theorem, any control strategy that
attempts to respond in less than two round trip times will be
unstable.  A packet loss is detected in at most two rtt, the
minimum stable response time).

There have also been claims that this scheme will result in
unfair or sub-optimal resource allocation (this is untrue if
equivalent implementations of ISO and our schemes are compared)
or that mistaking damage for congestion will unnecessarily
throttle the endpoints on some paths with a high intrinsic loss
rate (this is mostly untrue -- the scheme we propose is
analytically tractable so we've worked out its behavior under
random loss.  It turns out that window flow control schemes just
don't handle high loss rates well and throughput of a vanilla
TCP under high, random loss is abysmal.  Adding our congestion
control scheme makes things slightly worse but the practical
difference is negligible.  As an example (that we have calculated
and Jon Crowcroft at UCL has measured), it takes 40 256-byte
packets to fill the Satnet pipe.  Satnet currently shows a
random, 1% average packet loss.  The maximum throughput a
vanilla tcp could achieve at this loss rate is 56% of the 40kbs
channel bandwidth.  The maximum throughput our TCP can achieve at
this loss rate is 49% of the channel bandwidth.

In theory, the use of dynamic congestion control should allow
one to achieve much better throughput under high loss than is
possible with normal TCP -- performance comparable to, say,
NETBLT over the same lossy link.  The reason is that regular TCP
tries to communicate two different things with one number (the
window field in the packet): the amount of buffer the receiver
has available and the delay-bandwidth product of the pipe.  Our
congestion control scheme separates these two numbers.  The
sender estimates the pipe size so the receiver window need only
describe the receiver's buffer size.  As long as the receiver
advertises a sufficiently large buffer, (twice the delay-
bandwidth product) a 1% loss rate would translate into a 1%
throughput effect, not a factor-of-two effect.  Of course, we
have yet to put this theory to test.]

The other part of a congestion avoidance strategy, the endnode
action, is almost identical in Jain's DEC/ISO scheme and our
TCP.  This is not an accident (we copied Jain's scheme after
hearing his presentation at the Boston IETF & realizing that the
scheme was, in a sense, universal):  The endnode strategy
follows directly from a first-order time-series model of the
network.  Say we measure network `load' by average queue length
over fixed intervals of some appropriate length (something near
the rtt).  If L(i) is the load at interval i, a network not
subject to congestion can be modeled by saying L(i) changes
slowly compared to the sampling time.  I.e.,

    L(i) = N 

(the average queue length doesn't change over time).  If the
network is subject to congestion, this zero'th order model
breaks down.  The average queue length becomes the sum of two
terms, the N above that accounts for the average arrival rate
of new traffic and a new term that accounts for the left-over
traffic from the last time interval:

    L(i) = N + a L(i-1)

(As pragmatists, we extend the original model just enough to
explain the new behavior.  What we're doing here is taking the
first two terms in a taylor series expansion of L(t) when we
find that just the first term is inadequate.  There is reason to
believe one would eventually need a three term, second order
model, but not until the Internet has grown to several times its
current size.)

When the network is congested, the `a' term must be large and
the load (queues) will start increasing exponentially.  The only
way to stabilize the system is if the traffic sources throttle
back at least as fast as the queues are growing.  Since the way
a source controls load in a window-based protocol is to adjust
the size of the window, W, we end up with the sender policy

    On congestion:   W(i) = d W(i-1)    (d < 1)

I.e., a multiplicative decrease of the window size.  (This will
turn into an exponential decrease over time if the congestion
persists.)

If there's no congestion, the `a' term must be near zero and the
network load is about constant.  You have to try to increase the
bandwidth you're using to find out the current limit (e.g., you
could have been sharing the path with someone else and converged
to a window that gives you each half the available bandwidth.  If
he shuts down, 50% of the bandwidth will get wasted unless you
make some effort to increase your window size.)  What should the
increase policy be?

The first thought is to use a symmetric, multiplicative increase,
possibly with a longer time constant.  E.g.,  W(i) = b W(i-1),
1 < b <= 1/d.  This is a mistake.  The result will oscillate
wildly and, on the average, deliver poor throughput.  The reason
why is tedious to explain.  It has to do with that fact that it
is easy to drive the net into saturation but hard for the net
to recover (what Kleinrock, vol.2, calls the "rush-hour effect").
Thus overestimating the available bandwidth is costly.  But an
exponential, almost regardless of its time constant, increases
so quickly that large overestimates are inevitable.

Without justification, I'll simply state that the best increase
policy is to make small, constant changes to the window size (if
you've had a control theory course, you've seen the justification):

    On no congestion:   W(i) = W(i-1) + u	(u << the path delay-
						bandwidth product)

I.e., an additive increase policy.  This is exactly the policy that
Jain, et.al., suggest in DEC TR-506 and exactly the policy we've
implemented in TCP.  The only difference in our implementations is
the choice of constants for `d' and `u'.  We picked .5 and 1 for
reasons that are partially explained in the second of the attached
messages.  A more complete analysis is in the second in-progress
paper (and may be discussed at the upcoming IETF meeting).

All of the preceding has probably made it sound as if the
dynamic congestion algorithm is hairy but it's not.  Like
slow-start, it turns out to be three lines of code and one new
connection state variable (the combined slow-start/congestion
control algorithm is described in the second of the attached
msgs).


That covers about everything that's been done to date.  It's
about 1/3 of what we think clearly needs to be done.  The next
big step is to do the gateway `congestion detection' algorithms
so that a signal is sent to the endnodes as early as possible
(but not so early that the gateway ends up starved for traffic).
The way we anticipate doing these algorithms, gateway `self
protection' from a mis-behaving host will fall-out for free (that
host will simply have most of its packets dropped as the gateway
trys to tell it that it's using more than its fair share).  Thus,
like the endnode algorithm, the gateway algorithm will improve
things even if no endnode is modified to do dynamic congestion
avoidance.  And nodes that do implement congestion avoidance
will get their fair share of bandwidth and a minimum number of
packet drops.

Since congestion grows exponentially, detecting it early is
important.  (If it's detected early, small adjustments to the
senders' windows will cure it.  Otherwise massive adjustments
will be necessary to give the net enough spare capacity to pump
out the backlog.)  But, given the bursty nature of traffic,
reliable detection is a non-trivial problem.  There is a scheme
proposed in DEC TR-506 but we think it might have convergence
problems under high load and/or significant second-order dynamics
in the traffic.  We are thinking of using some of our earlier
work on ARMAX models for rtt/queue length prediction as the
basis of the detection.  Preliminary results suggest that this
approach works well at high load, is immune to second-order
effects in the traffic and is cheap enough to compute that it
wouldn't slow down thousand-packet-per-second gateways.

In addition to the gateway algorithms, we want to apply the
endnode algorithms to connectionless traffic (e.g., domain
server queries, RPC requests).  We have the rate-based
equivalent of the TCP window algorithm worked out (there should
be a message describing it on the tcp list sometime in the near
future).  Sun Microsystems has been very interested, and
supportive, during the development of the TCP congestion control
(I believe Sun OS 4.0 will ship with our new TCP) and Sun has
offered to cooperate in developing the RPC dynamic congestion
control algorithms, using NFS as a test-bed (since NFS is known
to have congestion problems).

The far future holds some work on controlling second-order, non-
ergodic effects, adaptively determining the rate constants in
the control algorithm, and some other things that are too vague
to mention.

 - Van

 ----------------------------
To: markl@PTT.LCS.MIT.EDU
Subject: Re: interpacket arrival variance and mean 
In-reply-to: Your message of Mon, 08 Jun 87 12:31:33 EDT.
Date: Mon, 15 Jun 87 06:08:01 PDT
From: Van Jacobson <van@lbl-csam.arpa>

Mark -

I'm working on long paper about transport protocol timers (models,
estimation, implementations, common implementation mistakes, etc.).
This has me all primed on the subject so attached is a long-winded
explanation and example C code for estimating the mean and variance
of a series of measurements.

Though I know your application isn't tcp, I'm going to use a new
tcp retransmit timer algorithm as an example.  The algorithm
illustrates the method and, based on 3 months of experiment, is
much better than the algorithm in rfc793 (though it isn't as good
as the algorithm I talked about at IETF and am currently debugging). 

Theory
------
You're probably familiar with the rfc793 algorithm for estimating
the mean round trip time.  This is the simplest example of a
class of estimators called "recursive prediction error" or
"stochastic gradient" algorithms.  In the past 20 years these
algorithms have revolutionized estimation and control theory so
it's probably worth while to look at the rfc793 estimator in some
detail. 

Given a new measurement, Meas, of the rtt, tcp updates an
estimate of the average rtt, Avg, by

	Avg <- (1 - g) Avg  +  g Meas

where g is a "gain" (0 < g < 1) that should be related to the
signal- to-noise ratio (or, equivalently, variance) of Meas. 
This makes a bit more sense (and computes faster) if we rearrange
and collect terms multiplied by g to get

	Avg <- Avg + g (Meas - Avg)

We can think of "Avg" as a prediction of the next measurement. 
So "Meas - Avg" is the error in that prediction and the
expression above says we make a new prediction based on the old
prediction plus some fraction of the prediction error.  The
prediction error is the sum of two components: (1) error due to
"noise" in the measurement (i.e., random, unpredictable effects
like fluctuations in competing traffic) and (2) error due to a
bad choice of "Avg".  Calling the random error RE and the
predictor error PE,

	Avg <- Avg + g RE + g PE

The "g PE" term gives Avg a kick in the right direction while the
"g RE" term gives it a kick in a random direction.  Over a number
of samples, the random kicks cancel each other out so this
algorithm tends to converge to the correct average.  But g
represents a compromise: We want a large g to get mileage out of
the PE term but a small g to minimize the damage from the RE
term.  Since the PE terms move Avg toward the real average no
matter what value we use for g, it's almost always better to use
a gain that's too small rather than one that's too large. 
Typical gain choices are .1 - .2 (though it's always a good
idea to take long look at your raw data before picking a gain). 

It's probably obvious that Avg will oscillate randomly around
the true average and the standard deviation of Avg will be
something like g sdev(Meas).  Also that Avg converges to the
true average exponentially with time constant 1/g.  So
making g smaller gives a stabler Avg at the expense of taking
a much longer time to get to the true average.

[My paper makes the preceding hand-waving a bit more rigorous
but I assume no one cares about rigor.  If you do care, check
out almost any text on digital filtering or estimation theory.]

If we want some measure of the variation in Meas, say to compute
a good value for the tcp retransmit timer, there are lots of
choices.  Statisticians love variance because it has some nice
mathematical properties.  But variance requires squaring (Meas -
Avg) so an estimator for it will contain two multiplies and a
large chance of integer overflow.  Also, most of the applications
I can think of want variation in the same units as Avg and Meas,
so we'll be forced to take the square root of the variance to use
it (i.e., probably at least a divide, multiply and two adds). 

A variation measure that's easy to compute, and has a nice,
intuitive justification, is the mean prediction error or mean
deviation.  This is just the average of abs(Meas - Avg). 
Intuitively, this is an estimate of how badly we've blown our
recent predictions (which seems like just the thing we'd want to
set up a retransmit timer).  Statistically, standard deviation
(= sqrt variance) goes like sqrt(sum((Meas - Avg)^2)) while mean
deviation goes like sum(sqrt((Meas - Avg)^2)).  Thus, by the
triangle inequality, mean deviation should be a more "conservative"
estimate of variation. 

If you really want standard deviation for some obscure reason,
there's usually a simple relation between mdev and sdev.  Eg.,
if the prediction errors are normally distributed, mdev =
sqrt(pi/2) sdev.  For most common distributions the factor
to go from sdev to mdev is near one (sqrt(pi/2) ~= 1.25).  Ie.,
mdev is a good approximation of sdev (and is much easier to
compute).

Practice
--------
So let's do estimators for Avg and mean deviation, Mdev.  Both
estimators compute means so we get two instances of the rfc793
algorithm:

	Err = abs (Meas - Avg)
	Avg <- Avg + g (Meas - Avg)
	Mdev <- Mdev + g (Err - Mdev)

If we want to do the above fast, it should probably be done in
integer arithmetic.  But the expressions contain fractions (g < 1)
so we'll have to do some scaling to keep everything integer.  If
we chose g so that 1/g is an integer, the scaling is easy.  A
particularly good choice for g is a reciprocal power of 2 
(ie., g = 1/2^n for some n).  Multiplying through by 1/g gives

	2^n Avg <- 2^n Avg + (Meas - Avg)
	2^n Mdev <- 2^n Mdev + (Err - Mdev)

To minimize round-off error, we probably want to keep the scaled
versions of Avg and Mdev rather than the unscaled versions.  If
we pick g = .125 = 1/8 (close to the .1 that rfc793 suggests) and
express all the above in C:

	Meas -= (Avg >> 3);
	Avg += Meas;
	if (Meas < 0)
		Meas = -Meas;
	Meas -= (Mdev >> 3);
	Mdev += Meas;

I've been using a variant of this to compute the retransmit timer
for my tcp.  It's clearly faster than the two floating point
multiplies that 4.3bsd uses and gives you twice as much information.
Since the variation is estimated dynamically rather than using
the wired-in beta of rfc793, the retransmit performance is also
much better: faster retransmissions on low variance links and
fewer spurious retransmissions on high variance links. 

It's not necessary to use the same gain for Avg and Mdev. 
Empirically, it looks like a retransmit timer estimate works
better if there's more gain (bigger g) in the Mdev estimator. 
This forces the timer to go up quickly in response to changes in
the rtt.  (Although it may not be obvious, the absolute value in
the calculation of Mdev introduces an asymmetry in the timer:
Because Mdev has the same sign as an increase and the opposite
sign of a decrease, more gain in Mdev makes the timer go up fast
and come down slow, "automatically" giving the behavior Dave
Mills suggests in rfc889.)

Using a gain of .25 on the deviation and computing the retransmit
timer, rto, as Avg + 2 Mdev, my tcp timer code looks like:

	Meas -= (Avg >> 3);
	Avg += Meas;
	if (Meas < 0)
		Meas = -Meas;
	Meas -= (Mdev >> 2);
	Mdev += Meas;
	rto = (Avg >> 3) + (Mdev >> 1);

Hope this helps.

  - Van

 ---------------------------------
To: jain%erlang.DEC@decwrl.dec.com (Raj Jain, LKG1-2/A19, DTN: 226-7642)
Cc: ietf@gateway.mitre.org
Subject: Re: Your congestion scheme 
In-Reply-To: Your message of 03 Nov 87 12:51:00 GMT.
Date: Mon, 16 Nov 87 06:03:29 PST
From: Van Jacobson <van@lbl-csam.arpa>

Raj,

Thanks for the note.  I hope you'll excuse my taking the liberty
of cc'ing this reply to the ietf:  At the last meeting there was a
great deal of interest in your congestion control scheme and our
adaptation of it. 

> I am curious to know what values of increase amount and decrease
> factor did you use.  In our previous study on congestion using
> timeout (CUTE scheme, IEEE JSAC, Oct 1986), we had found that the
> decrease factor should be small since packet losses are
> expensive.  In fact, we found that a decrease factor of zero
> (decreasing to one) was the best. 

We use .5 for the decrease factor and 1 for the increase factor. 
We also use something very close to CUTE (Mike Karels and I were
behind on our journal reading so we independently rediscovered
the algorithm and called it slow-start).  Since we use a lost
packet as the "congestion experienced" indicator, the CUTE
algorithm and the congestion avoidance algorithm (BTW, have you
picked a name for it yet?) get run together, even though they are
logically distinct. 

The sender keeps two state variables for congestion control: a
congestion window, cwnd, and a threshhold size, ssthresh, to
switch between the two algorithms.  The sender's output routine
sends the minimum of cwnd and the window advertised by the
receiver.  The rest of the congestion control sender code looks
like:  On a timeout, record half the current window size as
"ssthresh" (this is the multiplicative decrease part of the
congestion avoidance algorithm), then set the congestion window
to 1 packet and call the output routine (this initiates
slowstart/CUTE).  When new data is acked, the sender does 
something like

	if (cwnd < ssthresh)	  // if we're still doing slowstart
		cwnd += 1 packet  // open the window exponentially
	else
		cwnd += 1/cwnd    // otherwise do the Congestion
				  // Avoidance increment-by-1

Notice that our variation of CUTE opens the window exponentially
in time, as opposed to the linear scheme in your JSAC article. 
We looked at a linear scheme but were concerned about the
performance hit on links with a large bandwidth-delay product
(ie., satellite links).  An exponential builds up fast enough to
accomodate any bandwidth-delay and our testing showed no more
packet drops with exponential opening that with linear opening. 
(My model of what slowstart is doing -- starting an ack "clock"
to meter out packets -- suggested that there should be no
loss-rate difference between the two policies).

The reason for the 1/2 decrease, as opposed to the 7/8 you use,
was the following hand-waving:  When a packet is dropped, you're
either starting (or restarting after a drop) or steady-state
sending.  If you're starting, you know that half the current
window size "worked", ie., that a window's worth of packets were
exchanged with no drops (slowstart guarantees this).  Thus on
congestion you set the window to the largest size that you know
works then slowly increase the size.  If the connection is
steady-state running and a packet is dropped, it's probably
because a new connection started up and took some of your
bandwidth.  We usually run our nets with rho <= .5 so it's
probable that there are now exactly two conversations sharing the
bandwidth.  Ie., that you should reduce your window by half
because the bandwidth available to you has been reduced to half. 
And, if there are more than two conversations sharing the
bandwidth, halving your window is conservative -- and being
conservative at high traffic intensities is probably wise. 

Obviously, this large decrease term is accounting for the high
cost of our "congestion experienced" indicator compared to yours --
a dropped packet vs. a bit in the ack.  If the DEC bit were
available, the preceding "logic" should be ignored.  But I wanted
tcp congestion avoidance that we could deploy immediately and
incrementally, without adding code to the hundreds of Internet
gateways.  So using dropped packets seemed like the only choice. 
And, in system terms, the cost isn't that high: Currently packets
are dropped only when a large queue has formed.  If we had a bit
to force senders to reduce their windows, we'd still be stuck
with the queue since we'd still be running the bottleneck at 100%
utilization so there's no excess bandwidth available to dissipate
the queue.  If we toss a packet, a sender will shut up for 2 rtt,
exactly the time we need to empty the queue (in the ususal case).
If that sender restarts with the correct window size the queue
won't reform.  Thus we've reduced the delay to minimum without
the system losing any bottleneck bandwidth.

The 1-packet increase has less justification that the .5
decrease.  In fact, it's almost certainly too large.  If the
algorithm converges to a window size of w, you get O(w^2) packets
between drops with an additive increase policy.  We were shooting
for an average drop rate of <1% and found that on the Arpanet
(the worst case of the 4 networks we tested), windows converged
to 8 - 12 packets.  This yields 1 packet increments for a 1%
average drop rate. 

But, since we've done nothing in the gateways, the window we
converge to is the maximum the gateway can accept without dropping
packets.  I.e., in the terms you used, we are just to the left of
the cliff rather than just to the right of the knee.  If we
now fix the gateways so they start dropping packets when the
queue gets pushed past the knee, our increment will be much too
agressive and we'll have to drop it by at least a factor of 4
(since all my measurements on an unloaded Arpanet or Milnet
place their "pipe size" at 4-5 packets).  Mike and I have talked
about a second order control loop to adaptively determine the
appropriate increment to use for a path (there doesn't seem to
be much need to adjust the decrement).  It looks trivial to
implement such a loop (since changing the increment affects
the frequency of oscillation but not the mean window size,
the loop would affect rate of convergence but not convergence
and (first-order) stability).  But we think 2nd order stuff
should wait until we've spent some time on the 1st order part
of the algorithm for the gateways.

I'm tired and probably no longer making sense.  I think I'll
head home and get some sleep.  Hope to hear from you soon.

Cheers.

 - Van

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 88 11:24:15 EST
From:      terry@DVAX
To:        tcp-ip@sri-nic.arpa
Cc:        terry@dec-vax-11-750.arpa
Subject:   Data Acceptance Algorithms?
Hello All,

I am trying to weigh the pros and cons of "in-order" versus
"in-window" data acceptance algorithms for use in TCP.

To do this, I need to know the "real" chances of a packet arriving
out of order.  

It would seem to me that the extra overhead involved in an "in-window"
algorithm would be wasted if packets are "almost always" delivered in
order.

Has anyone out there ever attempted to measure the percentage of
out of order packets?  

I would like to collect as many samples from as many different 
networks as I can.  Any help is appreciated.

You may send your replies directly to me, and I will summarize to
the net.

Thanks in advance...      Terry Robb

************************************************************************
*-  Terence A. Robb                                                   -*
*-  Network Solutions                                                 -*
*-  Systems Programming Specialist                                    -*
*-  MILnet:   terry@dec-vax-11-750.arpa                               -*
*-  PHONEnet: (703) 749-1918                                          -*
*-  MAILnet:  8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180    -*
************************************************************************
*!                                                                    !*
*!                            Disclaimer                              !*
*!                                                                    !*
*! I alone take responsiblity for the content of this message...      !*
*! but if there is any problem, blame my wife.                        !*
*!                                                                    !*
************************************************************************   
-------
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 06:30:10 GMT
From:      guy@sun.uucp (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: What is SLIP?

> I have been told that SLIP has its roots in an old serial protocol 3Com
> came up with for communicating between fileservers, and was adopted for
> use with IP and asynchronous serial lines some time later, initially for
> use between gateways (IP routers).  Rick Adams did a public domain
> implementation for 4.2 Unix, and now one is distributed with 4.3.

The history, as I understand it (the CCI parts are correct - I was there - but
I don't know the history of this encapsulation scheme at 3Com):

	3Com's UNET TCP/IP implementation had a serial line encapsulation
	for IP packets.  I don't know for what this encapsulation was
	originally designed, but it was used in UNET for getting two machines
	with serial port hardware and nothing else to talk IP to each other;
	it was not just used between gateways.

	The Naval Surface Weapons Center put out a bid for an office
	automation system; Computer Consoles, Inc. bid a system consisting of
	two VAXes running 4.2BSD (with S5 compatibility additions) and lots of
	CCI Power 5/20 machines running S3 with UNET.  There needed to be
	*some* way to get the 5/20s to talk to the VAXes, so Rick whipped up
	the original SLIP; it used the 3Com encapsulation so it could talk to
	the 5/20s running UNET.

	He subsequently reimplemented it while at the Center for Seismic
	studies.

> I have heard that Sun will support it soon, if not already,

We don't have it now; I don't expect it to be officially supported in the next
release, but Rick does have a version that can, I believe, be put into current
SunOS releases, and I expect there will be versions to put into future
releases.  It may end up in a future release, but I don't know one way or the
other.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 12:32:00 EST
From:      <enger@bluto.scc.com>
To:        "terry" <terry@DEC-VAX-11-750.ARPA>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   TCP/IP posting regarding Data Acceptance Algorithms "!@#$%^&(){}."

I would like to recommend that consideration also be given to the pros and
cons of sending out mail containing an incomplete  From:  field.

Bob

-------
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 88 13:32:07 EST
From:      terry@DVAX
To:        tcp-ip@sri-nic.arpa
Cc:        terry@dec-vax-11-750.arpa
Subject:   Complete FROM: field.
   (Note the FROM: field of all my outgoing mail contains "terry@DVAX")

>I would like to recommend that consideration also be given to the pros and
>cons of sending out mail containing an incomplete  From:  field.
>
>Bob

Bob,

If your message is meant to suggest that my mail message contained
an incomplete "FROM:" field, I feel compelled to answer.

The address was complete.  It is the COMPLETE address of my node on our
local net.  I will agree is doesn't conform to standards.  If I had the
authority to change the name to meet the standard format, I would.
(Not that you could use it anyway.)

However, please note I did include my COMPLETE MILNET address 
at the bottom of my message, and, most importantly, I included the
proper punctuation at the end of my subject line.

---
Terry Robb
---

P.S. If your mail message meant something else... nevermind.

************************************************************************
*-  Terence A. Robb                                                   -*
*-  Network Solutions                                                 -*
*-  Systems Programming Specialist                                    -*
*-  MILnet:   terry@dec-vax-11-750.arpa                               -*
*-  PHONEnet: (703) 749-1918                                          -*
*-  MAILnet:  8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180    -*
************************************************************************
*!                                                                    !*
*!                            Disclaimer                              !*
*!                                                                    !*
*! I alone take responsiblity for the content of this message...      !*
*! but if there is any problem, blame my children.                    !*
*!                                                                    !*
************************************************************************   
-------
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 1988 13:37-EST
From:      CLYNN@G.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: DCA Protocol Lab Test Tools
Bob,
	Could you summarize the sorts of problems that the testing suite
has found?  I think that the list of "common" bugs, maybe sorted in
order of decreasing frequency, would be helpful both to those who are
doing implementations and to those who are trying to make the specs
clearer.

Charlie
-------
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 88 15:09 EDT
From:      <JFISHER%USGSRESV.BITNET@CUNYVM.CUNY.EDU> (James R. Fisher)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: DCA Protocol Lab Test Tools (& NSFnet Medal)
My eyebrows recently raised on seeing reference to the NSFnet Medal for
implementations.
We are thinking of joining NSFnet and I would VERY much like to hear of
known defects and perceived problems with NSFnet, AND of any implementations
which are worthy of the Medal. Flames welcome.
-------
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 14:19:11 GMT
From:      kleonard@gvlv2.UUCP (Ken Leonard --> kleonard@gvlv2@prc.unisys.com)
To:        comp.protocols.tcp-ip
Subject:   bouncepass

just checking to see if addresses work--please do minimum reply
thanx
Ken

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 88 19:36
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@relay.MOD.UK>
To:        tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa>
Subject:   Re: Dynamic Congestion Avoidance / Control
 
Delighted by Van Jacobson's msg. It merits a NOBEL prize. Is the King of
Sweden on the net?
 
John
-------
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 15:18:38 GMT
From:      merlin@hqda-ai.UUCP (David S. Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: What is SLIP?

In article <41751@sun.uucp>, guy@sun.uucp (Guy Harris) writes:
> We don't have it now; I don't expect it to be officially supported
> in the next release, but Rick does have a version that can, I
> believe, be put into current SunOS releases, and I expect there
> will be versions to put into future releases.  It may end up in a
> future release, but I don't know one way or the other.
> 
> Guy Harris  	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
> guy@sun.com (or guy@sun.arpa)

     Sun should be adding this.  Yes, there is a SLIP that runs on
Suns.  It was "solarized" by Chris Torek at the University of
Maryland.  I have tried it, and it does work.

     The problem is that in a binary-only Sun release, there is
no way to support a "disconnect-interface" procedure.  This
results in a kernel crash if the remote end goes away.  With a
dedicated hardwire line, that's not too much of a problem, but it
can be a real pain when you've got some intervening hardware.

     Sun should add a full SLIP, including disconnect,
immediately.  The code is already available from Chris Torek,
including the disconnect business.  For a company that claims that
"The network is the computer," here's an opportunity to put that
motto into practice.

-- 
David S. Hayes, The Merlin of Avalon	PhoneNet:  (202) 694-6900
UUCP:  *!uunet!cos!hqda-ai!merlin	ARPA:  ai01@hios-pent.arpa

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 16:24:15 GMT
From:      terry@DVAX
To:        comp.protocols.tcp-ip
Subject:   Data Acceptance Algorithms?

Hello All,

I am trying to weigh the pros and cons of "in-order" versus
"in-window" data acceptance algorithms for use in TCP.

To do this, I need to know the "real" chances of a packet arriving
out of order.  

It would seem to me that the extra overhead involved in an "in-window"
algorithm would be wasted if packets are "almost always" delivered in
order.

Has anyone out there ever attempted to measure the percentage of
out of order packets?  

I would like to collect as many samples from as many different 
networks as I can.  Any help is appreciated.

You may send your replies directly to me, and I will summarize to
the net.

Thanks in advance...      Terry Robb

************************************************************************
*-  Terence A. Robb                                                   -*
*-  Network Solutions                                                 -*
*-  Systems Programming Specialist                                    -*
*-  MILnet:   terry@dec-vax-11-750.arpa                               -*
*-  PHONEnet: (703) 749-1918                                          -*
*-  MAILnet:  8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180    -*
************************************************************************
*!                                                                    !*
*!                            Disclaimer                              !*
*!                                                                    !*
*! I alone take responsiblity for the content of this message...      !*
*! but if there is any problem, blame my wife.                        !*
*!                                                                    !*
************************************************************************   

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 16:49:29 GMT
From:      kleonard@gvlv2.UUCP (Ken Leonard --> kleonard@gvlv2@prc.unisys.com)
To:        comp.protocols.tcp-ip
Subject:   oops

Hal...

Unfortunately (or vice-versa), I'm now mostly out of the loop on ProtoLab,
and on testing in general.

Am now dealing with new species of lizards--sort of armored on the outside but,
as usual, not very well done on the inside.

Regardz,
Ken

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 16:51:36 GMT
From:      kleonard@gvlv2.UUCP (Ken Leonard --> kleonard@gvlv2@prc.unisys.com)
To:        comp.protocols.tcp-ip
Subject:   oops

Dave...

A flakeway, humm....  Sounds like time to get out the flatboat and go fishin'.

Talk to bobj and judym about the flakerizing abilities of ProtoLab corruption
mode testing.

Deck us all with Boston Charlie!
Ken

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 16:58:57 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Life in the Swamps / Testing

Dave,

    I love the idea and wish it were mine, but I cannot take credit for
    the  flakeway.  I stole both the concept and the term from the BBN
    wizards Bill Plummer and Ray Tomlinson. They came up with the first
    flakeway under TOPS-20, during the early TCP/IP days.  [I have seen
    the listing of that program, and I think I remember Ray actually
    wrote it; but Bill was responsible for popularizing it in the
    research community at that time [[about 1976-1978]]].  My only
    contribution was to write a flakeway for the UCLA ACP; it ran
    for there many years, reachable via source routing. 
    
    (For those who don't know, "flakeway" is a contraction of "flakey
    gateway", a test gateway implementation set to deliberately
    and randomly reorder, delay, and/or drop packets with some set
    specified frequency distributions. The idea was to test your
    TCP/IP implementation through such a monster).   
    
    From an historical perspective, it is interesting that the
    early work DID include real concern about robustness in the
    presence of long delays and packet losses, and there was active 
    testing implementations under such conditions. Then the second-
    generation of implementors came along, and worked entirely in the
    Ethernet environment, promptly ignoring/forgetting the lessons
    already learned.  One can speculate that if there were no LAN's
    in the world, we would have discovered (perforce) all the wonderful
    Van Jacobson ideas about 8 years ago.
    
    
Bob Braden
    

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 17:32:00 GMT
From:      enger@BLUTO.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   TCP/IP posting regarding Data Acceptance Algorithms "!@#$%^&(){}."


I would like to recommend that consideration also be given to the pros and
cons of sending out mail containing an incomplete  From:  field.

Bob

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 17:43:38 GMT
From:      kleonard@gvlv2.UUCP (Ken Leonard --> kleonard@gvlv2@prc.unisys.com)
To:        comp.protocols.tcp-ip
Subject:   OUCH

WOW!  when this mailer and this user decide to munge an alias, we do it RIGHT!

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 18:10:00 GMT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   A plea for sanity


    Date: Thursday, 11 February 1988  20:13-EST
    From: mcc@etn-wlv.eaton.com (Merton Campbell Crockett)

    [...]
    Perhaps its a problem with my view of electronic mail,
    particularly mail that is for forwarded to "tcp-ip@sri-nic.arpa";
    it is irrelevant to me whether a subscriber to this service from
    "bangland" failed to leave his PC powered-up to receive my comment
    or retort of questionable significance.  Why should I be inundated
    with "unable to deliver to xxx" messages?  Its "tcp-ip" that needs
    the knowledge as it may signify some network problem!

    It does raise some questions about SMTP and its interpretation of "From:"
    and "Forwarded by:".  The reporting of delivery errors should always be
    delivered to the "Forwarded by:" individual not the "From:" individual who
    may not have authorized the dissemination of the message.

Merton,

First off, TCP-IP is not really the place for this discussion (I know,
you didn't start it either).  If people want to continue it, please do
so in private or on Header-People@MC.LCS.MIT.EDU, the list for
discussion of mail protocols and lossage in the implementation of
those protocols.

Second, you should know that the SRI-NIC.ARPA mailer does everything
in its power to keep you from ever seeing those bounce messages:
specificly, it bashes the SMTP return-path of outgoing TCP-IP messages
to "TCP-IP-RELAY@SRI-NIC.ARPA".  Thus, anybody playing the game
correctly will send any and all automatic delivery flames to the list
maintainers at SRI-NIC, not to you (see RFC821 if this isn't clear).

The problem is that there are an awful lot of broken mailers out
there.  Chief offender in recent months has been one or more BITNET
mailers that discard the envelope ((B)SMTP) information and rewrite
the RFC822 message headers (which they then use for mail routing) in
completely bizzare ways.  This is worse than just throwing all the
mail on the floor, these mailers are very "smart" at figuring out who
the original sender of a message was so that they can torment her with
useless bug reports.  It has gotten to the point where posting a dozen
messages to one of the mailing lists I maintain produces over a
megabyte of mis-addressed garbage; I've started getting complaints
from subscribers because their (de)subscription requests are getting
lost under all this junk and thus being accidently ignored.

So, in closing (and as I've said on Header-People before), the problem
is not deficiencies in the existing mail protocols.  The problem is
mailers that don't implement the existing protocols and system
administrators who are unwilling/unable to install versions of the
mailers that DO implement the protocols correctly.  The main reason I
keep bringing this up in various forums is a hope that part of the
problem is ignorance on the part of the maintainers of the machines
running the broken mailers.

--Rob

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 18:32:07 GMT
From:      terry@DVAX
To:        comp.protocols.tcp-ip
Subject:   Complete FROM: field.


   (Note the FROM: field of all my outgoing mail contains "terry@DVAX")

>I would like to recommend that consideration also be given to the pros and
>cons of sending out mail containing an incomplete  From:  field.
>
>Bob

Bob,

If your message is meant to suggest that my mail message contained
an incomplete "FROM:" field, I feel compelled to answer.

The address was complete.  It is the COMPLETE address of my node on our
local net.  I will agree is doesn't conform to standards.  If I had the
authority to change the name to meet the standard format, I would.
(Not that you could use it anyway.)

However, please note I did include my COMPLETE MILNET address 
at the bottom of my message, and, most importantly, I included the
proper punctuation at the end of my subject line.

---
Terry Robb
---

P.S. If your mail message meant something else... nevermind.

************************************************************************
*-  Terence A. Robb                                                   -*
*-  Network Solutions                                                 -*
*-  Systems Programming Specialist                                    -*
*-  MILnet:   terry@dec-vax-11-750.arpa                               -*
*-  PHONEnet: (703) 749-1918                                          -*
*-  MAILnet:  8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180    -*
************************************************************************
*!                                                                    !*
*!                            Disclaimer                              !*
*!                                                                    !*
*! I alone take responsiblity for the content of this message...      !*
*! but if there is any problem, blame my children.                    !*
*!                                                                    !*
************************************************************************   

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 18:37:00 GMT
From:      CLYNN@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: DCA Protocol Lab Test Tools

Bob,
	Could you summarize the sorts of problems that the testing suite
has found?  I think that the list of "common" bugs, maybe sorted in
order of decreasing frequency, would be helpful both to those who are
doing implementations and to those who are trying to make the specs
clearer.

Charlie

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 18:50:23 GMT
From:      isns01@ms3.UUCP (Jim Chappell)
To:        comp.protocols.tcp-ip
Subject:   DDN Connection Problems

I've followed the PSN 7.0 dialog, but haven't seen my aspect of the
problem discussed:

Occasionally, near an hour hack, (9:58, for example,) we begin getting
syslog msgs: 'No buffer space available' from sendmail, mconnect,
etc. accessing particular systems.

At the same time we have no problems getting to other systems.

The milnet NOC tells us to reboot; but I doubt their veracity.

The problem clears up at near another hour hack.

Could someone be turning us on and off at the PSN  side?

Wwe are running vanilla 4.2BSD (We are getting ready to upgrade to 4.3BSD)
and 1822.
-- 
Jim Chappell               UUCP: ...!umd5!vrdxhq!ms3!jrc 
ISN Corp.  (703) 979-8900  ARPA: jrc@hios-pent
1235A Jeff Davis Hwy, Suite 220
Arlington, Va 22202

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 19:09:00 GMT
From:      JFISHER@USGSRESV.BITNET (James R. Fisher)
To:        comp.protocols.tcp-ip
Subject:   Re: DCA Protocol Lab Test Tools (& NSFnet Medal)

My eyebrows recently raised on seeing reference to the NSFnet Medal for
implementations.
We are thinking of joining NSFnet and I would VERY much like to hear of
known defects and perceived problems with NSFnet, AND of any implementations
which are worthy of the Medal. Flames welcome.

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 88 22:09:49 GMT
From:      schoff@NISC.NYSER.NET (Martin Lee Schoffstall)
To:        comp.protocols.tcp-ip
Subject:   sgmp v2.0 documentation available


Due to demand the documentation for the V2.0 of the NYSERNet
implementation of SGMP/SNMP (man pages, interface description,
and overall description) is now available via anonymous ftp
from nisc.nyser.net in
	snmp/v2doc.tar
This is about 90Kbytes.

Marty Schoffstall

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 88 01:46:17 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re:  Life in the Swamps / Testing

Regarding Testing:  It is an economic issue.  Who could argue that bakeoffs
aren't very useful?  Who can argue that conformance testing against a
"standard" isn't useful?  Neither is sufficient to ensure interoperability
in all cases.  Heck, the randomness of network behaviour ensures that
we will never get it perfect.  (Folks stil find bugs in 20 year old
Fortran and Cobol compilers...)

If we had a test suite that was in some sense 'official" we would not
have fiascos like I saw at Uniforum this week!  There was the usual
"hook all the TCP/IP speaking booths together" party.  And it barely
worked.  Why?  Two reasons:  1)  Not everyone did subnetting "right"
and 2)  the rwho broadcast storms made the net unusable much of
the time.  If we had a conformance test suite available that everyone
could test against, then these two rather simple hurdles could be tested
for and vendors would have to pass them to get a "certificate".  Would
this make the world "perfect"?  Probably not, but it would make it a lot, lot
better!  

Folks, we are actually trying to get our work done with these marvelous
networks.  And the world is going to be a lot better off when we are
all able to communicate with each other with ease.  Let's all vote to
support whatever it takes to make it work well.  No one approach will
suffice.

Dan
-------

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 88 03:36:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re: Dynamic Congestion Avoidance / Control


 
Delighted by Van Jacobson's msg. It merits a NOBEL prize. Is the King of
Sweden on the net?
 
John

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Feb 88 12:18:47 PST
From:      satz@clash.cisco.com
To:        Dan Lynch <LYNCH@a.isi.edu>
Cc:        Mills@louie.udel.edu, hrp%windsor.CRAY.COM@umn-rei-uc.arpa, kleonard@burdvax.prc.unisys.com, bobj@mcl.unisys.com, dcmartin@protolaba.arpa, tcp-ip@sri-nic.arpa
Subject:   Re: Life in the Swamps / Testing
>> If we had a test suite that was in some sense 'official" we would not
>> have fiascos like I saw at Uniforum this week!  There was the usual
>> "hook all the TCP/IP speaking booths together" party.  And it barely
>> worked.  Why?  Two reasons:  1)  Not everyone did subnetting "right"
>> and 2)  the rwho broadcast storms made the net unusable much of
>> the time.  If we had a conformance test suite available that everyone
>> could test against, then these two rather simple hurdles could be tested
>> for and vendors would have to pass them to get a "certificate".  Would
>> this make the world "perfect"?  Probably not, but it would make it a lot, lot
>> better!  

The major problem with the Uniforum network was misconfiguration and
lack of understanding of all of the broadcast addresses. However the
misconfiguration was so bad the it was almost impossible to discern
broadcasts from other packets. What happened was that the show-net
started out to be network 89 with a subnet number of 1. People who
requested individual subnet numbers got them starting at some larger
number.  Interestingly enough, however, was that people weren't able
to live with this arrangement for some reason networks like 8.0.0.0
and 1.0.0.0 started appearing instead. Unfortunately some hosts were
still sending out [IP] subnet broadcasts instead of network broadcasts
or general broadcasts (all ones). Test suites can do little to solve
this problem.

I also saw random ICMP message types flying around and packets with
bad checksums. A real live test suite would go along way toward
eliminating this problem.

The unusability of the network stemmed from a few hosts that were
generating error rates of 10%. Excelan, the show-net manager, quickly
resolved the problem when it was pointed out to them, much to their
credit.

Aside from all of that, it seems that Sun was advertising all of its
many networks via RIP and HP was offering a portal into its network
with an IGRP route. Sun refused to pass packets to the MILnet and HP
blocked access to the ARPAnet.
-------
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Feb 88 10:03:21 EST
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   Verification Suite










Hal Peterson (hrp%windsor.CRAY.COM@uc.msc.umn.edu) at Cray wrote

>I should stress, though, that a verification suite is only part of a
>comprehensive testing strategy, and that bake-offs can be extremely
>valuable for finding bugs.  A verification suite is software, and like
>all software it is imperfect.  It is entirely possible that two
>implementations both pass the suite but don't interoperate.  Bake-offs
>can catch that, and when they do they have found as many as FOUR bugs:
>
>1.  a bug in one of the implementations.
>2.  a bug in the other implementations; after all, they could both be
>    at fault.
>3.  a bug in the specification.  It may be unclear or inconsistent or
>    incomplete and so have misled the implementors.
>4.  a bug in the verification suite.  It should have caught the
>    problem, and next time it will, since it's a simple matter to add
>    a test to a well-designed suite.  The suite gets better as time
>    goes on.

His last two points bring two simple(?) questions to mind -

How do the Specification Bugs get resolved?

Who Verifies the Verification Suite???? (Qui Ipsos Custode Custodiet)

Frank Kastenholz
Atex Inc.
-------
-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 1988 12:17-EST
From:      CERF@A.ISI.EDU
To:        JBVB@AI.AI.MIT.EDU
Cc:        rti!scirtp!scott@MCNC.ORG, tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP/IP-NETBIOS Info Wanted
James,

Doesn't the use of TCP/IP to support NETBIOS also open up the possibility
of interactions between PCs in the TCP/IP-extended NETBIOS environment
and hosts in the rest of the Internet (or private internet)?

I think it was this extension of interaction which was the major motivating
factor for people like Dave Crocker (then of Ungermann-Bass, now of Wollongong).

Vint
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 88 07:22:01 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: What is SLIP?

Careful!  I only rewrote Rick Adams' code for 4.3BSD, removing the
horrible hacks needed to make it work in a binary-only system,
where there is no way to attach the interfaces at kernel startup.
Mark Weiser re-re-edited the code to run under several different
SunOS releases; various versions of this are available via anonymous
FTP from host mimsy.umd.edu.

At the moment, mimsy is being emulated by a Sun-3/50 with less than 5%
of the disk space of the Vax-11/780-5 whose place it is holding, and
the FTP archives are unavailable.  We anticipate that the machine
should be working again by the middle of next week, assuming that
nothing major went wrong when it was moved across the campus.  Please
also restrict anonymous FTP access to 7 AM to 7 PM EST (1200 to 0000
UTC) if possible.

Chris

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 88 12:37:39 GMT
From:      leonid@TAURUS.BITNET
To:        comp.protocols.tcp-ip
Subject:   Ip gateways vs. RFC 1009

I am researching the available equipment that is able to interconnect
TCP/IP LANs via leased lines, i.e. IMPlets. If you are running such
a network or have seen a report on this subject I would be most greteful
if you send me your comments, or a pointer to such a report.

We know about the Proteon, CISCO and Bridge GS/3M gatewys, are there many
more ? How do these and others comply with RFC 1009 specifications and
recommendations ? Another aspect of interest is the ability of the Gateway
to act as a DECNET gateway at the same time.

Please send your replies directly to me via e-mail, since I am not subscribed
to this mailing list. Many thanks.

Leonid Rosenboim, Tel-Aviv University, Israel.

        leonid@taurus.BITNET
         @cunyvm.cuny.edu:leonid@taurus.BITNET
         leonid%taurus.BITNET@cnuce-vm.arpa

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 88 15:03:21 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Verification Suite











Hal Peterson (hrp%windsor.CRAY.COM@uc.msc.umn.edu) at Cray wrote

>I should stress, though, that a verification suite is only part of a
>comprehensive testing strategy, and that bake-offs can be extremely
>valuable for finding bugs.  A verification suite is software, and like
>all software it is imperfect.  It is entirely possible that two
>implementations both pass the suite but don't interoperate.  Bake-offs
>can catch that, and when they do they have found as many as FOUR bugs:
>
>1.  a bug in one of the implementations.
>2.  a bug in the other implementations; after all, they could both be
>    at fault.
>3.  a bug in the specification.  It may be unclear or inconsistent or
>    incomplete and so have misled the implementors.
>4.  a bug in the verification suite.  It should have caught the
>    problem, and next time it will, since it's a simple matter to add
>    a test to a well-designed suite.  The suite gets better as time
>    goes on.

His last two points bring two simple(?) questions to mind -

How do the Specification Bugs get resolved?

Who Verifies the Verification Suite???? (Qui Ipsos Custode Custodiet)

Frank Kastenholz
Atex Inc.

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 88 17:17:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP-NETBIOS Info Wanted

James,

Doesn't the use of TCP/IP to support NETBIOS also open up the possibility
of interactions between PCs in the TCP/IP-extended NETBIOS environment
and hosts in the rest of the Internet (or private internet)?

I think it was this extension of interaction which was the major motivating
factor for people like Dave Crocker (then of Ungermann-Bass, now of Wollongong).

Vint

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 88 19:05:20 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  A plea for sanity

(In reply to Rob Austein's message <SRA.12374181810.BABYL@XX.LCS.MIT.EDU>)

I don't think it's fair to call a mailer "broken" because it retains the
address of the original sender for reply purposes.  If mailing-list
redistributions eradicated the original From: line, replacing the original
sender's address with that of the redistributor, their mailing lists would be
far less useful.  Ditto if our mailers replied according to the SMTP envelope
rather than the body of the message.  Note that the envelope's format is
not specified by RFC 822, only the message header is -- and messages can
be delivered by other means besides SMTP.

Though RFC 822 doesn't define it, I've seen some mailing lists distribute
messages with an Errors-To: line.  This seems to be just what's needed
to separate message replies from delivery error replies.

Sendmail seems to support "Errors-To"; how many other mailers do?

	Stuart Levy, Minn. Supercomputer Center

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 88 20:18:47 GMT
From:      satz@clash.cisco.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Life in the Swamps / Testing

>> If we had a test suite that was in some sense 'official" we would not
>> have fiascos like I saw at Uniforum this week!  There was the usual
>> "hook all the TCP/IP speaking booths together" party.  And it barely
>> worked.  Why?  Two reasons:  1)  Not everyone did subnetting "right"
>> and 2)  the rwho broadcast storms made the net unusable much of
>> the time.  If we had a conformance test suite available that everyone
>> could test against, then these two rather simple hurdles could be tested
>> for and vendors would have to pass them to get a "certificate".  Would
>> this make the world "perfect"?  Probably not, but it would make it a lot, lot
>> better!  

The major problem with the Uniforum network was misconfiguration and
lack of understanding of all of the broadcast addresses. However the
misconfiguration was so bad the it was almost impossible to discern
broadcasts from other packets. What happened was that the show-net
started out to be network 89 with a subnet number of 1. People who
requested individual subnet numbers got them starting at some larger
number.  Interestingly enough, however, was that people weren't able
to live with this arrangement for some reason networks like 8.0.0.0
and 1.0.0.0 started appearing instead. Unfortunately some hosts were
still sending out [IP] subnet broadcasts instead of network broadcasts
or general broadcasts (all ones). Test suites can do little to solve
this problem.

I also saw random ICMP message types flying around and packets with
bad checksums. A real live test suite would go along way toward
eliminating this problem.

The unusability of the network stemmed from a few hosts that were
generating error rates of 10%. Excelan, the show-net manager, quickly
resolved the problem when it was pointed out to them, much to their
credit.

Aside from all of that, it seems that Sun was advertising all of its
many networks via RIP and HP was offering a portal into its network
with an IGRP route. Sun refused to pass packets to the MILnet and HP
blocked access to the ARPAnet.

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 88 20:20:05 GMT
From:      MRC@PANDA.PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re:  A plea for sanity

Stuart -

     You completely misunderstand the issue.  SMTP (RFC 821) defines an
address that mailer error reports (as distinguished from replies) are
sent to.  The BITNET mailers in question are using the reply address,
ignoring the errors address, to send errors reports to.

     The BITNET mailers which do this are broken.

     Errors-To: is completely unnecessary if SMTP is correctly implemented.
If you are using a non-SMTP transport, it should possess this functionality
OR it should do whatever equivalent exists in that transport to pass on that
address.

-- Mark --

PS: I am the implementor of one of the major electronic mail packages in
    use on the Internet, and have been for 9 years.  I know what I'm
    talking about.
-------

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 88 02:09:22 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re:  A plea for sanity (Errors-To: lines)

Stuart Levy writes:
> Sendmail seems to support "Errors-To"; how many other mailers do?

	A couple of years ago I was running a small mailing list and decided
to add "Errors-To:" headers to outgoing messages.  Much to my surprise I got
some rather angry mail from a system administrator somewhere in Europe who
said that his mailer didn't grok the "Errors-To:" lines.  Not only didn't his
mailer grok the lines, but it couldn't digest them or even consume them and
pass them through unchanged.  It seems that when his mailer saw the
"Errors-To:" line it died, wreaking all sorts of havok and mayhem on his
machine.  He urgently requested that I either stop adding the non-standard
headers or stop sending mail to his machine!

	Personally I thought he (and/or his mailer) was over-reacting, but I
decided to drop the "Errors-To:" anyway.
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Feb 88 16:18:38 PST
From:      JLarson.pa@Xerox.COM
To:        Header-People@MC.LCS.MIT.EDU, TCP-IP@SRI-NIC.ARPA
Cc:        SRA@XX.LCS.MIT.EDU, JLarson.pa@Xerox.COM
Subject:   Xerox experience with broken mailer behaviour
We at Xerox were badly burned recently by sites which; 

1)  Do not use the domain name system to look up IP addresses

2)  Pick the "best" address (usually net 10) from the host table, 
    and never try any other address in the list.  

Our story should explain why I now consider 2) to be severely broken mailer
behaviour.  We installed an IP gateway at our PSN where the Xerox.Com mail
gateway used to be, so the address for Xerox.Com changed from a net 10 address
to a net 13 subnet address.  The Xerox.Com domain name server had the correct
information, so those sites properly using the domain name system did not have a
problem.  But our update to the host table (to remove the net 10 address from
Xerox.Com) got stalled in DDN red tape for several weeks (even though that same
net net 10 address was already in the host table in the GATEWAY entry!).  So,
although we were allowed to place the correct net 13 subnet address as the first
address in the host table, the bogus net 10 address (now the IP gateway) could
not be removed from the host table for those several weeks.  

You guessed it;  those mailers in 2) picking the "best" address from the host
table were picking a BOGUS address, mail failed to go through for several weeks
from these sites, and the result was irate many mail users and flurries of mail
between postmasters.  Note that the equivalent problem would have resulted if
that net 10 interface went down for an extended period, and there were an
alternate route to our net 13 subnet.  (Yes folks, network interfaces do go
down, sometimes even for extended periods.)  

There is little excuse for this broken mailer behaviour since it should be easy
to fix, even for mailers which are very heavily loaded.  

The solution is quite simple;  using that "best" address is fine for the FIRST
attempt, but on later retries the BEST address to use is a DIFFERENT address in
the address list.  Simply rotate the previously used address to the end of the
list, and use the next address in the address list on the next retry attempt.
Note that you need only try one address each attempt, so there is no detrimental
impact on a busy mailer. (The Xerox.com mailer implementation in fact knows how
busy it is and adjusts timeout values and multiple address attempts accordingly
to keep keep sick sites from affecting throughput when busy.  When not busy, it
tries all the addresses, and uses longer timeout values.)

Hopefully this message will prompt certain mail implementers to fix their broken
mailers, and prompt sites to start using the domain name system so others can
avoid our painful transition experience.  


Cheers,

John Larson
Xerox PARC
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 88 18:12:07 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   SLIP and Telebit modems

We use Telebit Trailblazer+ modems here to communicate between systems
running TCP/IP/SLIP.  Throughput is enhanced by sending large segments
and very large windows but if you get things too large you run the risk
of overflowing the buffers in the TB+. 

The solution here is to enable the hardware handshaking (Trailblazer+
drops CTS and the host stops sending data).  This will guarantee that
the TB+ buffers will never overflow.  Flow control in the reverse
direction, e.g.  from the modem to the host, has not been a problem
since our implementation of SLIP on the Convergent boxes seems happy to
accept data at 19,200 bps.

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Feb 88 13:27-0800
From:      The Mail Server<Postmaster@locke.hs.WASHINGTON.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable mail
Message had a bad or missing To address.
The entire text of the message follows:

Received: by BYUADMIN (Mailer X1.25) id 5978; Mon, 15 Feb 88 14:15:10 MST
Date: Mon, 15 Feb 88 15:51:52 EST
From: Bob Jones <bobj@MCL.UNISYS.COM>
Subject: Re:  DCA Protocol Lab Test Tools
Sender: "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
To: "(no name)" <BRUCE@UWALOCKE>
Reply-to: <TCP-IP@SRI-NIC.ARPA>
X-To:         hrp%windsor.CRAY.COM@uc.msc.umn.edu
X-cc:         mills@udel.edu, tcp-ip@sri-nic.arpa

Hal,  thanks for comments.  I am hoping some industrious laboratory
will offer the remote drivers in some generic for that can be quickly
adapted to any machine environ (with generic hooks?). If it will be
of any comfort to you, we are at a point where all of the specs are
firm now.  Thanks to you, we have learned a lot and your persistence
has helped us to debug our test system in the process.  Cray deserves
a hand!

bobj
-------
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Feb 88 13:36-0800
From:      The Mail Server<Postmaster@locke.hs.WASHINGTON.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable mail
Message had a bad or missing To address.
The entire text of the message follows:

Received: by BYUADMIN (Mailer X1.25) id 5437; Mon, 15 Feb 88 14:12:36 MST
Date: Mon, 15 Feb 88 11:11:38 IST
From: Hank Nussbacher <HANK%TAUNIVM.BITNET@CNUCE-VM.ARPA>
Subject: cisco AGS vs. Proteon p4200
Sender: "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
To: "(no name)" <BRUCE@UWALOCKE>
Reply-to: <TCP-IP@SRI-NIC.ARPA>
X-To:         tcp-ip@sri-nic.ARPA

Does anyone have any comparison study of these two multiprotocol routers?
If you have any comparison numbers, I would love to see them.

Thanks,
Hank
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 88 02:18:09 GMT
From:      MRC@PANDA.PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   trying multiple addresses


     I am sure the advocates of trying multiple mail addresses would
feel quite differently if they had to pay per-packet charges for network
access.  Historically, only a small percentage of network connection
failures -- typically less than 1% -- have been due to a dysfunctional
IP address.  The remaining (= overwhelming majority of) failures have
been due to dysfunctional networks, dysfunctional hosts, or dysfunctional
servers.

     It is possible that trying a different IP address may help in the
dysfunctional network case, although typically the "non-best" IP addresses
all involve the dysfunctional network in some way (look at some network
topology maps some time).  This is a relatively rare case anyway.

     Many times, the "non-best" IP address is substantially inferior to
the point where it should not be used under ANY circumstance.  No site
outside of Stanford should *ever* use SAIL's, Score's, or SUMEX-AIM's
net 36 IP address; the gateway between net 10 and net 36 (as well as the
net 36 subnet from that gateway) is seriously overloaded.

     If I understand JLarson.pa correctly, he's saying that Xerox.COM
will use SUMEX-AIM's net 36 address just because they couldn't connect
to the net 10 address the last time.  If this is common behavior it's
no wonder those of us who must use the net 10/36 gateway find it so
unusable.  Will I have to instruct the servers on multi-homed net 10/36
hosts to refuse connections on net 36 from non-net 36 hosts to get them
to stop?

     What about those guys multi-homed on a "free" and a pay-per-packet
X.25 net?  Do they appreciate this behavior?

     The *correct* solution to this problem is NOT kludgy algorithms in
the mailer.  The correct solution is multi-part, and involves:
1) complete the migration from the host table to the domain system.  The
   NIC simply cannot keep up with the changes in network topology (as the
   Xerox experience showed), and, frankly, it's unreasonable for us to
   expect them to.
2) domain database managers need to keep their name servers updated with
   changes to network topology.  TTL's should not be allowed to be so long
   that topology changes go unnoticed by resolvers for excessive periods
   of time.
3) better support needs to exist in the domain infrastructure for "best"
   IP address selection.

     This last point is important.  Presently, it is up to the local host
to decide upon a "best" IP address, based on quite incomplete information.
Many hosts (all Unix hosts?) simply pick the first IP address listed in
the NIC host table (or returned as A RR's from the domain system).  TOPS-20
selects in priority order: (1) first IP address from a directly connected
net that is "preferred" (e.g. a fast LAN), (2) first IP address from a
directly connected net that is "default" (e.g. a core net such as ARPANET),
(3) first IP address from any other directly connected net, (4) first IP
address.  "First IP address" means first from the address list from the
host table (or a set of A RR's from the domain system).  Note that there
is nothing whatsoever to do with "net 10".

     Almost 100% of the time, this makes the best possible choice of an
IP address.  It's only in those very few cases (which come up perhaps
2 or 3 times a YEAR!!!) where an otherwise highly desirable path breaks
for a long period of time that a problem comes up.  I consider it highly
objectionable to cycle through every other IP address (waiting a minute
or more for an IP retransmission timeout if the network is courteous
enough to tell me the other guy ain't there) every time I attempt to
connect to a dead host.

     JLarson's suggestion is less objectionable, but it involves one
piece of software (the mailer) telling a completely different piece of
software (host table or domain resolver) that the IP address given it
was sick.  Nobody wants to do the work to the host table software to
add such a feature.  It might be doable with the domain resolver (SRA
can comment on this); it certainly wouldn't be hard for the mailer to
pass on the word to the domain resolver.

     The problem is, what does "this IP address was sick" really mean?
How does "retransmission timeout" differ from "host dead" (a type 7
1822 message) differ from "host sent a reset" (refused the connection)
differ from any of the other ways a connection failed?  In which one(s)
of these do you say try another IP address, and in which one(s) do you
assume the host is really down, or really doesn't want to talk now?

     Again, what do you do about those cases when we really shouldn't
be using a particular IP address because of charging, or other
administrative issues?

     The domain system may be able to help; it was always my belief (I
remember suggesting this at the meeting when the domain system concept
was first invented) that nameservers should be allowed to tailor their
responses based on who was asking the question.  A domain query should
be something like: "I am on net 128.43 seeking an SMTP server for
FOO.BAR.COM, which is the best address for me to use?" and later on "I
am on net 128.43 seeking an SMTP server for FOO.BAR.COM and I already
tried 69.105.8.3, is there any other I should try?"

     The point is that a perfectly valid answer may be "if 69.105.8.3
ain't answering, he ain't up; try again later."

     This also gives the remote organization (which presumably knows
the status of their hosts) control over the IP address selection criteria,
based upon their knowledge instead of the local host's educated guesswork.

     Please, no flames.  If you're going to babble on and on about how I
should break my mailer to conform to your fantasy of how the world should
work, send it to *NUL: or /dev/null or whatever you call it.  Furthermore,
I'm not interested in any comments about a host table based means of IP
address selection.  The systems I support do not use host tables (and, for
the record, are currently the only TOPS-20's supporting MX mailing).  I
can't help but feel that if the problem of a sick "best" IP address happens
to a domain-based mailer, that the fault is that of the management of the
nameserver for that organization and not that of the mailer.

     If you have constructive observations, then let's talk.  Remember
that this is not about porting arguably "better" (or "worse") ideas from a
16-year-old operating system to a 19-year-old operating system.  This is
about what's going to be done in the next generation, that maybe will be
ported to the 16 and 19 year-olds.  I think we can do better than any of
the guesswork, and we should, if the threats of pay-per-packet come to
pass.

-- Mark --
-------

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 88 03:35:00 GMT
From:      WANCHO@SIMTEL20.ARPA ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   trying multiple addresses

For those who may be unaware, Mark's pay-per-packet comments *will*
apply to all MILNET hosts for outgoing traffic and TAC access sometime
in FY 89, unless the plans have been rescinded by some miracle.  And,
from what I've seen of the algorithm DCA intends to impose on us, it
ain't cheap!  When that happens, those sites, such as this one, which
support large mailing lists and anonymous ftp service may be forced to
withdraw those services... (or move to ARPANET where flat fees will
continue - no :).

--Frank

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 88 07:24:11 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: What is SLIP?

Jean-Francois,

This was actually the basis of a BOF (birds of a feather) meeting at
the TCP/IP Interoperability Conference last December.  The conclusion
was (as I remember hearing -- I was not there) it works, but has
some hitches:  You have to use the right kind of flow-control i.e.
your interface must implement RTS/CTS handshaking.  Dialing is
tricky (I don't remember the details).  And the turn-around-time
(since it is a pseudo full-duplex modem) makes it undesireable
for interactive applications, but works quite nicely with batch
data transfers e.g. mail and ftp.

-Philip

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 88 07:38:00 GMT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Bug in Sun OS 3.4 tcp?

In article <8802120105.AA05436@PHOEBE.CAM.UNISYS.COM> jonab@CAM.UNISYS.COM (Jonathan P. Biggar) writes:
>Does anyone know about a problem with tcp under Sun OS 3.4 where receiving
>a packet with the maximum segment size option messes up the window?

A zero window size bug was fixed in the current release of SunOS, 3.5.
This release also fixes problems with the TCP MSS being set incorrectly,
which was introduced in 3.4.

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 88 07:40:21 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re:  A plea for sanity (Errors-To: lines)

I don't have 822 handy, but aren't you supposed to pass through lines that
you don't grok?  I've seen mail headers that include "Fruit-of-the-day:"
and other such stuff (not to mention "Organization:", "Distribution:",
"Newsgroup:", and "X-Comment:").  Why should "Errors-To:" be a problem,
unless there was a bug in his mailer in handling this specific string?
How long ago was this, anyway?

-Philip

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 88 12:11:33 GMT
From:      HANK@TAUNIVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   cisco AGS vs. Proteon p4200

Does anyone have any comparison study of these two multiprotocol routers?
If you have any comparison numbers, I would love to see them.

Thanks,
Hank

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Feb 88 11:11:38 IST
From:      Hank Nussbacher <HANK%TAUNIVM.BITNET@CNUCE-VM.ARPA>
To:        tcp-ip@sri-nic.ARPA
Subject:   cisco AGS vs. Proteon p4200
Does anyone have any comparison study of these two multiprotocol routers?
If you have any comparison numbers, I would love to see them.

Thanks,
Hank
-------
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 88 16:37:30 GMT
From:      gross@gateway.mitre.ORG (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re:  Complete FROM: field.


> If your message is meant to suggest that my mail message contained
> an incomplete "FROM:" field, I feel compelled to answer.

Terry,

The heck with your `From:' line--I want to complain about your
15 line signoff message!  Your signoff is generally longer than
the message itself.  Please help reduce bit chaff on the network.
(You will also be showing consideration for folks who read mail 
over 1200 baud dial-up lines.)

Phill Gross

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 88 20:51:52 GMT
From:      bobj@MCL.UNISYS.COM (Bob Jones)
To:        comp.protocols.tcp-ip
Subject:   Re:  DCA Protocol Lab Test Tools

Hal,  thanks for comments.  I am hoping some industrious laboratory
will offer the remote drivers in some generic for that can be quickly
adapted to any machine environ (with generic hooks?). If it will be
of any comfort to you, we are at a point where all of the specs are
firm now.  Thanks to you, we have learned a lot and your persistence
has helped us to debug our test system in the process.  Cray deserves
a hand!

bobj

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 88 21:28:52 GMT
From:      bobj@MCL.UNISYS.COM (Bob Jones)
To:        comp.protocols.tcp-ip
Subject:   Re:  Life in the Swamps / Testing

Dan,  I was not nearly as verbose as you in my response to Dave, but
you expressed my sentiments exactly.  Anyway perfection is found only
in heaven. This is earth, and all of the solutions for that perfect
world are just not here..yet.

Again, thanks for your input.

bobj

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 88 23:27:07 GMT
From:      AI.CLIVE@MCC.COM (Clive Dawson)
To:        comp.protocols.tcp-ip
Subject:   Re: trying multiple addresses

Re:	Date: Sun, 14 Feb 88 18:18:09 PST
	From: Mark Crispin <MRC@PANDA.PANDA.COM>
	Subject: trying multiple addresses

Mark--

Your message implies that trying an alternate IP address after the
best one has failed will only win 1% of the time.  I disagree.  As
somebody who still has the job of dealing with the day-to-day hassles
of "keeping the mail flowing", I cannot afford to sit back and
consider what the "correct solution" will ultimately be once the whole
world arrives at some standard.  I will gladly accept any "kludgy
algorithms" that get the job done with no adverse effects.

Not counting the host-table-related problems (I know, you don't want
to hear this!) such as SU's Sierra, whose 10 address still appears
over a year after it died, or the more recent HI-MULTICS/CIM-VAX
address problem at Honeywell, where both addresses work, but SMTP
listens only on one, I have also had to deal with a multitude of other
problems in just the last week which were all solved by using
non-"best" IP addresses.  The following scenario comes up A LOT, at
least at this site:
	Q: Why isn't my mail getting through to host X?
	A: The host must be down.
	Q: Then why can I Telnet to it?
	A: Ah, your workstation is not directly connected to net 10,
	   and is so "dumb" that it doesn't realize that net 10 is the
	   only way out of this place anyway, so it chooses to use host
	   X's 128 address.  Meanwhile, our "smart" mail relay host (and
	   gateway) is directly connected to net 10 and therefore
	   insists on sticking to host X's 10 address regardless.

How am I supposed to tell users that "correct failure" is better
than "kludgy success"?  They could care less about these details,
and rightfully so.

	     If I understand JLarson.pa correctly, he's saying that Xerox.COM
	will use SUMEX-AIM's net 36 address just because they couldn't connect
	to the net 10 address the last time.  If this is common behavior it's
	no wonder those of us who must use the net 10/36 gateway find it so
	unusable.  Will I have to instruct the servers on multi-homed net
	10/36 hosts to refuse connections on net 36 from non-net 36 hosts to
	get them to stop?

Mark,  that's not how I understood JLarson at all.  He said that
this procedure was followed on RETRIES, and then ONLY at the
next retry interval.  This is quite different from adopting the
alternative IP address "permanently" thereafter for all deliveries.

It seems to me that this procedure is almost a complete win.  There is
no extra load on the sending mailer, and non-"best" IP addresses are
used only when they have to be, on a message-by-message basis.  It
might possibly be improved by a heuristic which says that if, on the
first retry, the second address is found to be down too, then 4 out
of every 5 (say) future retries should go back to using the "best" IP
address. This way, if SCORE is really down, the poor 10/36 gateway
won't get so much of a pounding with doomed connection attempts from
everybody.

Cheers,

Clive
-------

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 00:27:00 GMT
From:      WANCHO@SIMTEL20.ARPA ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   Correction on MILNET packet charges

The scheduled implementation for charge-back to directly connected
MILNET hosts is FY90, not FY89.  Sorry for the confusion.

--Frank

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 88 07:49:08 EST
From:      terry@DEC-VAX-11-750.ARPA
To:        tcp-ip@sri-nic.arpa
Subject:   Conforming!

Hello All,

> Re: "From:  address of terry@dvax "

MY host administrator has changed our official sitename to match
our MILnet sitename (dec-vax-11-750.arpa).  This will cause the 
"FROM" address of my mail to conform network requirements.

Seems only fair...

Terry Robb
************************************************************************
*-  Terence A. Robb                                                   -*
*-  Network Solutions                                                 -*
*-  Systems Programming Specialist                                    -*
*-  MILnet:   terry@dec-vax-11-750.arpa                               -*
*-  PHONEnet: (703) 749-1918                                          -*
*-  MAILnet:  8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180    -*
************************************************************************
-------
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 88  9:59:21 EST
From:      "Alan R. Hill" <ahill@cc7.bbn.com>
To:        gross@gateway.mitre.org
Cc:        tcp-ip@sri-nic.arpa, terry@dec-vax-11-750.arpa
Subject:   Re:  Complete FROM: field.
	It might also help if the current trend of including excerpts and
complete text of subject messages in responses wasn't so popular.  It seems
as though messages are getting more and more verbose as time passes (please
don't construe this to mean that I think messages contain useless input).

Alan

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 06:41:10 GMT
From:      MRC@PANDA.PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: trying multiple addresses

Clive -

     The NIC host table is a disaster, and the only way to fix the many
problems associated with it is to abandon it for domains.  Supported
TOPS-20 domain and mail software was announced a while ago; perhaps you
should consider adopting it at your site.  [As a side note, the problem
with Sierra's net 10 address being in the host table will go away very
soon since the plug is being pulled on Sierra.]

     Trying every possible IP address for a host which fails to respond
on its "primary" IP address is a recipe for performance disaster for any
background mailer with a large workload.  We're talking about thousands
of messages/day, friends, not a piddly couple of hundred.

     Furthermore, we all can rattle off the cases where the primary IP
address was wrong.  We can do this because there have been so few of
them!  What's more, most of those few are host-table only problems.  If
you run obsolete software, you should expect to have to put in some
maintenance on your own.

-- Mark --
-------

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 12:49:08 GMT
From:      terry@DEC-VAX-11-750.ARPA
To:        comp.protocols.tcp-ip
Subject:   Conforming!


Hello All,

> Re: "From:  address of terry@dvax "

MY host administrator has changed our official sitename to match
our MILnet sitename (dec-vax-11-750.arpa).  This will cause the 
"FROM" address of my mail to conform network requirements.

Seems only fair...

Terry Robb
************************************************************************
*-  Terence A. Robb                                                   -*
*-  Network Solutions                                                 -*
*-  Systems Programming Specialist                                    -*
*-  MILnet:   terry@dec-vax-11-750.arpa                               -*
*-  PHONEnet: (703) 749-1918                                          -*
*-  MAILnet:  8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180    -*
************************************************************************

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 13:34:17 GMT
From:      AI.CLIVE@MCC.COM (Clive Dawson)
To:        comp.protocols.tcp-ip
Subject:   Re: trying multiple addresses


	     Trying every possible IP address for a host which fails to
	respond on its "primary" IP address is a recipe for performance
	disaster for any background mailer with a large workload.  We're
	talking about thousands of messages/day, friends, not a piddly couple
	of hundred.

Yes, Mark, I know what large workloads are.  Considering that 

	a) this discussion deals with multi-homed hosts which
	   comprise only about 5% of the total host population, and
	b) the success rate for first delivery attempts exceeds 95%, and 
        c) once a message is in the retry queue the average number of
	   retries is greater than 1,

I would appreciate it if you would elaborate on just how this
"performance disaster" you predict will come about, especially for
sites using the algorithm we've discussed in the last few messages.

I'm glad to see you acknowledge that only "most" of these problems are
host-table related.  OK, let's eliminate these from consideration.
What do you propose that we do about the rest of the problems which
are not host-table related?  You seem to be resigned to the idea that
they should just be ignored because there are so few of them.  If
this is true, then a solution which only affects THESE FEW can hardly
cause a performance disaster.

Clive
-------

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 13:35:59 GMT
From:      dan@MITRE-BEDFORD.ARPA
To:        comp.protocols.tcp-ip
Subject:   IP security options (again)


     This is my second request for information on systems that can handle IP
security options.  I previously asked about systems that allowed the use of
the options.  I'd like to expand that request to include systems that will
ignore the security options without choking on the datagram.

Also, if there are any methods of setting the options on output, I would
appreciate hearing about them.

Thank you.

Daniel Willhite
dan@mitre-bedford.arpa

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 14:59:21 GMT
From:      ahill@CC7.BBN.COM ("Alan R. Hill")
To:        comp.protocols.tcp-ip
Subject:   Re:  Complete FROM: field.


	It might also help if the current trend of including excerpts and
complete text of subject messages in responses wasn't so popular.  It seems
as though messages are getting more and more verbose as time passes (please
don't construe this to mean that I think messages contain useless input).

Alan

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 15:44:57 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re:  Life in the Swamps / Testing


Bob,  You're welcome.  I calls 'em as I sees 'em, eh?  Actually
it is time for some leadership in all this and I have been
a patient person for over a year now.  Things don't get fixed
if there's no incentive to fix them.  Something as simple
as doing subnetting right or pluggin in the right broadcast
address should be done by now.  Must be we have to kick the vendors in the
butt!

Dan
-------

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 88 21:56:08 EST
From:      Lyle Evans <EVANSL%VTVM1.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  Complete FROM: field.
Amen. Besides using net capacity excessive signatures use up disk space for tho
se who store messages.
-------
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 17:17:00 GMT
From:      retrac@titan.rice.edu (John Carter)
To:        comp.protocols.tcp-ip
Subject:   Summary of responses to my tcp-ip performance query

Hello,

    Back in late November I posted the following request for information
to the network.  I had intended to post this summary of the responses that
I received, but I forgot.  What follows is my original posting followed by
the responses that I received.  Hope people find this to be useful!  Many
thanks to all of you who answered my query!!!

==============================================================================

>     I'm a fairly new reader of this newsgroup, so I apologize if this has
> already been discussed.  I would like to know what the best performance
> figures are for large memory to memory transfers using TCP-IP.  More
> specifically, what are the fastest reported average transfer times for
> transferring 10 Mbytes over a 10 Mbit/sec ethernet?  (or) What is the
> highest reported throughput of DATA across a 10 Mbit/sec ethernet using
> TCP-IP?
> 
>     Def.:  Memory to memory above means, the client generates the data
>            out of thin air and the server puts them all in one buffer
>	     (the "best case" situation).  I'm interested in raw transfer
> 	     rates and the cost of TCP-IP overhead on performance.
> 
>     I have seen performance figures for van Jacobson's modifications to
> Berkeley 4.3 TCP-IP which gave measurements of 23.3 secs for 10 MB over
> a 10 Mbit/sec ethernet (effective throughput of 3.4 Mbit/sec).  Are there
> any better?
> 
> John Carter
> Dept. of Computer Science, Rice University

==============================================================================

From: David Robinson <david@elroy.jpl.nasa.gov>
To: retrac@rice.edu
Subject: TCP performence


The best I have personally seen is between two Sun-3/260's doing
memory-memory transfers is 3.2Mbits/sec.  Their UDP topped out
at 5Mbits/sec.  This was on a fairly quite net, rwhod and routed
traffic only.  From my experience excelan boards have been the
worst, slower than my lowly Sun-2, but what can be expected from
a 80186??

I do not know what the limiting factor of the Sun's is by I suspect
that it is CPU bound, the e-net controllers each have large
memmory buffers (256K?).

	-David Robinson
	david@elroy.jpl.nasa.gov

[Wishing for an IP pure hardware chip!]

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

Subject: Re: What's the "best" TCP/IP throughput?
Date: 26 Oct 87 07:37:25 PST (Mon)
From: lekash@orville.nas.nasa.gov

Better performance for ethernet is not that likely until someone
builds a better interface card.  Thats the current bottleneck.
If you go to other media, say pronet-80, or hyperchannel, you
can get much higher rates.  we were seeing up to 17mbits/sec over
hyperchanel, proteon claims over seven for their ring.  I
would guess with performance tuning, those numbers will
increase. (We might even do some here.)

					john
---------------------------------------------------------------

From: nowicki%rose@sun.com (Bill Nowicki)
Message-Id: <8710272303.AA03617@rose.sun.com>
To: retrac@rice.edu
Subject: Re: What's the "best" TCP/IP throughput?

Disclaimer: this is NOT an official number, just my latest test in an
uncontrolled environment with an unannounced software configuration.
But between a pair of Sun-4/260s I am able to transfer with TCP over an
Ethernet at 5.0 Mbits/second.  

	-- WIN

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

From: Richard Fox <rfox@ames-nas.arpa>
Organization: NASA Ames Research Center, Mountain View, CA


I have just spent some time using the FTP protocol using tcp-ip over
an ethernet, gathering stats. As you are probably aware the results
at this point have been pretty disappointing. 

I would like to start investigating new and different protocols. So
any info you get could you please forward. Also, if you have other
protocols that need testing I would be glad to help. We have ethernets,
hyperchannels, satellites etc. and a strong interest in finding a more
efficient protocol than the current TCP-IP.

By the way, we have just received a new TCP implementation that is
supposed to have rate-control. If you are interested I will send you
the results after I have some time to play with it.


rich fox
(415)694-4358

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

From: erikn@sics.se (Erik Nordmark)
Summary: 1.8 Mbps between Vaxstation II's, about 4 Mbps between Sun-3's


When I was at Stanford I was working on David Cheriton's VMTP protocol.
There was already an implementation in the V distributed system and I 
did one in the 4.3BSD kernel.

These are the number we got:

Memory-to-memory bulk data transfer between 2 VAXstation II's on a 10 Mbps
Ethernet running 4.3BSD Unix:
	1.8 Mbps

Short request-reponse interaction: a 32 byte request and a 32 byte response
message (same system):
	send -----> recv
	     <----- reply

	8.6 milliseconds 

The implementation in V performs with about 4 Mbps and 2.3 ms between two
Sun-3's on a 10 MBPS Ethernet.

Note: The Unix implementation uses IP for datagram delivery whereas
the V implementation has its own mechanisms for delivery, routing
et.c. on the local net. An optimized version of the Unix
implementation that uses "raw" ethernet for packets on the local net
(and IP for internet packets) achieves about 2.1 Mbps between the two
microVAXes.


About VMTP:

The Versatile Message Transaction Protocol is a reliable transport
protocol based on the transaction style of communication. A
transaction consists of a request and a response message which are
limited in size to 1 Mbyte.  Current implementations limit the message
size to 16 kbytes, so there is room for performance improvements in
the implementations.

The protocol has:
	better naming then tcp/ip  (stable, location independent identifiers)
	support for real-time communication  
	support for security
	multicasting on LAN as well as WAN (latter relying on the Internet 
			Group Management Protocol and extensions to IP)
	solves the speed mismatch problem on the local net by using rate
			based flow control
	etc.


David Cheriton 		(cheriton@pescadero.stanford.edu)
"VMTP: a Transport Protocol for next generation ..."
Proc. Communications and Architecture and Protocols
Aug. 1986 (ACM)

Steve Deering
"Host extensions for IP multicasting"
RFC 988

Karen C. Lam
"4.3bsd Internet Multicast {Implementation Notes,Installation and Usage Notes}"
BBN Laboratories Inc, 10 Moulton Street, Cambridge MA


** Erik Nordmark **
Swedish Institute of Computer Science, Box 1263, S-163 13  SPANGA, Sweden
Phone: +46 8 750 79 70	Ttx: 812 61 54 SICS S	Fax: +46 8 751 72 30

uucp:	erikn@sics.UUCP or {seismo,mcvax}!enea!sics!erikn
Domain: erikn@sics.se

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

From: Jack Jansen <mcvax!cwi.nl!jack@uunet.uu.net>

The protocol used in the Amoeba distributed OS is probably the fastest
around currently (at least, that's what we like to think:-).

We do 420Kb/sec between two microvaxen, and 600+Kb/sec between two
68020 systems. This is all running the protocol between machines
running amoeba. I got up to 250Kb/sec once between two uVaxen running
ultrix 1.2.

References to amoeba should be easy to find, there's quite a bit
published, mainly written by Andrew S. Tanenbaum and Sape J. Mullender.
If you cannot find anything, drop me a line and I'll send you
a list of references.

Another protocol to look at might be the one used in David Cheriton's
V operating system. He does almost as good as we do.
--
	Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp)
	The shell is my oyster.

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

From: dmc%tv.tv.tek.com@relay.cs.net
Subject: Bulk data transfer protocol timings

We are running Stanford's V-system Version 6 kernels in
Tektronix 4405 workstations, which have 16.6 Mhz. 68020 processors.
The ethernet interface used is the AMD LANCE, with 64 receive
packet buffers and 8 transmit packet buffers of 1518 bytes.

The Inter-Kernel measurement program `timeipc' gives us the following
figures for segment transfers between the user process memory of
two 4405's.  The program runs at a real-time scheduling priority,
and normal process execution is essentially suspended while the test
is in progress.  The protocol is an early version of VMTP.

Send-Receive-ReplyWithSegment (5 trial average):
Size (bytes)	elapsed time/100 transactions	effective bit rate
0		.20 seconds
1024		.34 seconds			2.409 Mbit/sec.

Send-Receive-MoveTo-Reply (5 trial average):
Size (bytes)	elapsed time/100 transactions	effective bit rate
2048		.66 seconds			2.482 Mbit/sec.
4096		.99 seconds			3.310 Mbit/sec.
8192		1.40 seconds			4.681 Mbit/sec.
16384		2.32 seconds			5.650 Mbit/sec.
32768		4.18 seconds			6.271 Mbit/sec.
65536		7.91 seconds			6.628 Mbit/sec.
131072		15.30 seconds			6.853 Mbit/sec.

Send-ReceiveWithSegment-Reply (5 trial average):
Size (bytes)	elapsed time/100 transactions	effective bit rate
1024		.35				2.341 Mbit/sec.

Send-Receive-MoveFrom-Reply (5 trial average):
Size (bytes)	elapsed time/100 transactions	effective bit rate
2048		.78				2.101 Mbit/sec.
4096		1.01				3.244 Mbit/sec.
8192		1.58				4.148 Mbit/sec.
16384		2.62				5.003 Mbit/sec.
32768		4.57				5.736 Mbit/sec.
65536		7.87				6.662 Mbit/sec.
131072		15.2				6.899 Mbit/sec.

Don Craig
Tektronix Television Systems

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

From: Mike Muuss <mike@brl.arpa>

A pair of Sun-3/50 machines running SUNOS 3.3 with tcp_sndspace and 
tcp_rcvspace (or whatever they are called) increased to 16K (ie,
increased offered windows).  Test is typically 1 Mbyte memory to memory
using the TTCP program (copies on request).  Typical data rate is
3 Mbits/sec.  For two pairs, typically see 6 Mbits/sec total for both
connections.  Never bothered to do three pairs.  Trailers were off.

6 Mbits/sec is fairly close to the maximum usable bandwidth of an Ethernet.

On an NSC Hyperchannel, between a Gould PN9080 running UTX 2.0, using a
PI32 to access an A400, with an otherwise idle trunk to an A130 adaptor
connected to a Cray XMP48 running UNICOS 2.0 (at the time), I was able
to achieve 11 Mbits/sec aggregate, using MTU of 4144 and Cray-IP
encapsulation.  This was not using TCP at all, but merely IP/ICMP_Echo
request/response packets, in a "flood ping" test.

	Best,
	 -Mike

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

From: aeh@j.cc.purdue.edu (Dale Talcott)

Re your query about high speed network protocols:  Several of our
mainframes here at Purdue are connected using Control Data's LCN
(loosely coupled network).  This is not a 10Mbs based network, but may
provide some insight into limiting factors.

The LCN is somewhat Ethernet-like in that it is tapped-trunk using
coaxial cable, but it runs at 50Mbs instead of 10Mbs and uses 3/4 inch
coax.  There is carrier-sense, but collisions are avoided by providing
fixed time slots for each host to start a transmission.  In practice,
there are occasional collisions.  The maximum trunk length is limited
to about 2000 feet.  The typical number of taps on a trunk is small
(5 - 10).  The hardware level protocol is point-to-point, with no
broadcasts.  The hardware level protocol packet limit is 65535 16-bit
words.  The software packet size is 4096 bytes of data with a 12 byte
software header and 21 bytes of hardware framing, addressing, crc, etc.
However, there is a mode called "streaming" in which a sender can
"grab" the trunk and keep it for as long as it wants by holding the
carrier asserted between packets.

The hosts do not connect directly to the LCN.  Rather, there are
specialized minicomputers to do the connection.  These are called NADs
(network access devices).  There are several kinds of NADs, according
to the device the NAD is connecting to the LCN.  We have NADs for tape
controllers, disk controllers, VAXes, and various CDC Cyber mainframes.

Simplified network:

 +-----+                +-----+
 |host |                |host |
 +-----+                +-----+
    |                      |
 +---+                  +---+
  |nad|                  |nad|
 +---+                  +---+
    |                      |
===============================================  trunk
                |
              +---+
              |nad|
              +---+
                |
             +-----+   +---+    +---+   +----+
             |host |---|nad|====|nad|---|disk|
             +-----+   +---+    +---+   +----+

There are different protocols used, according to the devices being
connected.  When a host talks to another host, the protocol is called
RHF (remote host facility) and is more-or-less ISO seven layer in
philosophy.  In practice, there is much mingling of layers.

When a NAD pair with dedicated trunk is being used to connect a host to
its disks (as in the bottom example), the NADs use a simplified
protocol, idiosyncratic to the device and host operating system.

---
Now, for the numbers:

("Mbs" = "megabits per second", throughout.)

A Cyber 205 host to CDC 819 disk drives, over a dedicated trunk
achieved a sustained transfer rate of 30Mbs.  The instantaneous rate at
which the drives read is 36Mbs.  The 205 usually reads/writes data in
65536 byte chunks (memory small page size), and often reads .5Mbyte
chunks (memory large page).  The disk NADs use streaming mode between
themselves.  I do not remember the actual size of the file used to
determine this transfer rate, but it was at least 8 Mbytes.

--
Transfers among hosts using the RHF protocol, exclusive of the time
needed to build a connection:

CDC 6600 to CDC 6500, no other load on the network, 6 Mbit of
fabricated data at sending end, discarded at receiving end, packet size
of 3840 bytes:						6.5Mbs.

CDC 6600 to Cyber 205, disk to disk, both systems idle, 16 Mbytes of
data:							2.6Mbs.

Same file, opposite direction:				2.0Mbs.

VAX 11/780 (dual processor) running 4.3BSD to Cyber 205.  VAX
multiuser, but idle.  Cyber running typical middle-of-the-night, CPU
intensive, low priority workload.  Transfer rate for 1 Mbyte, "holey"
file on VAX to 205 disk file:				1.3Mbs.

(A holey Unix file does not require disk accesses to read the holes:
the system just fabricates a chuck of zeros.)  Same file, only real and
residing on Fuji Eagle disk:				1.1Mbs.

Statistics for transfers during normal production from 205 to 780 give
numbers in the .5Mbs range for moderately large files (~1Mbyte) when the
780 has to translate each '\037' character into '\n' (done with the VAX
movtc instruction).  Highest rate noticed was .8Mbs for ~.25Mbyte
transfer.

For a transfer from CDC Cyber 720 to VAX 780, no character translation,
disk to disk, the transfer rate was .96Mbs.  This was a while ago, and
I don't remember the loads on the two systems, but I suspect both were
idle.

For Cyber 205 to VAX 8600 running Ultrix 2.?, both systems in normal
daytime production (but the VAX still lightly loaded), a .5Mbyte file
transferred disk to disk with character translation at	1.05Mbs.
Normal rates are 20 - 30% better than the 780.  (Note: the 8600 is
at JVNC at Princeton, not at Purdue.)

---
Notice the huge disparity between the data rate the hardware (NADs and
LCN trunk) is capable of and that actually obtained once several layers
of host resident protocol are placed on top.  In developing the RHF
implementation for the VAXes, we noticed that every optimization in
host code (placing data blocks on page boundaries, using the movtc
instead of a C loop, etc) showed up in the transfer statistics.  (Our
first cut got only 24kbs!).  We have an open project to find why it
is still so slow.

Dale Talcott                            Systems programmer
ARPANET: aeh@j.cc.Purdue.EDU            Purdue University Computing Center
 BITNET: AEH@PURCCVM                    Mathematical Sciences Bldg.
  Phone: (317) 494-1787                 West Lafayette, IN 47907

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

From ogud@sdag.cs.umd.edu Tue Nov 24 00:05:11 1987

Sorry I did not read your mail earlier but I trying to finish my thesis on
the behavior of Ethernet here in the CS Dep.
One part of my study was to look at bandwith between SUN's and more machines
Another part was to examine the behavior of the net under overload conditions

The results are in short: (all load figures include headers)
	sun3/50 to sun3/50 transferrate 2Mbits for Max size TCP packets
			   max 500 pack per sec of min size TCP packets

	sun3/160 to sun3/160 multiply by 1.2

I had sun3/160 and sun3/50 listening to all the traffic using modified 
Etherspy program  and killed of all UNIX processes that are not needed
and at sun3/50 started to report dropped packets at around 25% load (2.5Mb)
Both machines where shot down a(dropping lot of packets) at 40% load and
started showing erratic behavior. 


How does this affect the transfer rate?
Well no protcol using TCP will get any better rate because the SUN's are the
bottleneck not the NET. When running FTP here at night on large files I 
see max 140Kbytes per sec or (140 * 1090 * 8 = 1.2Mb). The higest number 
I have heard about is 190 KBytes/sec or( 1.6 Mb). This number is probably for
a SUN3/260 and scales well down to the 140 for 3/50.

If you want more info send my questions and Hopefully I will be able to
answer them for you. 

Olafur Gudmundsson  Dept. of Computer Science University of Maryland
ARPA: ogud@brillig.edu
UUCP: {...}!seismo!umcp-cs!brillig!ogud   Tel: (301)-454-6153 (w)
UPS: College Park MD. 20742               ATT: (301)-595-4154 (h)

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

From mangler@csvax.caltech.edu Tue Nov 24 04:22:59 1987
>   From: David Robinson <david@elroy.jpl.nasa.gov>
>
>   The best I have personally seen is between two Sun-3/260's doing
>   memory-memory transfers is 3.2Mbits/sec.

What wasn't mentioned is that this was on SunOS 3.2.  Prior and later
versions of SunOS aren't nearly as fast at TCP.  SunOS 3.4 is 2X slower!

Don Speck   speck@vlsi.caltech.edu  {amdahl,scgvaxd}!cit-vax!speck

==============================================================================
         ___
        /   \             John Carter
=======O     \            Rice Univerity
|  _  |       \           Houston, Texas
| (_) |    (( ))
|__#__|    O/  \\O        ARPA/CSNET:  retrac@rice.edu
  | |     /+     -+.      UUCP: {Backbone or Internet site}!rice!retrac
  [N]     =       |
  [B]    //      //       Rockets record with me at the game: 13 -  0
  [A]    ))      \\       Rockets record w/o  me at the game:  4 -  4  Home
  |_|            =/                                           15 - 18  Total
 /___\                    ^^^ ME, *superstitious*?!? ^^^  No way!  :-)

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 18:50:11 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  trying multiple addresses

Egad!  I thought this question was settled about 4 years ago!  And the
answer was... JLarson is entirely right, and Mark Crispin is confusing 
a settled issue.

Bob Braden

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 19:17:04 GMT
From:      golds@rlgvax.UUCP (Rich Goldschmidt)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   "Standards" for PC sockets

There was a BOF at the 2nd TCP/IP Interoperability Conference about defining
application level and interrupt level standards for sockets for PC's.  It
was also discussed on this list prior to the conference.  I have heard
nothing since.  Has anything really happened with this, and will the
manufacturers really get on board and make this happen any time soon?

Rich Goldschmidt
rlgvax!golds@uunet.UU.NET
uunet!rlgvax!golds
sun!sundc!rlgvax!golds

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Feb 88 08:57:45 -0800
From:      David Walker <dwalker@orion.cf.uci.edu>
To:        tcp-ip%sri-nic.arpa@orion.cf.uci.edu
Cc:        Iglesias@orion.cf.uci.edu, Ct_Network_Services@orion.cf.uci.edu
Subject:   tn3270 for Wollongong VAX software?
Does anyone know of a tn3270 that has been developed for the
Wollongong's WINS software?  We've heard that there is one that runs
under EUNICE, but we'd rather not have to buy the rest of the UNIX
emulation.

                                        David Walker
                                        Network Services Manager
                                        UC Irvine
-------
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 19:44:00 GMT
From:      jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: trying multiple addresses

Mark talks all about "host table this" and "obsolete software this"
but the problem that I had (and I think J Larson had) was that,
due to NIC paperwork (i.e., chan
ging *anything* about a host/gateway
that requires an NCD), there are things that will hose you for
sure.  I couldn't get the host table *or the domain database*
changed, so places like sushi.stanford.edu, mcc.com, a.isi.edu (a
*root domain server*!!!) bounced mail headed our way for 5 weeks.

I'm running all the correct software, i'm hip to the "now it's your
namespace, now you have control over it" thang, but I think it's a bit
naive to say that "Ah well, 1% of the time, you'll lose" ...

Summary:  Mark, i'd appreciate it if you'd try a bit harder not to
bounce my mail.  Thanks.

/jordan

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 19:59:08 GMT
From:      MRC@PANDA.PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Braden on secondary IP addresses


     I've been in the NWG for at least 12 years, and I remember no
pronouncement that implementations *must* try all possible IP addresses.
I can think of just as many cases where it is undesirable as I can of
ones where it is desirable.

     Let's set the record straight on one thing.  The mailer in question
has no knowledge whatsoever of how to look up an address in a host table
or from a domain server.  It hasn't any notion of multi-homed hosts.  It
simply knows that it has to send a set of bits to a set of mailboxes at
a set of hosts.  The hosts are stored by name.  When the mailer attempts
to deliver a message, it does an operating system call which takes the
host name as an argument and returns a single IP address.

     Any change in IP address selection would have to be done at the
software at the other end of that system call.  One way for be for the
mailer to pass "advice" that a particular IP address has been shown to
fail.  Nobody is going to work on the host table software to do this.
The amount of work to do such a task is much more work that it would be
for Clive Dawson to upgrade his system to support domains.

     It would, I think, be relatively simple to put in such a function
into the domain software.  The only change to the mailer would be to
pass "advice"; presumably a 3 or 4 line code change.  I don't know what
sort of effort it would take to put this in the domain software.

     The question then becomes, what sort of criterion should the domain
software use beyond the current choice of "best" network, modified with
mailer "advice"?  Nobody has offered any suggestions.

     I again want to emphasize that the DEC-20 mailer does NOT "use the
first address and ignore the rest".  It has no way of knowing that any
other addresses exist; it is totally dependent upon external software
for any host information.  Don't assume that because your mailer has
internalized host table parsing routines that all mailers are written
that way.  I am a bit annoyed that the same people who are willing to
accept BITNET mailers which toss away RFC821 return path information
are quite happy to crucify software that isn't at fault.
-------

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 88 21:53:28 GMT
From:      mar@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   getting the host tables right

Recent discussion about mail problems indicates that some people have
been having problems coordinating host configuration changes.  Here
are some hints from an address change I performed a while back.

The goal was to change the address on every host in our installation,
including 2 listed in the hosttable, our domain nameserver, and our
mail hub.  We planned this a couple of months in advance.  The steps
we followed were:

1. Turn on both sets of addresses in our gateways, and use a PC
configured on the new network address to make sure we had connectivity
with the rest of the internet.

2. Notified the NIC that we were planning the change for about a month
later, and got back confirmation that they could change the hosttables
on the day we chose.  Also notified the system administrator at the
machine serving as secondary nameserver for our domain, and got
confirmation that they would be able to make the change on the correct
day.

3. Changed the timeouts in our name domain to 1 hour so that resolvers
wouldn't cache our old address for 3 days after the change.

4. A couple of days before the change we changed the sendmail.cf on
our mailhub to put:
	Notice: foo.arpa's address will be 1.2.3.4 after April 1
lines in the headers of all mail passing through.

5. We also started changing the addresses of PC's and lesser known
workstations a day early, just because it would take too long to
change everything at once.

6. On the flag day, we first checked with the NIC to see that they had
the new information.  We would have called off the change if they
hadn't done it yet.  We then changed the addresses of our well known
machines, and swapped in the new domain database.  We changed the text
of the extra header line in the message slightly.  

Since our secondary nameserver is run by a different organization at a
different site, as suggested in the RFC, hosts that had cached the old
information could still get to us.  They would be unable to contact
our primarhy nameserver at the old address, so try the secondary
nameserver (which hadn't moved) and get our new addresses from there.

7. I then monitored our gateway log for the next week to catch hosts
attempting to contact our old address.  When I spotted these, I sent
mail to the postmaster at those sites informing them of our move and
that they should get new hosttables.


The whole thing was relatively painless, with not much disruption of
service.  The flag day was on a Friday, so that caches would have a
better chance of timing out by Monday when people wanted to do work
again.  The key to the operation was planning it a couple of months in
advance, and not going from one stage to the next until we were sure
it was going to work.  If you are forced to make a change like this on
short notice, I imagine that there would be many more problems.
					-Mark

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 88 01:49:03 GMT
From:      karn@THUMPER.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Jain paper citation correction

The CUTE paper by Raj Jain that Van Jacobson referred to was actually in
the IEEE Journal on Selected Areas in Communications (aka "JSAC"), not
Transactions on Communications. The full paper title is "A Timeout-Based
Congestion Control Scheme for Window Flow-Controlled Networks". It is on
page 1162 of the October 1986 issue.

Many thanks to Van for his highly informative summary. I immediately coded
much of it into my own TCP and am now experimenting with it.

Phil

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Feb 88 7:28:41 EST
From:      "Kenneth A. Turkewitz" <turkewit@CCV.BBN.COM>
To:        Jim Chappell <vrdxhq!ms3!isns01@UMD5.UMD.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  DDN Connection Problems

Jim,
	The host "hios-pent.arpa" is a MILNET host, which is running
PSN Release 6.0, not PSN Release 7.0.
		--Ken Turkewitz
-------
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 88 02:56:08 GMT
From:      EVANSL@VTVM1.BITNET (Lyle Evans)
To:        comp.protocols.tcp-ip
Subject:   Re:  Complete FROM: field.

Amen. Besides using net capacity excessive signatures use up disk space for tho
se who store messages.

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 88 07:25:46 GMT
From:      david@ms.uky.edu (David Herron -- Resident E-mail Hack)
To:        comp.protocols.tcp-ip
Subject:   ftp hang while trying to talk to cu20b.columbia.edu

I'm experiencing some strange hangs while attempting to ftp files
from cu20b.  Specifically, the pattern is that I make the connection,
log in as anonymous and david@ms.uky.edu as the password.  Then I
start transferring some data (either a directory listing or an
actual get command) and after some short time (approximately 15K
worth of data has been transmitted) the transfer hangs and stops
doing things.

Running tcpdump to watch things and telling it to restrict itself
to the ftp port, sure enough the packets simply stop going by
after a time.

The local machines I have tried this from are an 11/750 with deuna
running mtxinu 4.3+nfs (we're one MR behind the current version),
uXavII's with DEQNA's and the same OS, Sun 3/something running 3.4,
and uVaxStation2000's with whatever the ether hardware is and
the next-to-current version of Ultrix.  Our sequent didn't
know how to reach that network so I wasn't le to try from
that machine.

Using ping, I get an response times like 250 ms at best, 2500 ms
at worst, and 600-700 avg and with packet lossage at somewhere
between 5% to 30% depending on the tides, or some other somewhat
unrelated/unknown effect.  I'm doing these transfers at night
most recently at 3AM on a saturday morning.

Our net is an ethernet attached to a proteon p4200 ip router which
is the gateway to suranet/nsfnet.  From there we go through some
gateway in wash dc (maryland?) to get to net 10.

One thing we've noticed recently on our net is something which may
be rwho related broadcast storms.  I haven't traced this down yet,
but will be doing some tracing on this in the next couple of days.
One thing I notice from ping is that occasionally there are
bursts of packets being lost and surrounding the lost packets
are long ping times.

um, some hard facts gathered with ping.  I watched for about 5 or 6
minutes just now.  Every minute like clockwork we'd experience some
packet loss, and generally for the next 20-30 seconds the ping
time would be much worse than the rest of the time.  But there was
enough variance in the details of what happened, as well as variation
in other parts of the minute, that it's not completely clear what
is happening.  I did see one extreme example in that time where
we lost about 40 packets and didn't have ANY pings come back for
about 30-40 seconds.

This does seem to be extreme lossage ... however, isn't tcp supposed
to be able to handle loss of packets and do re-transmissions?  Why
is tcp getting wedged?  Or possibly is it something in the way that ftp
works?  (I must admit that I know very little about how ftp operates
other than it runs using two tcp channels, one for data transfers
and the other for commands).

Any ideas?
-- 
<---- David Herron -- The E-Mail guy            <david@ms.uky.edu>
<---- or:                {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<----
<---- It takes more than a good memory to have good memories.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 88 12:28:41 GMT
From:      turkewit@CCV.BBN.COM ("Kenneth A. Turkewitz")
To:        comp.protocols.tcp-ip
Subject:   Re:  DDN Connection Problems


Jim,
	The host "hios-pent.arpa" is a MILNET host, which is running
PSN Release 6.0, not PSN Release 7.0.
		--Ken Turkewitz

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 88 16:37:52 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: IP security options (again)

Our PC/TCP accepts datagrams with the security option in them, and ignores
it just fine (since December 1987).  We presently have no means of setting
any options in outgoing IP datagrams.

James B. VanBokkelen
FTP Software Inc.

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 88 16:57:45 GMT
From:      dwalker@ORION.CF.UCI.EDU (David Walker)
To:        comp.protocols.tcp-ip
Subject:   tn3270 for Wollongong VAX software?

Does anyone know of a tn3270 that has been developed for the
Wollongong's WINS software?  We've heard that there is one that runs
under EUNICE, but we'd rather not have to buy the rest of the UNIX
emulation.

                                        David Walker
                                        Network Services Manager
                                        UC Irvine

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 88 19:53:13 GMT
From:      ras@blade.UUCP (R.A. Schnitzler)
To:        comp.protocols.tcp-ip
Subject:   Re: "Guidelines to write Subjects"

Of course the biggest problem with this is one we already face.  Most
messages on most (unmoderated) groups are followups.  More
specifically, for most postings, people do not do a thing to the
subject line, resulting in obsolete or uninformative subjects.  This
coding scheme would in practice, then, refer to the original message,
not necessarily the current one.

Also, I would have much preferred this topic coming up as a suggestion
("What do people think about...?" rather than an autocratic decree
"Please follow the guidelines below...."  I also resented the
implication that strict adherence to these guidelines had a direct
relationship to the intelligence of a posting.

Perhaps I missed some earlier postings that might have given a more
polite motivation to this decree.

-- 

"It's worse than that,			Ray Schnitzler
   it's physics, Jim"			Bell Communication Research  
					arpa: schnitz!bellcore.com
					uucp: ...!bellcore!schnitz

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 88 20:58:36 GMT
From:      sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp hang while trying to talk to cu20b.columbia.edu


  I'm experiencing some strange hangs while attempting to ftp files from
  cu20b.  Specifically, the pattern is that I make the connection, log
  in as anonymous and david@ms.uky.edu as the password.  Then I start
  transferring some data (either a directory listing or an actual get
  command) and after some short time (approximately 15K worth of data
  has been transmitted) the transfer hangs and stops doing things...

You are by far not the only site having this problem with FTP to CU20B.
We're getting lots of complaints about it.  Near as I can tell, what we're
doing is running out of IP free space, after which, all of our daemons get
very confused and stop working properly.  No one is really working on this
problem here because CU20B's lifetime is only a few more months, but if
anyone happens to have collected up some pertinent IP free space manager
monitor patches, and they don't look too complex to put in, I guess I'll
take a crack at them.

At least this is what I *think* is going on here...  /Ken
-------

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 88 21:03:54 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: "Standards" for PC sockets


Nothing must has come of this.  I was hoping that some group of the vendors 
would pick it up after the conference, but this has not happened and I haven't 
had the time to continue feeding the fire.

Drew

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 1988 11:17-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        CRB%NIHCUDEC.BITNET@CUNYVM.CUNY.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:   Conforming
Don't  blame  the  "DEC-VAX-11-750.ARPA" name on hostmaster.  She
was told to allow it by someone  from  my  organization.   *sigh*
I've  asked  her  to alert me the next time someone pushes a name
like this at her so I can try and prevent a repeat.

Mike

(DDN Program Office)
-------
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 88 05:21:53 GMT
From:      bzs@BU-CS.BU.EDU
To:        comp.protocols.tcp-ip
Subject:   "Guidelines to write Subjects"


Actually, I preferred the evil little editings in the political
flamage groups on USENET where subject lines like "Re: Urine testing"
became "Re: Urine tasting" and got bounced back and forth blindly...

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 88 06:26:44 GMT
From:      pavlov@hscfvax.harvard.edu (G.Pavlov)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp hang while trying to talk to cu20b.columbia.edu

In article <8377@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes:
> I'm experiencing some strange hangs while attempting to ftp files
> from cu20b.  Specifically, the pattern is that I make the connection,
> log in as anonymous and david@ms.uky.edu as the password.  Then I
> start transferring some data (either a directory listing or an
> actual get command) and after some short time (approximately 15K
> worth of data has been transmitted) the transfer hangs and stops
> doing things.

  According to the Kermit folks at Columbia, there are known problems at the
  cu20b end.  I experienced the same synptoms for several months (trying to
  get thru on a variety of machines) and finally gave up.  Used KERMSRV instead;
   
   greg pavlov, fstrf, amherst, ny

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 88 14:52:56 PST
From:      mcc@etn-wlv.eaton.com (Merton Campbell Crockett)
To:        CRB%NIHCUDEC.BITNET@cunyvm.cuny.edu, tcp-ip@sri-nic.arpa
Subject:   Re:  Conforming
If you have all your ducks in order, are really robust (no excrement out--but
accept excrement without complaint, and pass the DCA verification suite; you
could call yourself HUBBA.HUBBA.ARPA or in Robb's case TOP.GUN.MIL if the
Navy groups in San Diego haven't used it already.
-------
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 88  12:59:51 EST
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  Complete FROM:  field.
>     It might also help if the current trend of including excerpts and
> complete text of subject messages in responses wasn't so popular.  It seems
> as though messages are getting more and more verbose as time passes (please
> don't construe this to mean that I think messages contain useless input).

I like to see an excerpt from the message being responded to.  It helps
me keep track of the several threads of conversation that I am trying
to follow on multiple lists.
-------
-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 88  13:31:02  EDT
From:      "C. BACON" <CRB%NIHCUDEC.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   Conforming
Originatedby: <terry@DEC-VAX-11-750.ARPA>
OTo:      <CRB@NIHCUDEC>

Received: from NIHCU(Mailer) by NIHCUDEC(BitDae) on Thu, 18 Feb 88 10:37:26 EDT`

Received: by BYUADMIN (Mailer X1.25) id 5466; Thu, 18 Feb 88 08:32:49 MST
Date:         Tue, 16 Feb 88 07:49:08 EST
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
X-To:         tcp-ip@sri-nic.arpa


Hello All,

> Re: "From:  address of terry@dvax "

MY host administrator has changed our official sitename to match
our MILnet sitename (dec-vax-11-750.arpa).  This will cause the
"FROM" address of my mail to conform network requirements.

Seems only fair...

Terry Robb
************************************************************************
*-  Terence A. Robb                                                   -*
*-  Network Solutions                                                 -*
*-  Systems Programming Specialist                                    -*
*-  MILnet:   terry@dec-vax-11-750.arpa                               -*
*-  PHONEnet: (703) 749-1918                                          -*
*-  MAILnet:  8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180    -*
************************************************************************


Comment by C. BACON
I take it from the name that DEC-VAX-11-750.ARPA is the definitive and
authoritative gateway to all the 750s on the Internet!  You could get
just a wee bit dumber and name your site NETWORK-HOST.ARPA  (=:
--Or how about ARPA.ARPA (hostmaster could let it slip past!)
-------
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 88 18:49:44 PST
From:      Paul Mockapetris <pvm@venera.isi.edu>
To:        Mark Crispin <MRC@panda.panda.com>
Cc:        TCP-IP@sri-nic.arpa, Header-People@mc.lcs.mit.edu
Subject:   Re: Braden on secondary IP addresses
Mark, Bob,

There are real issues behind this debate, and they are 1) what are the
right policies with regard to hosts with multiple addresses and 2) where
should the policies be implemented.  It would be nice if everyone agreed
what the rules are, but the waters are pretty muddy.

There can be a large difference in performance depending on which
address you use.  My experience with domain and mail services suggests
that sometimes a host offers different services on different addresses,
and sometimes only a subset of the addresses are reachable due to
gateway, etc factors.  The bottom line is that sometimes whether you win
or lose depends on the source and/or destination address you choose.

There may always be a best address, but it isn't always possible to know
which one it is without empirical information.  I can always prefer
destination addresses which share a common network, but sometimes the
problem is "Given N non-local class C addresses, which one should I
use?"  Since the answer would seem to depend on both the identity of the
source and the identity of the destination, it doesn't seem that either
can solve the problem alone.

Its not really just a mail issue.  For example, domain resolvers
and mailers have similar options.  [A resolver has to decide (1) which
sending address to use, (2) which name server to ask, and (3) which
destination address to use when it targets a query.  A mailer has to
decide (1) which sending address to use (2) which MX RR (i.e. mail
server) to use, and (3) which destination address to use.  The parallels
continue when you think about what to do in case of errors, how you
tradeoff network resources vs local resources vs time to finish a
request, etc.  Admittedly, there are also large differences, but dealing
with multiple addresses is an issue which comes up whenever you have
such network services.]

The domain system won't solve this problem.  In fact, it will make it
worse by spreading multiple addresses in more contexts.

What we need is a consensus on policies regarding the use of multiple
addresses and single module that can be used by all applications to
implement the policies.  (Maybe we have discovered one of the missing
layers in the Internet 7 layer cake.)

paul
-------
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 88 16:25:33 GMT
From:      neerma@COD.NOSC.MIL (Merle A. Neer)
To:        comp.protocols.tcp-ip
Subject:   Need help with UNIX tcp

-------
It just occurred to me that this list may be the best
place to go for help with a problem we have been
struggling with for years.  We have been developing
client/server processes on tcp for going on ten years
and have had the unfortunate experience of having to
sometimes do it on UNIX.  The problem simply stated is
this: the user process cannot get the status of its
tcp connections from UNIX.

Yeah, we know about SIGPIPE but it only works sometimes.

What I'm really concerned about is that so many other
implementations of tcp seem to be derived directly from
the UNIX bsd versions of tcp.  They in turn inherit the
deep dark mysteriousness of the status of connects.

Have any UNIX guru-types ever considered offering a
'status(myconnect)' call?  We'll gladly pay for one.
Or even just a 'signal(YOURCONNECTISBOGUS,letmeknow)'
would be nice?

I would like also to hear from other unfortunate souls
that have to program on UNIX tcp to see how they have
dealt with this problem.

Yes, we have worshipped at the UNIX altar long enough to
deserve some secrets. Just a few.

Merle Neer
neerma@nosc
-------

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 88 16:32:05 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: IP security options (again)

My IP should also correctly ignore any options it doesn't
understand.  I've never seen a datagram with options, so I can't
confirm this for sure, but the code looks right...

Phil

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 88 17:31:02 GMT
From:      CRB@NIHCUDEC.BITNET ("C. BACON")
To:        comp.protocols.tcp-ip
Subject:   Conforming

Originatedby: <terry@DEC-VAX-11-750.ARPA>
OTo:      <CRB@NIHCUDEC>

Received: from NIHCU(Mailer) by NIHCUDEC(BitDae) on Thu, 18 Feb 88 10:37:26 EDT`

Received: by BYUADMIN (Mailer X1.25) id 5466; Thu, 18 Feb 88 08:32:49 MST
Date:         Tue, 16 Feb 88 07:49:08 EST
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
X-To:         tcp-ip@sri-nic.arpa


Hello All,

> Re: "From:  address of terry@dvax "

MY host administrator has changed our official sitename to match
our MILnet sitename (dec-vax-11-750.arpa).  This will cause the
"FROM" address of my mail to conform network requirements.

Seems only fair...

Terry Robb
************************************************************************
*-  Terence A. Robb                                                   -*
*-  Network Solutions                                                 -*
*-  Systems Programming Specialist                                    -*
*-  MILnet:   terry@dec-vax-11-750.arpa                               -*
*-  PHONEnet: (703) 749-1918                                          -*
*-  MAILnet:  8229 Boone Blvd., 7th Floor, Vienna, Virginia, 22180    -*
************************************************************************


Comment by C. BACON
I take it from the name that DEC-VAX-11-750.ARPA is the definitive and
authoritative gateway to all the 750s on the Internet!  You could get
just a wee bit dumber and name your site NETWORK-HOST.ARPA  (=:
--Or how about ARPA.ARPA (hostmaster could let it slip past!)

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 88 17:36:04 GMT
From:      robert@richp1.UUCP (Robert Miller)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: TCP/IP <-> SNA gateway products

Having trouble with mail to Ron Natalie:
Warning From uucp
We have been unable to contact machine 'ucbvax' since you queued your job.
	ucbvax!mail topaz.rutgers.edu!ron   (Date 02/16)

#############################################
##### Data File: ############################
>From richp1!robert  Tue Feb 16 04:35:36 1988 remote from ihnp4
Received: by ihnp4.ATT.COM id AA15074; 16 Feb 88 04:35:36 CST (Tue)
Received: by richp1.UUCP (smail2.5)
	id AA23845; 15 Feb 88 08:40:40 CST (Mon)
From: ihnp4!laidbak!spl1!richp1!robert
To: laidbak!ihnp4!ucbvax!topaz.rutgers.edu!ron (Ron Natalie)
Subject:  Re: TCP/IP <-> SNA gateway products
Message-Id: <8802150840.AA23845@richp1.UUCP>
Date: 15 Feb 88 08:40:40 CST (Mon)


>Do they (Bridge CS-1/SNA) allow you to define new terminals and keyboard
>maps yet?  This is the main reason why we panned them.
 
>-Ron

The Bridge CS/1-SNA will not allow you to define new terminals.
The sysgen menu does allow you to select, for each virtual circuit,
one of 17 pre-defined terminals or just display a terminal menu and
let the user select.  Keyboard mapping is two things.  The sysgen
menu has changed from asking you to select a character set of a
particular country or language to providing EBCDIC/ASCII and
ASCII/EBCDIC translation tables you can tailor to your needs.  In
addition to this, my company modified the telnet command to make
use of an external (to the CS/1-SNA) keymap file.  This was
accomplished with assistance from Bridge Communications.  Our
CS/1-SNA is sysgen'ed to always appear as a VT100 terminal.  Since
my company makes its own keyboards, we customize the keymap file to
map our keyboards to the VT100.  This is working great.

Robert Miller


-- 
.......................................
"To open, cut along dotted line."  ....:.......................................
                                  :     :  Robert Miller @ ihnp4!richp1!robert
                                   .....

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 88 17:59:51 GMT
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  Complete FROM:  field.

>     It might also help if the current trend of including excerpts and
> complete text of subject messages in responses wasn't so popular.  It seems
> as though messages are getting more and more verbose as time passes (please
> don't construe this to mean that I think messages contain useless input).

I like to see an excerpt from the message being responded to.  It helps
me keep track of the several threads of conversation that I am trying
to follow on multiple lists.

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 88 18:50:00 GMT
From:      WWB.TYM@OFFICE-1.ARPA (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp hang while trying to talk to cu20b.columbia.edu

Readers not interested in the guts of TCP implementation might as well skip 
this message.

I've had to muck about with Tenex TCP which is "related" to TOPS-20 TCP, and 
has much worse constraints with buffer space due to being part of a single 
section monitor.  Some of what I've done to try to cope with free storage 
problems may be relevant to your monitor, but only you can tell for sure.  I 
think there must be a jillion locally-hacked subflavors of this TCP code, and 
who knows how much resemblance remains between yours and mine.  I can say that 
I do have a copy of "DEC's source" as of about 2.5 years ago and it seems to 
have the same problems which I'm about to describe, so maybe you have them too.

Refer to the TCP packetizer near PKTZ10 (in source file TCPPZ or TCPTCP).  The 
call on TCPIPK will nonskip-return if you are indeed out of space.  Code in a 
literal tries to queue you to retry but as I understand the code, there's a 
problem.  Your TCB is not queued anywhere at this instant, but TSFP or TSEP is 
very probably on (else why are you here?)  So ENCPKT and/or DLAYPZ will 
effectively no-op and you're out of the packetizer without being queued 
anywhere.  Any future Force or Encourage will meet the same fate because of 
those same bits.  You're trapped in the Twilight Zone.  Cure: SETZRO 
<TSFP,TSEP>,(TCB) as the first thing in the literal that calls ENCPKT after 
TCPIPK failure.  If this scenario happened, it would be likely to yield the 
symptoms described by David Herron; but so might other things.

I made several changes to TCPPRC routine, a little too long to list here.  
Basically they are: not to run a free-storage scavenge more than once a second,
so as not to hog the CPU; and don't run TVTOPR on any pass that did a scavenge,
in hopes of making fewer and bigger Telnet packets.

It's better to avoid running out of space in the first place, even if that 
takes something drastic.  With an 1822 interface it's absolutely crucial not to
let the input interrupt level run out of buffers, so as to avoid RFNM-related 
deadlocks.  Solution: Never give Internet the "last" input buffer.  Put it back
on the input buffer list after processing the 1822 leader.  I suspect this 
isn't your problem though, since your addresses are class B/C, thus probably 
not 1822.

It would help to have some idea of what most of your space is being used for 
when you run out.  Absent specific data, I'd suspect huge retransmit queues 
caused by big windows and slow gateways between you and the FTPers.  You can 
brute-force cope with this somewhat either by clamping received windows, or by 
finagling the packetizer to refuse to packetize for any connection that has 
more than n packets on the RX queue, or where the first packet on the RX queue 
has actually been retransmitted (a quick test for congestion).  This will slow 
things down, but that's what you need to do when you're short of space.  You 
can condition this code on INTFSP being less than some threshold and shove it 
into the PKTZ10 area too.

If you have a lot of TVT (Telnet) tinygram traffic, you might want to add code 
in this same area to ask TCPIPK for only the size of buffer you need, rather 
than a max size buffer, when space is below the threshold.  Also in the OPSCAN 
routine (TTTVDV or TTANDV source file?) around OPSCA1+10 or so, just after the 
JUMPE T3,OPSCA7 you might add JN TSEP,(TCB),OPSCA7 which will prevent this 
routine from undoing any delay previously imposed by some other routine.  
Further down in this same routine you should also have a change published by 
Westfield and Crispin about 2-3 years ago which includes a test on whether the 
RX queue is empty.  This change is mainly performance-oriented but will save 
free storage too in some situations.

These cover the highlights of things I've done that seem relevant.  You can 
talk bits with me further if you're interested, of course.  I wanted to post 
this much in case it stirs up any comments from TOPS-20 hackers out there.  
Maybe someone out there has already done these changes in a form that will 
slide directly into CU20B monitor.  -b

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 88 19:17:00 GMT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:   Conforming

Don't  blame  the  "DEC-VAX-11-750.ARPA" name on hostmaster.  She
was told to allow it by someone  from  my  organization.   *sigh*
I've  asked  her  to alert me the next time someone pushes a name
like this at her so I can try and prevent a repeat.

Mike

(DDN Program Office)

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 88 20:30:26 GMT
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP, X.25 and ISO products

Many of you are probably interested in tracking the development of ISO
products since the DoD announcement to support ISO.  The Defense Data
Network (DDN) document, the "DDN Protocol Implementations and Vendors
Guide", produced by the DDN Network Information Center (NIC), contains
product descriptions of TCP/IP, X.25 and ISO products.  It is being
updated for release at the end of the month.

For those of you who are fairly new to the network, this document is a
guide to implementations and products associated with the DDN suite of
data communications protocols.  It is published for informational
purposes only.  Although inclusion does not constitute an endorsement
on behalf of DoD, the product descriptions may help you to locate
useful products or implementations.  To assist with the network's
transition to ISO protocols, we are making every attempt to include
descriptions of ISO-based products.

Over the last few months many vendors have been letting us know about
their TCP/IP and ISO product line.  If you know of any work being done
in support of TCP/IP, ISO, or X.25 that you would like to see listed
in this guide, please let the NIC know.  For your convenience, we
developed an online template for easily filling out the type of
information we are seeking.  The template is on the SRI-NIC.ARPA host
in the file NETINFO:VENDORS-TEMPLATE.TXT and may be FTPed or obtained
through SERVICE, the NIC's automatic mail service.  For instructions
or questions about any of the above, contact NIC@SRI-NIC.ARPA or call
us at 1-800-235-3155 or 415-859-3695.

-Francine Perillo  /DDN NIC
-------

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 1988 06:21-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        sra@MITRE-BEDFORD.ARPA
Cc:        LYNCH@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Life in the Swamps / Testing
Stan, the reason no one has done this (and it has crossed my mind
more than once) is that is leaves them liable  to  a  law  suite.
Without  some  sort of *formal* testing procedure, with objective
results, a vendor could sue and most probably win if I got up and
said  its product didn't work.  Unfortunately, passing the formal
testing is no guarantee of being able to interoperate.

We could start holding the internet bake-offs as an annual  event
and  publish  a  matrix  of who could talk to who and the type of
performance we saw.  And we  could  also  publish  which  vendors
declined to compete.  Comments?

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 1988 10:41 EST
From:      Charles Jerian <cpj@citi.umich.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   a ping with record route
A ping that works tolerably well with record route is
on citi.umich.edu 35.1.128.16 via anonymous ftp in
pub/ping.tar.Z  It works on 4.3 systems like RT's and
on a vax running ultrix with some kernel changes.   It crashes
a vax running stock ultrix.
Suns drop RR packets.  It used to work for me to arpa sites running
dec-10s but now that my arpa path goes to psc-gw instead of terp,
it has stopped working for me.
Various machines do different things with record route.  
Fuzzs turn them around but don't record their presence,
protogaters and 4.3 systems record their presence but don't turn
them around.  Kinetics boxes turn them around.  HP/UX turns them around.
Mailbridges don't turn them around or record their presence.
-------
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Feb 88 14:08:10 PST
From:      braden@venera.isi.edu
To:        LYNCH@a.isi.edu
Cc:        STJOHNS@sri-nic.arpa, sra@mitre-bedford.arpa, tcp-ip@sri-nic.arpa
Subject:   Re: Life in the Swamps / Testing

	Testing a "network" product is just a lot harder because you have
	the end systems and the network(s) all wrapped up in some kind
	of non deterministic swamp.  And we are asking for a "rating" or
	a pass/fail grade?  Or what?  

Dan,

   Neither of these seems very useful. What we really need for each
   product is a list of its deficiencies, bonuses, and "features" (things
   that cannot be classified as either - or +).

   There is a pretty well-known list of deficiencies -- ie failure to
   meet the written/commonly-accepted specification.  E.g., a host that
   cannot handle subnetting, a host that does not act on redirects, a
   host that does not timeout or somehow remove stale redirect
   information, a host that bombs when it receives an X for some value of
   X, a host that cannot switch to an alternative gateway when the one it
   is using fails, a host that cannot be multihomed, etc, etc., etc.  Or,
   a gateway that does not implement IP option Y for some value of Y, a
   gateway that cannot send redirects, a gateway that has no provision
   for sending Source Quench, etc., etc.  Or, a TCP that does not follow
   the retransmission guidelines that (we hope) will be published as a
   result of Van Jacobson's work.

   I think you get the idea.  The point is that there are qualitative
   (algorithmic) features that are the most important to the survival/
   success of the Internet.  If a host implementation included every
   single wonderful thing except subnetting, it might get a good
   "score"; yet it still has a grievous deficiency that needs to get
   fixed.
   
   Bob  Braden
   
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Feb 88 11:41:07 EST
From:      "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Life in the Swamps / Testing
I like Mike's idea of a bakeoff, but a list wouldn't bother us either
(as long as it was kept current, and some effort was made to let people
know when it was updated).  We try fairly hard to keep our code nicely
fixed up, and I think we would benefit (as well as the Internet community)
from any public effort that let the world know the gory details.

One problem with a bakeoff is that there are a number of fairly large
TCP vendors who aren't on the Internet, and so they'd have to have a
proxy site, if they chose to participate at all.

Regarding lawsuits, I don't think vendor X would have a leg to stand on
if someone said "Vendor X's product Y, in version Z, does not support
IP subnets as described in RFC 950", or "...is shipped with a sendmail.cf
that causes them to not terminate SMTP commands with CR LF".

James B. VanBokkelen
FTP Software Inc.

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Feb 88 11:45:42 EST
From:      H. Craig McKee <mckee@mitre.arpa>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Life in the Swamps / Testing
Mike StJohns notes:

>We could start holding the internet bake-offs as an annual  event
>and  publish  a  matrix  of who could talk to who and the type of
>performance we saw.  And we  could  also  publish  which  vendors
>declined to compete.  Comments?

I'd like to hear from the Corporation for Open Systems.
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Feb 88 12:20:24 EST
From:      Doug Montgomery <dougm@icst-osi.arpa>
To:        iso@nrtc.northrop.COM, satz@clash.cisco.com, tcp-ip@sri-nic.ARPA
Subject:   Re:  X.25 Call User Data for higher level protocols

Greg,

The reference you are looking for is "PDTR 9577: Protocol Identification in
the OSI Network Layer".  This proposed draft technical report contains a
description of the means used to identify network layer protocols/services and
where such information is located in a protocol.  The document also
provides a record of those values of protocol identifiers which have been
used by various authorities.  An annex of the PDTR decribes the location
and use of protocol identifiers in X.25.  

The source of the document is ISO/TC 97/SC 6/WG 2.  If you can't get
your hands on it elsewhere drop a note and I'll send you a copy.

+------------------------------------------------------------+
| Doug Montgomery                        dougm@icst-osi.arpa |
| National Bureau of Standards                               |
| Technology Building, B217              (301) 975-3630      |
| Giathersburg, MD 20899                 TELEX: 89-8493      |
+------------------------------------------------------------+
-------
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Fri 19 Feb 88 16:10:06-EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        STJOHNS@SRI-NIC.ARPA
Cc:        sra@MITRE-BEDFORD.ARPA, tcp-ip@SRI-NIC.ARPA, lynch@A.ISI.EDU
Subject:   Re: Life in the Swamps / Testing
Mike,  We all see product reviews in many of the trade magazines for
PC software and hardware.  The reviews vary as the products vary.  I've
never heard of a lawsuit stemming from one.  But I do see retractions
and clarifications!  But that is for testing PC level products.
Testing a "network" product is just a lot harder because you have
the end systems and the network(s) all wrapped up in some kind
of non deterministic swamp.  And we are asking for a "rating" or
a pass/fail grade?  Or what?  
I tried to get the "serious vendors" to establish a permanent 
"interoperability demonstration center" starting about a year ago.
It never flew because the costs are high and after you get it up
and running and the "score cards" are in, who needs to keep
running it all the time?  So, we are going to do it on a temporary
basis at the next TCP/IP Interoperability conference.  It will still cost
a bundle to put it all together, but it will give the "serious vendors"
a chance to show how well their products interoperate against the others.
I don't know where this activity will lead, but I do know that something 
like this has to happen if we are ever to get lots of the nagging bugs out.
Vendors will be given a list of "known bugs" and be warned to not bring
them along or the whole world will know how far behind they are.  On the
positive side, those vendors who show off well will get the publicity
that should enable them to sell more product to those who are trying to buy
effective solutions.

Dan
-------
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Feb 88 16:46:26 EST
From:      terry@DEC-VAX-11-750.ARPA
To:        tcp-ip@sri-nic.arpa
Cc:        terry@vax1.arpa
Subject:   Re: Data Acceptance Algorithms
I wish to thank those persons who sent me mail in response
to my "in-window" vs "in-order" algorithm question.

All of the responses recommended "in-window".  Those who said they have a
TCP using "in-order" wished they had "in-window".

The results were not surprising.  I must confess I was really more
interested in the statistics concerning out-of-order packets which
accompanied many of the responses.

When the mail finishes coming in (33 messages last count), I will
combine the statistics with those I have collected and post the results.

Thanks Again....         Terry "top gun" Robb
-------
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 88 12:59:52 GMT
From:      sra@MITRE-BEDFORD.ARPA (Stan Ames)
To:        comp.protocols.tcp-ip
Subject:   Re: Life in the Swamps / Testing

Dan

It has been bad enough that existing vendors have not seen fit to fix
such simple things as using the correct IP broadcast address.
What I see as troubling is that entirely new products are perpetuating
the problem.  Perhaps the emerging ISO vendors will learn from our mistake
and control products that claim to implement the protocols but have taken
creative interpretations.

Perhaps it is time for the internet group to list vendors that implement
the protocols correctly and also publish a list of those that do not.

Stan Ames

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 88 13:50:10 GMT
From:      galbp!gja@gatech.edu  (Greg Ansley)
To:        tcp-ip@sri-nic.arpa
Subject:   SLIP (what & where??)
< Line eater food >

I know this has been asked before recently but it wasn't important to 
me at the time ! :-)

A need a discription of SLIP, what it is and what it can do as well as 
a pointer to where I can get the code!

Please reply be mail so as not to bore the rest of the net!

Thanks,
Greg Ansley                         gja@galbp.LBP.HARRIS.COM
Harris/Lanier, Atlanta, GA          ...!gatech!galbp!gja
(404) 329-8200


-- 
Thanks,
Greg Ansley                         gja@galbp.LBP.HARRIS.COM
Harris/Lanier, Atlanta, GA          ...!gatech!galbp!gja
(404) 329-8200
-------
-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 88 14:21:00 GMT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Life in the Swamps / Testing

Stan, the reason no one has done this (and it has crossed my mind
more than once) is that is leaves them liable  to  a  law  suite.
Without  some  sort of *formal* testing procedure, with objective
results, a vendor could sue and most probably win if I got up and
said  its product didn't work.  Unfortunately, passing the formal
testing is no guarantee of being able to interoperate.

We could start holding the internet bake-offs as an annual  event
and  publish  a  matrix  of who could talk to who and the type of
performance we saw.  And we  could  also  publish  which  vendors
declined to compete.  Comments?

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 88 14:34:04 GMT
From:      lyle%asbi-sid.huachuca-em.arpa@HUACHUCA-EM.ARPA (Lyle Johnson)
To:        comp.protocols.tcp-ip
Subject:   MMDF E-MAIL Systems



I am attempting to find information on the MMDF E-MAIL package.  I especially
need information on who developed it and what organization they worked for at
the time.  I need information on contractual and legal aspects of the
development as well as the subsequent distribution rights.  I would like to
know who in fact has distribution rights to MMDF and who owns the source code,
and who is now responsible for software maintenance.

Please address any comments to:

LYLE%ASBI-SID@HUACHUCA-EM.ARPA

Thank you for any help you can give me.

Lyle Johnson

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 88 15:12:50 GMT
From:      jqj@uoregon.UUCP (JQ Johnson)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   KA9Q as an IP router?

Has anyone made any serious effort to use a PC with two Ethernet
interfaces as an IP router?  My impression is that the KA9Q code
is about 95% there to make this possible.  Such a beast would be
very nice if possible, since current commercial routers (CISCO,
Proteon, Bridge, etc.) all cost in the $9K or more range; one
could configure a 12MHz PC-AT clone with disk, memory, 2 Ethernets,
etc. for substantially under $2K.  One would not expect performance
to be comparable to that of a P4200 or CISCO, but for some
applications that would not be a problem.

My questions:
1/ is anyone actually doing this?  What sorts of packet forwarding
   rates do you get on what hardware?
2/ what are the current limitations on the KA9Q code that make
   this idea unfeasible?  I haven't looked at KA9Q in a while;
   does a current version have (1) support for any Ethernet I/F
   except 3C501?  (2) packet frag/reassembly?  (3) support for
   a range of routing protocols (RIP, HELO, EGP)?  (4) all the
   other things RFC1009 says a gateway has to do properly?
3/ has anyone considered doing this based on one of the other
   IP implementations for the PC?
4/ Is there any commercial product I've missed that provides a
   cheap (under $5K) moderate-performance IP router?

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 1988 23:15-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        JBVB@AI.AI.MIT.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Life in the Swamps / Testing
"Regarding lawsuits, ..."

You  are  right, under the circumstances you described, where you
can objectively state "facts" like  vendor  w  doesn't  implement
subnets.   Unfortunately, on the net we get things like "vendor y
has  poor  performance  when  talking  to  anyone  but  vendor  y
products"  Or  "vendor  z  has  a  garbage implementation".  I.e.
difficult to quantify things.  And difficult to prove  in  court.
Saying  those  things  without  the facts to back thme up is very
dangerous, especially when coming from a *official*  organization
as  it  can  lead  to  a  loss of business for the vendor and the
vendor trying to recoup by suing the person  or  org  who  ruined
their business.

Mike
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 88 16:02:27 GMT
From:      morgan@brambo.UUCP (Morgan W. Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI and Sockets

} Now, if you question really was: "I have a program written to use
} Berkeley sockets but I want to run it on a SVR3 machine which only
} has streams, what can I do?"  Then the answer is that some people
} who are "heavy into Streams/TLI" have written libraries on top of
} TLI which make it look like sockets.  

Does anyone know where a copy of these can be obtained (and don't say
anonymous FTP)?  Have they been posted to the net somewhere?

-- 
Morgan Jones - Bramalea Software Inc.        morgan@brambo.UUCP
      ...!{uunet!mnetor!lsuc!ncrcan, utgpu!telly}!brambo!morgan
"These might not even be my opinions, let alone anyone else's."

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 88 18:52:23 GMT
From:      rminnich@udel.EDU (Ron Minnich)
To:        comp.protocols.tcp-ip
Subject:   DDCMP for Unix

It never fails. Somebody posted an article about DDCMP for Unix
here a few days ago, and after the article was expired someone 
here asked me if i knew of a ddcmp for unix. Can anybody who
can point me at such a beast please send e-mail? Thanks?
ron
-- 
ron (rminnich@udel.edu)

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Feb 88 10:42:05 EST
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   Where is the KA9Q TCP?
I know this was on the list recently, but who/where can I get the packet Radio
TCP/IP from?

Also, while you are reading, who/where do I go at UCB to get the Unix/BSD
sources? (I have a valid AT&T Unix Source Licence).

Thanks
Frank Kastenholz
Atex Inc.

p.s. I suggest that responses be sent direct to me - no need to clutter the
net.
-------
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 88 07:03:40 GMT
From:      david@ms.uky.edu (David Herron -- Resident E-mail Hack)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: KA9Q as an IP router?

I am tentatively planning on building a gateway this summer using a
pc/at and a couple of ether cards and the software you were
suggesting.  I seem to recall, however, there being various pieces of
PD gateway software available -- for instance, the BRL gateway code.
Where/how could I get my hands on that?

A gateway for a couple thou' is very tempting


-- 
<---- David Herron -- The E-Mail guy            <david@ms.uky.edu>
<---- or:                {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<----
<---- It takes more than a good memory to have good memories.

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 88 15:42:05 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Where is the KA9Q TCP?

I know this was on the list recently, but who/where can I get the packet Radio
TCP/IP from?

Also, while you are reading, who/where do I go at UCB to get the Unix/BSD
sources? (I have a valid AT&T Unix Source Licence).

Thanks
Frank Kastenholz
Atex Inc.

p.s. I suggest that responses be sent direct to me - no need to clutter the
net.

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 1988 10:13-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP security options (again)
Umm...   the  security option is *COPIED* upon fragmentation.  Or
is supposed to be copied.  Check the documentation.  Mike
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 88 05:17:22 GMT
From:      bc@halley.UUCP (Bill Crews)
To:        comp.protocols.tcp-ip
Subject:   Re: "Guidelines to write Subjects"

In article <958@blade.UUCP> ras@blade.UUCP (R.A. Schnitzler) writes:
>Of course the biggest problem with this is one we already face.  Most
>messages on most (unmoderated) groups are followups.  More
>specifically, for most postings, people do not do a thing to the
>subject line, resulting in obsolete or uninformative subjects.  This
>coding scheme would in practice, then, refer to the original message,
>not necessarily the current one.

This discussion is all very informative, I guess, but I wonder who had the
eNORmous imagination to choose comp.protocols.tcp-ip for this subject.  A bad
choice of newsgroup FAR outweighs any consideration of exact syntax.

People, let us just let this drop.  If someone must discuss this, how about
news.misc or somewhere like that?  Please do not follow up to this message.
Over and out.

-bc
-- 
Bill Crews                                   Tandem Computers
bc@halley.UUCP                               Austin, Texas
..!rutgers!im4u!halley!bc                    (512) 244-8350

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 1988 14:37-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP security options (again)
The  new  RFC  is  out.   Check  the index.  Its been out about a
month.  BUT...  contrary to what the document says, it  is  still
not the final form.  Specifically, the IDs for the various levels
are changing to spread out the coding.  *sigh* I'll try and  keep
you  posted  as I find out the contortions the BLACKER people are
twisting the IPSO into.  Mike
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 88 17:33:16 GMT
From:      tucker%vger@GSWD-VMS.GOULD.COM (Tim Tucker)
To:        comp.protocols.tcp-ip
Subject:   IP security options (again)

We have found that any system using 4.3 BSD TCP/IP code can't handle the IP
security option.  The reason follows.  If you fragment a packet with the
IP security option, the option should only appear in the first fragment.  On
BSD 4.3 systems this is done correctly, but the IP header in the second or
more fragments is too long!  The option is removed correctly, but the IP header
size is not adjusted.  This bug causes fragmented packets with the IP security
option to be dropped in reassembly.  A big bug, since most people using
the option are connected to a link like the ARPAnet thru ethernet.

Tim Tucker
tucker@claudius.Gould.COM

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 88 18:13:00 GMT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: IP security options (again)

Umm...   the  security option is *COPIED* upon fragmentation.  Or
is supposed to be copied.  Check the documentation.  Mike

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 88 18:16:46 GMT
From:      rochester!ritcv!cci632!ccicpg!arnold!dave@cu-arpa.cs.cornell.edu  (Dave Arnold)
To:        tcp-ip@sri-nic.arpa
Subject:   Network Interface Working Group
In a previous posting, I asked a question regarding standard C-binding
network interfaces, and any work currently in progress on the
subject.  Following is what I considered to be the definitive
repsonse.

=======================================================================
From: <uunet!likewise!attunix!sfdic!ssa>
Posted-Date: Tue, 26 Jan 88 10:29:34 est
To: vdelta!dave
Subject: Re:  /usr/group Network Interface Working Group
Status: R

Dave,
	I have good news and bad news for you.  Luckily, most of it
is good.  First of all, I am the right person to contact.  I've been
chairing the committee for a little over a year now.  Unfortunately,
we have not made a tremendous amount of progress for various
reasons.
The interface that you proposed is exactly what I am personally shooting
for.  The committee's goal is to propose an interface that is source
code portable across POSIX-conforming systems.  To do this, we classified
networking applications into 3 catagories:

1) sophisticated - an application that knows it is running on a network
	and makes use of protocol or network-specific features (we do
	not address this type of application - it is inherently non-
	portable)
2) knowledgeable - an application that knows it is running on a network
	but does NOT make any use of protocol or network-specific
	features (in other words, it really wants a "reliable" bit pipe).
	We are working on this type of application first.
3) naive - an application that does not know that it is running over
	a network (e.g. a cat process that has its output directed to a
	network device).  We deferred dealing with this type of
	application until we finish the knowledgeable application.

It took a fair amount of time to define the problem as stated above.
At our last meeting, one of the members volunteered to write a proposal
off-line to present at the next meeting in Dallas on Feb. 8&9.
This proposal (nor any other) has not been approved yet.

Anyhow, to obtain our documents, you should call the /usr/group office at
408-986-8840 and ask for whichever documents your interested.
The complete list is:

NI-86-001 A Comparison of Sockets and the Transport Library Interface
NI-86-002 Palo Alto Meeting Minutes
NI-87-001 Portable Network Interface
NI-87-002 Washington D.C. Meeting Minutes
NI-87-003 Toronto Meeting Minutes
NI-87-004 POSIX Portable Network Interface (PNI) Issues Pertinant(sic) to
		Definition of a Theory of Operation
NI-87-005 Seattle Meeting Minutes
NI-87-006 Nashua Meeting Minutes
NI-87-007 Proposal for a POSIX Portable Network Interface (PNI) Definition

If you have any trouble obtaining any of them, let me know.  If you would
like, I can add you to our mailing list so you can obtain everything
as it is written.  Of course, you are also welcome to attend our meetings.
They are completely open; all that you have to do is be there.
Another note of interest is that we have had a newsgroup
(usrgroup.netinter) established for us to stimulate discussion.
Unfortunately, that group is not being fed into my machine at the moment,
so I have no idea what, if anything, has been posted.

If you have more specific questions, feel free to contact me.
BTW, if you didn't get the implication above, the bad news is that the
interface is not even close to being a standard, so if you had hoped to
use it in a soon-to-be-released product, it won't be there.  The good
news is that the work is underway and that you can help shape the
standard.

	Steve Albert
	AT&T
	190 River Road
	Room A-114
	Summit, NJ 07901
	(201)-522-6104
	...!attunix!ssa

-- 
Dave Arnold
dave@arnold.UUCP	{cci632|uunet}!ccicpg!arnold!dave
-------
-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 88 19:39:41 GMT
From:      tucker%vger@GSWD-VMS.GOULD.COM (Tim Tucker)
To:        comp.protocols.tcp-ip
Subject:   Re: IP security options (again)

> Umm...   the  security option is *COPIED* upon fragmentation.  Or
> is supposed to be copied.  Check the documentation.  Mike

Ok, your correct.  I guess I should say that the problem with the Berkeley
code is that it doesn't fragment packets correctly containing IP options
that don't get copied to all fragments.

By the way, anyone know when the new IP security option RFC will be out?

Tim Tucker
tucker@claudius.Gould.COM

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 88 21:41:16 GMT
From:      gross@GATEWAY.MITRE.ORG (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re:  X.25 Call User Data for higher level protocols

Doug,

I would like to get a copy of that document.  My version is at least
a year old.  If you are coming to the IETF meeting in a couple weeks,
why don't you bring a few extra copies?

Thanks,
Phill

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 88 22:37:00 GMT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: IP security options (again)

The  new  RFC  is  out.   Check  the index.  Its been out about a
month.  BUT...  contrary to what the document says, it  is  still
not the final form.  Specifically, the IDs for the various levels
are changing to spread out the coding.  *sigh* I'll try and  keep
you  posted  as I find out the contortions the BLACKER people are
twisting the IPSO into.  Mike

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 88 05:42:49 GMT
From:      johnr@intro.oz (John Andrew Rosauer [Network])
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   NFS for Macintoshes?

We have a thin Ethernet running through our building (and effectively
throughout the University) with IP running on top of this.
We run telnet, ftp and NFS on our UNIX boxes and our PCs (using SUN's
PC-NFS).
It would be nice to include Macintoshes (the standard ones, not Mac IIs)
into this network. I have seen lots of gateways to tcp/ip which
give you telnet and ftp but not NFS. Does anyone know if such products
exist and what are the hardware requirements? I am particularly interested
in solutions for an Ethernet card for a MAC SE and for the Kinetics
AppleTalk/Ethernet-tcp/ip gateway.

Thanks in advance.
________________________________________________________________________________
John Andrew Rosauer		ISD:	+61 2 692 3495
Network Group			ACSnet:	johnr@fibro.ucc.su.oz (also CSNET)
University Computing Service	ARPA:	johnr%fibro.ucc.su.oz@uunet.uu.net
University of Sydney. NSW 2008.	UUCP:	{enea,hplabs,mcvax,uunet,ubc-vision, \
AUSTRALIA.				prlb2,ukc}!munnari!fibro.ucc.su.oz!johnr

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Feb 88 15:01:51 -0500
From:      Andy Malis <malis@OAKLAND.BBN.COM>
To:        Jim Chappell <vrdxhq!ms3!isns01@UMD5.UMD.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, malis@OAKLAND.BBN.COM
Subject:   Re: DDN Connection Problems
Jim,

As Ken Turkewitz already pointed out, your host is on the MILNET,
which is using PSN 6.0.

If this helps, when my local host ran ULTRIX 1.2 (based upon 4.2
BSD), and its PSN was down following a power failure, it would
also type out the "No buffer space available" message.  When the
PSN came back up, the messages went away.

So this may just be the same problem - when you are receiving
these messages, your host's PSN is probably down.   You should
check this with the Milnet MC at (202) 692-5726.

Andy
-------
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 88 17:08:58 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: IP security options (again)



The IP Security Option must be copied into every fragment of an IP-fragmented
datagram.

		RFC-791 page 18, MIL-STD-1778 page 36, RFC-1038 page 2

--jon.

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 88 19:04:22 GMT
From:      kleonard@PRC.Unisys.COM (Ken Leonard --> kleonard@gvlv2@prc.unisys.com)
To:        comp.protocols.tcp-ip
Subject:   Re: Life in the Swamps / Testing

In article <[SRI-NIC.ARPA]Fri,.19.Feb.88.06:21:34.PST.STJOHNS> STJOHNS@SRI-NIC.ARPA writes:
>...
>more than once) is that is leaves them liable  to  a  law  suite [sic].
>...
>results, a vendor could sue and most probably win if I got up and
>said  its product didn't work.  Unfortunately, passing the formal
>testing is no guarantee of being able to interoperate.
>...

Which is why the DCA/NBS "ProtoLab NVLAP" program needs our support.  The
output from a ProtoLab test suite of a protocol implementation IS NOT JUST
a good/nogood tag;  it is a COMPLETE and TRACEABLE standard-compliance
report.  Which means that any potential user can evaluate, in light of
OWN/REAL/ACCEPTABLE/NECESSARY task to be accomplished, whether or
not to buy a particular implementation.

And, properly done, the ProtoLab results show a HECK OF A LOT about the
chances of interoperability, too.

Regardz,                                     [Engineering:  The Art of Science]
Ken Leonard
---                                                                         ---
This represents neither my employer's opinion nor my own:  It's just something
I overheard in a low-class bar down by the docks.

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 88 20:01:51 GMT
From:      malis@OAKLAND.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: DDN Connection Problems

Jim,

As Ken Turkewitz already pointed out, your host is on the MILNET,
which is using PSN 6.0.

If this helps, when my local host ran ULTRIX 1.2 (based upon 4.2
BSD), and its PSN was down following a power failure, it would
also type out the "No buffer space available" message.  When the
PSN came back up, the messages went away.

So this may just be the same problem - when you are receiving
these messages, your host's PSN is probably down.   You should
check this with the Milnet MC at (202) 692-5726.

Andy

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 88 20:51:03 GMT
From:      jerry@oliveb.olivetti.com (Jerry Aguirre)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: KA9Q as an IP router?

The 3C501 ethernet interface supported by the KA9Q sofware will never
make a high performance gateway.  It has only one buffer and drops
packets sent too close together or while it is transmitting.

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 88 11:19 CST
From:      <GREG%FNALNET.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   CMU package
I have just installed the CMU TCP/IP package on several Microvax'en and am
experienced a strange Telnet situation. The DEC TPU editor screen and cursor
functions do not work properly if the terminal is defined as device=VT200, but
work if defined as device=VT100.

Have I done somthing wrong?

Is this a known or documented bug (feature)?

Have any of you experienced this as well?


Thanks,
Greg Chartrand - Fermilab

P.O. Box 500 - Batavia, Il. 60510
(312) 840-3727
GREG@FNAL.BITNET or GREG%FNAL.HEPNET@LBL.ARPA
-------
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 88 05:39:37 GMT
From:      van@LBL-CSAM.ARPA (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   more on tcp congestion control

Phil -

Thanks for correcting the CUTE reference (I've got to start
putting JSAC and COM in separate piles) and thanks for your
interesting message on changes to the ka9q package.  You
bring up a lot of things that I should have covered so I'm
cc'ing this reply to the tcp/ip list (in the unlikely event
that anyone else is interested).

> I suggest rounding your computed RTO values up to the next
> highest number of ticks when setting the timer. This is
> especially important when you calculate retransmission timeouts
> based on mean deviations, since they can be very small.
> Otherwise it's possible for truncation effects to set the timer
> LESS than the current SRTT.

Good point.  I should have edited that timer msg I inserted
because it contained several rounding errors.  The line

	rto = (Avg >> 3) + (Mdev >> 1);

should have read

	rto = ((Avg >> 2) + Mdev + 3) >> 1;

which is how things read in the timer rfc & the bsd code -- Avg
could also be rounded but it doesn't make much practical
difference.  The mysterious "+ 3" is half a tick for rounding
plus one tick because the send is phased randomly with respect
to the clock (i.e., there's a +-1/2 tick uncertainty in when
the timer goes off).  Also, because of the timer uncertainty, the
minimum value for rto should be two ticks.  You can save a
"if (rto < 2) rto = 2" step, at the cost of a half-tick bias
in rto, if you make the above

	rto = ((Avg >> 2) + Mdev + 4) >> 1;

> 3. When you refer to "packets" in the context of setting the
> congestion window in TCP, what do you mean? One MSS?

Yes, by "packet" without a qualifier (such as "arbitrary size
packet") I always mean a one MSS sized packet.

> I tried that first, but I ran into problems. When I have an
> entire SLIP link to myself, the mean deviation sits at a very
> low value.  Thus the RTO sits just above the SRTT.  But when
> slowstart opens up the window to send more, the round trip time
> immediately increases beyond the retransmission timeout and an
> unnecessary retransmission occurs.  The congestion window
> oscillates rapidly, with an unnecessary retransmission in each
> cycle.

I think I understand the problem (although I think you're
confusing the slowstart & congestion control algorithms -- more
on that in the next section) but I'm not sure I agree with the
analysis.  I run tcp stuff, bind & NFS over a 2400 baud slip
link from home to work and I've spent a bit of time
investigating the link's behavior (waiting for the damn slow
link gave me a lot of time when I couldn't do anything but
investigate the link behavior :-).

Having the rtt variance in addition to the rtt is a big help
when you're trying to start a bandwidth-limited link.  Since
errors in the variance decay quickly, you can afford to pump it
up whenever you're uncertain about how long a send is going to
take.  In particular, when starting we set the variance to a
`big number' (default is 3 sec but this can be overridden on a
per-route basis) and the rtt to either our best estimate (also
kept in the route) or zero.  After the syn packet, we'll know
the rtt for a zero length packet and rttvar will get decayed by
at most 25%.  As long as the the rtt for the first data packet
changes by < 2*.75*bigNumber, we won't get a spurious timeout.
We're free to overestimate bigNumber initially because even a
factor of 10 error will be `forgotten' in 8 packet exchanges.

The same scheme applies for the 2nd and future packet exchanges.
If the link is delay limited, increasing the window from one to
two packets will have no effect.  If the link is bandwidth
limited, doubling the window size will double the rtt.  In
general, given that we know the rtt, R(W), for a window size of
W, the worst case rtt change for a window size of W+dW is
R(W)*dW/W.  We don't know if we'll see the worse case but the
above reflects our "uncertainty" in the rtt of the next packet
if we increase the window size.  Thus it should get lumped into rttvar:

	rttvar += rtt * dW/W;

During slowstart, dW is the max segment size, mss, and W is
snd.cwnd so the above becomes

	rttvar += rtt * mss/snd.cwnd

before each snd.cwnd change.  (The above needs appropriate
scaling and rounding but they're implemenatation dependent.
Also, it overestimates the possible rtt change when snd.cwnd is
small but that turns out to be desirable.)

> So I'm trying something else. I initialize the congestion window
> at one MSS, but then I increase the congestion window by the
> actual amount of data acked each time an ACK comes in.  This
> effectively slows the slow-start algorithm so the timer can have
> more time to adapt.  Or at least the congestion window
> oscillation occurs at a much lower rate. What do you think?

If you mean open cwnd by MIN(amount.acked, mss), that's a real
interesting idea and I'm going to think about it.  The above
timer hacking takes care of spurious retransmits but there's
another problem:  Slowstart is designed to prevent hitting a
gateway with bursts of packets.  If you send a few small packets
when the connection starts, their acks will open the window so
that if you suddenly decide to send a bunch of data, you'll hit
the gateway with a burst.  This small/large switch is exactly
what happens in an SMTP conversation & it looks like your mod
will cure the problem.

But, if you mean what you said, I don't think it's a good idea.
Consider what happens when you send 1,2,3,4 and 1 is dropped.
2-4 are cached on the other side so when you retransmit 1 and
fill the hole in the sequence space, all four packets will be
acked.  If you increment by the amount acked, cwnd will get
fully opened and you'll blast out a window's worth of
back-to-back packets, almost guaranteeing another drop.
(I've shown the IETF lots of pictures of this kind of stable
failure mode.)

> 4. I'm confused by the modified slow-start algorithm you
> described, the one that uses a threshold to change the amount
> the congestion window is increased. Again, what does it mean to
> increase the congestion window by 1/cwind? Is cwind in packets
> (what size?) or bytes (increase the window by fractions of a
> byte?)

We found it was important to distinguish startup behavior from
steady-state behavior.  (It sounds as if you're lumping the two
together.)  The thing we call "slow start" just has to do with
starting data flowing.  The algorithm has a very short lifetime
-- it typically runs for the first 3-5 rtt after you first start
sending on a connection or restart after a drop.  When slow
start shuts down, the link is in equilibrium (the pipe is full
and you've exchanged a full window of data so you know the ack
"clock" is working).  At this point another algorithm,
congestion avoidance, takes over.  This algorithm is responsible
for estimating how much data is needed to fill the pipe under
the current (time-varying) load.  The congestion avoidance &
slowstart are separate algorithms with completely different
objectives.  They just happen to run consecutively and just
happen to accomplish their individual objectives by twiddling
the same state variable (cwnd).

The congestion avoidance algorithm is described well in DEC
technical report DEC-TR-506, "Congestion Avoidance in Computer
Networks with a Connectionless Network Layer" by Raj Jain, K. K.
Ramakrishnan, Dah-Ming Chiu, August, 1987.  The idea is that when
you try to use a window larger than the bandwidth*delay of the
network path, the excess window won't fit in the pipe so it
must show up in a queue somewhere.  In the usual case, "somewhere"
will be the outbound queue of the slowest link in the path.
That link will probably be a bottleneck for a lot of other
conversations and it's likely its queue will fill up and overflow.
We treat this as a signal that our window is too large and
reduce it (Jain doesn't wait for an overflow -- his signal is
a bit in packet that the gateway can set to say its congested.)

But the `bandwidth' in the delay-bandwidth product is *your
share* of the fixed link bandwidth and your share can change as
conversations using the same path come and go.  The gateway
tells you when you're using too much but says nothing when
you're using too little.  To find out if someone has shut down
and your share is now larger, you continuously test by slowly
increasing your window size until the gateway says you're using
too much.  (Thus the window will oscillate around some mean
value.  The algorithm is designed to do this.  But we've tried
to set the adjustable parameters that determine the oscillation
so that the bandwidth lost to testing the path is at most 1%.)

From a linear system argument, you can show that best probe
policy is to make your bandwidth vs. time obey dB/dt = C for
some constant C.  Since B = W / R, where W is the window size
and R is the round trip time, and R is constant, this says you
want dW/dt = c for some other c.  In other words, in one rtt we
want the window to go smoothly from size W to size W+c.  I want
the algorithm to be "self clocked" so we go looking for how to
do the above change using acks rather than time to drive the dW.
If the max packet size is mss and we have decent silly window
code, a window of W will generate at most W/mss acks and it will
generate them spread out over one rtt.  Thus if we increment by
c/(W/mss) = c*mss/W per ack, we will have opened the window by c
after one rtt.  An appropriate c for current arpanet conditions
turns out to be one mss so the increment part of the congestion
avoidance turns into

	snd.cwnd += mss*mss / snd.cwnd;

(you might have to worry about the the fixed-point in this if you
were trying to send small packets over a net with a large bandwidth
delay product but it's not a problem in any net I know of.)

> 5. You didn't specifically mention ICMP source quench, but I
> assume you mean that the congestion window should be cut in half
> each time you get one.  To make this meaningful I also limit the
> congestion window to be no more than the offered window. One
> question: should the congestion window be allowed to decrease
> below one MSS? I would say yes, but I'd like to hear your
> opinion.

I didn't mention source quench because it's a disaster and I keep
hoping it will go away.  There must be at least one rtt of hysteresis
or "dead time" for any control algorithm to be stable.  By using
packet drops and timeouts to drive things, we get this automatically.
But it's very, very hard to get the right kind of hysteresis with
source quench.  It's also possible to show that source quench leads
to a very unfair bandwidth allocation -- SQ is preferentially 
delivered to the hosts using the smallest windows (I have lots of
trace data showing this and can explain why it happens but the
explanation is mathematical and quite involved).

So, since SQ currently happens only when one or more packets has
been dropped, all we do is close snd.cwnd down to one packet (so
no more will get dropped) but we don't touch snd.ssthresh
(because the slowstart time is short, ssthresh is the crucial
window control, not cwnd).  Ssthresh and the rest of the
congestion control stuff will get handled correctly, and with
the right "time constants", when we eventually take the timeout
for the lost packet.

We limit cwnd to be at most the offered window (you violate
rfc793 if you ever send more than the offered window).  I don't
think it's a good idea to let cwnd get below one mss.  Dropping
cwnd below mss forces you to send small packets, increasing the
overhead per data byte xferred.  Thus you are using the network
less efficiently at a time it's heavily loaded and you really
want to make the most efficient possible use of it.  This is an
unstable positive feedback that can lead to collapse.  If mss is
set correctly, it never makes sense to send a smaller packet.

> 6. It's interesting to note that the "set the congestion window
> to one packet after a timeout" rule automatically implies the
> "first-only retransmission" rule, thus simplifying my code
> somewhat.  In effect, a timeout is just a very drastic source
> quench.

Yes, there were several sort-of ad-hoc pieces of code, like the
first-only rexmit and all the source quench handling, that were
taken out because their job was handled in a more unified way by
the slowstart/cong. avoidance framework -- it was very
satisfying.  We removed something like 15 lines and replaced
them with 6.  Of course, we then stuck in your clamped
retransmit backoff algorithm, a fast retransmit algorithm (that
got described at one of the IETF meetings) and a few more
goodies, and ended up +3 lines from the original 4.3 code
instead of the -9 we expected (not including, of course, dozens
of lines of bug fixes).

I prefer to think of source quench as a poorly considered, ill
behaved timeout :-).

 - Van

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 88 12:48:19 CST
From:      "Paul Lustgraaf" <GR.PJL%ISUMVS.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
;  Why one specific hosts ethernet packets are not passed
;  through a "bridge"?

The first thing to check, given that some hardware/software
combinations allow you to change it (WHY?), is that you don't
have a duplicate ethernet address.


Paul Lustgraaf        GR.PJL@ISUMVS.BITNET
Network Specialist
Computation Center
Iowa State University
Ames, IA  50011
515-294-0324

-------
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 88 13:10:52 EST
From:      Gary Malkin <PETTY@MITVMA.MIT.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   TALK Protocol
========================================================================
Date:         Tue, 23 Feb 88 12:55:39 EST
From:         Gary Malkin <PETTY@MITVMA>
Subject:      TALK Protocol
To:           TCPIP@SRI-NIC.ARPA

Spartacus's KNET allows multiple forms o file transfer and remote login
between IBM and non-IBM nodes.  What it does not have is the ability to
allow a user on an IBM node to communicate with a user on a non-IBM node.
I have been thinking about implementing TALK on the IBM side to provide
this service.  What I need to know is: what is the inter-daemon protocol
(the UDP handshake).  I also need info about error codes and timeout
parameters.  If anyone has this information handy, please let me know.

Thank you in advance for your help.
' Gary Malkin         TCPIP@SRI-NIC.ARPA   2/23/88 TALK Protocol
-------
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 88 19:53:00 EST
From:      <enger@bluto.scc.com>
To:        "greg%fnal.hepnet" <greg%fnal.hepnet@LBL.GOV>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   Using DEC VT200 mode through telnet

Greg:
I believe VT200 mode allows the system to transmit 8-bit control codes to the
terminal.  TPU takes advantage of this.  For instance, the "<esc>[" sequence
is replaced by "<csi>" (9B in hex).  This makes the host/terminal
communications more compact, and perhaps quicker. 

Unfortunately, the intervening com facilities must pass 8-bit codes.
I don't think telnet normally does this.

I logged into my Sun running their latest software, but couldn't find
an option to put its telnet into binary mode.

I logged onto our VMS Vax, and fired up the Wollongong telnet. It does support
a "binary" mode, and this successfully runs TPU. Unfortunately, the command
cannot be placed into their TELINIT. telnet startup configuration file;
instead it must be typed in manually once the connection has been opened. 

Best wishes,
Bob Enger

-------
-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 88 16:44:29 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Link level Ethernet bridges

Does anyone on this list have an inkling about why given the following
configuration that one specific hosts ethernet packets are not passed
through a "bridge":

    segment 1       segment 2

	Ha--|       |--Hz
	    |       |
	Hb--|       |--Hz-1
	    |       |
	Hp--|       |
	    .       .
	    .       .
	    .       .
	Hq--|       |--Hr
      	    |--[D]--|
      	    

All the hosts Ha through Hz  with the exception of Hp can communicate over
the ether.  All the hosts Ha through Hq INCLUDING Hp can communicate over
segment 1.  

Phil Wood

P.S.  I'm afraid to mention any vendor's names for fear of getting sue'd.

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 88 16:47:34 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Life in the Swamps / Testing

Well, the unclear comments and generalizations had better not get any stamp
of approval from the organization involved (just like a good bug-reporting
system will bounce anything like that right back to the originator for
clarification without a developer ever having to read it...).  The list
needs an editor.

I think a simple list of easy-to-prove facts would do a good deal of good,
and it could be done in fairly short order.  List the vendors who are
perpetuating 4.2 bugs (UDP checksums, TFTP, non-RFC959 FTP, the old broadcast
address, thinking they're a router by default).  List the vendors who don't
support nameservers (the majority).  List the vendors who don't support
subnets (maybe a minority, now?).  List the vendors who don't support ICMP
redirects (harder to determine).  Millitary-related people might even be
able to collect a list of who can and can't handle IP packets with options.

The sophisticated, repeatable data from a test suite is desirable, but we
can begin the process much sooner.  Perhaps we can even get many of the simple
problems out of the way (RFC959 FTP only requires adding 4 table entries to
the server's parser), and maybe even get most of the vendors used to
sophisticated input from the field, perhaps even including directions for
new development...

jbvb

PS: maybe it all looks too easy for me, because both of my PCs can run our
network monitor program at a moment's notice, but the Sun people have
their own tools, too.

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 88 17:19:00 GMT
From:      GREG@FNALNET.BITNET
To:        comp.protocols.tcp-ip
Subject:   CMU package

I have just installed the CMU TCP/IP package on several Microvax'en and am
experienced a strange Telnet situation. The DEC TPU editor screen and cursor
functions do not work properly if the terminal is defined as device=VT200, but
work if defined as device=VT100.

Have I done somthing wrong?

Is this a known or documented bug (feature)?

Have any of you experienced this as well?


Thanks,
Greg Chartrand - Fermilab

P.O. Box 500 - Batavia, Il. 60510
(312) 840-3727
GREG@FNAL.BITNET or GREG%FNAL.HEPNET@LBL.ARPA

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 88 18:48:19 GMT
From:      GR.PJL@ISUMVS.BITNET ("Paul Lustgraaf")
To:        comp.protocols.tcp-ip
Subject:   (none)

;  Why one specific hosts ethernet packets are not passed
;  through a "bridge"?

The first thing to check, given that some hardware/software
combinations allow you to change it (WHY?), is that you don't
have a duplicate ethernet address.


Paul Lustgraaf        GR.PJL@ISUMVS.BITNET
Network Specialist
Computation Center
Iowa State University
Ames, IA  50011
515-294-0324

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 88 19:21:26 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   PSN Physical connections.

Is there an RFC or other document someplace that describes the
physical connection between a host and a PSN?  This was a lot easier
in the 1822 days, but now there is rs232, rs449, v.35, dce, dte,
internal clocking, external clocking, providing an external clock, and
all sorts of other things that are necessary to get X.25 working
properly...  There are apparently several varieties of interface
available on the PSN, not to mention several types of PSNs.  Id like
to know ALL the available configurations, so that I can tell people
"yes, to connect a cisco Gateway to your PSN, you will also need and
X, a Y, and a Z, or you can get the PSN reconfigured to be FOO, in
which case you won't need the Z any more".

Thankyou
Bill Westfield
cisco Systems.
-------

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 88 21:44:43 GMT
From:      catlett@NCSA.UIUC.EDU (Charlie Catlett)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Terminal Servers


NCSA is considering the purchase of terminal servers for asynchronous access
to our suite of machines.  Can I get some testimonials or horror stories
from those who have experience using these boxes?  Does anyone have an
opinion on which vendor has the best/worst?
Thanks in advance,
Charlie Catlett
National Center for Supercomputing Applications
catlett@ncsa.uiuc.edu
catlett@ncsavmsa.bitnet

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 88 22:23:24 GMT
From:      oconnor@SCCGATE.SCC.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re:  a ping with record route

Actually the ping program referenced creates echo request packets with
the Loose Source and Record Route (LSRR, type 131) IP option not the
RR (type 7) IP option.  And my Sun, for one, does not ignore them.

			Mike

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 88 23:12:20 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Link level Ethernet bridges (Modified)! does that mean joke?

Naming names.  No dispersions intended.  But, hey, I want to know!

Does anyone on this list have an inkling about why given the following
configuration that 99.9% packets destined for an HP system are not passed
through a DEC MacLevel Bridge? (Thats right, one maybe every 300 to 400
packets)

	segment #1				segment #2

  8:0:20:1:33:1e  Ha--|                        |--Hz    8:0:2b:3:92:23
  		      |                        |
  8:0:20:1:47:d2  Hb--|                        |--Hz-1  8:0:20:1:d7:e5
		      |icmp              icmp  |--Hy    2:7:1:0:a6:59
   8:0:9:0:65:3d Hp*--|echo->            echo->|--Hx    aa:0:4:0:da:4 hummmm.  
   		       nada            <-reply |
		      .                        .
		      .                        .
		      .                        .
  8:0:20:1:66:6a  Hq--|                        |--Hr    8:0:2b:3:91:5c 
      		      |----?[DEC lanBridge]?---|
      	    
        SUBNET 1 of Class B network 128.165, mask==0xfffffc00

There is probably alot of irreverent/irrelevant, but, it was fun.
	
All the hosts Ha through Hz  with the exception of Hp can communicate over
the ether. By communicate, I mean ICMP echo, vanilla, no ip options.
All the hosts Ha through Hq ***INCLUDING*** Hp* CAN communicate
over segment #1. When attempting an ICMP Echo between Hp and Hx, an
'etherfind' on segment #2 shows an echo and echo reply
reply packet.  While an 'etherfind' on segment #1 shows an echo packet,
one out of 400 reply's make it.  Do this with any other pair, like
Ha -- Hx, or Hp -- Ha, and it works bwainoh.

* Hp == HP-UX hp320 6.01 B 9000/320  Is there something strange about that
	address? ... I don't think so.
	(Little is known about this one of a kind on our net.  It would be
	 nice if we could look at its "arp" tables, but they did it their
	 way, what if? ...,  Rumor has it that the system is BSD3.4 made
	 to look like system V.) 
  Ha == Sun UNIX 4.2 Release 3.4
  	(This release is known to be worthless on a subnet, however, it
  	 appears to work if it stands alone and does not use the yellow
  	 pages.)
  Hr == VAX-11/785 running VMS/Wollengon (3.1) (They do ICMP mask request
        replys correctly, its about time!, but don't send them too many
        packets in a row!)
  Hz == VAX-11/785 running BSD 4.3 (They forget to swap their subnetmask
        and mess up anyone foolish enough to broadcast an ICMP mask request,
        fixed by me, cause I got source!)
Hz-1 == Sun 3/260 running 3.5 (Hey, I can ifconfig netmasks and broadcast
	addresses, but darn I still can't ip route between 128.165.4.xx
	(mask == 0xfffffc00) and 192.5.16.96 (mask == 0xffffffe0), and
	double darn the routed just chewed up all my cpu and flooded
	the net with gosh knows what kind of "routing" packets, and those
	yellow lights on the DEC LanBridge just don't blink anymore, their
	SOLID.)
  Hx == VAX-8600 running Ultrix V2.0-1 (Talk about skizoid, this dude
  	talks DECNET and INTERNET of'n a one DEUNA and it's network
  	application suite has been loaded at j random times with:
  	
  		gethostbyname from /etc/hosts
  		gethostbyname from /etc/yp
  		gethostbyname from /etc/resolv.conf (yup, ypserv -i)
  		
  	So try, and answer a vanilla users question like  "why can I rsh
  	and not rlogin!")
  Hy == Celerity running Accel UNIX, (They were nice to rush us a patch
  	for their systems that fixed a bug that stomped on SUN clients
  	attempting to boot.
...  == Bridge, Inc. terminal servers, Bridge, Inc. GS7's and GS3's, pure
	DECNET VMS VAX systems, IBMPC's, KINETICS MacInTosh "gateway's",
	miscelaneous DEC terminal servers, IBM RT's which respond to
	ICMP echo requests and return the IP Record Route option, bless
	there heart!)
  
Phil Wood

P.S.  I'm not afraid anymore.  I think I'll save this one.

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 88 23:28:44 GMT
From:      neerma@COD.NOSC.MIL (Merle A. Neer)
To:        comp.protocols.tcp-ip
Subject:   Re: Link level Ethernet bridges

In our own experience in a similar configuration we
discovered that some segments have more errors occurring
on them.  In turn some hosts are less tolerant of errors
and refused to talk over a 'corrupted' cable.

I dont know if this is your problem but you might look
at the local ether segment to see if some transcievers
have been installed improperly etc.

As I mentioned we had a similar problem in that some
hosts could not communicate throught a bridge yet
could talk to each other if they were on a local cable.
When we moved these particular hosts to a new cable
they were ok.

What can I say..it worked!

Merle.
neerma at nosc

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

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 88 00:08:42 GMT
From:      neerma@COD.NOSC.MIL (Merle A. Neer)
To:        comp.protocols.tcp-ip
Subject:   Forwarded: Message of 23-Feb-88 15:27:07

-------
Forwarded mail follows:
From Mailer@SRI-NIC.ARPA Tue Feb 23 15:30:50 1988
Message-Id: <8802232330.AA00584@cod.nosc.mil>
Date: Tue, 23 Feb 88 15:28:48 PST
From: The Mailer Daemon <Mailer@SRI-NIC.ARPA>
To: neerma
Subject: Message of 23-Feb-88 15:27:07

Message failed for the following:
tcp-ip-RELAY@SRI-NIC.ARPA: No such directory name
	    ------------
Received: from cod.nosc.mil by SRI-NIC.ARPA with TCP; Tue 23 Feb 88 15:27:12-PST
Received: by cod.nosc.mil (5.58/1.27)
	id AA00402; Tue, 23 Feb 88 15:28:44 PST
Date: Tue, 23 Feb 88 15:28:44 PST
From: neerma@cod.nosc.mil (Merle A. Neer)
Message-Id: <8802232328.AA00402@cod.nosc.mil>
To: tcp-ip-RELAY@sri-nic.arpa
Cc: tcp-ip@sri-nic.arpa
Subject: Re: Link level Ethernet bridges
In-Reply-To: Your message of Tue Feb 23 11:24:48 1988

In our own experience in a similar configuration we
discovered that some segments have more errors occurring
on them.  In turn some hosts are less tolerant of errors
and refused to talk over a 'corrupted' cable.

I dont know if this is your problem but you might look
at the local ether segment to see if some transcievers
have been installed improperly etc.

As I mentioned we had a similar problem in that some
hosts could not communicate throught a bridge yet
could talk to each other if they were on a local cable.
When we moved these particular hosts to a new cable
they were ok.

What can I say..it worked!

Merle.
neerma at nosc

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

-------

-------

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 88 00:53:00 GMT
From:      enger@BLUTO.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   Using DEC VT200 mode through telnet


 Greg:
I believe VT200 mode allows the system to transmit 8-bit control codes to the
terminal.  TPU takes advantage of this.  For instance, the "<esc>[" sequence
is replaced by "<csi>" (9B in hex).  This makes the host/terminal
communications more compact, and perhaps quicker. 

Unfortunately, the intervening com facilities must pass 8-bit codes.
I don't think telnet normally does this.

I logged into my Sun running their latest software, but couldn't find
an option to put its telnet into binary mode.

I logged onto our VMS Vax, and fired up the Wollongong telnet. It does support
a "binary" mode, and this successfully runs TPU. Unfortunately, the command
cannot be placed into their TELINIT. telnet startup configuration file;
instead it must be typed in manually once the connection has been opened. 

Best wishes,
Bob Enger

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 88 02:20:07 GMT
From:      gaw@columbia-pdn (Glen A. Warholic)
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN Physical connections.

If such a document existed it would be worth a fortune and I doubt if
asking for it would get you it.

Seriously I have never seen one and as you stated during the
days of 1822 you could pull out good old report 1822 and be ready
to go.  But now with V.35 on an RS-449 connector and the new move to
put a clock generator in the PSN(DTE) so that it can connect to
another DTE(host/gateway) without the use of a modem eliminator,
the number of possibilities of the ways to connect to a PSN
can be mind boggling.

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 88 8:46:29 EST
From:      "Kenneth A. Turkewitz" <turkewit@CCV.BBN.COM>
To:        William Westfield <BILLW@MATHOM.CISCO.COM>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  PSN Physical connections.

Bill,
	There is such a document that was written by BBN Communications
for DCA last year.  It is called "C/30E Physical Layer Interface Guide."
I believe that DCA was going to add a few things and publish this in
some easily obtainable mode.  (The cover of the document includes,
"DCAI No: DCAI-350-180-()."  I'm not sure whether or not this will help
uniquely identify the document to DCA.)
	I would check with DCEC (start with Charlie Morgan,
"CEMorgan@DDN1.arpa") to find out the status of this document.  He
might also know how to obtain a copy of it.
		--Ken Turkewitz
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 88 08:20:34 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   4.3BSD IP Option / Fragmentation Bug Fix

4.3BSD network bug (#?, ip_output)
Index:	sys/netinet/ip_output.c 4.3BSD FIX

Introduction:

This is not official, if a fix already exists, then excuse me.  I have
shown an IP Option/fragmentation problem to exist by generating IP
Security Option packets large enough to be fragmented.  I was able to
see the corruption via SUN's 'etherfind' on a 4.0beta LAN.  And,
consequently, fixed the problem.  Success being a "correct" response
to an ICMP Echo with IP Security Option, packet size > 1500 bytes,
generating 2 fragments.  I personally would have liked to see the
Security option come back, but what the hey, I got the Echo Reply!.

Description:

When sending IP packets which have to be fragmented, ip_output would
do strange things if any IP Options were included.   The result was that
the packets were discarded by Gateways, or thrown out by receiving
hosts because:

	IP options were essentially copied twice to the outgoing
	fragment due to having incorrectly set the offset
	for copies from the source mbuf.  The IHL was not taken into
	account.  This generated a bogus data portion in the packet.

	If the IP option was one that should only appear in the first
	fragment, then the checksum was calculated wrong on the second
	and succeeding fragments due to the use of the original IHL which
	included the option section length.

	I assume that this is only a problem with packet origination, and
	not with the 'ip forwarding mode'.
Fix:
	Apply the diffs shown below, if you are not a feared of viruses.

Signed:

	Phil Wood, cpw@lanl.gov

*** ip_output.c.orig	Tue Jul 28 10:27:53 1987
--- ip_output.c	Wed Feb 24 00:48:34 1988
***************
*** 5,7 ****
   *
!  *	@(#)ip_output.c	7.1 (Berkeley) 6/5/86
   */
--- 5,7 ----
   *
!  *	@(#)ip_output.c	7.1 (LANL)  2/24/88
   */
***************
*** 44,46 ****
  	register struct ifnet *ifp;
! 	int len, hlen = sizeof (struct ip), off, error = 0;
  	struct route iproute;
--- 44,46 ----
  	register struct ifnet *ifp;
! 	int len, hlen = sizeof (struct ip), off, error = 0, ohlen;
  	struct route iproute;
***************
*** 177,180 ****
  	 */
! 	m->m_len -= sizeof (struct ip);
! 	m->m_off += sizeof (struct ip);
  	for (off = 0; off < ip->ip_len-hlen; off += len) {
--- 177,181 ----
  	 */
! 	m->m_len -= hlen;
! 	m->m_off += hlen;
! 	ohlen = hlen;
  	for (off = 0; off < ip->ip_len-hlen; off += len) {
***************
*** 182,183 ****
--- 183,185 ----
  		struct ip *mhip;
+ 		register olen = 0;
  
***************
*** 191,194 ****
  		if (hlen > sizeof (struct ip)) {
! 			int olen = ip_optcopy(ip, mhip, off);
! 			mh->m_len = sizeof (struct ip) + olen;
  		} else
--- 193,198 ----
  		if (hlen > sizeof (struct ip)) {
! 			olen = ip_optcopy(ip, mhip, off);
! 			ohlen = sizeof (struct ip) + olen;
! 			mh->m_len = ohlen;
! 			mhip->ip_hl = ohlen >> 2;
  		} else
***************
*** 204,206 ****
  		}
! 		mhip->ip_len += sizeof (struct ip);
  		mhip->ip_len = htons((u_short)mhip->ip_len);
--- 208,210 ----
  		}
! 		mhip->ip_len += sizeof (struct ip) + olen;
  		mhip->ip_len = htons((u_short)mhip->ip_len);
***************
*** 214,216 ****
  		mhip->ip_sum = 0;
! 		mhip->ip_sum = in_cksum(mh, hlen);
  		if (error = (*ifp->if_output)(ifp, mh, (struct sockaddr *)dst))
--- 218,220 ----
  		mhip->ip_sum = 0;
! 		mhip->ip_sum = in_cksum(mh, ohlen );
  		if (error = (*ifp->if_output)(ifp, mh, (struct sockaddr *)dst))

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 88 13:46:29 GMT
From:      turkewit@CCV.BBN.COM ("Kenneth A. Turkewitz")
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN Physical connections.


Bill,
	There is such a document that was written by BBN Communications
for DCA last year.  It is called "C/30E Physical Layer Interface Guide."
I believe that DCA was going to add a few things and publish this in
some easily obtainable mode.  (The cover of the document includes,
"DCAI No: DCAI-350-180-()."  I'm not sure whether or not this will help
uniquely identify the document to DCA.)
	I would check with DCEC (start with Charlie Morgan,
"CEMorgan@DDN1.arpa") to find out the status of this document.  He
might also know how to obtain a copy of it.
		--Ken Turkewitz

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 88 15:51:43 GMT
From:      dannyb@kulcs.uucp (Danny Backx)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with UNIX tcp

> sometimes do it on UNIX.  The problem simply stated is
> this: the user process cannot get the status of its
> tcp connections from UNIX.
 [...] 
> Have any UNIX guru-types ever considered offering a
> 'status(myconnect)' call?  We'll gladly pay for one.
> Or even just a 'signal(YOURCONNECTISBOGUS,letmeknow)'
> would be nice?
 [...] 
> Merle Neer
> neerma@nosc

Could you post a more complete list of what you think a user interface to TCP
should include ?

As for your request on 'YOURCONNECTISBOGUS', I think you can arrange something
like that on BSD. (I don't know whether you're talking about BSD or Sys-V).
If you are interested, look in the manual entries for socket(2),
setsocketopt(2) - look for the SO_KEEPALIVE option.
I'm not sure if you can detect dead connections with select(2), or maybe
with SIGIO or SIGURG.

If you find a way, please post it. I'm sure lots of people are interested.

	Danny

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Danny Backx                            |  mail: Katholieke Universiteit Leuven 
 Tel: +32 16 200656 x 3537              |        Dept. Computer Science
 E-mail: dannyb@kulcs.UUCP              |        Celestijnenlaan 200 A
         ... mcvax!prlb2!kulcs!dannyb   |        B-3030 Leuven
         dannyb@kulcs.BITNET            |        Belgium     

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 88 16:17:24 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: CMU package

DEC editors usually have strong opinions about using VT220s in 8-bit
mode, and most Telnet streams won't pass 8-bit unless the 'binary'
option has been agreed upon.  Few Telnet clients or servers even
support 'binary', and there is still a group of Neanderthals out there
who insist on sending parity in the 8th bit, so you just can't turn
off the masking operation.

Some time back, I suggested a concerted campaign to identify and sit
upon those who send parity, so the rest of us can just make the masking
operation optional, but I got shot at, and am now quietly implementing
'binary' in my own Telnets.  Fat lot of good that will do most people.

jbvb

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 88 21:22:12 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN Physical connections.

This reminds me of the time, about 2 months ago, when we attemted to use
Sun Microsystems, Inc. MCP board, their SUNLINK X.25 software, and a
PDN to see what kind of connectivity we could get.  Like communicating
with other nodes off the PDN.  We had a serial line junky in here, with
mucho patents to his name, a million dollor serial line analyzer with
lots of beautiful color monitor displays, and various loopback plugs.
It took a couple of days, and visits from various Mountain Bell types
before we could "pad" on over to a Microvax, via Phoenix at 56 Kbits.
We never did get the Internet Router to work, but thats another story
which is "fixed in 4.0"

Phil Wood   cpw@lanl.gov

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 88 21:38:45 GMT
From:      jch@DEVVAX.TN.CORNELL.EDU (Jeffrey C Honig)
To:        comp.protocols.tcp-ip
Subject:   Re: Using DEC VT200 mode through telnet

The SET TERM command on VMS has a qualifier /NOEIGHTBIT or something
similar that will solve your problem.

Jeff

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 88 00:56:47 GMT
From:      pitstop!sundc!rlgvax!dennis@sun.com  (Dennis.Bednar)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: SLIP (what & where??)
In article <3805@galbp.LBP.HARRIS.COM>, gja@galbp.LBP.HARRIS.COM (Greg Ansley) writes:
> 
> A need a discription of SLIP, what it is and what it can do as well as 
> a pointer to where I can get the code!
> Please reply be mail so as not to bore the rest of the net!

I prefer to bore the net.  Here's what I know:

SLIP = Serial Line Internet Protocol

IP packets are sent over an RS-232C serial wire encapsulated
and decapsulated according to the packet formatting rules.
There is no packet header, and only a single byte for the
packet trailer.  Since the byte used for the packet trailer
could appear as data in the packet, certain escape conventions
are used to prevent this possiblity.  The sending side adds
extra escape prefix characters while sending a packet, and
the receiving side removes the extra escape chars and stores
the unencoded packet for further processing.

SLIP is just another oe of the possible lowest level protocols
between TCP/IP and the raw hardware.  SLIP is at the same level
as ethernet/ARP, or an 1822 "bit-banger" protocol, or the newer
DDN X.25 (I think levels 3 and 2) interface.

Historically, as I know it, SLIP was invented by 3com Corp. when
Bruce Borden et.al. developed a TCP/IP package known as UNET.
But it might have been invented at Ford Aerospace, because the
comments in the source code indicated that Ford had some role
as far as helping 3com with some of the software.
Above 4 years ago, Rick Adams worked here at CCI, and ported
UNET to a CCI 5/20 processor running Unix S3.  We required
communications between our VAX 780 and the 5/20, and at that
time, the VAX only supported TCP/IP/ethernet, but not SLIP,
and the 5/20 only supported SLIP, but not ethernet. So Rick
Adams wrote the first SLIP driver for the 4.2BSD kernel that
allowed TCP/IP communication between our 4.2BSD VAX and our
S3 5/20.  End of story.

As for the packet format, TCP/IP packets are sent "serially",
one-byte-at a time, left-to-right, high-order to low-order
as you might expect if you look at the IP or TCP specs.
The following encoding rules apply (below is the output of
a dumb program called "unetchars" which I wrote several
years ago): I wrote it to document the packet format when we had
to understand and analyze  protocol problems seen on a Data
Line Monitor:




		How IP Packets are Sent over an Asynchronous Line



	+------------+--------------------------------------------+-------------+
	| LNI header |    LNI (Local Network Interface) data      | LNI Trailer |
	+------------+-----------+------------+-------------------+-------------+
	             | IP header | TCP header | optional TCP data |
	             +-----------+------------+-------------------+

	             |<------------ Data Encoding Rules --------->|


			Special Octets Used For Data Encoding

	 Name      Hex  Octal  Decimal    Description
	FRMEND     0xc0  0300    192      Frame End Character
	FRMESC     0xdb  0333    219      Frame Escape Character
	M_FRMEND   0xdc  0334    220      Meta Frame End Character
	M_FRMESC   0xdd  0335    221      Meta Frame Escape Character


	There is no LNI header for an asynchronous serial line.
	That is, there is no special character to introduce a sent frame.

	In the LNI data field, the sender applies the following rules:
	A data FRMEND octet is sent as FRMESC, M_FRMEND sequence.
	A data FRMESC octet is sent as FRMESC, M_FRMESC sequence.
	All other octets are sent without any translation.
	The receiving IP decodes by stripping and translating the extra octets.

	The LNI trailer contains only the FRMEND octet.
	That is, a frame is sent ending with the FRMEND character.



	Example:
	Want to send ('a', FRMESC, 'b', FRMEND, 'c').
	Sent as ('a', FRMESC, M_FRMESC, 'b', FRMESC, M_FRMEND, 'c', FRMEND).
	Note the last sent octet is not part of the LNI data field.



	Data Octet To Send               Data Sequence Actually Sent
	Hex   Octal   Decimal             Hex           Octal       Decimal
	0xdb  0333    219           (0xdb, 0xdd)    (0333, 0335)    (219, 221)
	0xc0  0300    192           (0xdb, 0xdc)    (0333, 0334)    (219, 220)






	Justification of the Rules:

	1. Sending the FRMEND data octet as a FRMESC, M_FRMEND sequence:
	   We must be able to send the FRMEND as a data character,
	   so the FRMEND has to be escaped, otherwise the receiver would
	   misinterpret it as a premature end of packet.


	2. Sending the FRMESC data octet as a FRMESC, M_FRMESC sequence:
	   Because the FRMESC is used as an escape, there has to be a way
	   of treating a FRMESC as data.  For example, if this rule weren't
	   defined, then there would be an ambiguous packet.  Suppose the
	   sender wanted to send the (data_char, FRMESC, M_FRMEND, data_char)
	   sequence.  According to rule 1 only, there would be no translation
	   of octets.  Therefore the receiver would receive it as
	   (data_char, FRMEND_data_char, data_char),
	   which is not what is intended.
-- 
FullName:	Dennis Bednar
UUCP:		{uunet|sundc}!rlgvax!dennis
USMail:		CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone:	+1 703 648 3300
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 88 01:12:24 GMT
From:      tcs@USNA.MIL (Terry Slattery)
To:        comp.protocols.tcp-ip
Subject:   Re:  Life in the Swamps / Testing

Is there any reason why the regular vendor list cannot be expanded to
include additional 'facts' about an implementation.  Such facts would
be subnet support, nameserver support, specific questions relating to
whether known widespread bugs are fixed (i.e. udp checksums, TFTP,
etc).  Vendors then voluntarily complete the form.  It then becomes a
"keep up with the Jones'" task to fill out the form with as much
positive information as possible.  False listings would be discovered
and possible negative publicity would eliminate them.

Someone who knows most of the pitfalls needs to come up with the first
template.  As new items need be added, a new field is added to each
entry.  Old fields can be aged away as the problem subsides (i.e. we
don't need to decide right here and now ALL the right questions to ask
- just get close.)  Announcements of a new field will eventually get
the vendors and they will answer the empty item.

	-tcs

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 88 07:35 CST
From:      <GREG%FNALNET.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   CMU Telnet problem
Thank you all for your assistance. Problem solved and totally
understood!

Regarsd,

Greg Chartrand - Fermilab
-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 88 02:03:50 GMT
From:      MRC@PANDA.PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: CMU package

I sympathize with JBVB's problem.  I've been fighting it for almost 10 years
now, both in my own code (Telnet implementations for 3 different operating
systems) and in other's code.  As far as I know, Telnet implementations
which get various of these complexities right are few and far between.
Here's my own list of Neanderthals:

 . host systems which send parity over Telnet connections.  These are
   becoming rarer over time, but there's still a few out there.

 . operating systems which can't tell the difference between a terminal
   which sends parity and one which doesn't, making it virtually impossible
   for the Telnet client to know what to do with that 8th bit.  ITS is the
   only OS I know that lets an application know that the 8th bit is
   significant.  WAITS gets partial credit for supporting this for terminals
   it recognizes under its display service.  VAX/VMS may also be a winner.
   I believe Unix flunks, as does most versions of TOPS-20 (only PANDA
   TOPS-20 has a "parity terminal" status bit).

 . Telnet servers which confuse Telnet binary state with some local concept
   of what is binary.  Tenex gets a big, red F in this (this was the infamous
   "new Telnet performance bug" of the late 70's), as do certain versions of
   Unix which associate Telnet binary with something called "raw mode."  This
   is one of the most serious problems facing Telnet application developers
   trying to do something useful with 8-bit I/O.

 . operating systems which have no way to instruct the Telnet server to get
   out of binary mode.  WAITS and PANDA versions of TOPS-20 are the only OS's
   I know of that handle this problem, which is what once a TAC user does
   @B I S he can't get out of binary mode.

 . Telnet servers which fail to double '377 (FFh for you Unix guys).  Most
   versions of TOPS-20 (except for PANDA) have this serious bug, and it's led
   to a plethoria of programs which manually double FFh.  Guess what happens
   when you try to run such programs on a PANDA system which does it right...

The most distressing part about all of this is that these bugs are ancient
bugs, that intelligent hackers have fixed years ago, but still broken versions
continue to proliferate.
-------

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 88 08:24 EDT
From:      "Eliot Moss, GRC A351B, x5-4206  25-Feb-1988 0821" <MOSS@CS-UMASS.ARPA>
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: VT200 and CMU/TEK TCP/IP Telnet
If Telnet'ing from/to a CMU/TEK TCP/IP host, use the /BINARY option to go
into binary mode so as to allow the 8-bit controls to flow. Of course, as
pointed out in a number of recent messages, if there is a non-CMU/TEK host
involved that does not do the right thing with binary mode, this will not
work right. We do know it to work right between two CMU/TEK hosts running
version 6.2 of that software.
					Eliot Moss
					Assistant Professor
					Dept. of Comp. and Info. Sci.
					Univ. of Mass., Amherst
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 88 06:53:15 GMT
From:      VSRAANAN@WEIZMANN.BITNET (raanan michael)
To:        comp.protocols.tcp-ip
Subject:   Re: Using DEC VT200 mode through telnet

Greg, Bob.
i had the same problem here wile telnet vms (excelan exos board) to
unix machine.
  we succeeded to make telnet connection by typing "<cntrl> j"
  (linefeed) after <cr> during logon time (userid and password).
  another command that helped was "set term/noeight" before telnet.
  in that case the connection will be done with 7 bit, so  vt220
  8 bit functions will not work.
  raanan.

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 88 08:53:15 +0200
From:      raanan michael <VSRAANAN%WEIZMANN.BITNET@CNUCE-VM.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Using DEC VT200 mode through telnet
Greg, Bob.
i had the same problem here wile telnet vms (excelan exos board) to
unix machine.
  we succeeded to make telnet connection by typing "<cntrl> j"
  (linefeed) after <cr> during logon time (userid and password).
  another command that helped was "set term/noeight" before telnet.
  in that case the connection will be done with 7 bit, so  vt220
  8 bit functions will not work.
  raanan.
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 88 12:24:00 GMT
From:      MOSS@CS-UMASS.ARPA ("Eliot Moss, GRC A351B, x5-4206  25-Feb-1988 0821")
To:        comp.protocols.tcp-ip
Subject:   Re: VT200 and CMU/TEK TCP/IP Telnet

If Telnet'ing from/to a CMU/TEK TCP/IP host, use the /BINARY option to go
into binary mode so as to allow the 8-bit controls to flow. Of course, as
pointed out in a number of recent messages, if there is a non-CMU/TEK host
involved that does not do the right thing with binary mode, this will not
work right. We do know it to work right between two CMU/TEK hosts running
version 6.2 of that software.
					Eliot Moss
					Assistant Professor
					Dept. of Comp. and Info. Sci.
					Univ. of Mass., Amherst

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 88 13:35:00 GMT
From:      GREG@FNALNET.BITNET
To:        comp.protocols.tcp-ip
Subject:   CMU Telnet problem

Thank you all for your assistance. Problem solved and totally
understood!

Regarsd,

Greg Chartrand - Fermilab

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 88 19:20 EST
From:      The Mail Server <Postmaster%TRINCC.BITNET@MITVMA.MIT.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
Message had a bad or missing To address.
The entire text of the message follows:

Received: From MARIST(MAILER) by TRINCC with RSCS id 1286 for SHAVER@TRINCC;
 Thu, 25-FEB-1988 19:20 EST
Received: by MARIST (Mailer X1.25) id 1277; Thu, 25 Feb 88 19:22:08 EST
Date: Thu, 25 Feb 88 07:35:00 CST
From: GREG%FNALNET.BITNET@CUNYVM.CUNY.EDU
Subject: CMU Telnet problem
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@MARIST>
To: JERRY SHAVER <SHAVER@TRINCC>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments:     Warning -- original Sender: tag was TCPIP-L@BYUADMIN

Thank you all for your assistance. Problem solved and totally
understood!

Regarsd,

Greg Chartrand - Fermilab
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 88 14:20:37 GMT
From:      golds@rlgvax.UUCP (Rich Goldschmidt)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   PC Application Support for Ethernet


How do others out there support the many different ethernet boards for PCs.
Sun's PC-NFS does not support any of the "smart" boards, comes with its own
driver for each board, and tough luck for any network application which 
would like to coexist (unless you build it with their Toolkit).  Locus's
PC-Interface has their own 3Com driver that talks only to their application,
so nothing else can use it.  However, they use the drivers provided by Excelan
or Micom, so it is at least possible to coexist, if you want to write different
application back ends for each of those boards.  And now Excelan has come out
with a new revision of its socket development library which is incompatible
with previous versions!

I am curious what other approaches have been used or might work to have 
several applications share a driver, and work with most of the existing boards.

The lack of standards here between board manufacturers causes application 
developers to support a subset, and really hurts the growth of PC networking.
I always thought it was unfortunate that a particular product only supported
a few boards, until I started looking into what it takes...

Rich Goldschmidt
rlgvax!golds@uunet.UU.NET
uunet!rlgvax!golds
sun!sundc!rlgvax

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 88 14:29:36 GMT
From:      mohamed@hscfvax.harvard.edu (Mohamed_el_Lozy)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Time synchronization in a Distributed Environment

In article <2710@druhi.ATT.COM> aws@druhi.ATT.COM (SteereA) writes:
>  I am looking for articles, references, implementations,
>etc. for solving the problem of keeping N machines within
>a specified time of one another.  I appreciate any and all pointers.

I am directing followup to comp.protocols.tcp-ip, where it would be
more appropriate.  I assume that the machines are networked.

A good start would be in three RFCs written by Dave Mills:
	956	Algorithms for synchronizing network clocks
	957	Experiments in network clock synchronization
	958	Network time protocol (NTP)
They all came out in 1985, and have reasonable references for that time.

A UNIX (BSD only, as I recall) implementation of NTP has been written
at trantor.umd.edu, which also maintains a mailing list.  To get on it
send mail to ntp-request@trantor.umd.edu.

There is also often quite a bit of network time discussion in
comp.protocols.tcp-ip, especially when interesting things like leap
seconds turn up.

BSD4.3 implementations have a timed program, discussed at some length
in the documentation (not available to me right now).

I would very much appreciate some post 1985 references.

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 88 22:30 EST
From:      The Mail Server <Postmaster%TRINCC.BITNET@MITVMA.MIT.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
Message had a bad or missing To address.
The entire text of the message follows:

Received: From MARIST(MAILER) by TRINCC with RSCS id 1611 for SHAVER@TRINCC;
 Thu, 25-FEB-1988 22:30 EST
Received: by MARIST (Mailer X1.25) id 1602; Thu, 25 Feb 88 22:31:50 EST
Date: Thu, 25 Feb 88 16:39:36 MST
From: "C. Philip Wood" <cpw%sneezy@LANL.GOV>
Subject: Link level Ethernet bridges problem solved
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@MARIST>
To: JERRY SHAVER <SHAVER@TRINCC>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments:     Warning -- original Sender: tag was TCPIP-L@BYUADMIN

I want to thank all of you who responded with many helpful suggestions.
And as usual, it appears that the original understanding of the problem
did not lead me to any reasonable conclusion.  The bridge was not a factor.

In particular thanks to 'Merle'

> I dont know if this is your problem but you might look
> at the local ether segment to see if some transcievers
> have been installed improperly etc.


and Doug Blair

> I had an installation with an HP 9000 that had the same problem.
> The HP people swore up and down that their transceiver was fine, but I
> swapped it out anyway and guess what?  it worked.  I would assume that
> other folks might have this problem with their transceivers, and am
> not throwing stones at HP in particular.

We sent some folks in the know out to investigate the segment with the HP
on it.  It turns out that the DEC lanBridge and all the hosts on the
second segment had nothing to do with the problem.  What follows is a
more detailed picture of the problem and the "fix".

    Ha      Hp        Miscellaneous  hosts    DEREP****LanBridge
    |    ? |          (Apollo,Sun,IBMPC)    |
    |    | |                    |
    C.......+.+...................................DESTA
        1 2
Ha== Sun UNIX 4.2 Release 3.4
Hp== HP-UX hp320 6.01 B 9000/320
+ == Thinnet transceiver? with BNC connectors
. == Thinnet
C == BNC connector
* == Fiber
? == no connection

No one seems to know what the extra + was doing connected via 1 foot of
Thinnet at location 1.  However, 1 was swapped with 2 and things started
to work.  It was decided to initial #2 with "NG" and remove it from the
configuration as follows:

    |      |
    C.........+...................................DESTA

Phil Wood,  cpw@lanl.gov



-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 88 23:39:36 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Link level Ethernet bridges problem solved

I want to thank all of you who responded with many helpful suggestions.
And as usual, it appears that the original understanding of the problem
did not lead me to any reasonable conclusion.  The bridge was not a factor.

In particular thanks to 'Merle'

> I dont know if this is your problem but you might look
> at the local ether segment to see if some transcievers
> have been installed improperly etc.


and Doug Blair

> I had an installation with an HP 9000 that had the same problem.
> The HP people swore up and down that their transceiver was fine, but I
> swapped it out anyway and guess what?  it worked.  I would assume that
> other folks might have this problem with their transceivers, and am
> not throwing stones at HP in particular.

We sent some folks in the know out to investigate the segment with the HP
on it.  It turns out that the DEC lanBridge and all the hosts on the
second segment had nothing to do with the problem.  What follows is a
more detailed picture of the problem and the "fix".

	Ha	  Hp		Miscellaneous  hosts	DEREP****LanBridge
	|	? | 		 (Apollo,Sun,IBMPC)	|
	|	| |					|
	C.......+.+...................................DESTA
		1 2
Ha== Sun UNIX 4.2 Release 3.4
Hp== HP-UX hp320 6.01 B 9000/320
+ == Thinnet transceiver? with BNC connectors 
. == Thinnet
C == BNC connector 
* == Fiber
? == no connection

No one seems to know what the extra + was doing connected via 1 foot of
Thinnet at location 1.  However, 1 was swapped with 2 and things started
to work.  It was decided to initial #2 with "NG" and remove it from the
configuration as follows:

	|	  |
	C.........+...................................DESTA
	
Phil Wood,  cpw@lanl.gov

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 88 00:06:43 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Exchanging serial numbers

Here at Sirius Systems we have been discussing a means to protect our
TCP/IP software without placing undue strain on the users.  The primary
concern is that someone might purchase one copy of the package and then
copy it to all his/her systems.  The concept that we came up with is to
exchange serial number information as part of the options field in the
TCP header when two TCP's exchange SYNs at session establishment.  TCP
resets the connection and returns a protocol error if both versions of
the software have the same serial number. 

Our reading of MIL-1778 and RFC-793 leads us to believe that the only
predefined option types are 0 (End of option list), 1 (No-op), and 2
(MSS).  We propose a fourth option (type 3) for exchanging serial
numbers.  The option type would be 3, the length would be 8, the next
two octets would be a vendor code, and the last four octets would be the
serial number.

The separate vendor code and serial number permits vendors to have
identical serial numbers but still allow the overall value of the
combined fields to be unique.  This would prevent potential conflicts
when communicating between different vendors' software/hardware. 

Now comes the reason for this letter: is a strange option in a TCP
header likely to break others' TCP implementations or will other TCPs
ignore an unrecognized option?

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 1988 08:18-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Exchanging serial numbers
Pardon  me  for  saying  this,  but  this  is one of the sorriest
schemes I've ever heard about.  The  only  place  this  would  be
applicable  is  at  the  low end (PC's) as larger system normally
bundle this software in their distribution.  And businesses  that
purchase  larger  systems  generally  aren't  going  to  risk the
penalties for license violation for those system.

Now take it a little further.  The PC's don't generally  talk  to
each  other, so who's going to know if you copy the software?  In
the absolute worst case, the two systems can use an  intermediary
to communicate.

Also, how do you deal with site license where you provide masters
and let them make the copies?

Your best bet is to trust your customers, make good software, and
price it competatively.

Mike
-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 88 08:28:19 MST
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        tcp-ip@sri-nic.arpa
Subject:   Re:  Exchanging serial numbers

>                                 The concept that we came up with is to
> exchange serial number information as part of the options field in the
> TCP header when two TCP's exchange SYNs at session establishment.  TCP
> resets the connection and returns a protocol error if both versions of
> the software have the same serial number.
 
Does this mean you cannot talk to yourself?

Phil Wood, cpw@lanl.gov
 

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 88 14:01:38 PST
From:      Mark Crispin <Crispin@SUMEX-AIM.Stanford.EDU>
To:        Craig Partridge <craig@BBN.COM>
Cc:        TCP-IP Group <TCP-IP@SRI-NIC.ARPA>
Subject:   RFC 1047
[Please forgive any partial message which may have gotten out...]

Craig -

     I read your RFC 1047 with a great deal of interest, since I've been
battling this problem for many years.  I suggest that RFC 1047 should be
included with any distribution of "Internet mail RFC's", since the issues
it addresses are important.

     I am in full agreement with your recommendations, and in fact the
TOPS-20 mailsystem has always used that strategy.  More specifically, the
TOPS-20 SMTP client will wait up to 5 minutes for a response from the SMTP
server, and the TOPS-20 SMTP server limits its actions upon receiving the
EOF "." to closing the mail queue disk file and sending a "wake-up" interrupt
to the mailer, both of which are relatively fast operations.

     I have found that the law of diminishing returns comes into play with
much greater timeouts.  Specifically, an SMTP client which waits twice as
long (10 minutes) before its patience is exhausted does not receive much of
a reward in terms of additional successfully delivered messages, but does
receive a punishment in terms of reduced throughput due to servers which
never do come back.

     I am also not convinced that the delay in sending the "wake-up"
interrupt to the mailer is worth the benefit (the mailer starts work on the
queue right away instead of waiting as long as five minutes for a wake-up
from other sources) of immediate delivery of incoming netmail.  In perverse
circumstances, a delay of as long as 20 seconds can happen in the course of
attempting to send the "wake-up", and another delay of 20 seconds to receive
an acknowledgement.  Since these "perverse circumstances" generally happen
during periods of extreme load, the resulting 40 seconds can, in theory, be
stretched to a much longer period of time.  I have never observed any
problems of this nature; the SMTP synchronization problems I've observed
with the TOPS-20 server have been either a lower-level (TCP or IP) problem
or a bug in the other system's SMTP client.  However, it is something that
I worry about.

     In general, with electronic mail, if there's a choice between doing
a time-consuming act in the server and doing it asynchronously, pick the
latter choice.  Make your SMTP process be a minimal bit-pusher.

-- Mark --

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 88 07:25:07 GMT
From:      OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   Final Call for Papers: IFIP 6.5 Working Conference

ACE +1 (415) 941-3399 Trollheim: +1 (415) 325-9427


FINAL CALL FOR PAPERS FOR THE IFIP 6.5 WORKING CONFERENCE TO BE
      HELD ON OCTOBER 10-12, 1988 IN SOUTHERN CALIFORNIA.  

==============================================================
= The SUBMISSION DATES have been EXTENDED to MARCH 31, 1988. =
==============================================================

The list of netmail contact addresses has been expanded with
addresses on several networks that forward mail to the
conference organizers.  

We ask that this Call for Papers be freely passed along to
anyone who might be interested in submitting a paper, especially
to geographic areas that seem to be out of reach via netmail,
such as South America, Africa, and Asia.  

The long list of Program Committee Members actually represents
the initial list of reviewers, and we are seeking additional
reviewers to deal with the expected 60-75 submitted papers.
Please contact us if you want to be added to out list of
reviewers, or if you want to serve on the main program
committee.  You can contact any of the listed organizers or
program CoChairs by any available means at your disposal.  

Papers that are accepted will be published by North-Holland in
a Hard Cover Proceedings of the Conference.

.PAGE

CALL FOR PAPERS -- 1988 IFIP WG 6.5 INTERNATIONAL 
                   WORKING CONFERENCE ON MESSAGE HANDLING 
                   AND DISTRIBUTED APPLICATION SYSTEMS

                -- 10 to 12 October, 1988

                -- Red Lion Inn, Costa Mesa, California, USA
                   Near the University of California at Irvine

SPONSORED BY: IFIP TC 6 & the University of California at Irvine

PROGRAM:  The purpose of the conference is to provide an
international forum for the exchange of information on the
technical, economic, social, and political impacts and
experiences with computer messaging and distributed application
infrastructures in the automated workplace environment.  The
conference format will be two days of conference paper
presentations combined with one day of workshops.  Papers are
desired in the following topic areas:  

International Standards and Profiles -- 1988 
        Current Status of CCITT/ISO and Future Plans
        Implementors' Agreements and Harmonization
        Implementation Issues and Experience
        Testing and Conformance Activities 

Interconnection and Interworking
        Interconnection Issues and Experiences
          (X.400 ADMD/ADMD, ADMD/PRMD, PRMD/PRMD)
        Multi-Vender Private Domains
        Gateways to/from Non-X.400 Domains and Architectures
        TELEX and TELETEX Interworking
        Postal System Interworking
        Facsimile Interworking
        Voice Mail Interworking
        Multilateral and Bilateral Agreements

User Agent Models and Designs 
        User Agent Functions and Services
        Distributed User Agents (Such as X.400 Message Store)
        User Interface Designs and Experience
        User Agents and User Interfaces for Impaired Users
        Object Collection Management -- Personal & Institutional
        (Store, Organize, Search, Retrieve, Share, Purge, Archive)

Group Communication Models and Services
        Organizational Communication Flows
        Distribution Lists for MHS
        Distributed Conferencing Services
        Real-Time, Multi-Media, Mixed-Mode Conferencing
          (Video, Voice, Graphics, Text -- MHS, FTAM, VTP)
        Models for Group Communication

Information Object Standards for Interchange
        Abstract Syntax and Structure Encoding
          Open Document Architecture
          Open Document Interchange Format
          Electronic Document Interchange
          Electronic Funds Transfer
        Multi-Media Objects (Graphics, FAX, Voice, Text)        

Distribution of Services and Applications 
        Workstations and Servers in Networks
        Services Based on Cooperating Distributed Processes
          (MHS, FTAM, Directory, DBMS, Conferencing)

Security, Authentication, Privacy, Confidentiality
        Authentication Framework Standards 
        Exchange of Encrypted Information Objects
        TransBorder Data Flow 
        Legal Issues

Management and Operation of Distributed Services
        Registration of Entities and Domains
        Administration of Directory Information Bases
        Distribution of Authority and Responsibility
        Fault Isolation and Reporting
        Queuing, Routing, and Congestion 
        Quality of Service Management

Directory Services
        Naming and Addressing
        Public Directory Services
        Interworking Between Public and Private Services
        Interworking of Directory with other Applications

Policy Issues
        International Issues
        National Issues
        Public Regulatory Issues
        Public Access Issues

Impacts of MHS and Distributed Services
        Social and Behavioral Impacts
        Organizational Impacts
        National and Governmental Impacts 

INSTRUCTIONS TO AUTHORS:  Prospective Authors are invited to
submit for review, unpublished original contributions (not
exceeding 5000 words) which describe recent developments on any
design or service aspect of computer message systems and
distributed application systems.  

PUBLICATION:  Proceedings of the Conference will be Published by
North-Holland, as has been done for prior IFIP 6.5 conferences.

DEADLINES: 

Today:  Send a message or letter or phone any of the contacts
        below, stating your intention to submit a paper,
        or stating your general interest in the conference.  

March 29, 1988: Draft Versions of Papers Due for Review.
  May 30, 1988: Notification of Acceptance/Rejection.
 June 30, 1988: Camera-Ready papers required for publication.

 SUBMIT PAPERS TO: Dr. Peter Schicker
                   Zellweger Telecommunications AG
                   CH-8634 Hombrectikon, Switzerland

                   Telephone: +41 55 416 377
                   Telex:            875 558
                   Facsimile: +41 55 416 385
         BITNET:  "Peter Schicker" <schicker@CERNVAX>

       OR TO:      Ole-Jorgen Jacobsen
                   Advanced Computing Environments
                   480 San Antonio Road   Suite 100
                   Mountain View, California, USA 94040

                   Telephone:  +1 415 941 3399
                               +1 415 325 9542
                   Internet:   Ole@CSLI.Stanford.EDU

PROGRAM COMMITTEE:   Peter Schicker (CH - European CoChair)
                     Ole Jacobsen (USA - North American CoChair)

David Biran (IL)       Tim Bishop (CDN)       Bert Boutmy (NL)       
Ebe Butrini (I)        Ian Cunningham (CDN)   Andre' Danthine (B)    
Harry Forsdick (USA)   Jose' Granado (P)      H.G. Hegering (D)      
Christian Huitema (F)  W.J. Jaburek (A)       Dipak Khakhar (S)      
Thomas Kalin (YU)      Farouk Kamoun (TN)     Steve Kille (GB)     
Albert Ku"ndig (CH)    Susan Lebeck (USA)     Erik Lillevold (N)     
Dan Lynch (USA)        James McHugh (USA)     Manuel Medina (E)      
Richard Miller (USA)   Najah Naffah (F)       Yukio Nakagome (J)     
S. Ramani (IND)        Steve Rothwell (USA)   Horst Santo (D)        
Erik Skovgaard (CDN)   Hugh Smith (GB)        Otto Spaniol (D)       
Rolf Speth (B)         Doug Steedman (CDN)    Einar Stefferud (USA)  
John Stidd (USA)       Tibor Szentivany (H)   Fred Szatnjnkrycer (F) 
David Taylor (USA)     Liane Turoco (BR)      Ronald Uhlig (USA)     
James White (USA)      Paolo Zupa (I)         


ORGANIZING COMMITTEE:  Einar Stefferud (General Chair)
                       James McHugh (Local Arrangements Chair)
                       Jeff Cole (UCI Conference Coordinator)

NETWORK MAIL CONTACTS:  

     "Peter Schicker BITNET"      <Schicker@cernvax>
     "Ole Jacobsen INTERNET"      <Ole@CSLI.Stanford.edu>
     "Einar Stefferud INTERNET"   <EStefferud@NRTC.Northrop.com>
     "Einar Stefferud INTERNET"   <EStefferud@ics.uci.edu>
     "Einar Stefferud BITNET"     <EStef@uci>
     "Jeff Cole BITNET"           <JTCOLE@uci>
     "Jeff Cole INTERNET"         <JTCole@ics.uci.edu>
     "Conference Office BITNET"   <IFIP65@uci>
     "Conference Office BITNET"   <IFIP65@cernvax>
     "Conference Office INTERNET" <IFIP65@ics.uci.edu>
-------

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 88 12:49 EST
From:      The Mail Server <Postmaster%TRINCC.BITNET@MITVMA.MIT.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
Message had a bad or missing To address.
The entire text of the message follows:

Received: From MARIST(MAILER) by TRINCC with RSCS id 2610 for SHAVER@TRINCC;
 Fri, 26-FEB-1988 12:49 EST
Received: by MARIST (Mailer X1.25) id 2601; Fri, 26 Feb 88 12:49:51 EST
Date: Fri, 26 Feb 88 10:37:10 MST
From: STJOHNS@SRI-NIC.ARPA
Subject: Re:  Exchanging serial numbers
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@MARIST>
To: JERRY SHAVER <SHAVER@TRINCC>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments:     Warning -- original Sender: tag was TCPIP-L@BYUADMIN

Pardon  me  for  saying  this,  but  this  is one of the sorriest
schemes I've ever heard about.  The  only  place  this  would  be
applicable  is  at  the  low end (PC's) as larger system normally
bundle this software in their distribution.  And businesses  that
purchase  larger  systems  generally  aren't  going  to  risk the
penalties for license violation for those system.

Now take it a little further.  The PC's don't generally  talk  to
each  other, so who's going to know if you copy the software?  In
the absolute worst case, the two systems can use an  intermediary
to communicate.

Also, how do you deal with site license where you provide masters
and let them make the copies?

Your best bet is to trust your customers, make good software, and
price it competatively.

Mike
-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 88 12:49:44 EST (Fri)
From:      wb6rqn!brian@Sun.COM (Brian Lloyd)
To:        bellcore!sri-nic.arpa!tcp-ip@Sun.COM
Subject:   Re:  Exchanging serial numbers
No Phil, talking to yourself is permitted.  All we do in that case is compare
the source and destination host addresses and permit the connection if they
are the same even though the serial numbers also match.

Quite frankly, I like talking to myself.  I am quite a nice guy and I find
my company quite stimulating :-).

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 88 14:58:13 EST
From:      terry@DEC-VAX-11-750.ARPA
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Exchanging serial numbers
All,

>Pardon  me  for  saying  this,  but  this  is one of the sorriest
>schemes I've ever heard about.  [...]

First, I completely agree with Mike's evaluation of the software
protection  scheme.  The scheme doesn't appear to me to be well 
thought out.

>Your best bet is to trust your customers, make good software, and
>price it competatively.

However, this last statement is wishful thinking.  Show me a person
who has never seen a piece of pirated software, and I'll show you
someone who has never seen a computer.

Terry Robb
-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 88 19:23:00 EST
From:      Mills@UDEL.EDU
To:        ineng@isi.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Source-quench wrench
Folks,

In a previous message I concluded that the source-quench policy implemented
for the NSFNET Backbone fuzzballs could in fact help reduce the impact of
severe congestion now affecting that network. This conclusion was reached on
the basis of scanty data involving a Cray TCP implementation.

Mike Minnich and I cooked up an experiment to determine the effectiveness of
the policy with the latest 4.3 TCP, including the Van Jacobson mods, and to
search for possible fairness problems. The experiment involves the following
configuration:

	+-------+		+-------+		+-------+		
	|	| 10 Mb/s Ether	|	|   9600-bps	|	|
	|source	|==============>|gateway|==============>| sink	|
	|	|		|	|		|	|
	+-------+		+-------+		+-------+		

Data originates at the source (Sun/3), piles up at the gateway (fuzzball) and
is discarded at the sink (fuzzball). The gateway uses the same
selective-preemption and source-quench policies as in the NSFNET Backbone and
previously described to this list. In the experiment the traffic was four (4)
simultaneous FTP data connections, each with a max send window of about 4000
octets and a max receive window of about 2000 octets. There was enough
buffering that no packets were lost and only a few retransmissions during the
experiment, which involved a couple of megabytes.

The experiment was started with quench messages disabled at the gateway and
allowed to stabilize. The mean delay in the queue on the 9600-bps side of the
gateway was measured at about 6.3 seconds. Quench messages were then enabled,
with the result that the mean delay dropped to about 4.2 seconds, or a
reduction of about one-third. According to well-known results from queueing
theory, this means a reduction of one-third in buffering requirements as well.
All four transfers proceeded at similar rates, as confirmed by real-time
observation.

Without getting into a detailed discussion about the fuzzball or 4.3 TCP
implementations, it should be mentioned that the fuzzball sends ICMP Source
Quench messages to the host with the most data queued for transmission at a
rate depending on the excess of the measured mean queue length above a preset
threshold, in this case about 1.5. The 4.3 TCP reacts to a quench message by
immediately reducing the send window size and then allowing it to grow as the
result of ACKs for previously sent data. It would seem that the system
performance could be further improved by tuning the various time constants and
gain settings in both implementations.

Since much of the congestion now occuring in the NSFNET Backbone results from
very similar configurations, we conclude (a) the fuzzball policy can improve
system performance in a significant way and (b) the recent 4.3 mods should be
deployed quickly and to the widest possible extent.

Dave
-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 88 16:54:00 GMT
From:      phil@amdcad.AMD.COM (Phil Ngai)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: KA9Q as an IP router?

In article <15696@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes:
<The 3C501 ethernet interface supported by the KA9Q sofware will never
<make a high performance gateway.  It has only one buffer and drops
<packets sent too close together or while it is transmitting.

We've got a LANCE on an AT half card. Anyone interested in porting
KA9Q to it? We might even be willing to pay (a reasonable fee). It
would also be nice if someone could fix the VT100 emulation. 

-- 
I speak for myself, not the company.

Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 1988 09:04-EST
From:      CERF@A.ISI.EDU
To:        wb6rqn!brian@Sun.COM
Cc:        bellcore!sri-nic.arpa!tcp-ip@Sun.COM, doug%sirius@Sun.COM
Subject:   Re: Exchanging serial numbers
If you plan to break if you get the same serial number as you sent,
you will fail to provide service to processes that call themselves.
The TCP protocol specifically allows this (supports it as a
simultaneous initiation of connection case). The idea is to allow
processes, whereever situated, to use the TCP/IP as a way of communicating.
It sounds to me as if your serial number checking plan will break
that feature...

Vint

P.S. I just realized that your plan would break communications
between distinct processes in the same host should they try
to communicate via TCP/IP. In applications for which software
is moved from one place to another during or prior to execution,
a process might well call another in the same host without 
realizing it. Furthermore, you might want that feature so as to
avoid having to do something special to distinguish inter-host
and intra-host communication.

Vint
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 1988 09:27-EST
From:      CERF@A.ISI.EDU
To:        wb6rqn!brian@Sun.COM
Cc:        bellcore!sri-nic.arpa!tcp-ip@Sun.COM
Subject:   Re:  Exchanging serial numbers
What if your host has two interfaces into the Internet with different
Internet addresses - more checks for OK sources/sinks for a particular
serial number?

As a practical matter, if the checking causes enough difficulty, either
you will dry up your market or someone will find a way to disable the
check and then propagate copies of the "denatured" versions...

The idea, while having some surface appeal, feels a lot like copy
protect schemes which drove away the market.

Vint
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Feb 88 16:21 EST
From:      BEAME%MCMASTER.BITNET@CUNYVM.CUNY.EDU
To:        tcp-ip@sri-nic.ARPA
Subject:   IEEE 802.3 LAN Considerations vs. 802.5 Token Ring

  I've been asked by my boss, to comment on a document that deals with
Ethernet Vs IBM Token Ring. It is EXTREMLY biased in favour of IBM Token
Ring.

I recall just recently a message about Token Ring Bridges source routing
and what the IEEE said about it. If someone has that message saved and
could sent it to me, I would be very appreciative.

If anyone has figures on maximum through-put of 10 Mbps Ethernet, I could
make good use of them.

Also if anyone has information on "token" loss and its impact on a Token
Ring, I could include it in my comments. (The above document never mentions
the posibility).


     - Carl Beame
       Beame@MCMASTER.BITNET


-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 88 14:04:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Exchanging serial numbers

If you plan to break if you get the same serial number as you sent,
you will fail to provide service to processes that call themselves.
The TCP protocol specifically allows this (supports it as a
simultaneous initiation of connection case). The idea is to allow
processes, whereever situated, to use the TCP/IP as a way of communicating.
It sounds to me as if your serial number checking plan will break
that feature...

Vint

P.S. I just realized that your plan would break communications
between distinct processes in the same host should they try
to communicate via TCP/IP. In applications for which software
is moved from one place to another during or prior to execution,
a process might well call another in the same host without 
realizing it. Furthermore, you might want that feature so as to
avoid having to do something special to distinguish inter-host
and intra-host communication.

Vint

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 88 14:27:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Exchanging serial numbers

What if your host has two interfaces into the Internet with different
Internet addresses - more checks for OK sources/sinks for a particular
serial number?

As a practical matter, if the checking causes enough difficulty, either
you will dry up your market or someone will find a way to disable the
check and then propagate copies of the "denatured" versions...

The idea, while having some surface appeal, feels a lot like copy
protect schemes which drove away the market.

Vint

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 88 16:13:48 GMT
From:      nasa@ms.uky.edu (Eric T. Freeman)
To:        comp.protocols.tcp-ip
Subject:   tn3270

Could someone send me the address of any place I can ftp the newest
version of tn3270?  Thanks.

Eric Freeman
University of Kentucky Computer Science
nasa@g.ms.uky.edu

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 88 16:28:26 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Re: Exchanging serial numbers

I am sorry that some of you think that the concept of exchanging serial
numbers is a poor one.  I agree that it provides only limited protection
but it is a concern of the principles of the corporation. 

In the environment where it will run most frequently, i.e. in a LAN
consisting of Convergent 'S' series UNIX boxes and Convergent NGen
workstations, the scheme will be relatively effective.  NGens run a
distributed operating system called CTOS so the serial number exchange
will be effective.

I appreciate the feedback and I understand that some of you would not
choose such a mechanism.  On the other hand it will work and it will not
impact operations with other, dissimilar systems.  I reiterate my
original request: will exchange of serial numbers in the TCP options
field cause problems with the other TCP implementations?

Thanks again.

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 88 21:21:00 GMT
From:      BEAME@MCMASTER.BITNET
To:        comp.protocols.tcp-ip
Subject:   IEEE 802.3 LAN Considerations vs. 802.5 Token Ring


  I've been asked by my boss, to comment on a document that deals with
Ethernet Vs IBM Token Ring. It is EXTREMLY biased in favour of IBM Token
Ring.

I recall just recently a message about Token Ring Bridges source routing
and what the IEEE said about it. If someone has that message saved and
could sent it to me, I would be very appreciative.

If anyone has figures on maximum through-put of 10 Mbps Ethernet, I could
make good use of them.

Also if anyone has information on "token" loss and its impact on a Token
Ring, I could include it in my comments. (The above document never mentions
the posibility).


     - Carl Beame
       Beame@MCMASTER.BITNET

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 88 07:44:35 GMT
From:      cyrus@hi.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   rsh equivalent


I am looking for PD version of code that accomplishes the same thing
as rsh but conforms to the RFC's (machine name case independent).
We have users who like to pipe BIG jobs from one machine to another
machine via rsh's.  

The reason I am interested in something other than rsh is because
here at UNM we are strongly considering disallowing the r* programs
(rsh/rcp/rlogin) because they do NOT conform to the RFC's as well
as being BIG security problems (.rhosts).

I have heard of other Universities defining their own protocols to
accomplish distributed processing without the big security holes.
I would appreciate ANY information any of you might have concerning
such protocols/utilities and there possible availability.

Thanks in advance,

-- 
    @__________@    W. Tait Cyrus   (505) 277-0806
   /|         /|    University of New Mexico
  / |        / |    Dept of Electircal & Computer Engineering 
 @__|_______@  |       Parallel Processing Research Group (PPRG)
 |  |       |  |       UNM/LANL Hypercube Project
 |  |  hc   |  |    Albuquerque, New Mexico 87131
 |  @.......|..@    
 | /        | /     e-mail:      
 @/_________@/        cyrus@hc.dspo.gov

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 88 11:56:22 GMT
From:      leonid@TAURUS.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: Exchanging serial numbers

In article <8802251906.AA04676@wb6rqn.UUCP> brian@wb6rqn.UUCP writes:
>Here at Sirius Systems we have been discussing a means to protect our
>TCP/IP software without placing undue strain on the users. ...

May I mention a very much similar solution done by Sun Microsystems in their
PS-NFS 2.0 product, and please excuse me if this has already been mentioned.
They just used ICMP discard packets to broadcast the serial number of each
booting system. All non-PC-NFS system dropped those packets as they should,
while all PC-NFS's look at this broadcast, make some sanity check and compare
it to their own. If a violation has been detcted, the punishment is to
stop both systems with the same number and print an appropriate message
to the screen.

To tell you the truth, I'm not really sure weather they use ICMP discard or
UDP discard packets, but all are better than try to twist TCP for one's
particular needs. Also, if a serial number problem would cause a TCP connection
to fail, how a user would know that there is a problem hah?

It seems that some vendors that really need a serial number protection scheme,
should try to define a new UDP service which would very conveniently handle
this and maybe other problems.

Leonid

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 88 19:21:00 GMT
From:      jacob6@ntvax.UUCP
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for AT&T 3B2'S



Hi Folks,

I was wondering if any of can give some information about
the availability of PD source of tcp-ip for AT&T 3b2 machine.
Your response in this matter will be deeply appreciated.

-Jey

North Texas state University
Denton, Tx 76201.

UUCP: convex!ntvax!jacob6

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 88 19:26:00 GMT
From:      jacob6@ntvax.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP for AT&T 3B2'S


/* Written  1:21 pm  Feb 28, 1988 by ntvax.UUCP!jacob6 in ntvax:comp.protocols.tcp-ip */ /* ---------- "TCP-IP for AT&T 3B2'S" ---------- */ Hi Folks,

Iam wondering if any of you folks know about any PD source
of TCP-IP for AT&T 3B2 machines.  Your response in this matter
will be deeply appreciated.

-Jey

North Texas state University
Denton, Tx 76201.

UUCP: convex!ntvax!jacob6

/* End of text from ntvax:comp.protocols.tcp-ip */

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 88 20:01:01 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Re:  Exchanging serial numbers

Thanks for the responses.  Most of the responses have been of a
philosophical rather than a technical nature but I appreciate them
anyway.  I guess that a further comment on the proposed serial number
exchange system is warrented.

The intention behind exchanging serial numbers is very simple: to keep
the software from being useful if it is copied.  It protects by
preventing an operator from gaining an advantage from the copy while the
original is still running.  In this way it is definitely a form of copy
protection.  The intention is to provide a scheme that will help protect
our software in a manner that is totally transparent to the user.  Any
protection system that in any way impedes the operations of a legitimate
user is not acceptable to us (I don't like copy protection schemes
either but I do want to protect our software).

We accept this scheme as being imperfect but useful and, as such, worth
our time to implement.  In the environment where we operate (Convergent
Technologies workstations) this will be an effective protection scheme.

As for two clients running in the same host, we have dealt with that
problem.  In our implementation of the protection scheme we bother to
exchange serial numbers only of the source and destination addresses are
different.  Should the remote system fail to return the serial number
option the connection is permitted.  The remote system has identified
that it is not one of our software implementations simply by the
omission of the serial number option in the TCP options field. 

We have never bothered to deal with multi-homed hosts since our software
assumes a 1-to-1 correspondence between a host and an IP address.
Although that is not the case with all systems in the Internet, it is
with our software.

Now I will ask my original question again.  Will the appearance of a
strange option in the TCP header cause a problem for other
implementations of TCP?  I want to know if my serial number exchange
will confuse other TCP implementations or will they just ignore and
discard the information as I suspect they should.  As I stated in my
second paragraph, we want the protection to be transparent and if it
prevents connectivity we won't use it.

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 88 20:10:31 GMT
From:      wesommer@athena.mit.edu (William Sommerfeld)
To:        comp.protocols.tcp-ip
Subject:   Re: rsh equivalent

In article <23511@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes:
>I have heard of other Universities defining their own protocols to
>accomplish distributed processing without the big security holes.
>I would appreciate ANY information any of you might have concerning
>such protocols/utilities and their possible availability.

We should have something for you in about a month..  the Kerberos[1]
authentication system developed here at Athena should be released in
"about a month".  It's written in C, and is known to work on the VAX
and RT/PC (both running 4.3BSD UNIX), the Sun (release 3[?]), and
partially (subject to memory restrictions and the lack of an operating
system) on the IBM PC.  We use DES as the encryption algorithm; we
will [probably] ship a reasonably fast software DES to US sites, while
international sites may have to find their own DES implementation[2]. 

Note that kerberos is not a panacea (is anything?); you still have to
be careful about how you choose your password and where you type it;
kerberos allows you to avoid sending your password over the network in
the clear, but it can't prevent you from doing that if you so choose.
If you make your files globally writable, Kerberos can't save you. 

We have kerberos-authenticated versions of rlogin, rsh, rcp, and NFS;
we haven't done kerberos authenticated telnet or ftp [yet?], mostly
because we don't use either protocol very much internally.

				Bill Sommerfeld
				MIT Project Athena

[1] Kerberos is the Greek name for what the Romans called Cerberus,
the three headed dog guarding the entrance to Hell.

[2] Flames about DES exportability to /dev/null please; we'd prefer to
believe John Gilmore's analysis of the laws, but we'd rather not find
out the hard way that he was wrong.

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      29 Feb 88 00:06:52 GMT
From:      encore!peralta@husc6.harvard.edu  (Rick Peralta)
To:        tcp-ip@sri-nic.arpa
Subject:   Bogus TCP packets
When TCP gets a packet that is flawed for some reason, what be done with it?
According to the TCP spec.  bogus data should be ignored.  Also, in the same
documents it is said that some allowances should have to be made.

Officially you should just throw the packet away, but that causes problems.
I have been experimenting with just accepting what looks ok and ignoring
the rest.  This seems ok, especially if you try and do output whenever
the other side says something strange.

Any pointers to authoratative documents, unauthoratative documents, comments,
suggestions, hints, pointers and opinions greatly appreciated.

If this turns out to be a burning issue or the reignition of a Holy War;
I offer to collect all information and summarise it to the net.

Rick

-- 
Rick Peralta, Encore Computer Corp, Marlboro MA   (617) 460-0500
arpa: peralta@multimax.arpa (192.5.63.14)
uucp: {allegra,decvax,ihnp4,linus,necntc,talcott}!encore!peralta
"Once you've got all the questions; the answers should be easy."
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Feb 88 08:38:42 EST
From:      "John A. Shriver" <jas@monk.proteon.com>
To:        Arthur L Anger <ANGER@MITVMA>
Subject:   [Postmaster%TRINCC.BITNET@MITVMA.MIT.EDU: Undeliverable mail]
One more of several complaints about SHAVER@TRINCC.
----------------------------Original message----------------------------
Will somebody please terminate the offending mailer.  Bugs causing
mail to buonce to lists should be fixed rapidly...

Received: by monk.proteon.com; Fri, 26 Feb 88 20:07:34 EST
Message-Id: <8802270107.AA03720@monk.proteon.com>
Received: from MITVMA.MIT.EDU by SRI-NIC.ARPA with TCP; Fri 26 Feb 88
 10:20:44-PST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 26 Feb 88 13:17:44 EST
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Received: from trincc.bitnet (smtpuser) by MITVMA.MIT.EDU (Mailer X1.25) with
 BSMTP id 5199; Fri, 26 Feb 88 12:54:30 EST
Received: from JNET-DAEMON by trincc.bitnet; Fri, 26 Feb 88 12:49 EST
Date: Fri, 26 Feb 88 12:49 EST
From: The Mail Server <Postmaster%TRINCC.BITNET@MITVMA.MIT.EDU>
Subject: Undeliverable mail
To: TCP-IP@SRI-NIC.ARPA

Message had a bad or missing To address.
The entire text of the message follows:

Received: From MARIST(MAILER) by TRINCC with RSCS id 2610 for SHAVER@TRINCC;
 Fri, 26-FEB-1988 12:49 EST
Received: by MARIST (Mailer X1.25) id 2601; Fri, 26 Feb 88 12:49:51 EST
Date: Fri, 26 Feb 88 10:37:10 MST
From: STJOHNS@SRI-NIC.ARPA
Subject: Re:  Exchanging serial numbers
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@MARIST>
To: JERRY SHAVER <SHAVER@TRINCC>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments:     Warning -- original Sender: tag was TCPIP-L@BYUADMIN

Pardon  me  for  saying  this,  but  this  is one of the sorriest
schemes I've ever heard about.  The  only  place  this  would  be
applicable  is  at  the  low end (PC's) as larger system normally
bundle this software in their distribution.  And businesses  that
purchase  larger  systems  generally  aren't  going  to  risk the
penalties for license violation for those system.

Now take it a little further.  The PC's don't generally  talk  to
each  other, so who's going to know if you copy the software?  In
the absolute worst case, the two systems can use an  intermediary
to communicate.

Also, how do you deal with site license where you provide masters
and let them make the copies?

Your best bet is to trust your customers, make good software, and
price it competatively.

Mike
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      29 Feb 88 21:02:47 GMT
From:      shj@ultra.UUCP (Steve Jay)
To:        comp.protocols.tcp-ip
Subject:   FTP vs. VMS & long passwords

FTP client on an Amdahl (UTS580-1.1.3, 4.3 Net) system or Ultrix (V2.0-1) gets

   "530 Login failed (bad Username or Password), give new USER and PASS "

when attempting to use FTP server on a VAX VMS system, and the password
for the VAX account is over 8 characters long.

This has been observed with VAX's running Wollongong (versions 3.1 & 4.0)
and Excelan (EXOS Version 4.5) servers.  Client FTP on a BSD 4.3
system to the VMS servers works fine.  The UTS and Ultrix clients also
work when the VMS password is 8 or fewer characters.

Has anyone else seen this behavior?  Does anyone know who's fault it is?
Who should I complain to?

I am not on the tcp-ip list, so please send responses directly to me
at the email addresses shown below.

Thanks for your help.

Steve Jay                       domain: shj@ultra.com
Ultra Network Technologies	Internet: ultra!shj@ames.arc.nasa.gov
2140 Bering drive               uucp: ...ames!ultra!shj
San Jose, CA 95131		
408-922-0100

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      29 Feb 88 21:40:22 GMT
From:      hagan@SCOTTY.DCCS.UPENN.EDU (John Dotts Hagan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Terminal Servers

I strongly recommend paying special attention to the Encore annex terminal
servers and cisco's terminal server.  Both are quality products that implement
many of the newest and best features.

Penn has adopted the annex as our terminal server of choice, but we made the
decision before the cisco product had added a bunch of new features (like
a good reverse terminal service).

I would also go on record as saying the Bridge products we evaulated about
12 months ago were not good at all.  However, a new major release of software
is out and I have no experience with it.

--Kid.

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      29 Feb 88 21:59:05 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   TN3270 for SystemV

Greetings All....
I was wondering if anyone had gotten around to porting TN3270 over to System V?
I would really appreciate any info that anyone would care to share on the sub-
ject.
		Thanks in advance,
				  Chris VandenBerg
				   ACC
				   805 963-9431
				   chris@acc-sb-unix.arpa
	"Captain, I cannah' change the laws of PHYSICS..."
	"Scotty, you're fired!"

END OF DOCUMENT