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 April 1988 (457 messages, 246155 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/04.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 00:00:01 GMT
From:      meese@kremvax.arpa
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   OSI abandoned!


	WASHINGTON -- In a simultaneous announcement that took the
computer industry by surprise, OSI leaders today said that they were
abandoning their effort to promote the OSI Protocol Suite in favor of
the existing US Department of Defense (DoD) ARPANET Protocol Suite. 

	The official reason cited for the decison was a new report from
the Office of Technology Assessment stating that the manpower required
to fully implement and test even the few OSI protocols that are now
defined would consume the entire output of American university computer
science programs for the rest of the century, and that printing and
distributing the necessary protocol specifications would consume the
entire American and Canadian paper supplies for the next five years. 

	However, one high-placed source speaking on condition of
anonymity said, ``The whole OSI thing was a practical joke one of the
guys cooked up a few years ago.  Nobody ever expected anybody to take it
seriously.  I mean, who would believe an organization supposedly
dedicated to tearing down barriers to free and open communications
between computers when it's run by a former director of the National
Security Agency? I guess computer people are a lot more gullible than we
thought.  We kept dropping hints, making the whole thing more and more
ridiculous. We hoped that people would eventually catch on, but it didn't
work.  Finally, our consciences got to us.''

	In related news, officials at the Mitre Corporation in Bedford,
Massachussetts reported that one of their employees, as yet publicly
unidentified, froze ``as solid as stone'' when he heard the announcement. 
Medical experts have as yet been unable to communicate with the victim
or get him to relax his facial muscles, which are reportedly locked into
what was described as an ``enormous grin''. 

	AP-NR-04-01-88 0001EST

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 00:31:17 GMT
From:      schoff@A.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: OSI does not mean X.25


    ALL OF THIS IS AVAILABLE *NOW*.  The Transport, Internet, and host-
    gateway protocol standards are done.  They are not "working drafts".
    They are being implemented.  They are already available in commercial
    products from at least one large computer manufacturer (DG).  You
    can get copies of the standards from your local national standards
    body.  In Finland, call Esko Ojanpera at (+358)-0-456 65-6.

Is it interoperable with anyone else's?  Does it work in an OSI internet?
[ let's say 4 ethernets, a 802.5, and a X.25 interconnection
	for simplicity sake].

Or is it the standard:

	It Talks To Itself on a Single Cable

Marty

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 00:34:18 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: SLIP working group?

> ... it is in fact true.  He said the purpose of these committees is to
> produce a solution that makes technical sense AND places all parties
> involved at equal DISadvantage, this concept making more sense in a
> commercial environment....

Thank you.  I couldn't have asked for a more damning indictment of the
international standards process.

Someday, perhaps there'll be a protocol standards organization
controlled completely by users. Realizing the importance of the process,
they will each invest sufficient time and money so that they can be
thoroughly versed with the technical issues. However, anyone associated
with a commercial vendor of products controlled by the standards in
question would be automatically disqualified from membership.

I can dream, can't I?

Phil

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 02:08:12 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET

It might not be that bad...  the Bell System Tech. J. a few years ago had
an article on supplying telephone power directly over the optical fiber,
using LEDs and photocells.  Efficiency was quite high -- photocells do
a good job when they see light of the right wavelength.
	Stuart Levy

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 03:39:30 GMT
From:      jru@etn-rad.UUCP (John Unekis)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc
Subject:   PC to SUN


  Does anyone know of an intelligent (on-board cpu+memory) comm 
  controller that will drive multiple serial channels on a VME
  bus. It should have software support for SUN OS, and allow PC/NFS
  or some other SLIP type of file exchange to run over the comm 
  lines, including support on the PC side under DOS.

  Any help is appreciated.

  {ihnp4 or jplgodo or voder} !wlbr!etn-rad!jru

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 04:36:16 GMT
From:      milazzo@RICE.EDU (Paul Milazzo)
To:        comp.protocols.tcp-ip
Subject:   The case for SLIP CRCs

The lack of link-level checking in SLIP has caused us no end of
trouble.  Higher-level checksums help, but NOT enough.

The connection in question is a link to a site located a few blocks off
campus.  Engineered for the lowest possible cost, the link consists of
two leased cable pairs, each 4 to 5 miles long, driven by limited-
distance "modems"; it connects two SUN 3/1xx machines speaking SLIP at
9600 baud through console serial ports.  The MTU is 576 bytes.

The link performs poorly:  late at night, perhaps 2% of 50-byte
datagrams and 30% of 500-byte datagrams delivered contain errors; the
daytime error rate is usually higher.  Fortunately, the link, while
important, is lightly used.

UDP sans checksums was predictably a disaster; the off-campus domain
server contained the strangest cached information imaginable.
Activating UDP checksumming on all our name server hosts protects local
domain traffic; it does NOT protect the off-campus site from errors in
non-checksummed domain packets originating elsewhere in the Internet.

TCP traffic is of course immune to link-level vagaries, right?  Wrong.
I have rcp'ed and FTPed many large files over this link; more often
than not they arrive damaged in some subtle way.  Let me repeat:  files
transmitted via image (TYPE I) FTP between identical hosts separated by
a single SLIP link often fail to survive the trip.

I have not analysed in detail the damage to the data, but the effect is
real, if difficult to explain.  I can only imagine that at the error
rates we experience, damage transparent to the IP checksum algorithm
sometimes occurs.  I believe a link-level CRC would pass fewer errors.
If not, it would at least pass DIFFERENT errors, substantially
improving the error detection when used together with the IP checksum
algorithm.

The morals of our story:

    1) Make sure your domain server host checksums UDP packets.
    2) Sometimes TCP checksums are not enough.

                                Paul G. Milazzo <milazzo@rice.EDU>
                                Dept. of Computer Science
                                Rice University, Houston, TX

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 04:41:55 GMT
From:      droms@BKNLVMS.BITNET
To:        comp.protocols.tcp-ip
Subject:   NFS across the Internet

I'd like to hear from anyone who has successfully run NFS across the
Internet, or who can point me to references reporting the use of NFS
across the Internet.  By "across the Internet", I mean between sites
on separate LANs, managed by disjoint administrations.  Thanks...

- Ralph Droms
  Department of Computer Science
  Bucknell University
  droms@bknlvms.bitnet

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 04:46:44 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet ring

Alex,  Thanks for the excellent tutorial on the difference between
layer 2 and layer 1!  (or have I messed up the numbers???) It continues
to amaze me how innovative people can figure out how to maximize
things for new situations.  In the last few weeks I have seen
references to "brouters" (bridge/router -- level 2/level 3 animals).
I get the feeling that the primorial ooze of networking (or distributed
computation) is still in the fermentation stage and is not "ready for
drinking".  

Anyway, Steve, you got "lucky" ("smart" is more accurate because Steve
know there was a resource out there, somewhere) because Alex chimed in.

Dan
-------

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 05:07:53 GMT
From:      droms@BKNLVMS.BITNET
To:        comp.protocols.tcp-ip
Subject:   Checksums (again)

Having come in at only at the tail end of this discussion, I don't know
if anyone has pointed out that, assuming a packet length of < 2**16-1
words, the checksum algorithm can wait to add back all the carry bits
until *after* the checksum loop is completed.  I.e.:

while (computing-the-checksum) {
    checksum += buf[i++];
    }
checksum = checksum && 0xFFFF + (checksum >> 16);
checksum = checksum && 0xFFFF + (checksum >> 16); /* sic - the first carry */
                                                  /* "add back" may cause  */
                                                  /* a second carry out    */

Using this technique, and unrolling the loop to do 32 additions in line,
I was able to reduce the average number of instructions per short word
from ~10 to 3+ on an IBM RT PC (since the RT is a register-to-register
RISC CPU, 3 instructions per short word is the minimum to load the word,
add to the checksum and increment the pointer).  This optimization
reduced the time spent in the RT 4.2BSD checksum routine from 10% to
about 1% on large TCP data transfers, with a resulting increase in
throughput of about 10%.

- Ralph Droms
  Department of Computer Science
  Bucknell University
  droms@bknlvms.bitnet

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 05:17:56 GMT
From:      gds@spam.istc.sri.com (Greg Skinner)
To:        comp.protocols.tcp-ip,comp.mail.misc,comp.bugs.4bsd
Subject:   sendmail queueing discipline

For those who are unfamiliar, sendmail attempts an SMTP session for
each message in the queue.

When on networks where bandwidth is at a premium, this may be fine.
Where it is not, it can be expensive, especially when it involves
repeatedly tearing down and setting up a TCP connection.

I did some checking and discovered that SMTP was perfectly willing to
accept multiple mail transactions to the same host for 4.[23]bsd
systems.  There was a noticeably longer pause between the first "mail
from" command and subsequent "mail from"'s, but it did work.

I may have an opportunity to rewrite sendmail to make multiple mail
transactions to the same host within one SMTP session.  I'd like to
know if anyone else has done this on a 4.[23]bsd system (can I get the
patches :-), if any other mail delivery agents do this, and how people
feel about it.

--gregbo

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 05:23:16 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   ignoring UDP checksums


Datagrams without an end-to-end check are dangerous. There are lots
of places for the datagram to get damaged without the ethernet CRC
detecting it. An ethernet bridge with local memory might have a bad
bit and corrupt one out of 1000 packets; if it doesn't put some kind
of check in the packet when it's received and verify it again as the
packet is transmitted, one in 1000 packets would get corrupted and
lots of files accessed via NFS would lose lots of bits.

The same problem exists in IP routers, only worse because they're
more complicated.

I don't know how most ethernet chips do their CRC calculation but I
would imagine their receiving algorithm to be something like this:
	collect byte
	calculate into CRC
	store in memory
	repeat until done with packet
	verify CRC

If that's the way they work then a bad bit on your ethernet card
could also damage the packet and you wouldn't know unless you had an
end-to-end verification.

MIT had a problem years ago with a Chaosnet bridge which had a flaky
memory board; it would sometimes trash a couple of bits. Chaosnet had
no checksum in its packets; it depended solely on the network
hardware to verify the data. A lot of data transferred through this
bridge suffered true bit rot and the problem was a real pain to find.

I also know of people who use NFS through IP routers and they
sometimes have files corrupted because of damaged packets which would
be caught by enabling UDP checksums.
-- 
			- john romkey
UUCP: romkey@kaos.uucp			ARPA: romkey@xx.lcs.mit.edu
 ...harvard!spdcc!kaos!romkey		Telephone: (617) 776-3121

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 05:26:06 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP working group?

Dave,

We agree. Error detection and correction on an end-to-end basis is
essential for most data applications. Doing it at the link level as well
is almost always redundant and can only be justified as a performance
enhancement under rare circumstances.

If you're running a "heavy" backbone link you've probably already spent
the money to run synchronous HDLC framing, since this shaves off 2 bits
of overhead per byte sent. In this case I don't really object to simple
link error detection (without retransmission) mainly because it comes
"for free" in the HDLC chips, not because it's really necessary.

But full ARQ protocols like LAPB at the link layer are a waste of
bandwidth and cycles. Our ARPANET gateway is probably as active as any.
It speaks 1822/HDH/LAPB over a 56kbps line to Columbia. Timers, RRs,
keepalive polling at both the HDH and LAPB layers, the whole bit. In the
28+ hours since it was last booted, it received 4.3 million HDLC frames
from the IMP. Only 48.7% contained IP datagrams; the rest were overhead
frames. (The number of CRC errors on input frames was ZERO). Of the 6.3
million packets sent, a mere 33.3% were IP datagrams.  This is silly.
The only time LAPB tries to do recovery is when the link has been cut
somewhere. It can retransmit all it wants, but it won't get anywhere
until I call up AT&T and complain.  DDS circuits either work perfectly
or not at all.

Fortunately, we've got plenty of excess link bandwidth and the CPU in
the dedicated Sun gateway has nothing else to do anyway, so all of this
is merely amusing and not a real problem. (I can only thank the Deities
that we don't have to run X.25!) But as links and switches get faster,
even the link overhead in HDH has got to go.

Mr. Beattie really ought to read the classic paper by Saltzer, Reed
and Clark, "End-to-End Arguments in System Design".

Phil

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 05:26:53 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: draft ulana sw & sec spec

1. Why no mention of RFCs 963 and 964, detailing the ways in which
the descriptions of IP and TCP in MIL-STD 1777 and 1778 are wrong?
The 1983 dates on the MIL-STDs lead me to believe that they haven't
been revised to correct these problems.

2. Why no mention of RFC-950, "Internet Standard Subnetting Procedure"?

This brings up another issue that has been on my mind recently:  Is anyone
working on a "Requirements for Internet Hosts" RFC, in the vein of RFC1009?
I have recently encountered a number of very literal readings of the MIL-STDs
into government procurement specifications, such that a PC is required to:

a. Support 'Page Mode' in its FTP.

b. Generate ICMP Time Exceeded messages, even though it has only one interface,
and this represents discarding an otherwise perfectly acceptable packet
(albeit one which barely got to me).

c. Reply to ICMP Information Request messages, which appear to me to be 
intended for DDN use, and not for a broadcast LAN.  I can't guess exactly
why they might want this, but BOOTP seems to be much better suited.  There
is also the issue of whether a workstation should reply to this sort of
thing at all (particularly if the request is broadcast).

d. Support the IP option "Satnet stream ID", which I am informed is not
relevant to any of the standard upper layer protocols (TCP, UDP, etc.).
I can ignore it just fine, but I don't know if this is 'support'.

I would be interested in working with anyone who is working on a host-
oriented equivalent to RFC1009.  I might even have time to start one
myself.  Of course, if I'm entirely wrong in my criticism above, I'm
not the right person...

James VanBokkelen
FTP Software Inc.

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 07:22:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: draft ulana sw & sec spec

Ves and Stan,

Two thoughts after a first pass scan of the performance specs:

1. Will the windows lawsuits between Apple and HP/Microsoft create
problems for vendors trying to respond to the ULANA specs?

2. Should the electronic mail requirements include anything about
interoperability with Internet Mail (perhaps it does so by inclusion of
reference to SMTP ?), with any public mail service?, with name server
capabilities?

Vint

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 07:59:18 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   vendors on committees (was Re: SLIP working group?)

In article <1017@thumper.bellcore.com> karn@thumper.bellcore.com
(Phil R. Karn) writes:
>Someday, perhaps there'll be a protocol standards organization
>controlled completely by users. Realizing the importance of the process,
>they will each invest sufficient time and money so that they can be
>thoroughly versed with the technical issues. However, anyone associated
>with a commercial vendor of products controlled by the standards in
>question would be automatically disqualified from membership.

I don't want to waste people's time with this, and I don't mean this
as a flame, but I've got something to say in response here:

Come on, Phil, there are some of us out here in vendor-land who have
a lot of experience and can make valid contributions to protocol
designs. There are a lot of differences between having years of
experience working with (for instance) IP over serial lines and
spending the money and time to read a book on serial lines and the
relevant RFC's.

There are maybe one or two other people out there (Jerry Saltzer,
Dave Bridgham) who have as many years of experience as me with TCP/IP
on IBM PC's. That's because we worked on the very first implementation
on PC's (there were other people involved too, but none of them are
still into TCP/IP and IBM PC's). I'm not saying here that there's no
one out there who knows more about the subject than me, but when you
work on something for six consecutive years, you usually learn a few
tricks. I can contribute a lot to design issues in this area and
others. Because I still have some tenuous connection with FTP
Software, I don't think I should automatically be disaqualified from
being involved. Some of us out here are capable of impartiality. I
will usually place the best technical solution over monetary gain.

There are a starting to be major contributions made to the TCP/IP
protocol suite by vendors. If, for instance, a standards committee
was formed to specify a standardized protocol for network shared
filesystems, your rule would say no one from Sun (NFS is important)
or AT&T (RFS shouldn't be completely ignored) could be on the
committee, when there's a lot of talent and knowledge in this area in
these companies. That seems like a very bad idea.

In general, any rule that says "All X are Y" is wrong, or at least
unfair, and yours was a rule like that. It doesn't build in any
margin for special cases that don't fit. Of course, the rule says
that the rule itself is wrong, too.
-- 
			- john romkey
UUCP: romkey@kaos.uucp			ARPA: romkey@xx.lcs.mit.edu
 ...harvard!spdcc!kaos!romkey		Telephone: (617) 776-3121

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 09:05:09 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: SLIP working group?

Uh... there is a good reason why you might not be ABLE to turn UDP checksumming
on, and thus would want some sort of (simple) CRC on your SLIP line. There was
a bug in some (all?) 4.2 BSD systems which calculated the UDP checksum wrong
(but consistently, for talking to other 4.2's), and 4.3 fixed it. So 4.3 can
now talk to non-BSD systems which checksum the right way. However, if you still
happen to have some "old" 4.2 systems on your net, and if they happen to be
binary-only systems (i.e., the kernel and/or the net code is supplied by a
3rd-party vendor who may or may not still be in business), you may have to
turn off checksumming to be able to talk UDP to them. (A client of mine has
that problem.) Since UDP checksum "on/off" is a per-host function and not per
"connection" (at least in 4.3), it's hard (without delving into the net code)
to get UDP cheksums on SLIP lines and not on the Ethernet. So a simple CRC
on the SLIP lines might be in order after all...

By the way, computing the standard Ethernet CRC-32 only takes a couple of
XOR's and a table lookup per byte (and the table is only 256 32-bit words).
The C code for the inner loop is:

	while (len-- > 0)
		sum = (sum >> 8) ^ CRC32_table[ (sum & 0xFF) ^ *cp++ ];

The overhead is thus tolerable on a serial line, even on micros, and there
is no reason not to do it (except compatibility with earlier SLIP's). My own
preference would be to extend the SLIP frame to include a full Ethernet header,
use the standard Ethernet numbers, type field, and CRC-32. (Let's call it SLEN,
for Serial Line EtherNet, to distinguish it from SLIP.)

The advantage of a SLEN is that you get ARP, RARP, XNS, DECnet (*ugh*),
and whatever else, besides IP. And you don't have to worry about lack
of UDP checksums.

(Of course, you now have to apply some clever flow control to Ethernet
broadcast packets...  ;-}   ;-}  )

Note that Xerox already defined a "SLEN" for SDLC links. See "Level 0
Point-to-Point Protocol Spec T33-2.0", XSIPS 018201, January 1982 [~6 pages].
It includes some hooks for managing half-duplex lines (might be helpful for
some modems?) in a low-level "link command", which also provided for controlled
termination of dialup connections. Note that their protocol left off the
Ethernet destination number, but kept the source (for authentication?);
the type field was cut to 4 bits (*ugh*), and the CRC was a modified
CRC-16. Still, it's almost usable as it stands, if we could grab a couple
of types for ARP & IP (or go back to 16 bits?), and change the SDLC framing
to SLIP-like async (and maybe go back to CRC-32?).


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1988 14:15-EST
From:      CERF@A.ISI.EDU
To:        haverty@CCV.BBN.COM
Cc:        postel@VENERA.ISI.EDU, tcp-ip@SRI-NIC.ARPA michel@CCT.BBN.COM
Subject:   Re: RFCs by E-Mail
Jack,

I obtained a program from the SRI-NIC called PC SAM which operates
in some ways like Desktop Express. It doesn't run in the background
like Lotus Express, but it does pull and push mail on its own
like Desktop Express does.

I'm with you on different mode of interaction than remote to a 
time-shared host through a packet net. 

Vint
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 09:19:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re: LAN Hardware/Software advice needed

Sharan,
 
Mid last year there was much critical comment of the Wollongong
TCP/IP etc implementation for VAX VMS. Since then there has been
significant people change (David Crocker and Marshall Rose in) and
release of V3.1 (I think there is a newre release but not aware that
it has made it to the UK yet).
 
I have been much impressed with the product, it is very comprehensive
and we are slowly learning how to use its extensive facilities. In the
last two weeks we have moved into using the EGP Gateway features and
are now supporting two other European sites, over X25, into the
Internet.
 
Future work is to explore the name server functions. I think I may have
heard that Van J's TCP flow control is in the new release.
 
John Laws
Distributed Information Systems Division
RSRE Malvern

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Apr 88  17:20:01 EST
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  TCP/IP for IBM's MVS
> Has anyone compared the alternatives for TCP/IP implementations for the
> IBM MVS operating system (e.g. KNET, ACC, etc). A full function
> alternative, preferably with nice gateway capability to&from SNA
> networks would be ideal (dream on :-).

Last year we talked to ACC, Advintech (then called CISCO),
Fibronics, and Network Solutions.  We felt that ACC's product would
best meet our needs.  Due to long procurement delays, we are just
about to get it, so I can't tell you how it worked out yet.  I also
asked some of the lists who was using what for MVS.  The
overwhelming majority response was ACC.

Some of the product features that are important to us are SMTP, FTP,
Telnet, TN3270, domain name resolver, a reasonable way to interface
SMTP to our mail system, and a way to adapt FTP to our user and data
set naming conventions.  Some of the products lacked basic features
like SMTP or TN3270.  Others had interfacing problems in our
environment.

We weren't looking for an SNA Gateway, but I don't recall such a
beast in any of the products.
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 12:34:43 GMT
From:      haverty@CCV.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: RFCs by E-Mail

Hi Jon,

The electronic mail channel is nice, but note that Tony's Mac doesn't
have an electronic mail server either.  Even if it did, given the nature
of personal computers (not always powered up, may be doing other things, etc.)
I'm not sure it would help if it did.  Perhaps if there was a pervasive
use of the PC-Mail (is that the right name) service that would meet the needs.

Like Tony, I have a MAC on my desk, and happen to have a PC-clone as well,
on the Internet.  We also tend to occasionally carry a laptop on trips.  There
is more computing power and memory on my desk than there was in an entire
computation center building not too many years ago.  I do 99% of my work
on those machines, and the frequency with which I interact with the network
to check mail, etc., is on a consistent downward trend.  What we're reacting to
I think is the situation where it's still necessary to establish a virtual
terminal link to a machine on the net, and login, type/send small packets,
etc., like I'm doing now.

I've been using Lotus Express, Desktop Express, and Compuserve Navigator,
which are all Personal-machine-oriented programs to utilize the services
of public networks (Compuserve and MCIMail).   It's an entirely different
style of network usage, where the fact that the network is involved becomes
almost invisible.

Anybody have ideas (or software...) that would make such usage exist
on the Internet?

Jack

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 15:18:10 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Fiber Optic Ring Backbone

In article <8803292224.AA13808@trout.nosc.mil> carrs@TROUT.NOSC.MIL (Stephen M. Carr) writes:
>    c.  Implementation of IEEE 802.3 in a ring topology seems to
>me would require something akin to the opposite of IEEE 802.4
>Token Bus.  In other words, implement me a bus protocol in a ring
>topology.  Not that IEEE 802.4 doesn't make sense, but it appears
>that essentially the MAP folks have implemented a ring protocol
>in a bus environment.  I am sure they have their reasons, the MAP
>community isn't stupid.  But what about implementing IEEE 802.3
>in a ring topology?  Is this for real?  I confess, I am ignorant.

Well, I did a Master's thesis on a network that was similar to what
you're talking about.  Physically and electrically the network was a
token passing ring.  Logically, it was a bus, in the sense that there
was only one transmitter active at a time, and all information was
received by all nodes at the same time.  So, I do think that IEEE
802.3 could be implemented in a ring technology, albeit without token
passing.

As an aside, the header that I used was remarkably similar to the
Ethernet header, but with one octet addresses.  I guess round wheels
get reinvented all the time.
-russ
-- 
-russ
AT&T: (315)268-6591  BITNET: NELSON@CLUTX  Internet: nelson@clutx.clarkson.edu
GEnie: BH01  Compu$erve: 70441,205

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 15:41:10 GMT
From:      bukys@cs.rochester.edu (Liudvikas Bukys)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: SLIP working group?

One should either leave SLIP alone (it works as it is), or re-do it
altogether, addressing some of the most severe problems while you're at
it.  For instance, someone at UDEL (Dave Farber & et al) noted that
header bytes are mostly predictable, and devised a faster (less
wasteful) serial-line protocol for slower lines.  If a SLIP working
group emerges, *that* is the direction it should take off in.  If
you're going to have a new protocol, it might as well be better, not
just different!

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 15:43:38 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?

In article <8803302037.AA02493@PHOEBE.CAM.UNISYS.COM> jonab@CAM.UNISYS.COM (Jonathan P. Biggar) writes:
>Why don't we make the new versions of SLIP upwards compatible?  ...
>Add a negotiation feature to SLIP ...
>Everything can just default to the current SLIP usage.

That's a good idea.  Being that today's April 1, I'll just point out that
the negotiation packet(s) could have a checksum, CRC, or go bare.

By the way, I wasn't looking to start a public discussion.  I thought,
since all discussion of SLIP had vanished from tcp-ip, that people were
working on it in the background.  Obviously this is not the case.  As for
me, I'm convinced that a CRC is both necessary and sufficient and Efficient.

-- 
-russ
AT&T: (315)268-6591  BITNET: NELSON@CLUTX  Internet: nelson@clutx.clarkson.edu
GEnie: BH01  Compu$erve: 70441,205

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 15:48:00 GMT
From:      Plummer@DOCKMASTER.ARPA
To:        comp.protocols.tcp-ip
Subject:   Wang TCP/IP

I have done a bit of checking about the status of Wang's TCP/IP.  We
currently have two beta sites:  Scott Air FOrce Base (4 months) and the
University of Wisconsin (1 month).  THey are running TCP/IP, FTP, SMTP
and in-bound telnet.  As I understand it, we are on the tail end of a
normal development cycle, having a small number of minor bugs to be
fixed.  If anyone has more questions, Steve Chunn of our Communications
Software Department will be happy to speak with you.  1-800-225-0254 x
75184 or 617-967-5184.  --Bill Plummer
                                           WANG Laboratories, Inc.
                                                     Plummer -at DOCKMASTER

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 16:09:18 GMT
From:      geoff@fernwood.mpk.ca.us (Geoff Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   Public RFC retrieval (via Net Mail).

Tony Michael:

No need to have FTP access to retrieve RFC's, et al.  Just send a note to:
Service@sri-nic.arpa with "HELP" in the subject of your message and you'll
receive instructions.  

Caveat: make sure the host you mail the request from is in the Internet host
table. The NIC doesn't seem to support MX Records and won't beable to return a
reply to you otherwise.
__
  Geoff Goodfellow    Geoff@fernwood.mpk.ca.us   ..!sun!quintus!fernwood!Geoff

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 16:28:27 GMT
From:      jh@tut.fi (Juha Hein{nen)
To:        comp.protocols.tcp-ip
Subject:   OSI does not mean X.25


   Evidently there are still people who see "OSI" and hear "X.25" and
   "connections".  ** THIS IS NOT A VALID ASSUMPTION! **

   You can have OSI with a Transport protocol similar to TCP (ISO
   8073) and a connectionless internetwork protocol (ISO 8473) even
   more similar to IP.  You do not have to have X.25.  You do not have
   to have PTTs.  You do not have to have network connections.  There
   is NO part of OSI that requires X.25 (although if X.25 is all you
   have, you can use it to support OSI).  OSI loves LANs.  The OSI IP
   likes nothing better than to connect LANs together (or to any other
   type of subnetwork).
   ...

I fully agree with all you are saying about ISO IP/TP4 supporting
LANs.  The problem is that according to EC politics, you are NOT
allowed to run ISO IP in the European academic OSI network!!!!
Instead you have to run CONS and they even force you to run X.25 on
your Ethernet.  This is THE European OSI.

Of course we in Finland and even wider in Scandinavia don't accept this
bullshit and are just now in the process to set up an Internet using
multiprotocol routers that soon will support ISO IP.  Because of this,
the leaders of the political OSI migration are saying that we are non
European heretics.  

Hope this clarifies my earlier comment. I have nothing against OSI
but European OSI politics.

Juha Heinanen

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 16:40:19 GMT
From:      alex@oravax.UUCP (Alex Feldman)
To:        comp.protocols.tcp-ip
Subject:   SLIP for beginners (me)

I think I want to implement SLIP on our system here.  Unfortunately,
I can't even make that decision because I don't know enought about it.
Would someone kindly point me towardssome sort of primer, and tell me
where I could get software?

Thanks, 

-- 
           Alex Feldman

           oravax!alex@cu-arpa.cs.cornell.edu               (ARPANET) 
           ...{rochester,allegra}!cornell!oravax!alex       (UUCP)

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 18:25:06 GMT
From:      mo@maximo.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   internet in abstentia


I think SUN's new PC/NFS release has a mail queuing system
whereby the PC can call up (Ethernet, or possibly SLIP??),
gather mail, send mail queued, disconnect, and then go solo again.
	-Mike

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 19:08:20 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: draft ulana sw & sec spec

Yes, there is a WG of the IETF doing exactly that.  Your friend and mine
JNC is supposedly holed up writing Good Words about the IP layer, even
as I type. (Go, Go, Noel!).  By the way, I seem to be the chair of this
WG.  If you want to devote time & energy to it, let me know.
 
 Bob Braden
 

   

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 19:09:20 GMT
From:      dwall@hpindda.HP.COM (Darren Wall)
To:        comp.protocols.tcp-ip
Subject:   IP/X.25 Call User Data ...


Is it an "accepted practice" to use 0xCC in the first byte of
Call User Data in an X.25 CALL REQUEST Packet for routing IP
data over an X.25 Link?  I know that for DDN Standard Services
it's required, but I had thought that everyone did it whether
DDN Standard is being requested or not.

The reason that I ask is I noticed that Cisco Box that we have
does not use any Call User Data in it's CALL REQUEST Packet.

The Cisco I am using is:
System Bootstrap, Version 3.0(3), copyright (c) 1987 by cisco Systems, Inc.
ASM/AGS System, Version 6.1(343), compiled Wed 11-Nov-87 15:58

Darren Wall

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 19:15:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: RFCs by E-Mail

Jack,

I obtained a program from the SRI-NIC called PC SAM which operates
in some ways like Desktop Express. It doesn't run in the background
like Lotus Express, but it does pull and push mail on its own
like Desktop Express does.

I'm with you on different mode of interaction than remote to a 
time-shared host through a packet net. 

Vint

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 19:25:39 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: draft ulana sw & sec spec


	This brings up another issue that has been on my mind recently:  Is anyone
	working on a "Requirements for Internet Hosts" RFC, in the vein of RFC1009?

 
Yes, there is a WG of the IETF doing exactly that.  Your friend and mine
JNC is supposedly holed up writing Good Words about the IP layer, even
as I type. (Go, Go, Noel!).  By the way, I seem to be the chair of this
WG.  If you can put time and energy to it, let me know!
 
    Bob Braden
	
PS: To those who got an earlier, garbaged, copy of this message, I apologize
on behalf of a well-known Bay-Area university and a well-known Bay Area
workstation mfr, who were responsible for the mailer software I use.
RTB

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 19:46:50 GMT
From:      timk@NCSA.UIUC.EDU (Tim Krauskopf)
To:        comp.protocols.tcp-ip
Subject:   Re: LAN Hardware/Software advice & NCSA Telnet

To clear some points about this comment:
	
	Q:	How can the IBM PC's and Mac SEs also do the rlogin/telnet/ftp,etc.,
		action with either of the UNIX VAX or VMS uVAX? How should
		be go about doing this? Money is no object but of course
		a few hundred feet above the ground is our limit (read $50,000
		to $150,00 is my anticipated budget :-). Feel free to share your
		expreriences and flights of fancy. I'm all ears! 
	A:	You can fully equip an IBM-PC with an Ethernet card and TCP
		software for less than $500 dollars.  You can probably do it
		for less than $300 if you rely on Public Domain software and
		the cheaper Ethernet cards.  We tend towards the Micom 5210
		cards these days.  For Macintoshes, there is no good way for
		the non-MAC-II's to hold an Ethernet card.  However, you can
		run TCP/IP nicely by using an Appletalk->Ethernet gateway.
		Specifically, the Kinetics FastPath (less than $2000) which will
		serve an entire Appletalk net.  We use this in conjunction with
		the public domain NCSA telnet.  You can get Ethernet cards for
		the MAC-II's and rumor has it for the SE, but I have no experience
		with this as the FastPath box is more economical when you have
		more than one or two Macs to hook up.
	
Kinetics sells working, available for many months, Ethernet devices for:
	Mac SE internal board (Etherport SE)
	external Ethernet (EtherSC) - hooks up to Mac SCSI port
	gateway from AppleTalk/Ethernet - (FastPath)
I consider these to be "good" ways for non-Mac II's to Ethernet - they
are all running in my building.
Kinetics, Apple and 3COM all sell Mac II Ethernet boards.

NCSA Telnet supports all of these and also comes in a PC version.
Anon FTP from ftp.ncsa.uiuc.edu (128.174.20.50).

Tony Michel (from different posting) will be happy to find out that his
version of NCSA Telnet for the Mac (1.12 - 6/87) was updated in November
(2.1 - 11/87) and 2.2 will be out this summer.  Yes tn3270 but no user
FTP yet.

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

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 20:29:04 GMT
From:      cyrus@hi.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   computing network loads


   I am looking for an equation that roughly computes the theoretical
load on a network given only the following information:
	1) time over which the load is to be computed,
	2) the number of packets seen in that time,
	3) the number of bytes seen in that time.

   Currently I am using something like:
	num_bytes / (MBYTES_PER_SEC * time)

where I have arbitrarally picked MBYTES_PER_SEC to be 1 MegaBytes / sec.
Given a 10MBit (1.25 MByte) channel, subtracting overhead for preambles,
CRC bytes, collisions & the minimum time between packets, I came up
with the VERY approximate # of 1 MByte/sec.

   I know that 1 Meg is a VERY magic number because there are many
different media that the data can be traveling across which will 
effect this magic number.

   So, back to the question.  Is this a good approximation?  What
values for MBYTES_PER_SEC should be used for the various medias,
i.e. think wire, thin wire, broadband, fiber, etc.?
   I don't want to worry about distances between stations and the
media between them, just a rough approximation.

   I have looked at the Blue Book to try to find a "nice" method
for computing network loads, but I am having a hard time trying
to come up with a better equation.  Any help anyone could supply
me (as far a clarification of what the Blue Book is saying and
how to use that information) would be greatly appreciated.

Thanks,

-- 
    @__________@    W. Tait Cyrus   (505) 277-0806
   /|         /|    University of New Mexico
  / |        / |    Dept of Electrical & Computer Engineering 
 @__|_______@  |       Parallel Processing Research Group (PPRG)
 |  |       |  |       UNM/LANL Hypercube Project
 |  |  hc   |  |    Albuquerque, New Mexico 87131
 |  @.......|..@    
 | /        | /     e-mail:      
 @/_________@/        cyrus@hc.dspo.gov

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 21:27:22 GMT
From:      PERILLO@SRI-NIC.ARPA (Francine Perillo)
To:        comp.protocols.tcp-ip
Subject:   RFCs, IENs and the DDN NIC

As you may have already heard, the DDN Network Information Center
("the NIC") has many of the RFCs and IENs online at SRI-NIC.ARPA.  The
famous IEN 45 is now there as well in IEN:IEN-45.TXT.

They are available either through anonymous FTP (log in as "anonymous"
with password "guest") or through our automatic mail request program
called SERVICE.  Mail requests to SERVICE@SRI-NIC.ARPA and indicate in
the subject field the RFC or IEN number, as in "Subject: IEN 45" .
"Help" in the subject field gives you a help file on SERVICE.

-Francine /DDN Network Information Center
-------

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 21:53:44 GMT
From:      kline@UXC.CSO.UIUC.EDU (Charley Kline)
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums (again)

When I first started the CTSS TCP/IP project, Dave Clark suggested that
I publish the checksum algorithm. His contention was that most checksummers
are dreadfully machine-dependent, incomprehensible, and artful things. Well,
I didn't put much effort into art, but I thought I'd oblige him.

What I do to compute checksums on a Cray is a vector operation
in assembler of all things. I can do up to 512 bytes of packet at a
time. The core of the algorithm looks as follows. A1 holds the address
of the 512-byte block of memory to checksum (I'm leaving out many
details having to do with short blocks, because they are ugly).

	EBM
	A0	A1
	VL	64		use full vectors
	S1	<32		form 32-bit mask from the right.
	A2	32
	V1	,A0,1		load packet into V1
	V2	S1&V1		Form right-hand 32-bits in V2.
	V3	V1>A2		Form left-hand 32-bits in V3.
	V1	V2+V3		Add the two together.
	A2	63		Prepare to collapse into a scalar.
	S1	0
	S4	<16		Form 16-bit mask from the right.
	A4	16
CK$LOOP S2	V1,A2
	A2	A2-1
	A0	A2
	S1	S1+S2
	JAN	CK$LOOP
	S2	S1&S4		Form right-hand 16-bits in S2
	S1	S1>A4		Form left-hand 16-bits in S1
	S1	S1+S2
	S2	S1&S4		Form right-hand 16-bits in S2
	S1	S1>A4		Form left-hand 16-bits in S1
	S1	S1+S2
	S1	#S1		Take one's complement
	CMR			At this point, S1 contains the checksum.



Note that this takes full advantage of the fact that the one's complement
sum is an Abelian Group--I can add 32-bit pieces instead of 16-bit pieces,
as has been mentioned. I can also take advantage of the fact that the sum of
the checksums of several blocks is the same as the checksum of the sum
by carrying out this checksum on several blocks and adding up the answers.

First I load two copies of the packet into two vector registers. One
gets vector-shifted right 32 bits; the other gets vector-ANDED with a
32 bit mask. Then the two are added together. Since all these operations
chain, I can produce one result per clock cycle. Then I collapse
the results in the vector by adding each element to a scalar register.
Finally, the end-around carry and conversion to 16-bits. It's all
terribly fast. Now if only context-switching and IPC under CTSS were
as fast...

-----
Charley Kline,  University of Illinois Computing Services
kline@uxc.cso.uiuc.edu
{ihnp4,uunet,pur-ee,convex}!uiucuxc!kline

"Birth.   School.   Work.   Death."

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 22:20:01 GMT
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP for IBM's MVS

> Has anyone compared the alternatives for TCP/IP implementations for the
> IBM MVS operating system (e.g. KNET, ACC, etc). A full function
> alternative, preferably with nice gateway capability to&from SNA
> networks would be ideal (dream on :-).

Last year we talked to ACC, Advintech (then called CISCO),
Fibronics, and Network Solutions.  We felt that ACC's product would
best meet our needs.  Due to long procurement delays, we are just
about to get it, so I can't tell you how it worked out yet.  I also
asked some of the lists who was using what for MVS.  The
overwhelming majority response was ACC.

Some of the product features that are important to us are SMTP, FTP,
Telnet, TN3270, domain name resolver, a reasonable way to interface
SMTP to our mail system, and a way to adapt FTP to our user and data
set naming conventions.  Some of the products lacked basic features
like SMTP or TN3270.  Others had interfacing problems in our
environment.

We weren't looking for an SNA Gateway, but I don't recall such a
beast in any of the products.

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 22:50:12 GMT
From:      Crispin@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: RFCs by E-Mail

Jack -

     At SUMEX-AIM, we have a distributed mailsystem called MM-D, which
is supported by a client on Xerox Lisp machines (a TI Lisp machine client
is almost finished, and work has started on a MAC client) and servers on
a DEC-20 and Unix.  It's gotten to the point that several of us have more
or less abandoned logging into the timesharing system to read our mail;
we do it from our workstation.

     MM-D uses the IMAP2 protocol, which compares to POP2 in much the way
a BMW compares to a tricycle.  The modality of IMAP2 is more interactive
than POP2, but there's nothing in IMAP2 that requires that; it can be
used in an offline way such as PC Mail.

-- Mark --
-------

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 23:46:16 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: SLIP working group?

In article <9312@tut.cis.ohio-state.edu> pritch@tut.cis.ohio-state.edu (Norm Pritchett) writes:
[...]
>representative to ANSI and ISO touched upon the subject and confirmed
>it is in fact true.  He said the purpose of these committees is to
>produce a solution that makes technical sense AND places all parties
>involved at equal DISadvantage, this concept making more sense in a
                   ^^^
Is this why ISO uses the acronym for Draft International Standard?
:-)

b

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 23:52:29 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP for IBM's MVS


	
	Has anyone compared the alternatives for TCP/IP implementations for the
	IBM MVS operating system (e.g. KNET, ACC, etc). A full function
	alternative, preferably with nice gateway capability to&from SNA
	networks would be ideal (dream on :-).
	
That depends upon what you mean by a "gateway capability".  A transport-level
gateway doesn;t work because the upper layers are different. If you
mean: the ability to use a 3278 transparently end-to-end across an SNA
and a TCP-IP network, you've got it in the UCLA ACP and all the
vendor products derived from it.  If you mean: the ability to gateway
BITNET mail to/from SMTP mail under MVS, there is a mail system 
available from UCLA that does that (with some restrictions).
There is not a file transfer gateway  because the two protocol
families use such different file tranfer models.

Bob Braden

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 88 23:54:13 GMT
From:      hirai@swatsun.uucp (Eiji "A.G." Hirai)
To:        comp.protocols.tcp-ip
Subject:   Stop comp.protocols.tcp-ip.eniac !


	There's a joker with a bad taste for jokes who's running a real
vote collection for the establishment of a joke newsgroup called
comp.protocols.tcp-ip.eniac on news.groups.  Now, this may be a joke and
come to nothing but I think we should err on the safe side and prevent
such a group from forming.

	He has in mind discussions along the lines of talk.bizarre under
this new newsgroup.  He has over 160 yes votes and 40 or so no votes. 
He needs only 100 more yes votes than no votes so the group might be
created (if he's not joking) if we don't say "hey, this is stupid".

	So I plead to you, send in a short mail to him saying "I vote no
to you newsgroup proposal".  He may be joking, but it's always better to
err on the safe side and prevent this newsgroup from getting created.

	I think this newsgroup proposal flies in the face of what the
comp.* newsgroup are supposed to be.  It's totally ignores the Usenet
naming scheme that brought some semblance or order to Usenet.  The
people in talk.bizarre can talk all they want but let's not invite them
into the comp.* groups with this absurd idea that Bob Webber has
conceived.

	If you don't want talk.bizarre discussions in the comp.* groups
which you read, why, send in your vote!  I beg you in the name of
sanity.

	I'll append his article explaining what his newsgroup is so you
can judge for yourself how absurd this is.

						-a.g. hirai

----- forwarded article from news.groups -----

From: webber@athos.rutgers.edu (Bob Webber)
Subject: Repeat of the Original comp.protocols.tcp-ip.eniac Proposal
Date: 26 Mar 88 10:53:18 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

Now, 26 Mar, we are closing in on the last week of voting for this group.
As things stand, the tally is about 145 yes versus 26 no votes.  However,
this by no means means the voting is over.  As per Usenet regulation #1095
the period of voting lasts 30 days.  So, please send your yes votes
to:
      rutgers!aramis.rutgers.edu!webber
or
      webber@aramis.rutgers.edu
depending on the preferences of your local system.  In case your
system expired the original proposal, I enclose it below
(Originally posted: Sun, 6 Mar 88 07:47:45 EST):

After rereading a whole lot of news.groups messages, ending with:

   From: heiby@falkor.UUCP (Ron Heiby) Message-ID: <142@falkor.UUCP>
   ...
   (Now I have to live in fear that some moron starts taking a vote on
   the creation of misc.silly.putty or, even worse, sci.silly.putty and
   the whole net blames me.  Oh, the nightmares!)

I have finally figured out what group is in desparate need of creation.
        It has been noted that talk.bizarre has become mundane.
        It has been noted that soc.sex waves a red flag at the bean counters.
        It has been noted that junk food is not the soul of cyberpunk.
        It has been noted that we lack sci.silly.putty.

How can we solve all of these problems.  Clearly what is needed is an
inconspicuous group for people who know what the group is about to
post and yet whose name is such that it won't draw postings (or
attention) from the beancounter mentality.

I propose the unmoderated group:
                comp.protocols.tcp-ip.eniac

If you don't know what should be posted to such a group, don't worry
-- it's just some obscure high tech stuff.  If you think this posting
is some kind of joke, fine -- enjoy -- and just for the heck of it:
send me a YES vote.  If you understand the true meaning of this group
proposal, I look forward to collecting your YES vote.  If you are on
some site that just can't support one more group, then go ahead and
send your NO vote (everyone will sympathize and perhaps someone will
even donate a machine to you so you will have room).  DO NOT POST VOTES
TO NEWS GROUPS.  SUCH VOTES DO NOT COUNT IN THE TOTALS PRESENTED TO
THE BACKBONE.  Send your votes by email to:
     webber@aramis.rutgers.edu
     rutgers!aramis.rutgers.edu!webber
[rutgers is a backbone site, so if you can reach any backbone, getting the
path to reach rutgers is no problem -- if you have difficulties, check with
your local sysadmin or the nearest usenet site that has a mail wizard.
don't expect to be able to rely on the reply command in your news
program -- many things about mail on usenet have changed since it was written.]

The voting starts now: which my machine says is
               Sun Mar  6 07:30:41 EST 1988
According to the backbone rules, the vote will end:
               Wed Apr  6 07:30:41 EST 1988

Since it is unclear what the significance of votes mailed before this time
but recieved after it is, I urge you to vote in favour of this group
as soon as you can see your way free to.

---- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 88 00:22:30 GMT
From:      lupine!klein@uunet.uu.net  (Doug Klein)
To:        tcp-ip@sri-nic.arpa
Subject:   Need SLIP information
I'm interested in information on SLIP, but do not know
where to get current information on it. Specifically,

	- where do I get a written spec?

	- are there public domain implementations available? 
          where?

Please e-mail responses to:  uunet!lupine!klein

Thanks in advance,

Doug Klein
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 88 02:57:21 GMT
From:      rhorn@infinet.UUCP (Rob Horn)
To:        comp.protocols.tcp-ip
Subject:   Checksums, CRC's, and NFS

There are sometimes good reasons to use CRC rather than just checksums,
especially when in the asynch world.  We send a lot of data over hostile
links using asynch and we have found that one of the more anti-social failure
modes of port sharing devices and muxes is byte or buffer swapping.  Checksums
don't catch these.  CRC's do, and they cost relatively little.  Our CRC
code compiles into only nine (9) instructions per byte, and could be cut
to seven (7) if we went to assembler.  This is not as good as checksums, but
it is nothing when compared to the CPU cost of servicing the interrupts
for the comm device.  I think that CRC's have gotten too much bad press
because people think they are expensive.  So our CRC code (sans 512 byte table)
is attached at the end.

On the other hand, for reliable high speed links (like LANs) I think
Sun made the right decision to drop even checksums.  With a typical 8
KB block, even if the checksum cost is down to 1 microsecond per byte
you have added 8 milliseconds to the response.  This is a big portion
of the total response time for a disk on the same LAN, especially for
a cache hit.  But Sun should have made checksumming a per mount
option, to accomodate those cases where the connection is slower or
less reliable than a LAN.

Rob Horn
     ...harvard!adelie!infinet!rhorn,   ..!ulowell!infinet!rhorn

/*
 *  A simple table driven CRC calculator.
 */

extern BYTE CRC_TABLE [256] [2];

rx_crc(crc, buffer, len)

char crc[2];
char *buffer;
short len;

{
#define high  1
#define low  0
register BYTE *crcptr;
register char crclow;
register char crchigh;
register char *workptr;
register char *limit;   /* This should only be a register on 68K or VAXen */
                            /*  Not on Intel processors */
crclow = 0xff;
crchigh = 0xff;
limit = buffer + len;
workptr = buffer;
while( workptr < limit) {
   crcptr   = CRC_TABLE [(unsigned char) ( *workptr++ ^ crclow)];
   crclow   = crcptr[high] ^ crchigh;
   crchigh  = crcptr[low];
   }
crc[low] = crclow;
crc[high] = crchigh;

}
-- 
				Rob  Horn
	UUCP:	...harvard!adelie!infinet!rhorn
	Snail:	Infinet,  40 High St., North Andover, MA
	(Note: harvard!infinet path is in maps but not working yet)

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 1988 14:12-PST
From:      WREN@A.ISI.EDU
To:        TCP-IP-REQUEST@SRI-NIC.ARPA
Cc:        WREN@A.ISI.EDU
Subject:   PLEASE POST TO TCP-IP BULLETIN BOARD


Distributed operating system needed-

I am working on a project that has as building blocks, Ethernet and TCP/IP.
We are now considering a choice of distributed operating systems for peer
to peer communication at the application level.

The following computers are either on or will soon join our LAN.
VAX (VMS), Symbolics, SUN, ENCORE, BUTTERFLY, MAC II.
Any of the above is a potential server.


1) One of the considerations is NFS by Sun.  I would like to determine which 
computers (esp. in the above list) have the SUN NFS hosted on them already.

2) Other suggestions are welcome.

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

   WREN@A.ISI.EDU    (WRENWICK LEE)
	PH: (808)471-8574

---------------------------------------
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 88 20:42:52 GMT
From:      stev@VAX.FTP.COM (Stev Knowles)
To:        comp.protocols.tcp-ip
Subject:   SLIP


slip is an acronym fo Serial Line Internet Protocol. yes, one can even
run IP over a lowly serial line. this does have it's useful aspects.
this allows geographicaly disjoint LANS to have direct routing across
between all the machine on all the lans. when you are connected
properly, routing can be used to allow you to connect from your
machine (the client) to any machine the gateway knows how to find. i
run a slip line to a C-gateway at MIT (my internet link) and on an 
in-house machine for testing or our commercial inplementation. slip is
useful for a limited amount of things. it will not replace a real
network connection (*trust me*). we see *real world* throughput of
80-85 percent of the line speed. this isnt bad, but an ethernet or
Pronet10 is a much better connection. i have been told about people
seeing 97 percent line troughput, with no data compression. (both of
these figures are for *data*, not *packets*) seems to me that this
does not leave enough space for the headers, but i dont remember all
of the numbers now.

ok, slip is good for connecting machines (or, better yet, networks) on
diffrent campuses, or getting one machine along way from a everyone
else on to the network. but it wont work very well for a local network.
(am i confused, or didnt DECNet (*gasp*) run on serial lines when it
first camme out?)


excuse me, i ramble. corrections to the above are welcome, flames can
be flushed.

stev knowles

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 88 22:12:00 GMT
From:      WREN@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   PLEASE POST TO TCP-IP BULLETIN BOARD



Distributed operating system needed-

I am working on a project that has as building blocks, Ethernet and TCP/IP.
We are now considering a choice of distributed operating systems for peer
to peer communication at the application level.

The following computers are either on or will soon join our LAN.
VAX (VMS), Symbolics, SUN, ENCORE, BUTTERFLY, MAC II.
Any of the above is a potential server.


1) One of the considerations is NFS by Sun.  I would like to determine which 
computers (esp. in the above list) have the SUN NFS hosted on them already.

2) Other suggestions are welcome.

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

   WREN@A.ISI.EDU    (WRENWICK LEE)
	PH: (808)471-8574

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

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 88 23:51:49 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   SLIP link error correction

The most important feature is to permit the link driver to discard
damaged packets.  For this reason a SLIP link checksum is a good idea. 

On the other hand this attitude of, "...but link error correction is
braindamaged," makes me uncomfortable.  There MAY be an occasion where
doing link error correction could result in an improvement in
performance.  I am not advocating that all SLIP links should offer link
error correction but rather am pushing for it as an option.  Perhaps it
could be negotiated at link establishment and could be placed in the
"you don't really have to implement this option" catagory for those of
you who find the thought of link error correction repugnant.

As a user of TCP/IP over packet radio I can assure you that link error
correction does indeed have a place, especially when you have several
lossy links concatenated in given IP route.  The throughput increase can
be dramatic.  It may not be useful in all situation but it is HIGHLY
desireable in some.

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

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 1988 09:19-PDT
From:      CERF@A.ISI.EDU
To:        spdcc!kaos!romkey@HUSC6.HARVARD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: ignoring UDP checksums
John R -

thanks for the horror story regarding chaosnet; Jack Haverty has similar
stories to tell about flaky hardware whose failure was masked by the
simple but essential end/end checksums protectingTCP and IP packets.
The big lesson learned in the case Jack tells about is that we should have
been reporting the failure/retransmission statistics somewhere; as it was,
we went on for 6 months without realizing we had bad crosstalk/interference
in cabling under the floor...

Vint
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 88 09:43:23 GMT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP working group?

Error detection should be implemented as close to the potential source
of the error as possible. In a IP link from my home PC to my
workstation, there might be 5 hops, 4 of which are over various LANs
and gateways all using CRCs and 1 SLIP on a lossy voice grade phone
line with no error detection. With an end-to-end checksum, all of
these links are treated equally, and as a result, packets which get
mangled on my phone line are passed in mangled form throughout my
reliable but heavily loaded internet only to be thrown away at the
destination because of a bad checksum. Worse, because this checksum
has to be calculated and compared, it uses cycles on the CPUs at both
ends. Even worse is that fact that in 4bsd this is a host wide option,
so if I have a single SLIP based client of my NFS fileserver and I
want him to get checksummed packets, I have to checksum packets for
all Ethernet only local users as well, users who are more likely to be
concerned with speed and not with data corruption on the Ethernet. It
seems to me that the sooner I can detect that a packet has been
corrupted, the sooner I should throw it away and initiate a
retransmission of the data, minimizing both the end-system CPU and the
total network bandwidth spent.  CRCs are commonly implemented in
hardware on Ethernet, in various syncronous serial chips, and on many
modems. Why not in SLIP framing as well?  End-to-End checksums
certainly have their place, but depending on them alone to catch data
errors on a variety of media in a complex internet wastes both net
bandwidth and host CPU.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 88 16:19:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ignoring UDP checksums

John R -

thanks for the horror story regarding chaosnet; Jack Haverty has similar
stories to tell about flaky hardware whose failure was masked by the
simple but essential end/end checksums protectingTCP and IP packets.
The big lesson learned in the case Jack tells about is that we should have
been reporting the failure/retransmission statistics somewhere; as it was,
we went on for 6 months without realizing we had bad crosstalk/interference
in cabling under the floor...

Vint

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 88 22:27:00 EST
From:      <enger@bluto.scc.com>
To:        "melohn" <melohn@sun.com>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   Is performing the checksum really that bad?
Bill:

You wrote recently that, 

	Even worse is that fact that in 4bsd this [end-to-end
	checksum] is a host wide option, so if I have a single SLIP
	based client of my NFS fileserver and I want him to get
	checksummed packets, I have to checksum packets for all
	Ethernet only local users as well, users who are more likely
	to be concerned with SPEED [my emphasis] and not with data
	corruption on the Ethernet.

It occured to me that we now live in a new era: A.J. (after Jacobson).
An era in which two small Sun workstations can obtain a TCP throughput
of 8 Mbps, checksums, headers and all; and without fully consuming the CPUs!

I am NOT commenting one way or the other on the SLIP controversy.  
Rather, I would like to offer the thought that the impact on performance
caused by running with end-to-end checksumming enabled may be greater than
it need be.  Perhaps implementers could follow Mr. Jacobson's fine example 
by revising their algorithms and optimizing their code.  Even when only 
modest throughputs are required, a user would still benefit from the 
reduction in CPU utilization.

Bob

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 88 19:58:59 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums

[ My apologies for following this up several days late.  I am only now
  starting to catch up on my mail. ]

It seems to me that a lot of the discussion over the last couple of weeks
has been about designing an error detection that does protocol verification
(or aids in debugging, anyway) by doing index-off-by-one detection.  Now
this is a neat idea (on paper), but I wouldn't want to implement it (at
least not entirely in software).  Or if I did, I would do it in a protocol
analyzer, not in a production implementation...

I still believe the greatest aid in finding index-off-by-one and similiar
problems is not done by building elaborate debugging into an implementation
in an on-line environment (eg. the Internet), but in the TCP/IP bake-offs.
I just wish more implementors would perform complete tests (options and
everything) against a real variety of implementations before going to market.

"Do I work against a Sun?  Check.  Do I work against a Wollongong?  Check..."

In a perfect world...

-Philip

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 88 20:49:55 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
To:        comp.protocols.tcp-ip
Subject:   Re:  A network you can trust


    Ignoring hosts, however, and just considering the network layer,
    the discussion is still interesting.  I like datagram in the sense
    that the network isn't obligated to do sequence and guarenteed
    delivery and so on, and can squash packets if it has to.  However,
    I like some of the "set up" notions of VC.  These days, there are
    many things that one might want to "set up" (or more appropriately,
    cache) in the gateways along the path.  These include routing
    information, address information (like a Landmark Address, for instance),
    VISA information.  All of these things can be done without destroying
    the "datagram" aspect of the network.

Paul,

    Sounds to me like you want a frame-relay network.  Sort of a
hybrid...  You set up a "channel" by specifying an end-point, type of
service, etc.  All packets associated with that channel will have those
properties.  The subnet maintains state at the sender's DCE only.

-Philip

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 03:02:00 GMT
From:      german@uxh.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Wang TCP/IP


I had a meeting with some Wang sales people last week and it still is not
a deliverable product.  It is my understanding that some DOD Wang sites 
have a working TCP/IP, but it is not yet ready as a product.  They pointed
out that no product manager at Wang would announce a product if unable to
ship within 45 days due to past problems with advanced announements.

         Greg German (german@uxc.CSO.UIUC.EDU) (217-333-8293)
US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801
Office:  181 Digital Computer Lab.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 03:27:00 GMT
From:      enger@BLUTO.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   Is performing the checksum really that bad?

Bill:

You wrote recently that, 

	Even worse is that fact that in 4bsd this [end-to-end
	checksum] is a host wide option, so if I have a single SLIP
	based client of my NFS fileserver and I want him to get
	checksummed packets, I have to checksum packets for all
	Ethernet only local users as well, users who are more likely
	to be concerned with SPEED [my emphasis] and not with data
	corruption on the Ethernet.

It occured to me that we now live in a new era: A.J. (after Jacobson).
An era in which two small Sun workstations can obtain a TCP throughput
of 8 Mbps, checksums, headers and all; and without fully consuming the CPUs!

I am NOT commenting one way or the other on the SLIP controversy.  
Rather, I would like to offer the thought that the impact on performance
caused by running with end-to-end checksumming enabled may be greater than
it need be.  Perhaps implementers could follow Mr. Jacobson's fine example 
by revising their algorithms and optimizing their code.  Even when only 
modest throughputs are required, a user would still benefit from the 
reduction in CPU utilization.

Bob

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Mon,  4 Apr 88 16:56:52 -0400 (EDT)
From:      Drew Daniel Perkins <ddp+@andrew.cmu.edu>
To:        Randy <randy@larry.cs.washington.edu>
Cc:        tcp-ip@sri-nic.arpa, randy@larry.cs.washington.edu
Subject:   Re: CRC calculation costs (was Re: SLIP working group? )
> *Excerpts from: 30-Mar-88 Re: CRC calculation costs (..*
> *Randy@larry.cs.washingto (680)*

> I'm interested by your statements that checksuming is a very small part of
> the procotcol processing.
That is not what I said.  What I said was that the cost was "low" when using an
incremental table driven CRC computation at asyncronous line speeds (9600 baud).

Drew
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Apr 88 14:32:59 EDT
From:      dvaughan@wnyosi4.arpa
To:        tcp-ip@sri-nic.arpa
Cc:        dvaughan
Subject:   Addition to mailing list
I'd like to be added to your mailing list.  What must I do
in order to get added?  Any help much appreciated.

David Vaughan
NAVDAC (Navy) (v)288-4671, (c)202-433-4671
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 13:38:24 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums, CRC's, and NFS

I seem to recall an article several years ago where cyclical reduncancy check
(CRC), longitudinal redundancy check (LRC), and vertical redundancy check (VRC)
were discussed.  The thrust of the article was that they are, indeed, useful
in detecting transmission errors; however, the difference in the ability of
the CRC algorithm and the LRC algorithm to detect transmission errors was not
that great.  The error detection rates were something like 98% and 94%,
respectively.

A gut feel is that a VRC/LRC combination for error detection is just as reliable
as a CRC for detection of errors *and* saves 5 instructions per byte assuming
the use of a CRC table.  

Merton Campbell Crockett
mcc@etn-wlv.eaton.com

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 14:21:00 GMT
From:      Hornig@ALDERAAN.SCRC.SYMBOLICS.COM (Charles Hornig)
To:        comp.protocols.tcp-ip
Subject:   PLEASE POST TO TCP-IP BULLETIN BOARD


    Date: 2 Apr 1988 14:12-PST
    From: WREN@A.ISI.EDU

    Distributed operating system needed-

    I am working on a project that has as building blocks, Ethernet and TCP/IP.
    We are now considering a choice of distributed operating systems for peer
    to peer communication at the application level.

    The following computers are either on or will soon join our LAN.
    VAX (VMS), Symbolics, SUN, ENCORE, BUTTERFLY, MAC II.
    Any of the above is a potential server.

    1) One of the considerations is NFS by Sun.  I would like to determine which 
    computers (esp. in the above list) have the SUN NFS hosted on them already.

An NFS for the Symbolics is available from ILA (Telephone (617)
577-9500).

    2) Other suggestions are welcome.

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

       WREN@A.ISI.EDU    (WRENWICK LEE)
	    PH: (808)471-8574

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

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 16:55:00 GMT
From:      zweig@uiucdcsp.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Checksums, CRC's, and NFS


	I agree strongly with the point about checksums missing bugaboos
like word-swaps. Especially with all the OSI hassling and with everyone
from Apple to McDonald's (just kidding) brewing up TCP/IP code, the likelihood
that byte-sex induced problems and weird buffer misuse errors will occur 
is increased. 
	Another big overhead that often gets left out of the computation is
this: how much CPU and man-time does it take to figure out what's going on
and fix bugs (rare though they be) caused by _not_ having CRC's in the right
places (i.e. over noisy asynch lines)?? If important files get bit rot and no-
body notices for a long time, it can take many hours of travail to set things
right -- this is a hidden cost of not using CRC's that needs to be taken into
account when talking about bandwidth. A zillion bits per second won't buy you
a thing if you have to go over the files with a fine-toothed comb to see if
they have been munched.

Johnny Zweig
University of Illinois at Urbana-Champaign
(standard disclaimer about being a grad-student and ignorant, etc., etc.)

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 17:57:40 GMT
From:      bobshaw@cg-atla.UUCP (Steve Robertshaw X5552)
To:        comp.protocols.tcp-ip
Subject:   Request for TCP/IP source in C.


We have a 68020 board that has an ethernet (82586 based) sub-system.
Communicates to peripherals is done via a proprietary
Transport Protocol. I am currently investigating what it would take to get
TCP/IP support on this board.

Does anyone have a list of TCP/IP packages that can either be bought or had
publicly. It would be optimal if such a port package were written in C.

In addition, any hints on past experiences in this type of effort would be
highly appreciated. Thanks a lot.


Steve Robertshaw

Compugraphic, Inc.                         decvax!cg-atla!bobshaw
200 Ballardvale St., 200-3-5S               ulowell/ \laidback
Wilmington, Ma.  01887                  cbosgd!ima/   \cgeuro

bobshaw@cg-atla

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 18:32:59 GMT
From:      dvaughan@WNYOSI4.ARPA
To:        comp.protocols.tcp-ip
Subject:   Addition to mailing list

I'd like to be added to your mailing list.  What must I do
in order to get added?  Any help much appreciated.

David Vaughan
NAVDAC (Navy) (v)288-4671, (c)202-433-4671

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 19:58:52 GMT
From:      karels@OKEEFFE.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   release of updated network sources for 4.3BSD

The long-promised release of updated IP/TCP and XNS sources for 4.3BSD
and related systems is now available for anonymous FTP from
ucbarpa.Berkeley.EDU.  The complete source is also being posted to the
"official" 4.3BSD bug fix newsgroup.  The README file for the update is
attached below, and lists the files that comprise the release.  Note that
sites with 4.3BSD source do not require all of these files; one file
contains only unmodified 4.3BSD sources.

For those of you who found the previous files on ucbarpa (placed there
for various testers), note that the release was updated and installed
*today*, April 4.

At some time later in the year, we intend to provide a networking release
that includes these sources as well as network client and server programs
and library files.  That release will be made under a new license agreement
that does not require any AT&T UN*X license; the new license will allow
redistribution and other uses, provided that due credit is given
the University as usual.

		Mike


==============================================================================

This is the description of a release of updated networking software
for the 4.3BSD distribution from the University of California, Berkeley.
These changes are part of the current Berkeley operating system and
will be included in future tape releases.  This release is being
made available by anonymous FTP from the ARPANET and on the Usenet
newsgroup comp.bugs.4bsd.ucb-fixes.

The major changes in this release are in the TCP send policy.
Because the improvements in the send policy could significantly
reduce congestion on the ARPANET and the NSFNET, all sites with
direct or indirect connections to long-haul nets are urged to upgrade
as quickly as possible.  Vendors supplying TCP products based on 4.2BSD
or 4.3BSD are strongly urged to update as quickly as possible.  Vendors
using other TCP implementations should consider the use of the new algorithms
as well, and may find the current Berkeley source code useful as a guide
to their implementation.

The FTP release consists of five files: tcp.tar, inet.tar, netns.tar,
socket.tar and imp.tar.  They are all present on host ucbarpa.Berkeley.EDU
in the directory pub/4.3.  (Each is also available in compressed form,
indicated by a trailing ".Z".)  Each archive file includes a copy of this
file (called README).

The first file, tcp.tar, contains sources for the current version of TCP,
including the slow start algorithm and other work by Van Jacobson of LBL
and a retransmission timer algorithm suggested by Phil Karn.  It is designed
to replace the 4.3BSD TCP, although it also has #ifdef's for installation
in a 4.2-based system (including SunOS versions up to 3.6).  The changes made
since the release of 4.3 dramatically improve performance over slow and/or
lossy networks such as the ARPANET/Milnet and Satnet, and also reduce the
number of unnecessary retransmissions nearly to zero.  Performance on
fast, local-area networks is also somewhat improved, especially on faster
processors when larger buffers are used.  Several new bug fixes have
also been made.  The file TCP_INSTALL contains some hints on configuring
TCP for systems other than standard 4.3BSD and 4.2BSD.

The second file, inet.tar, contains sources for IP, ICMP, UDP and common
internet code (all of the netinet directory except the TCP sources).
It also includes a few files from the sys and h directories that have
been changed since the 4.3BSD release.  There are changes in the processing
of IP record-route and timestamp options and in handling of certain broadcast
UDP requests.  The mbuf allocation routines include a fix for a race and
changes to call the protocol drain routines when appropriate, and will
no longer panic when new allocation requests discover that the mbuf map
has been exhausted.  A recent problem in the code for fragmenting IP packets
with options is fixed.  The complete source for the netstat program is also
included in inet.tar.  It will be usable only on 4.3BSD systems without
modification.  (Note: there are two versions of main.c and host.c in
the netstat directory.  Unless you are installing the new imp code,
you must use main.c.oldimp and host.c.oldimp.)

The combination of tcp.tar and inet.tar is sufficient to upgrade a 4.3BSD
system to the current level of IP/TCP.  It is strongly recommended that
4.3BSD sites that are connected to the Internet, directly or indirectly,
as well as 4.3BSD gateway sites, should upgrade as quickly as possible.

The third file, netns.tar, contains the current version of the Xerox NS
protocols from the netns source directory.  The Sequenced Packet Protocol
has modifications similar to those in TCP, as well as several bug fixes.
Sites that use XNS must upgrade it at the same time as TCP, as the old
XNS code used the old tcp_timer.h.

The fourth file, socket.tar, includes the remainder of the socket and generic
network source files.  These files are identical to those in the 4.3BSD
release.  They are provided for completeness for those who do not have access
to the original 4.3BSD sources.  They are not required for installation
of the TCP and other internet fixes in a 4.3BSD system, nor for installation
of the new internet code into most 4.2BSD-derived systems.  They may
be useful for upgrading the socket or network code in a 4.2BSD-derived
system.  We cannot provide any assistance in such upgrades, but we
are interested in hearing about any successful upgrades.

The fifth file, imp.tar, includes recent modifications to the code for
handling an ARPANET/Milnet IMP using an AHIP (1822) interface.  It was not
quite ready for distribution when the rest of the update was finished, and
may not be present in the anonymous FTP area immediately.  If you want
it, check back later or watch for an announcement on the tcp-ip mailing
list.

Note that the Berkeley network source code is *not* public-domain.
However, as it contains no code licensed by AT&T or others, it is owned
by the Regents of the University of California, Berkeley.  It is provided
as-is, without any warranty, for any purpose.  It may be used, modified or
redistributed in source or binary forms, as long as due credit is given
to the University and the University copyright notices are retained.

These sources may be updated from time to time as improvements or additions
are made.  The next update will include support for IP multicast done
by Steve Deering at Stanford.  Updates will be announced on the tcp-ip
mailing list, which is redistributed on Usenet.

	Mike Karels	karels@Berkeley.EDU
	Van Jacobson	van@lbl-csam.arpa

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 21:03:43 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: link level crap protection

> *Excerpts from: 30-Mar-88 link level crap protection Mike*
> *O'Dell@uunet.UU.NET (587)*
 
> For my two cents...
> If the purpose of a SLIP checksum is ONLY to allow SLIP to know
> a packet is bad and to discard it, then it is tolerable.
> If it does ANYTHING beyond inspect it for damage, trash
> the broken packet, and increment a counter, it is wrong.

This is exactly what it will do, no more, no less.

Drew

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 21:50:49 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP working group?

> *Excerpts from: 30-Mar-88 Re: SLIP working group? Rick Adams@seismo.CSS.GO*
> *(1929)*
 
> If you are going to add multiple protocol support to SLIP, please do it
> in the following manner.
 
> The first byte following a FRAME_END is the protocol type byte.
 
> If the byte is 0x40 - 0x4F the packet is considered to be an IP packet
> and the protocol type byte IS INCLUDED as part of the packet.
I'd originally planned on doing it exactly that way.  Quite a few people I
talked to thought that it wasn't worth it so I dropped the idea.  Maybe I
should take another look at it.  There is one small problem with it which makes
it slightly restrictive.  Just being able to receive old-style packets doesn't
make you backward-compatible.  You have to transmit them also.  To do that you
probably need to keep some state about whether or not you have received
old-style packets.  If the first packet you receive is an old-style packet then
set some flag.  If later you disconnect or receive a packet with a type field
(first byte something other than 0x4x) then reset the flag.

However, this assumes that the first host to transmit packets is the old host.
What if it is the other way around?  What if you send a packet with a type
field to a host which doesn't understand them?  The receiving end won't
understand them and will hopefully drop them on the floor because the IP
checksum was not valid (which suggests that type 0 and 0xff should not be
used!) or maybe because the IP header is not version 4 (which won't be true in
the suggested scheme).  However since the packet is dropped, it won't elicit a
response which will cause the transmitter to continue transmitting new-style
packets unless we add some other hacks like counting transmitted packets and
switching modes after N packets if we don't receive any.  In the simple case
where we are using slip to link pc's and gateways this might not be a problem.
The gateways will likely be the first to change (smaller numbers) and the pc's
will follow (or maybe not).  However we are shooting for wider use of slip than
this simple application.  Supporting gateway-gateway connections is a definite
goal.

Comments?

Drew

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 22:22:07 GMT
From:      Crispin@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   IMAP2 protocol/implementation status

Friends,

     My message to TCP-IP about the IMAP2 protocol seems to have triggered a
flurry of messages, all asking the same thing.  I hope to forestall a
continued blizzard with this message.

     At the present time, the only documentation for IMAP2 consists of some
very preliminary notes which are by now woefully out of date and a BNF.  The
BNF is in the RFC822 extended form, but it hasn't been thoroughly checked for
accuracy or completeness yet.

    I am working on an RFC describing IMAP2, and hope to have it out the door
in the next couple of weeks if my schedule will permit.

    There are several IMAP2 implementations at present:
(1) DEC-20 server, written in assembly language.  This is a completed program,
and will be modified in the future only to add extensions to the language.
(2) Unix server, written in C.  This is still in beta test and has a few
missing capabilities.  Should be available soon.
(3) Xerox Lisp client, written in hybrid InterLisp/Common Lisp.  This program
should be moving towards a stable, final version shortly.
(4) TI Lisp client, written in Common Lisp.  This is a port of the Xerox Lisp
client, and is still under development (mostly in its window handling).
(5) MAC client.  Work has just started.

     We intend to make these implementations generally available, and we
encourage new implementations.  The DEC-20 server can be found online at
SUMEX-AIM.STANFORD.EDU as SS:<MM>MAPSER.MAC and SS:<MM>IMAPSV.MAC; the other
implementations will be offered once policies/procedures/etc are ready.

     The BNF can be found on PS:<CRISPIN.MM-D>IMAP2-SPECIFICATION.TXT on
SUMEX-AIM.STANFORD.EDU.

     If any brave souls would like to start on an implementation from the BNF
(that's pretty much how the Unix server was written!) and/or the DEC-20 code,
I can offer encouragement and question-answering as well as being willing to
set up bake-offs.  At present all of the implementations are compatible with
each other and we'd like to keep it that way!

-- Mark --

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 22:37:45 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP complexity

In fact, there is one very nasty error which the IP checksum does not catch.
Because carries are added in, a word of 0's is interchangable with a word of
1's.  For example:
x + 0 = x
x + 0xffff = x !!!!

This problem has caused us no end of trouble.  Early Ungermann Bass ethernet
boards for IBM RTPC's had a problem such that a packet would be corrupted AFTER
it had passed the ethernet CRC check.  However it also passed the IP/UDP
checksum test.  This caused us many problems with corrupted files and
directories.  The point is that this type of error may not be that uncommon on
async lines.  Noise could easily insert nulls.  If those nulls were in the
place of valid 0xff's you may be in trouble.

Drew

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 22:57:20 GMT
From:      ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre)
To:        comp.protocols.tcp-ip,news.groups
Subject:   comp.protocols.tcp-ip.eniac


Well, such a group (for interesting stuff) already exists in the Internet side
of things. It's called INFO-COBOL.  Why not create comp.lang.cobol on the
USENET side (which would be even better from a bean-counter-point of view,
plus have some kind of correspondence with with already existing list.)

Some enterprising soul could set up a one-way link between the groups if
necessary (since I doubt the Internetters would want to put up with the 
trash from the USENET side, and the USENET types probably wouldn't put up
with 'moderation' anyway.)

Here's a copy of the mail I sent...  I wonder how many header-parsing
programs and news systems it will break?


Date: Mon, 4 Apr 88 18:42:38 EDT
From: Ralph.Hyre@IUS3.IUS.CS.CMU.EDU
To: webber@ARAMIS.RUTGERS.EDU
Subject: NO for comp.protocols.tcp-ip.eniac

It might be acceptable if the name were changed to comp.lang.cobol,
since there's an info-cobol (hack) mailing list in the Internet
which could be fed into comp.lang.cobol.

Thanks.
					- Ralph

--
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
-- 
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 23:40:50 GMT
From:      smith@cos.com (Steve Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Fiber Optic Ring Backbone

In article <8803292224.AA13808@trout.nosc.mil> carrs@TROUT.NOSC.MIL (Stephen M. Carr) writes:

>[Asks for info on an "802.3 fiber optic ring network" from Fibercom]

I am not familiar with Fibercom or their products.  However, there is
currently an effort within the IEEE 802.3 committee to come up with a
standard fiber optic star network (FOSTAR).  This network would be
compatible with all other 10 MBit/sec 802.3 networks at the AUI level -
all you'd need to change to go to fiber optics would be the MAU (or tap
tranceiver, for you non 802.3 types :-)

Technically, the problem with using fiber optics in a bus topology is
that (unless you're No Such Agency :-) there is no such thing as a high
impedance tap.  As a result, you either have to have a true ring
topology (as in FDDI) or have some kind of gizmo (called a hub) in the
middle of your network to handle signal distribution.  The hub can be
either passive or active.  Both ways have their adherents.  Passive
systems are cheaper and don't need power for the hub.  Active systems
can cover longer distances, handle more nodes, and are easier to
balance.

Unfortunately, the two types are not compatible, except through
repeaters.  Also, some of the discussions within the FOSTAR committee
seem to be approaching the holy war state, and it looks like we may end
up with two separate, incompatible standards (active hub and passive
hub).


Since you want to use this stuff as a backbone, you might investigate a
new standard, IEEE 802.3, Section 9.9, December 1987, "Vendor
Independant Fiber Optic Inter Repeater Link".  It might be closer to
what you need.


(Anything that looks like an Official Opinion probably isn't.)

-- 
                -- Steve
(smith@cos.com)    ({uunet sundc decuac hqda-ai hadron}!cos!smith)
"Truth is stranger than fiction because fiction has to make sense."

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 88 23:43:18 GMT
From:      ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   Mac TCP/IP (KA9Q vs. NCSA vs. SU-MacIP)


[not sure if followup to comp.protocols.appletalk is completely appropriate,
but as long as we're machine-specific we might as well.]

In article <8804021615.AA18966@ucbvax.Berkeley.EDU> michel@CCT.BBN.COM (Tony Michel) writes:
>Well, Thanks!...
>My Mac is a real host on the Internet!  
>
>This system works very well, and is shockingly cheap.
>
>Having said something nice, now let me grumble.  The correct solution to
>my previous query would be to have the NCSA software support  User FTP, and
>I'm not sure why it does not.  Perhaps they have plans?  Anyway, for
>something FREE, it's great.
SU-MacIP is another implementation from Stanford which supports multiple 
TELNET, FTP, and Finger stuff, using as much of the Mac Interface as the
implementors though of.  User FTP is most impressive, since it looks
like a standard file dialog for copying from disk to disk.

There's also a free (to non-commercial, presumably, since it's Mikel
Matthews' port of Phil Karn's 'KA9Q' TCP/IP stuff), but it's definitely
non-Mac interface at this point. [In fact my version crashes when you use 
the mouse, due to interrupt problems.]  It also purports to support TCP over
Appletalk, but since I wasn't able to understand the documentation well 
enough to configure it I was never able to try telnetting to something
else via our Apple LocalTalk<->Kinetics<->Ethernet connection.

I believe SuU-MacCIP is available for a small amount of money, small being 
relative to who you are [University vs. Commercial.]  (Yes, there was some 
grumbling on info-appletalk [aka comp.protocols.appletalk] about the licensing
policy when it was announced over a year ago, since people at commercial places
[BBN in particular] helped out with early guts of the code, then were getting
screwed on the licensing fee)

Possible Disclaimer: The ITC here was stress testing 2 early implementations of
these last fall, and NCSA was so flakey as to be unusable, so it was hard to 
get experience with it versus the much more stable SU-MacIP.  I don't recall
version numbers, but I'm fairly certain that they were both pre-release.
Neither version dealt with the Kinetics box crashing very well.  (That's
the weak link that I see in this Mac networking stuff)

Hopefully someone will write an IP router for a Mac II that uses the Apple 
EtherTalk card to link some Apple LocalTalk nets together.  (Can A/UX do this,
or has Apple had time to rip the TCP/IP stuff out and put DECnet in:-(
--
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
-- 
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Apr 88 07:13 CST
From:      PMDF Mail Server <Postmaster@UHRCC2.CRCC.UH.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
The message could not be delivered to:

Addressee: howard%crcc
Reason: 
  %LIB-E-ACTIMAGE, error activating image DUA8:[SYS0.][SYSLIB]DELIVER_MAILSHR.EXE;6
  -SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image

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

Received: from JNET-DAEMON by UHRCC2.CRCC.UH.EDU; Tue, 5 Apr 88 07:09 CST
Received: From TAMVM1(MAILER) by UHRCC2 with RSCS id 6052 for NSMCC@UHRCC2;
 Tue,  5 Apr 88 07:08 CST
Received: by TAMVM1 (Mailer X1.24) id 6024; Tue, 05 Apr 88 08:11:58 CDT
Date: Mon, 4 Apr 88 18:08:20 PST
From: postel@venera.isi.EDU
Subject: IP/X.25 Call User Data
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@TAMVM1.BITNET>
To: 'Howard Jares' <NSMCC@UHRCC2>
X-VMS-To: 'Howard Jares' <NSMCC@UHRCC2>
Reply-to: TCP-IP@SRI-NIC.ARPA
Resent-date: Tue, 5 Apr 88 07:10 CST
Resent-to: howard%crcc@UHRCC2.CRCC.UH.EDU

Darren Wall:
     
See RFC-877.
     
--jon.
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 01:19:04 GMT
From:      johnl@n3dmc.UUCP (John Limpert)
To:        comp.protocols.tcp-ip
Subject:   SLIP link error correction

Link error correction may be desirable in some situations, but I don't
think it belong in SLIP.  SLIP should be a simple, easy to implement
method for transmitting/receiving packets.  The addition of a link level
CRC check doesn't bother me, it would be easy to implement, reduce the
chance of undetected data corruption and do minimal violence to the
existing SLIP 'philosophy'.  The addition of the retransmission of
damaged packets adds a great deal of complexity, assumes a bidirectional
link, and provides a completely different service.  This should be a
separate protocol.  SLIP should not be asked to do more than datagram
encapsulation.  Any changes should be upwards compatible with existing
implementations and not change the ability to implement it as a simple
simplex transformation. 

I do support the addition of an optional link level CRC check.  The
table lookup computation of 16 or 32 bit CRC's is a relatively cheap way
of adding reliability.  The existing IP checksum is adequate for
assuring end-to-end integrity, but I don't think it is appropriate for
link level error detection.  Don't tell me to buy a bunch of MNP modems,
I had a hard time acquiring the existing dumb modems.  The
telecommunications Czars (TELCO and LOCAL) are not interested in my
problems.  I have to live with noisy, voice grade lines and dumb modems. 

John Limpert	bellcore!wb6rqn!n3dmc!johnl
		johnl@n3dmc.UUCP

P.S. If someone could mail a copy of the VMTP RFC to johnl@gronk.UUCP,
it would be greatly appreciated.

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 02:08:20 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   IP/X.25 Call User Data

Darren Wall:

See RFC-877.

--jon.

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 1988 06:38-EDT
From:      CERF@A.ISI.EDU
To:        philipp@LARRY.MCRCIM.MCGILL.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Checksums
Philip:

I introduced the "off by one" idea, tongue in cheek, in a private
message to Jack Haverty who then took up the challenge... actually,
I don't think we are ready for clairvoyant software, unless maybe Jack
has some ideas I haven't heard yet...

Vint
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 1988 11:04-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        Link@GUNTER-ADAM.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, afddn.beach@GUNTER-ADAM.ARPA afres.hq-sip@GUNTER-ADAM.ARPA, tmd@MITRE-BEDFORD.ARPA
Subject:   Re: Net Nums and Gateways
You are doing exactly the right thing...  42 class B addresses.

BUT...   if  you  decide  to  install trunkc between your various
gateways, you could  treat  all  the  networks  served  by  those
gateways as part of the same class B subnetted network.

Mike St Johns, DDN Program

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 1988 10:16:52 CST
From:      Link@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        LINK@GUNTER-ADAM.ARPA, afddn.beach@GUNTER-ADAM.ARPA, afres.hq-sip@GUNTER-ADAM.ARPA, tmd@MITRE-BEDFORD.ARPA
Subject:   Net Nums and Gateways

	I'm getting the legwork started to connect 42 local area 
(802.3) networks up to the MILNET and have run into a hitch.  
A single Class B network would have ample address space for the 
hosts on all 42; however, each of my networks is geographically 
separated.  I could request Class C networks, but several of my nets
will have more than the allowed 254 (256) hosts. 

	Sue at the NIC (HOSTMASTER) sent me INTERNET-NUMBER-TEMPLATE.TXT,
which is the application for net numbers and referenced me to RFC 950, 
the Subnetting procedures.  Neither of these really answer my questions;
the template strongly recommends subnetting if you have multiple lans and
more than a 100 hosts and RFC 950 discusses that subnetting.  All good
information, in fact we will be running local subnets at most locations 
(all those that have more than a single baseband segment) and will use
a local bit mask on the bridges.  My problem is we'll have 42 separate
connections (gateways) to the MILNET and it's my understanding that I
can't break up a Class B (or any class net, for that matter) network 
into subnets across the DDN.

	Because of the reasoning shown above, I'm planning on requesting
a block of 42 Class B network numbers.  I realize that Class C would 
suffice for many of my nets, but allowing for growth, most of them should
exceed the address space of a Class C net in a fairly short time.  Of
course if I've made some glaring error in reasoning (like not knowing of
a graceful way to cram more than 256 hosts into an 8-bit address space)
feel free to flame me.  Otherwise, I'd appreciate any pointers anybody
out there can give me; I like pats on the back too...

	I'm also looking for the gateways to connect all these lans to
the MILNET.  I know a few vendors, but know someone would be upset if
they didn't get a copy of our IFB and they had a product that satisfy
the requirement.

	Please address all replies directly to me; I might miss them in
filtering through the rest of the TCP-IP mail.  I'll summarize for the
world.  Thanks.



  |====================================================================|
  |  Link Verstegen                Network Solutions, Inc. (NSI)       |
  |  Lead Hardware Engineer        4350 Will Rogers Parkway, Suite 100 |
  |                                Oklahoma City, OK  73064            |
  |  Link@Gunter-Adam.ARPA         (405)942-8884                       |
  |====================================================================|

-------
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 07:27:56 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.protocols.tcp-ip,news.groups
Subject:   INFO-COBOL (was comp.protocols.tcp-ip.eniac)

In article <1306@PT.CS.CMU.EDU> ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre) writes:
>Well, such a group (for interesting stuff) already exists in the Internet side
>of things. It's called INFO-COBOL.  Why not create comp.lang.cobol on the
>USENET side (which would be even better from a bean-counter-point of view,
>plus have some kind of correspondence with with already existing list.)

INFO-COBOL has been pretty dead for some time now, unless it's misplaced a
large chunk of its readership. Since it's probably being run off a Cobolics
Workstation, that's not too unlikely...
-- 
			- john romkey
UUCP: romkey@kaos.uucp			ARPA: romkey@xx.lcs.mit.edu
 ...harvard!spdcc!kaos!romkey		Telephone: (617) 776-3121

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 10:17:59 GMT
From:      swb@DEVVAX.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP working group?

Drew, consider version negotiation.  The EGP3 crowd worked out a
wonderful system for it.  I can't remember if it was going to be its
own RFC, or if it's included in the EGP3 document (or both).
						Scott

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 10:38:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums

Philip:

I introduced the "off by one" idea, tongue in cheek, in a private
message to Jack Haverty who then took up the challenge... actually,
I don't think we are ready for clairvoyant software, unless maybe Jack
has some ideas I haven't heard yet...

Vint

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Apr 88 17:02 CDT
From:      Neil Erdwien <NEIL%KSUVM.BITNET@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   SLIP suggestion
Has anyone considered making SLIP work on an IBM system?  In particular,
most IBM systems will only handle 7-bit ASCII.  When I last looked at
SLIP it assumed an 8-bit channel.  IBM reads must be terminated by a
carriage return also.  There might also be full/half duplex
compatibility problems.

Neil Erdwien
Kansas State University
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Apr 88 12:08:38 BST
From:      "John Heaton (G1YYH@G4BVE) 061-275-6011" <ZZAPSJC%CMS.UMRCC.AC.UK@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   STOP SENDING POSTCARDS

PLEASE IGNORE THE MESSAGE REPRODUCED BELOW, THERE HAS BEEN AN APPEAL ON TV
IN THE UK FOR THIS TO STOP. THE STORY IS TRUE, BUT DAVID HAS ALREADY
ESTABLISHED A WORLD RECORD FOR COLLECTING POSTCARDS, AND AS SCHOOL IS
GETTING FED UP WITH THE EXCESSIVE MAIL.


>  David is a 7 year old boy who is dying from cancer.
>  Before he does, he has a dream of one day being in the Guiness Book of
>  Records for the person who has had the most postcards sent to him.
>  If you would like to help David achieve his dream, all you have to do is send
>  a postcard to him as soon as possible.
>  Send to :
>             David
>             c/o Miss McWilliams
>             St. Martin de Porres Infant School
>             Luton,
>             Bedfordshire
>             England       **DON'T FORGET TO SIGN YOUR NAME**


===============================================================================
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 16:16:52 GMT
From:      Link@GUNTER-ADAM.ARPA
To:        comp.protocols.tcp-ip
Subject:   Net Nums and Gateways


	I'm getting the legwork started to connect 42 local area 
(802.3) networks up to the MILNET and have run into a hitch.  
A single Class B network would have ample address space for the 
hosts on all 42; however, each of my networks is geographically 
separated.  I could request Class C networks, but several of my nets
will have more than the allowed 254 (256) hosts. 

	Sue at the NIC (HOSTMASTER) sent me INTERNET-NUMBER-TEMPLATE.TXT,
which is the application for net numbers and referenced me to RFC 950, 
the Subnetting procedures.  Neither of these really answer my questions;
the template strongly recommends subnetting if you have multiple lans and
more than a 100 hosts and RFC 950 discusses that subnetting.  All good
information, in fact we will be running local subnets at most locations 
(all those that have more than a single baseband segment) and will use
a local bit mask on the bridges.  My problem is we'll have 42 separate
connections (gateways) to the MILNET and it's my understanding that I
can't break up a Class B (or any class net, for that matter) network 
into subnets across the DDN.

	Because of the reasoning shown above, I'm planning on requesting
a block of 42 Class B network numbers.  I realize that Class C would 
suffice for many of my nets, but allowing for growth, most of them should
exceed the address space of a Class C net in a fairly short time.  Of
course if I've made some glaring error in reasoning (like not knowing of
a graceful way to cram more than 256 hosts into an 8-bit address space)
feel free to flame me.  Otherwise, I'd appreciate any pointers anybody
out there can give me; I like pats on the back too...

	I'm also looking for the gateways to connect all these lans to
the MILNET.  I know a few vendors, but know someone would be upset if
they didn't get a copy of our IFB and they had a product that satisfy
the requirement.

	Please address all replies directly to me; I might miss them in
filtering through the rest of the TCP-IP mail.  I'll summarize for the
world.  Thanks.



  |====================================================================|
  |  Link Verstegen                Network Solutions, Inc. (NSI)       |
  |  Lead Hardware Engineer        4350 Will Rogers Parkway, Suite 100 |
  |                                Oklahoma City, OK  73064            |
  |  Link@Gunter-Adam.ARPA         (405)942-8884                       |
  |====================================================================|

-------

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 16:45:00 GMT
From:      zweig@uiucdcsp.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Request for TCP/IP source in C.


Two nice TCP/IP implementations:

		KAQ9

		NCSA Telnet

  Both are nice and written in C. I hacked the NCSA code for awhile, trying
something rather ickier than just adapting it to a 68020 board. Either
should work nicely for your application -- maybe you should grab both.
  NCSA code is available via anonymous FTP from: ncsa.uiuc.edu. You just cd
into the NCSA_Telnet directory and mget what you want.

Johnny Zweig
Dept. of Computer Science
University of Illinois at Urbana-Champaign
(standard disclaimer)

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 16:52:31 GMT
From:      braden@venera.isi.EDU
To:        comp.protocols.tcp-ip
Subject:   OSI Has Arrived!

There are intermittent bursts of controversy on this list about whether
or not the OSI protocols are only paper figments.  Attached you will find
a piece of hard evidence that some OSI protocols (X.400) are actually alive
and functioning.  You can tell this are real, not demoware, because it is
screwing up!  (No, MTA is NOT the Boston subway system).

Bob Braden


----- Begin Forwarded Message -----

From @RELAY.CS.NET:mmdf@zix.gmd.dbp.de Mon Apr  4 19:39:05 1988
Date: Mon, 4 Apr 88 19:38:59 PDT
Posted-Date: Mon, 4 Apr 88 19:38:59 PDT
Received-Date: Mon, 4 Apr 88 19:38:59 PDT
Message-Id: <8804050238.AA23604@venera.isi.edu>
Received: from RELAY.CS.NET by venera.isi.edu (5.54/5.51)
	id AA23604; Mon, 4 Apr 88 19:38:59 PDT
Received: from relay2.cs.net by RELAY.CS.NET id am10000; 4 Apr 88 22:37 EDT
Received: from zix.gmd.dbp.de by RELAY.CS.NET id ce01890; 4 Apr 88 22:25 EDT
Received: from zix.gmd.dbp.de by .zix.gmd.dbp.de id a003643; 5 Apr 88 1:10 MET
To: braden@VENERA.ISI.EDU
From: DFN Gateway <postmaster%zix.gmd.dbp.de@RELAY.CS.NET>
Subject: DFN Mail Network -- failed mail
Status: R

Mail Failure Diagnostics:
Rejected-Message-id: <8803301719.AA03945@braden.isi.edu>

Message Recipients:
   nittmann@rusvx1.rus.uni-stuttgart.dbp.de: MTA congestion


----- End Forwarded Message -----

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 17:19:00 GMT
From:      cracraft@venera.isi.edu (Stuart Cracraft)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   netin: Connection reset by peer

The following transaction took place on two subnets
(e.g. A.B.C and A.B.C2). 

I ftp'd from one host to a MicroVax running Ultrix.
Then, a 'dir' or 'get' command resulted in:

200 PORT command okay.
150 Opening data connection for /bin/ls (128.149.3.151,1213) (0 bytes).
netin: Connection reset by peer
226 Transfer complete.

Does anyone know what the mysterious 'netin: Connection reset by peer' is?

	Stuart

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 17:50:55 GMT
From:      dwall@hpindda.HP.COM (Darren Wall)
To:        comp.protocols.tcp-ip
Subject:   Re: IP/X.25 Call User Data ...

> 
> Is it an "accepted practice" to use 0xCC in the first byte of
> Call User Data in an X.25 CALL REQUEST Packet for routing IP
> data over an X.25 Link?  I know that for DDN Standard Services
> it's required, but I had thought that everyone did it whether
> DDN Standard is being requested or not.
> 

Please note the "accepted practice" phrase.  The reason I posted
the note was to find out if other people knew of implementations
that did the same thing.

After talking with my Corporate Telecommunications Department, I 
understand that this is a bug with the particular version of firmware
that I had.  However, this was the first node of many that I need
to set up and I was shocked to find that my assumptions were wrong.
The 0xCC flag is important when nodes need simultaneous X.25 and IP
access.

Darren Wall

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 17:56:38 GMT
From:      LYMAN_CHAPIN@ICE9.CEO.DG.COM
To:        comp.protocols.tcp-ip
Subject:   Re: OSI does not mean X.25

>> Not to put too fine a point on it, how many different vendors have
>> implementations which are either known to interoperate or have been
>> through COS certification? I'm glad to know the specs are finished.
>> I will be even more happy to know that there are implementations for
>> many operating systems and hardware bases which can work together and
>> which you can buy off the shelf.

Amen!  OSI has a LONG way to go before it even comes close to the level
of real-product availability of TCP/IP.  It would be very difficult
(although not impossible) to go out into the world today & put together
a fully OSI network using commercially available hardware & software.
And, more to the point, there would be very little reason to go to the
trouble of doing so - TCP/IP products are readily available, they do
the job, and they are (after years of experience and engineering) both
efficient and reliable.  I am not suggesting that the moment an OSI
product becomes available, it is ipso facto preferable to its TCP/IP
counterpart!  But sooner or later everyone (well, almost everyone) is
going to have to figure out how to make OSI networks work.

Unfortunately, while a few people have been working to factor the
advantages of TCP/IP internetworking into OSI (via ISO TP/IP) in an
effort to make OSI viable (i.e. not just X.25 and PTTs), too many
other people have been just bashing it (and OSI, like most network
architectures, is highly bashable), on the assumption (presumably)
that they would never have to live with it.  Which brings us to the
current state of affairs:  commercial OSI gear is X.25-based (and
most of it is in Europe), because the people with a vested interest
in TP/IP-based OSI haven't been working on OSI - they've been
working on TCP/IP, and taking pot shots at OSI whenever possible.
Perhaps OSI will fail worldwide, thereby keeping the world safe
for TCP/IP.  Or, perhaps OSI (based on X.25) will quickly become
the norm in the rest of the world (thanks to various combinations
of PTTs), while we play catch-up.  I like TCP/IP a whole lot better
than X.25-OSI;  but I would like an internationally viable TP/IP-OSI
even better.

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

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 18:04:00 GMT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Net Nums and Gateways

You are doing exactly the right thing...  42 class B addresses.

BUT...   if  you  decide  to  install trunkc between your various
gateways, you could  treat  all  the  networks  served  by  those
gateways as part of the same class B subnetted network.

Mike St Johns, DDN Program

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 18:45:21 GMT
From:      rminnich@udel.EDU (Ron Minnich)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?

In article <8803311257.AA16410@mome.cs.umd.edu> steve@cs.umd.EDU (Steven D. Miller) writes:
>As of the last time I looked (SunOS 3.2), you can't turn UDP checksums on
>for NFS packets.  A code path that is completely separate from the "normal"
>UDP and IP output code paths is being taken.  Has this changed since 3.2
>came out?  How many NFS licensees are also not using checksums here?
   I got an interesting perspective on this from Sequent. Udel
just got a 10-processor Balance system, with NFS. NFS did not 
come with it, though, as shipments of NFS had been halted. The
reason, according to support people at Sequent, is that undetected
errors were making their way through their enet hardware, undetected
because checksums were turned off on NFS. The fix was to isolate
the patterns and tighten up their enet hardware. The fix was hard
because it was something like 10 patterns that occurred VERY infrequently.
I am told that NFS is shipping again from Sequent, minus errors.
We don't have ours yet, though.
   Going from Mt. Xinu 4.3 to an Ultrix system we can very easily
and very repeatably (100%) get errors just compiling files. We haven't
had a chance to track it down, but when we compile one of the X-windows
files (a small one) the .o file gets trashed. And yes, no UDP checksums.
-- 
ron (rminnich@udel.edu)

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 19:47:39 GMT
From:      riedl@cs.purdue.EDU (John T Riedl)
To:        comp.protocols.tcp-ip
Subject:   Re: CRC calculation costs (was Re: SLIP working group? )

Tom Mueller and I did some experiments [1] on measuring the costs of
various components of UDP on Suns (3/50s), using *very small packets*.
We measured UDP round-trips of 7.2ms, with checksuming being 0.12ms of
that, and mbuf manipulation about 0.5ms.  1.6ms was spent in the
socket layering (just the socket abstraction code), 0.5ms in the
context switch on receive, and 0.4ms in copying from kernel to user
space.  Note that these are the cheap 1s-complement bitsums that have
been under discussion recently and that only the headers are being
checksumed.

Our data compare well with Watson and Mamrak's work on VMS [2].  They
report on transmitting 1024 byte packets.  The total transmission time
(one-way) was 4.2ms, of which 0.5 ms was data checksuming vs. 0.8ms
for the context switch and system call overhead.  So at least in some
environments, checksuming is relatively cheap.

[1] Bharat Bhargava, Tom Mueller, and John Riedl, "Experimental
Analysis of Layered Ethernet Software".  In Proceedings of the
ACM-IEEE Computer Society 1987 Fall Joint Computer Conference.

[2] Richard Watson and Sandy Mamrak, "Gaining Efficiency in Transport
Services by Appropriate Design and Implementation Choices".  ACM
Transactions on Computer Systems, May 1987.
-- 
John Riedl
{ucbvax,decvax,hplabs}!purdue!riedl  -or-  riedl@mordred.cs.purdue.edu

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 21:08:01 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: Checksums, CRC's, and NFS


	places (i.e. over noisy asynch lines)?? If important files get bit

The point I was trying to make and a lot of people missed is:
	An async line is not usually noisy. You do not have to
	automatically put a CRC on it. You probably don't use a
	CRC between your terminal and the TTY MUX on the host. That's
	because it's not necessary in 99% of the cases.

	The same holds true for async lines in general. They don't
	normally have a noise problem. If you have a serious noise
	problem, you shouldn't be using a simple async scheme. Buy a
	paid of decent modems and let them do the work. (E.g.
	today you can buy a pair of telebit trailblazers for $1345.)

If you need a special case for your special environment, fine. 
However, don't claim that a protocol that doesn't have it is
broken.

No one seems to feel the need to put a CRC around the TCP/IP packet
that is handed to the ethernet. Yet, given a broken ethernet board, you
could be just as likely to have a corrupt packet as with SLIP without a
CRC

--rick

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 21:28:41 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   SLIP

Drew,

Allowing an LLP (SLIP in this case) to "use" information contained in a
ULP header violates the concept of layering and it invites disaster
should the ULP header change in the future.  As the specifier of the LLP
you have no control over ULP header content.  

On the other hand it appears that "new" SLIP will negotiate options. 
This implies that both ends know how to negotiate.  Since there is no
way for "old" SLIP to negotiate with "new" SLIP it might be possible to
use that information (the lack of negotiation) to flag this as an "old"
slip link.  When a "new" SLIP driver attempts to elict a response from
an "old" SLIP driver, a valid response seems unlikely.  A reasonable
number of attempts can be made before the "new" SLIP driver decides to
speak "old" SLIP. 

One more thing -- we have been trying to contact you for some time now
to no avail.  Could you please ACK this messags so that I know that you
have received it?  Could you also give me another address, i.e. 
telephone number, where I can reach you?  Thanks.

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
brian@wb6rqn.uucp
Share and enjoy!

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 21:32:04 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Becoming part of the Internet

At Sirius Systems we are actively involved in the development of TCP/IP
based products.  We would like to become part of the Internet if it is
possible.  Currently our software supports IEEE 802.3 (not too useful in
this case), AX.25 (again not too useful), and SLIP.  We plan to have
X.25 in place Real Soon Now.  We would like to find some way to become a
permanent part of the Internet.  Any suggestions would be greatly
appreciated. 

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
brian@wb6rqn.uucp
Share and enjoy!

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 88 22:02:00 GMT
From:      NEIL@KSUVM.BITNET (Neil Erdwien)
To:        comp.protocols.tcp-ip
Subject:   SLIP suggestion

Has anyone considered making SLIP work on an IBM system?  In particular,
most IBM systems will only handle 7-bit ASCII.  When I last looked at
SLIP it assumed an 8-bit channel.  IBM reads must be terminated by a
carriage return also.  There might also be full/half duplex
compatibility problems.

Neil Erdwien
Kansas State University

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 00:37:00 GMT
From:      YMUM86@PRIME-A.CENTRAL-SERVICES.UMIST.AC.UK (John Heaton)
To:        comp.protocols.tcp-ip
Subject:   POSTCARDS to DAVID

Keith

In Info-Hams digest 131 there was a mail message about a boy called David
living in Wales who is dying from cancer, the message was repeated from
sri-nic.arpa, and was asking people to send David a postcard c/o a Miss
MacWilliams at his school.

About a month ago there was a report on the BBC TV program 'Thats Life'
which said the school had been flooded with postcards from around the
world. David has achieved his record attempt, but the postcards keep
on flowing in. The school/parents have requested that no more postcards
be sent.

Could you please recirculate this request around any similar networks
/mailing lists etc.,

John Heaton, UMRCC Network Unit (Room G45)
             Manchester University

Telephone    : +44 61 275 6011
Janet        : J.Heaton @ UMIST.CN.PA
BitNET/Earn  : J.Heaton % PA.CN.UMIST.AC.UK @ UKACRL
Packet Radio : G1YYH @ G4BVE


Tue, 05 Apr 88 13:37:52 BST

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Wed, 06 Apr 88 08:57 PDT
From:      Michael Stein                        <CSYSMAS@UCLA-CCN.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: SLIP suggestion
> >Has anyone considered making SLIP work on an IBM system?  In particular,
> >most IBM systems will only handle 7-bit ASCII.  When I last looked at
> >SLIP it assumed an 8-bit channel.  IBM reads must be terminated by a
> >carriage return also.  There might also be full/half duplex
> >compatibility problems.

Likely the "near future" best way to do this is to run SLIP to a
PC which sits on a local LAN.  (Who's using your PC when your not
there?)

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Wed, 06 Apr 88 08:41:14 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Link@GUNTER-ADAM.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, afddn.beach@GUNTER-ADAM.ARPA, afres.hq-sip@GUNTER-ADAM.ARPA, tmd@MITRE-BEDFORD.ARPA, brescia@PARK-STREET.BBN.COM
Subject:   Re: Net Nums and Gateways

     <from STJOHNS>
     You are doing exactly the right thing...  42 class B addresses.

Since the idea of subnetting is to hide the distinction among the subnets from
the rest of the routers, you can use a single net which you subnet.  The
penalty you pay is to have the other routers send to an arbitrary one of your
42 gateways in order to reach a particular subnet.  This means you must be
prepared to take a packet addressed to subnet #27 in on the gateway for subnet
#33 and forward it to the proper your other gateway for subnet #33.  You may
have better (faster) connections inside your domain than on the DDN, so it may
not be too painful in user delay or DDN overload.

If the source of the packet is a host on the DDN, rather than a gateway, then
your gateway can send an ICMP redirect-host to get further packets to the
proper gateway [flames about hosts which do not listen to redirect-host go to
those hosts].

This example has come up often in the past, but usually the number of sites
has been around 2 rather than 42.  For the cases where the sites have no
separate connection, they used separate nets.  For the cases where the
sites had backdoor trunks, or a bridged ethernet, they used a single net, and
paid the extra penalty of sending traffic over their internal trunk that came
in on the 'wrong' gateway.

Mike
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 02:42:13 GMT
From:      donegan@stanton.TCC.COM (Steven P. Donegan)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: computing network loads

In article <23564@hi.unm.edu>, cyrus@hi.unm.edu (Tait Cyrus) writes:
> 
>    I am looking for an equation that roughly computes the theoretical
> load on a network given only the following information:
> 	1) time over which the load is to be computed,
> 	2) the number of packets seen in that time,
> 	3) the number of bytes seen in that time.
> 
>    Currently I am using something like:
> 	num_bytes / (MBYTES_PER_SEC * time)
There is a fundamental question which must be asked before any answer to
this question can be considered - what type of LAN are you trying to get
bandwidth utilization numbers for? An Ethernet type LAN is extremely variable
based on the number of 'stations' or 'nodes', differences in nodal load and
collision detection timing, traffic rate per node etc. A token ring on the
other hand can be very predictable in it's performance.

Steve Donegan
Sr. Telecommunications Analyst
Western Digital Corp.
donegan@stanton

-- 
Steven P. Donegan
Sr. Telecommunications Analyst
Western Digital Corp.

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 03:17:43 GMT
From:      jeffreyb@dasys1.UUCP (Jeffrey L Bromberger)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Overload Problem

This posting is for a friend on a machine with no outgoing newsfeed.
He/I/we have no idea why this happens (no outgoing, yet incoming
news), but that goes in a different group :-)

Here is his article
===========   cut here  ==============

I am new to the problems of TCP/IP on an ethernet and am slowly
learning my way around.  We have a problem which I can "fix" but which
I don't understand.  The observable problem is that the ethernet
becomes so filled with packets that none of the computers connected to
it can get any work done because they are busy servicing interrupts.
Since I don't know what the packets contain, I hesitate to label it a
broadcast storm.

Let me describe our setup more completely.  We have a Vax/780, a
Vax/750, a Celerity 1260, and a Bridge Communications CS/100 connected
together by a DELNI.  We run 4.3BSD Unix on the 3 computers and use
TCP/IP.

The problem first occured when we connected an Evans&Sutherland PS350
to the DELNI.  Booting up the PS350 would send the interrupt rate on
the 780 to a level where it wasn't even an adequate single user
machine.  I eventually persuaded myself that it was related to
trailers and the way to get rid of the problem was to use arp -s to
define the name and ethernet address for the PS350 (leaving off the
trailer attribute).  None of the other hosts on the "ethernet" had arp
entries in the boot startup file (/etc/rc.local).  I did not add them.

I think now that the above analysis of the problem was incorrect.

The reason that I changed my mind is that the problem came back after
being gone for about 9 months.  The occasion of the reappearance was a
rebuilding of the system disk for the CS/100.  The CS/100 had been a
bit flakey recently and so it seemed like a good idea to start with a
fresh system diskette.  It was rebuilt with all the same parameters as
the original.  Booting up the CS/100 caused the problem.  Rebooting
seems to have eliminated the problem for the time being.  Both the
Vaxen have been down since the change and the problem has not come
back.  (It has been 2 weeks now.)

Now, the questions.  What tools do I have in BSD Unix to diagnose this
problem?  Should I use arp -s to define all of the hosts on the
ethernet?  Why?  Any ideas what is causing the problem?

I would like to have a better understanding of what is giong on here
because in a short while we will be running a real ethernet with at
least another Bridge hung off it.

Thanks for your help.  If these questions are too elementary to have
answers of general interest then mail to me instead of posting.

Dan Schlitt
UUCP: backbone!cmcl2!{phri,cucard}!ccnysci!dan
BITNET: dan@ccnysci.BITNET

=========  cut here  ================

There it is.  Can you help us please, as this bogging down of the
ethernet is making life/work here abominable.

Thanks in advance!!
-- 
*---Jeffrey Bromberger -- 2847 West 22nd Street Brooklyn, NY 11224---*
|   Compu$erve:  71171,730                   /dasys1!jeffreyb        |
|   UUCP:                 cmcl2!{cucard,phri}!ccnysci!jeffrey        |
*---Disclaimer: "My school disavows any knowledge of my actions!" ---*

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 03:45:10 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP suggestion

Neil,

Ouch. I can't believe "most" IBM systems are that bad. Twenty years ago (really)
I designed this fool thing called the Data Concentrator, which used a PDP8 (!)
and interfaced directly to a System/360-67 Multiplexor Channel. We had a lot
of fun at U Michigan hooking the thing up to a wonderful brew of hokey
terminals, which were the smallest thing just larger than a Turing Machine that
was potentially useful. While the PDP8 system was retired only a few years
ago, its successors are yet clanking away at Michigan, where that crew has
gotten rather good at making the things. My point is that maybe you should be
looking beyond IBM and, furthermore, lots of other good souls have beaten
the dumb-ASCII curse with that approach.

It was once worse. You had to end the line with <CR><LF><XOFF>.

Dave

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 04:36:19 GMT
From:      mdm@TRWRB.DSD.TRW.COM (Michael D. Marcinkevicz)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Consulting help

Folks:
	We've a wide-area network here at TRW that could really use some
consulting for DECnet and TCP/IP Ethernet.  Does anyone know of L.A.
area consulting services available?

Some vendors are quite expensive.  What price ranges you've seen?

Please mail directly to mdm@trwrb.dsd.trw.com.  I'll post responses to the net.

Thanks,

--Mike

	Michael Marcinkevicz			(213) 812-2154
	TRW Space and Defense Sector, Communications services
	trwrb!mdm@trwind.TRW.COM		(ARPA)
	...{decvax,ihnp4,ucbvax}!trwrb!mdm	(UUCP)

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Wed,  6 Apr 1988 11:48:00.68 EDT
From:      <droms%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   NFS across the Internet
Thanks to all who responded to my recent request for references to
experiences with NFS across the Internet.  I received about 5 replies,
all of which confirm Barry Shein's observation that "the concept is
not nearly so wild as [has been suggested]".

A summary of the replies is available on request.

- Ralph Droms
  Computer Science Department
  Bucknell University
  droms@bknlvms.bitnet

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 12:41:14 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Net Nums and Gateways


     <from STJOHNS>
     You are doing exactly the right thing...  42 class B addresses.

Since the idea of subnetting is to hide the distinction among the subnets from
the rest of the routers, you can use a single net which you subnet.  The
penalty you pay is to have the other routers send to an arbitrary one of your
42 gateways in order to reach a particular subnet.  This means you must be
prepared to take a packet addressed to subnet #27 in on the gateway for subnet
#33 and forward it to the proper your other gateway for subnet #33.  You may
have better (faster) connections inside your domain than on the DDN, so it may
not be too painful in user delay or DDN overload.

If the source of the packet is a host on the DDN, rather than a gateway, then
your gateway can send an ICMP redirect-host to get further packets to the
proper gateway [flames about hosts which do not listen to redirect-host go to
those hosts].

This example has come up often in the past, but usually the number of sites
has been around 2 rather than 42.  For the cases where the sites have no
separate connection, they used separate nets.  For the cases where the
sites had backdoor trunks, or a bridged ethernet, they used a single net, and
paid the extra penalty of sending traffic over their internal trunk that came
in on the 'wrong' gateway.

Mike

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Wed, 06 Apr 88  16:53:53 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  SLIP suggestion
> > >Has anyone considered making SLIP work on an IBM system?  In particular,
> > >most IBM systems will only handle 7-bit ASCII.  When I last looked at
> > >SLIP it assumed an 8-bit channel.  IBM reads must be terminated by a
> > >carriage return also.  There might also be full/half duplex
> > >compatibility problems.
>
> Likely the "near future" best way to do this is to run SLIP to a
> PC which sits on a local LAN.  (Who's using your PC when your not
> there?)
>

I have an IBM mainframe.  If I were going to provide SLIP access to
it, I think I would get something like the Cisco communications
server that supports SLIP and put it on the same Ethernet as the
mainframe.  I haven't actually done this, however.
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 14:37:51 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   SLIP suggestion


>Has anyone considered making SLIP work on an IBM system?  In particular,
>most IBM systems will only handle 7-bit ASCII.  When I last looked at
>SLIP it assumed an 8-bit channel.  IBM reads must be terminated by a
>carriage return also.  There might also be full/half duplex
>compatibility problems.
>
>Neil Erdwien
>Kansas State University

Gee, took a minute to figure out if this was referring to a PC or
what.

My guess is you're referring to a 370 architecture mainframe running a
line to a 3705 or equivalent. I've never done SLIP but I did write a
serial link of my own design once a few years ago between a 4.2 Unix
(probably 4.1 back then) system here and a 3705 which transferred jobs
for printing or batch execution.

Basically I found the only way to deal with the 3705 was to write a
layer which passed the packets as discrete ascii lines of text (I just
translated to hex ascii, prepending each line with a checksum and byte
count) and lock-stepped out the packets (send/ack/send/ack etc., just
like a card reader.)

The half-duplex nature of the interface presents some interesting
problems. Actually, it's more like quarter-duplex, it won't even
listen unless it wants to (you have to lock-step on a prompt from it,
usually a dot in column one.) If you talk before it's expecting you to
it throws away the characters and then demands a carraige return to
assure it you won't do that again (at which point you are free to
start the error cycle all over again.)

It's not ideal (hah!) but it can be done, once I got it working it
worked pretty much unnoticed, but there were a lot of heuristics in
there (did we just get a "!:" oops, it's angry! send a <CR> and back
off for a bit waiting for a "<CR><LF>.").

You also might want to see if there's a mode buried in there that was
used for downloading from a KSR33 paper tape which did flow control
(used ^S/^Q to express it's distaste for your data.)

Or get a network interface...

	-Barry Shein, Boston University

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 15:05:28 GMT
From:      hrp@windsor.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   SLIP link error correction

There was a paper in IEEE Transactions on Communications some time in
1980 (plus or minus a year) about an error detection scheme that was
almost as easy to calculate as a checksum, but at the same time was
almost as effective as CRC-16 at detecting link errors.  Sorry about
the vague citation, but the Cray library wasn't subscribing to ToC
back then, so I can't look it up.

--
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

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 15:57:00 GMT
From:      CSYSMAS@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP suggestion

> >Has anyone considered making SLIP work on an IBM system?  In particular,
> >most IBM systems will only handle 7-bit ASCII.  When I last looked at
> >SLIP it assumed an 8-bit channel.  IBM reads must be terminated by a
> >carriage return also.  There might also be full/half duplex
> >compatibility problems.

Likely the "near future" best way to do this is to run SLIP to a
PC which sits on a local LAN.  (Who's using your PC when your not
there?)

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 16:46:32 GMT
From:      eshop@saturn.ucsc.edu (Jim Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Overload Problem

You problem was described in a message from Tom Ferrin at UCSF:

+The ARP code for negotiating the use of trailers with another host
+is broken.  If the remote host cannot understand trailers, the
+algorithm can get stuck in a loop continually exchanging ARP_REPLY
+packets with the remote host.  This floods the ethernet with LOTS
+of packets for several minutes until the algorithm gives up trying.

+The scenario is as follows: 1) the local host tries to resolve a
+ethernet address that is not in it's arp table by sending out a
+ARPOP_REQUEST packet; 2) the remote host sends a ARPOP_REPLY with
+the ETHERTYPE_IP protocol field set indicating that it does
+not wish to receive trailers; 3) local host sends a ARPOP_REPLY
+announcing that it does wish to receive trailers; 4) remote host
+sends another ETHERTYPE_IP reply indicating it does not wish to
+send trailers either.  This reply is indistinguishable from #2
+above and the whole cycle repeats.

Tom goes on to describe mods to VAX unix to break the cycle.  
Revised code is now available, however, from E&S that fixes the
problem on the PS3xx end.  That is probably the preferable solution.
Contact E&S for an upgrade.

jim

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 20:17:13 GMT
From:      larry@pdn.UUCP (Larry Swift)
To:        comp.protocols.tcp-ip
Subject:   Re: The case for SLIP CRCs

Are you talking about checksums or CRC's (cyclic redundancy checks)?
They're not the same.

Larry Swift                     UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981           She's old and she's creaky, but she holds!

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 21:10:07 GMT
From:      robert@SPAM.ISTC.SRI.COM (Robert Allen)
To:        comp.protocols.tcp-ip
Subject:   TCP socket question under SunOS 3.4.



    Recently I was experimenting with client and server processes under
    SunOS 3.4, using the 4.2 BSD networking kernel, which used TCP
    sockets to carry out Inter Process Communication (IPC).  I dis-
    covered several points which I think have some relevance to this list
    so I thought I'd mention them and open the topic for discussion.

    Note: I discuss the issues below.  I've included dumps from netstat
	  below the discussion to show exactly what I saw; they are
	  labled appropriately.

    Background
    ----------
	- 1 Server process listening at a port number for connections
	  from processes attemping connections at that port.  The backlog
	  to the UNIX listen() call is 5.

	- 30 client processes attempting, somewhat sequentially, to
	  connect to the server at the agreed upon port number.

    Issues
    ------
	- Due to UNIX implementation issues, the Server can accept upto
	  26 client connections.  After that point the limit on the max.
	  number of open file descriptors per-process will be exceeded.

	- If the Server attempts to support a 27th client connection then
	  two things happen simultaneously:

		1. The Server hears the connection request, and attempts an
		   accept().  The accept() fails due to the UNIX restriction
		   on the max. number of open file descriptors per process.
		   Thus, the Server cannot accept the 27th connection.

		2. The Client makes a connect() call, and the call succeeds!
		   A netstat -a shows the TCP connection for that socket as
		   being "ESTABLISHED".  The connections in the listen()
		   backlog are all ESTABLISHED as well.  These connections
		   can be picked up by the Server routine if the Server closes
		   some of its' open file descriptors (previously accepted
		   connections) and does some more accept()s.

	- The 'netstat -a' shows that the "Recv-Q" is getting filled, but
	  since the Server process cannot accept the socket/connection, it
	  cannot read from it, and hence the system cannot free the data
	  buffered up.

    Questions
    ---------
	    Some people will probably point out that what I've discovered
	is an excellent reason to implement a session-layer protocol on top
	of the sockets between the Client and Server here.  This is the same
	conclusion I've arrived at.  However, up until now I supposed that
	the UNIX socket implementation *provided* a session layer protocol.
	While I was obviously wrong in this instance, I'm curious to know
	whether I was assigning the socket interface more significance than
	it merited (ie. it *isn't* a session layer protocol), or if this is
	a (pardon the word) 'bug' of the implementation.  I'm not trying to
	cast aspersions regarding implementation with this question!  Although
	this test was done on a Sun 3, I will soon be doing this test on a
	Hewlett-Packard 9000 series computer, and I don't know what results
	I'll get there.  If this is a bug, is it a 4.2 bug?  A 4.3 bug?  A
	Sun bug?

	    On a more direct note, what do the entries mean in the "Recv-Q"?
	Does each element therein correspond to a TCP message, or an mbuf,
	or what?  How high can the Q go (To the TCP high-water mark?)?  What
	happens when it reaches that point (does the system crash, or do the
	Clients' write() calls block?)?

	Comments/Explanations will be much appreciated,

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

/****************************************************************************/
/* In all the output below only sockets used for the Client or Server are   */
/* listed.  The listen socket at port 3030 is the Server listen socket.     */
/* The command used in all cases is "netstat -a"			    */
/****************************************************************************/

/* The following netstat was taken as the 30 Client processes were
 * attempting to connect to the server process.  Some are established
 * and some are still getting established.
 */
Active connections (including servers)
Proto Recv-Q Send-Q  Local Address      Foreign Address    (state)
tcp        0      0  milk10.3030        milk10.1643        ESTABLISHED
tcp        0      0  milk10.1643        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1642     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1641        ESTABLISHED
tcp        0      0  milk10.1641        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1640     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1639        ESTABLISHED
tcp        0      0  milk10.1639        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1638     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1637        ESTABLISHED
tcp        0      0  milk10.1637        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1636     localhost.sunrpc   TIME_WAIT
tcp        0      0  localhost.1635     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1634        ESTABLISHED
tcp        0      0  milk10.1634        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1633     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1632        ESTABLISHED
tcp        0      0  milk10.1632        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1631     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1630        ESTABLISHED
tcp        0      0  milk10.1630        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1629     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1628        ESTABLISHED
tcp        0      0  milk10.1628        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1627     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1626        ESTABLISHED
tcp        0      0  milk10.1626        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1625     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1624        ESTABLISHED
tcp        0      0  milk10.1624        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1623     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1622        ESTABLISHED
tcp        0      0  milk10.1622        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1621     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1620        ESTABLISHED
tcp        0      0  milk10.1620        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1619     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1618        ESTABLISHED
tcp        0      0  milk10.1618        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1617     localhost.sunrpc   TIME_WAIT
tcp        0      0  milk10.3030        milk10.1616        ESTABLISHED
tcp        0      0  milk10.1616        milk10.3030        ESTABLISHED
tcp        0      0  localhost.1615     localhost.sunrpc   TIME_WAIT
tcp        0      0  localhost.1614     localhost.sunrpc   TIME_WAIT
tcp        0      0  *.3030             *.*                LISTEN


/* A few seconds later.  All sockets which the Server can accept on are
 * full.  All clients' connect() calls have returned 0, which indicates
 * that they have connected.  Note that 4 connections which show "ESTABLISHED"
 * have "Recv-Q"'s of 11.  These are the Clients which think they are
 * connected to the Server based on the connect() call return of 0, but
 * which in actuality are still in the listen backlog of the Server.  Left
 * alone, the Clients will be able to send data through the socket, and will
 * get no UNIX error indications, because they are connected to the peer TCP
 * entity.
 */
Active connections (including servers)
Proto Recv-Q Send-Q  Local Address      Foreign Address    (state)
tcp        0      0  localhost.1677     localhost.sunrpc   TIME_WAIT
tcp       11      0  milk10.3030        milk10.1675        ESTABLISHED
tcp        0      0  milk10.1675        milk10.3030        ESTABLISHED
tcp       11      0  milk10.3030        milk10.1673        ESTABLISHED
tcp        0      0  milk10.1673        milk10.3030        ESTABLISHED
tcp       11      0  milk10.3030        milk10.1671        ESTABLISHED
tcp        0      0  milk10.1671        milk10.3030        ESTABLISHED
tcp       11      0  milk10.3030        milk10.1669        ESTABLISHED
tcp        0      0  milk10.1669        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1667        ESTABLISHED
tcp        0      0  milk10.1667        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1665        ESTABLISHED
tcp        0      0  milk10.1665        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1663        ESTABLISHED
tcp        0      0  milk10.1663        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1661        ESTABLISHED
tcp        0      0  milk10.1661        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1659        ESTABLISHED
tcp        0      0  milk10.1659        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1657        ESTABLISHED
tcp        0      0  milk10.1657        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1655        ESTABLISHED
tcp        0      0  milk10.1655        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1653        ESTABLISHED
tcp        0      0  milk10.1653        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1651        ESTABLISHED
tcp        0      0  milk10.1651        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1649        ESTABLISHED
tcp        0      0  milk10.1649        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1647        ESTABLISHED
tcp        0      0  milk10.1647        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1645        ESTABLISHED
tcp        0      0  milk10.1645        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1643        ESTABLISHED
tcp        0      0  milk10.1643        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1641        ESTABLISHED
tcp        0      0  milk10.1641        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1639        ESTABLISHED
tcp        0      0  milk10.1639        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1637        ESTABLISHED
tcp        0      0  milk10.1637        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1634        ESTABLISHED
tcp        0      0  milk10.1634        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1632        ESTABLISHED
tcp        0      0  milk10.1632        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1630        ESTABLISHED
tcp        0      0  milk10.1630        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1628        ESTABLISHED
tcp        0      0  milk10.1628        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1626        ESTABLISHED
tcp        0      0  milk10.1626        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1624        ESTABLISHED
tcp        0      0  milk10.1624        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1622        ESTABLISHED
tcp        0      0  milk10.1622        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1620        ESTABLISHED
tcp        0      0  milk10.1620        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1618        ESTABLISHED
tcp        0      0  milk10.1618        milk10.3030        ESTABLISHED
tcp        0      0  milk10.3030        milk10.1616        ESTABLISHED
tcp        0      0  milk10.1616        milk10.3030        ESTABLISHED
tcp        0      0  *.3030             *.*                LISTEN

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 23:16:44 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP GATEWAY for DECNET

Evening all...
		About a week ago someone sent an extensive description of
somethings they had seen relating to the DECNET - TCP/IP gateway. I don't
remember the facts but now find myself in need of this info. AS usual,
this was one of those "scan and delete" sessions that we all go through
after leaving the mailbox unchecked for 2 or 3 days. Can anyone help me
overcome my lack of foresight and send me any info you may have on this
product. I do remember something something about a module called PORTAL.
		Ring any bells???
			Many thanks in advance,
						Chris VandenBerg
						ACC
						chris@acc-sb-unix.arpa

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 88 23:58:41 GMT
From:      edward@csvaxa.UUCP (Edward Wilkinson)
To:        comp.protocols.tcp-ip
Subject:   a few questions about a NFS based network over ethernet

The following article is being posted for  our Software Manager. Sorry
about repeating this article - last time it went to comp.dcom.lans but
*nobody* replied :-( We're about to make a sizeable decision about our
LAN & we'd like to hear from people who have made similar decisions in
the past so that we can avoid any obvious problems.

                     A t D h V a A n N k C s E

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

What  is  an acceptable load   on an  802.3 network? We  are intending
putting approx. 300 PCs running Sun's PC-NFS on a single net, with the
intention of expanding to 1200 within 5 years. Will  a single trunk be
capable  of supporting that  number of work stations or  should  we be
looking at putting  in several parallel cables? If  so how many?   How
much  horse power would  be reasonable to   support the number of  PCs
being proposed?  i.e. what  size machine  should   we have for   a NFS
server?

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

All   replies to   him please, or  to this   newsgroup if  the info is
generally useful.


--
Ed Wilkinson @ Computer Centre, Massey University, Palmerston North, NZ
uucp: {uunet,watmath!cantuar}!vuwcomp!csvaxa!edward   DTE: 530163000005
Janet/Greybook: E.Wilkinson@nz.ac.massey      Phone: +64 63 69099 x8587
CSnet/ACSnet/Internet: E.Wilkinson@massey.ac.nz    New Zealand = GMT+12

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Apr 88 08:05 5
From:      "I am only and egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   subnet probems fixed
     Hello.

     Back in late December and early January I asked for help with our
network at Northeastern University.  Many replies were received all of 
which helped.

     Thank you all.  I'm sorry it took so long to get back to say that.  
The help was much appreciated.  

     A good deal of our problem seems to have been Sun OS 3.4.  The 3.5 
release works a LOT better with subnets than 3.4 did.  I only recently 
discovered that there were a number a patches for 3.4 dealing with 
subnets.  The most successful of these were put into 3.5 as I understand 
it.  When we finally received 3.5 and went to it, things started working
much better. 

     It was mostly a less than ideal TCP/IP implementation that seems to
have done us in. 

     Again, thank you all.

Chris Johnson
Northeastern University.
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 03:13:45 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP socket question under SunOS 3.4.

If the server attempts an accept() call which returns with
an EMFILE (`too many open files') error, the pending connection
should NOT be established.  I.e., that it is is a bug.

4.3BSD does not have this bug (see /sys/sys/uipc_syscalls.c$accept(),
around line 137).

Chris

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 04:36:55 GMT
From:      Ariel@en-c06.Prime.COM
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums (was Re: Ping, checksum algorithm?)

Forwarded article follows:

----------------------------------------------------------------
Hi,

I noted your article about the TCP and IP checksum algorithm
on Usenet. Feel free to post this if you feel it is of interest;
I only have CSnet/ARPAnet access.

The algorithm used by Prime's TCP/IP/X.25 software is very
similar to your "psuedo-code". Note that it is not necessary
to add the carries back in until the end. (Prime 50-series
machines have network byte order)

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

int checksumIP(ip)
IP_header *ip;
{
uns16 *word;
uns32 sum;
int count;

ip->IP_checksum = 0;
count = ip->IP_IHL * 2;
sum = 0;
word = (uns16 *)ip;

/* magic occurs ... */

while (count--) sum += *word++;
while (sum > 0xFFFF) sum = (sum & 0xFFFF) + (sum >> 16L);
sum = (~sum & 0xFFFF);

ip->IP_checksum = sum;

return;
}

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

Note that most of the work is in the single instruction while
loop, with a non-complex termination test. The second while
loop is executed at most twice.

A 9955 or 6350 running this in CIX mode blows the doors off of
any poor controller micro-processor.

Robert Ullmann
Prime.COM zone/domain adminitrator
Ariel@en-c06.Prime.COM

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 1988 14:44-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        jbvb@VAX.FTP.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: MIL-STD vs. RFC
I  tell  you three times: "where the MIL-STDS and RFC's disagree,
the RFCs are correct".

The point  of  contact  for  standards  matters  is  Kevin  Ebel,
Ebel@DCA-EMS.ARPA, tell him I sent you *grin*.

Seriously  though - officially, the MIL-STDs superceded the RFCs,
however we (DCA and DCEC) are aware that the MIL-STDs  have  some
problems.  (Like IP not being able to deliver data to its ULP, or
was it TCP?  *grin*).  Our guidance has been to take the  average
of the RFCs and the MIL-STDs...  sort of...

Mike

(Umm,  if  you  get  guidance that is different than the above, I
would appreciate hearing details on who said it so I  can  either
get them or me straightened out.  )

I guess I ought to make it official:

Mike  StJohns,  Capt,  USAF,  DDN  Program, Defense Communication
Agency
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Apr 88 11:52:35 EDT
From:      Dick Cogger <RHX@CORNELLC.CCS.CORNELL.EDU>
To:        TCP/IP List <tcp-ip@sri-nic.arpa>
Subject:   Cornell Mac/PC IP University Release

All Interested Parties:
    (Please forgive posting to multiple lists, due to
       overlapping subject matter)

Cornell University MacIP and PC/IP are now available to colleges and
Universities, essentially free.

Cornell's versions of Mac and PC programs implement telnet, tn3270,
and serial port terminal emulators compatible with the TCP/IP
applicaitons.  A ping application is also available.  These programs
are derived from the MIT PC/IP, and the Mac's Appletalk drivers were
developed at Stanford.  Major features are as follows:

1.  Both tn and tn3270 are quite fast.  With tn3270, full screens are
displayed in less than a second, counting host time to generate the
screen.  Times approximately as follows:  PC/XT 1 sec, MacPlus, .6
SEC, PC/AT OR MACII .45 SEC.

2.  User key-mapping is supported.  On the Mac, a simple macro
facility provides the mapping.  (The PC will have the equivalent
soon.)

3.  A very easy-to-use file transfer is built into the tn3270.  A
simple host command (e.g. "download foo memo") effects the
transfer.  Speed is about 3Kbytes/sec.

4.  Serial port versions of the terminal programs present a near-
identical user interface, including the same key mapping, same
visual appearance.  If calling an IBM host via 7171, the file transfer
works trasparently with error checking, albeit more slowly.  In fact,
the same CMS module is used whether operating on TCP/IP or by
async connection-- therefore, upload/download commands may be
imbedded in exec's to operate either way.

5.  The Mac versions support Appletalk and Omninet (Ethertalk soon),
the PC versions support Appletalk (TOPS Flashtalk card), Omninet,
Ethernet (3C501), Pronet-10, and a Netbios 5C interface.  This latter
is IP over Netbios, not to be confused with the reverse, and permits
the use of various networks for telnet while running local file-
service, such as Novell.

6.  With Appletalk, the Mac and PC can be used with the Kinetics
fastpath.  The PC will operate normally on an ethernet or Pronet.
Omninet and the Netbios interface require a matching router which
we have at Cornell but is not generally available (see below).

We've been running the Omninet versions for over 18 months at
Cornell, and the Appletalk versions for several months.  I'd estimate
that over 100 people use them daily and the number is growing.
However, they havn't been tested much outside Cornell, and most of
the use at Cornell is over low-latency local nets.

At least for now, we will be licensing these programs to colleges
and universities only, with a simple license that basically has the
licensee agreeing not to redistribute or hold Cornell responsible for
any problems.  For now, we won't be sending out source, but
eventually we will on some basis.  For non-university folks, we hope
to find a commercial vendor who will release (sell) and support the
programs, but we havn't been able to conclude such an arrangement.
If we don't soon, we'll probably put it all in the public domain.

If you want to license these programs, send me electronic mail and
I'll send you a copy of the agreement to sign and return.  SPECIAL:
The first 25 requests I get, we'll provide the disks and postage to
send it to you. (You'll know if you're in the 25 when you get the
license form.)  After that, there will be a distribution fee of $25.00.

Regarding the IP Router (Gateway):  We use a PC/AT clone,
configured with one backbone interface and up to four local net
interfaces.  Usually, the backbone is Pronet, but it could be ethernet.
The local nets are Omninet or Appletalk, or some of both.  We have
about 10 gateways in service in this configuration, and expect
several more soon.  With these Omninet/Appletalk units, we locate
the router in a locked room at one of eight locations served by our
backbone Pronet.  From there, we run a telephone type twisted pair
(part of our System 85 wireplant) to the building of interest where
we install a star hub at the BDF (Building Distribution Frame).
Additional telephone pairs go from the hub to outlets in offices.
Also for local nets we can support ethernet or pronet or the Netbios
interface.  We've tested the Netbios interface with Starlan and IBM
TokenRing, so far; it should work with lots of other nets.  For this
type of local net, we're thinking of using an Omninet (1 Mbit) to
connect a port on a backbone gateway to a "satelite gateway"
connected on the local ethernet or Netbios net.

The gateways are assembled without disks, keyboards, or monitors.
They boot over the backbone and download configuration.  The boot
server is a PC running a simple net monitor that pings listed IP
addresses and displays responding status while answering boot
requests in the background.  Even stuffed full of cards, the gateway
boxes usually cost under $2000 for the hardware.  Performance
seems to be excellent, although we have not done extensive testing.
In one test we did do, an appletalk wire was saturated at 75
packets/sec (plus another 150/sec on the wire for ALAP RTS/CTS
packets), about 180 Kbits/sec, all of the packets coming/going to a
Pronet using 23% of the AT's CPU.

Right now, we're adding Appletalk protocol-forwarding with IP
tunnel-routing (like the KIP code for the Kinetics box).

We're working on arranging for the AT-based gateway to be made
available, but because of licensing issues, it seems to be taking a
long time.  Let me know if you would be interested.

-Dick Cogger, Cornell University
Internet:  RHX@CornellC.ccs.cornell.edu
Bitnet:     RHX@CornellC
607-255-7566
U.S.Mail:   Richard Cogger, Cornell University, 192 Caldwell Hall,
                   Ithaca, NY 14853
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Apr 88 11:55:17 EDT
From:      Dick Cogger <RHX@CORNELLC.CCS.CORNELL.EDU>
To:        TCP/IP List <tcp-ip@sri-nic.arpa>
Subject:   Checksum in FEP


    Probably, the following suggestion has been discussed in the past,
but I haven't seen a reference:  Why not offload JUST the IP and TCP
checksumming to a Front End Processor (or controller board)?
   Doing so would require code operating at a lower layer to "peek" at
fields deeper in the packet, and protocol layer-bigots may object, but
it should work.
   For incoming packets, if the lap-type is IP (or the SNAP, etc.) then
checksum the header-- if bad drop the packet.  If the IP-type is TCP,
checksum the packet; if bad drop it.  In general, this is what the
higher layer in the host is going to do anyway.  If you trust the
channel or dualported memory used to get the packet from the controller
board, you could then rely on getting only good (in terms of checksums)
packets.
    For outgoing packets, the controller could make the same sort of
tests and calculate and fill in checksums only if the host had left them
as zero.
    In both cases, the host code could (re)do the checksumming if it
wanted to.  In any case, the programming interface to the host would
not be complicated (tcp, udp socket clients; multiple boards, etc.), but
a major source of host overhead would be offloaded.  Of course, the
fast host processor might still be able to execute the checksum faster
than a slow controller board.

Dick Cogger
RHX@CornellC.ccs.cornell.edu
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Thu,  7 Apr 1988 13:42:47.85 EDT
From:      <droms%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   Summary of responses to "NFS over the Internet"

I received enough requests for a summary of repsonses to my earlier
posting to warrant posting the summary to the net.  As Barry Shein
suggests, "the concept is not nearly as wild as [it might seem]".

- Ralph Droms
  Computer Science Department
  Bucknell University
  droms@bknlvms.bitnet

-----
From:   edu%"bhoward@sol.engin.umich.edu" 31-MAR-1988 13:46

at one point, i mounted hoser.berkeley.edu:/usr/src or /usr/src/X
(not certain anymore which) from sol.engin.umich.edu  this was last
summer and throughput was low, but it worked.  i don't recall doing
anything special, simply did a mount hoser:directory /n/hoser/directory

            bruce
-----
From:   EDU%"bzs%bu-cs.bu.edu@buita.BU.EDU"  1-APR-1988 04:48

As far as NFS over a serial line I tried it one evening over our 9.6Kb
Cypress line between BU and UCB. It really wasn't bad, NFS is not a
particularly high overhead protocol, the info being exchanged is
fairly similar to what gets exchanged in an FTP session (DIR,GET,PUT
etc.) Of course this disregards transmission problems which I didn't
seem to have that evening, the question was thruput.

It's probably an intuitive confusion that because NFS is so useful and
neat that it must therefore demand massive bandwidth (or perhaps
people are mixing the thought with ND, the diskless protocol?)

Doubtless you'd want your binaries local but as a very easy to use
"ftp" (eg. snooping around directories, copying stuff, file
management) it's really not bad on a relatively slow line in my
experience, perhaps a little slower than FTP but being able to use the
native OS interface to the remote file system can make it worthwhile.

Note that there are various timeout parameters etc that would need to
be tuned (can be set on a per mount basis) for smooth performance, but
the concept is not nearly as wild as seems to be presented here.

    -Barry Shein, Boston University
-----
From:   EDU%"pdb@SEI.CMU.EDU"  1-APR-1988 12:29

I've done it.  (I only lose on one qualification - I had it running between
two LANs, and the traffic had to cross the ARPANET to get between them.
But I administer both those LANs.)

--Pat.
-----
From:   edu%"hedrick@aramis.rutgers.edu"  1-APR-1988 17:19

We run NFS between departments all the time.  In different buildings
through 2 gateways.  We also know people who have mounted our disks
across the Arpanet, but this was done just as a hack, for a few
minutes.  Note that when we do it between our departments, we require
that all the departments involved coordinate their uid allocation,
since otherwise there are security problems.
-----
From:   NET%"roy%phri@uunet.UU.NET"  2-APR-1988 11:56

    I remember reading a while ago that Rob Liebschutz (liebschutz@ig.com
and/or liebschutz@bionet-20.arpa) and Mel Pleasant (pleasant@rutgers.edu) had
tried remote mounting an NFS file system at Intelligenetics in California from
Rutgers in New Jersey over the Internet.  Supposedly they had no problems.
You might try asking Rob or Mel for more details.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
-----
From:   EDU%"sy.Ken@CU20B.COLUMBIA.EDU" 30-MAR-1988 11:38

We use NFS disk mounts between here and another machine (the exact
whereabouts I can't tell you, but it's not on this campus), separated
by a T1 circuit.  Seems to work quite well, although is, of course,
a bit slower than you would get off the direct ether.

As for disjoint administrations, we are Columbia University, and the
disks we mount belong to the NYSER Network Information machine.

/Ken
-------
From:   EDU%"sy.Ken@CU20B.COLUMBIA.EDU" 30-MAR-1988 16:32

OK, well, that's not us, I guess...  however, the technical (mechanical)
aspects of such a hookup work well.  The NYSER disks look like real local
disks to us, and even with the distance separating us, we get pretty
decent response time.  Can't say anything about administrative aspects
concerning common roots and all that, though... /Ken
-------
From:   GOV%"cpw%sneezy@LANL.GOV" 30-MAR-1988 19:57

As a lark, I mounted an NFS filesystem in La Jolla, CA.  The linkage was:

[Client]-ethernet (Los Alamos, NM)
       |
    IP router -- ethernet
            |
             IP router -- 19.2 serial line -- IP router
                              |
                              ethernet - [File Server]
                                (La Jolla, CA)

By the way, one could consider this a security breach.  In fact one did,
after I told them about it.  This is a pet gripe of mine:  Sun ships their
systems WIDE OPEN, and its up to the user to shut them down.  I think it
should be the other way around.

wood, cornett philip  (cpw@lanl.gov)
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 14:21:04 GMT
From:      mfidelma@bbn.com (Miles Fidelman)
To:        comp.protocols.tcp-ip
Subject:   Re: Becoming part of the Internet

You could always join CSNet. Try contacting the CSNet information center
at BBN Labs in Cambridge, MA.  Their phone number is 617-873-2777 and 
their email address is cic@sh.cs.net  I'll send you a little more info by
mail.

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 15:08:35 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  release of updated network sources for 4.3BSD

For those of you with VAX's that are planning on incorporating the Berkeley
fixes, the following patch should be applied to ip_output.c.  It's the
old byte order problem coming back to haunt us...

Index:	/sys/netinet/ip_output.c 4.3 (with new inet code)
Submitted by: C. Philip Wood

Description:
	Ip_output, when called upon to fragment, sends the incorrect
	length and fragment flag in the first packet.
Repeat-By:
	Use minor internet discard protocol with udp and a packet length > the
	mtu of the network you are netting on, and monitor the network with a
	suitable tool.

		% discard -t datagram -l 1700 -p 1 doc
	
	Or, ship it through a vanilla IP gateway that keeps track of
	data length and header header length errors for IP.  Take a snap
	before and after you send the fragmented packet and watch the
	count of bad packets. 
	
		% netstat -s | grep "with data length"
		265 with data length < header length
		% netstat -s | grep "with data length"
		266 with data length < header length
	
Fix:
*** ip_output.c Wed Apr  6 11:52:50 1988
--- ip_output.c.orig    Tue Mar 15 22:12:40 1988
***************
*** 10,14 ****
   * is provided ``as is'' without express or implied warranty.
   *
!  *    @(#)ip_output.c 7.9 (LANL) 3/15/88
   */
  
--- 10,14 ----
   * is provided ``as is'' without express or implied warranty.
   *
!  *    @(#)ip_output.c 7.9 (Berkeley) 3/15/88
   */
  
***************
*** 233,238 ****
	 */
	m_adj(m0, hlen + firstlen - ip->ip_len);
!       ip->ip_len = htons((u_short)(hlen + firstlen));
!       ip->ip_off = htons((u_short)(ip->ip_off | IP_MF));
	ip->ip_sum = 0;
	ip->ip_sum = in_cksum(m0, hlen);
--- 233,238 ----
	 */
	m_adj(m0, hlen + firstlen - ip->ip_len);
!       ip->ip_len = hlen + firstlen;
!       ip->ip_off |= IP_MF;
	ip->ip_sum = 0;
	ip->ip_sum = in_cksum(m0, hlen); 

       

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 15:36:42 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   KA9Q TCP/IP commercially available

Sirius Systems has the KA9Q "Net" code available for commercial and
government purposes.  We include our enhancements, bug fixes, and
additional drivers (our Ethernet driver is much faster and supports
additional interface cards).  We do track Phil's work and add his
improvements but ours is a more robust product when we are through with
it. 

In addition to the product we provide support and training.  We can help
someone who is interested in porting the code to other processors.  If
anyone is interested please contact us for further information.

Brian Lloyd, President
Sirius Systems, Inc.
19200 Tilford Way, Germantown, MD 20874 
(301) 540-2066
brian@wb6rqn.uucp
Share and enjoy!

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 15:52:35 GMT
From:      RHX@CORNELLC.CCS.CORNELL.EDU (Dick Cogger)
To:        comp.protocols.tcp-ip
Subject:   Cornell Mac/PC IP University Release


All Interested Parties:
    (Please forgive posting to multiple lists, due to
       overlapping subject matter)

Cornell University MacIP and PC/IP are now available to colleges and
Universities, essentially free.

Cornell's versions of Mac and PC programs implement telnet, tn3270,
and serial port terminal emulators compatible with the TCP/IP
applicaitons.  A ping application is also available.  These programs
are derived from the MIT PC/IP, and the Mac's Appletalk drivers were
developed at Stanford.  Major features are as follows:

1.  Both tn and tn3270 are quite fast.  With tn3270, full screens are
displayed in less than a second, counting host time to generate the
screen.  Times approximately as follows:  PC/XT 1 sec, MacPlus, .6
SEC, PC/AT OR MACII .45 SEC.

2.  User key-mapping is supported.  On the Mac, a simple macro
facility provides the mapping.  (The PC will have the equivalent
soon.)

3.  A very easy-to-use file transfer is built into the tn3270.  A
simple host command (e.g. "download foo memo") effects the
transfer.  Speed is about 3Kbytes/sec.

4.  Serial port versions of the terminal programs present a near-
identical user interface, including the same key mapping, same
visual appearance.  If calling an IBM host via 7171, the file transfer
works trasparently with error checking, albeit more slowly.  In fact,
the same CMS module is used whether operating on TCP/IP or by
async connection-- therefore, upload/download commands may be
imbedded in exec's to operate either way.

5.  The Mac versions support Appletalk and Omninet (Ethertalk soon),
the PC versions support Appletalk (TOPS Flashtalk card), Omninet,
Ethernet (3C501), Pronet-10, and a Netbios 5C interface.  This latter
is IP over Netbios, not to be confused with the reverse, and permits
the use of various networks for telnet while running local file-
service, such as Novell.

6.  With Appletalk, the Mac and PC can be used with the Kinetics
fastpath.  The PC will operate normally on an ethernet or Pronet.
Omninet and the Netbios interface require a matching router which
we have at Cornell but is not generally available (see below).

We've been running the Omninet versions for over 18 months at
Cornell, and the Appletalk versions for several months.  I'd estimate
that over 100 people use them daily and the number is growing.
However, they havn't been tested much outside Cornell, and most of
the use at Cornell is over low-latency local nets.

At least for now, we will be licensing these programs to colleges
and universities only, with a simple license that basically has the
licensee agreeing not to redistribute or hold Cornell responsible for
any problems.  For now, we won't be sending out source, but
eventually we will on some basis.  For non-university folks, we hope
to find a commercial vendor who will release (sell) and support the
programs, but we havn't been able to conclude such an arrangement.
If we don't soon, we'll probably put it all in the public domain.

If you want to license these programs, send me electronic mail and
I'll send you a copy of the agreement to sign and return.  SPECIAL:
The first 25 requests I get, we'll provide the disks and postage to
send it to you. (You'll know if you're in the 25 when you get the
license form.)  After that, there will be a distribution fee of $25.00.

Regarding the IP Router (Gateway):  We use a PC/AT clone,
configured with one backbone interface and up to four local net
interfaces.  Usually, the backbone is Pronet, but it could be ethernet.
The local nets are Omninet or Appletalk, or some of both.  We have
about 10 gateways in service in this configuration, and expect
several more soon.  With these Omninet/Appletalk units, we locate
the router in a locked room at one of eight locations served by our
backbone Pronet.  From there, we run a telephone type twisted pair
(part of our System 85 wireplant) to the building of interest where
we install a star hub at the BDF (Building Distribution Frame).
Additional telephone pairs go from the hub to outlets in offices.
Also for local nets we can support ethernet or pronet or the Netbios
interface.  We've tested the Netbios interface with Starlan and IBM
TokenRing, so far; it should work with lots of other nets.  For this
type of local net, we're thinking of using an Omninet (1 Mbit) to
connect a port on a backbone gateway to a "satelite gateway"
connected on the local ethernet or Netbios net.

The gateways are assembled without disks, keyboards, or monitors.
They boot over the backbone and download configuration.  The boot
server is a PC running a simple net monitor that pings listed IP
addresses and displays responding status while answering boot
requests in the background.  Even stuffed full of cards, the gateway
boxes usually cost under $2000 for the hardware.  Performance
seems to be excellent, although we have not done extensive testing.
In one test we did do, an appletalk wire was saturated at 75
packets/sec (plus another 150/sec on the wire for ALAP RTS/CTS
packets), about 180 Kbits/sec, all of the packets coming/going to a
Pronet using 23% of the AT's CPU.

Right now, we're adding Appletalk protocol-forwarding with IP
tunnel-routing (like the KIP code for the Kinetics box).

We're working on arranging for the AT-based gateway to be made
available, but because of licensing issues, it seems to be taking a
long time.  Let me know if you would be interested.

-Dick Cogger, Cornell University
Internet:  RHX@CornellC.ccs.cornell.edu
Bitnet:     RHX@CornellC
607-255-7566
U.S.Mail:   Richard Cogger, Cornell University, 192 Caldwell Hall,
                   Ithaca, NY 14853

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 15:55:17 GMT
From:      RHX@CORNELLC.CCS.CORNELL.EDU (Dick Cogger)
To:        comp.protocols.tcp-ip
Subject:   Checksum in FEP



    Probably, the following suggestion has been discussed in the past,
but I haven't seen a reference:  Why not offload JUST the IP and TCP
checksumming to a Front End Processor (or controller board)?
   Doing so would require code operating at a lower layer to "peek" at
fields deeper in the packet, and protocol layer-bigots may object, but
it should work.
   For incoming packets, if the lap-type is IP (or the SNAP, etc.) then
checksum the header-- if bad drop the packet.  If the IP-type is TCP,
checksum the packet; if bad drop it.  In general, this is what the
higher layer in the host is going to do anyway.  If you trust the
channel or dualported memory used to get the packet from the controller
board, you could then rely on getting only good (in terms of checksums)
packets.
    For outgoing packets, the controller could make the same sort of
tests and calculate and fill in checksums only if the host had left them
as zero.
    In both cases, the host code could (re)do the checksumming if it
wanted to.  In any case, the programming interface to the host would
not be complicated (tcp, udp socket clients; multiple boards, etc.), but
a major source of host overhead would be offloaded.  Of course, the
fast host processor might still be able to execute the checksum faster
than a slow controller board.

Dick Cogger
RHX@CornellC.ccs.cornell.edu

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 17:35:29 GMT
From:      droms@BKNLVMS.BITNET
To:        comp.protocols.tcp-ip
Subject:   NFS across the Internet


Thanks to all who responded to my recent request for references to
experiences with NFS across the Internet.  I received about 5 replies,
all of which confirm Barry Shein's observation that "the concept is
not nearly so wild as [has been suggested]".

A summary of the replies is available on request.

- Ralph Droms
  Computer Science Department
  Bucknell University
  droms@bknlvms.bitnet

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 19:31:00 GMT
From:      zweig@uiucdcsp.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet source


	Oops! Sorry folks. The NCSA Telnet code is available via
anonymous FTP from:

		ftp.ncsa.uiuc.edu

not from ncsa.uiuc.edu which (as any fool can see) is something else.
	My apologies for the inconvenience.

Johnny Z
Univ. of Ill. at Urbana Champaign
Dept. of Computer Science

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 19:37:26 GMT
From:      n2dsy@hou2d.UUCP (G.BEATTIE)
To:        comp.protocols.iso,comp.protocols.tcp-ip,rec.ham-radio.packet
Subject:   Asynchronous Framing Technique Document File: AFT.DOC


Here is the document file that I promised last week describing
the Asynchonous Framing Technique (AFT).  This is only a
framing protocol.  It contains NO state machine, transparency
and error control. 

Four files will follow this message(but only in comp.protocols.tcp-ip):
 
1. AFT.C - a machine independent implementation of the AFT software.
2. ASYNC.ASM - an MS-DOS device driver to use with AFT.
3. TEST1.C - a test and demo programme for the AFT software.
4. Test2.C - another test and demo programme for the AFT software.

The file contained in this message is AFT.DOC.

If you like what you see here in the document file, go to the
newsgroup "comp.protocols.tcp-ip" and pull the other four files.









            Machine Independent Asynchronous Framing Technique (AFT)

            Version 1.0, by John Howell (N2FVN), August 7, 1987

            This software is in the public domain.  It is provided on an
            'as is' basis without warranty.

            This is a portable implementation of the Asynchronous
            Framing Technique for X.25 (X.25/AFT) Revision 2 coded in
            the C language.  AFT is a protocol which allows X.25 style
            framing to be done over an asynchronous communication
            channel.  It allows for detection of the start and end of
            frames, detection of corrupted transmission, and sending of
            frames containing eight bit characters over communication
            links which cannot accept all possible characters.

            AFT is intended to be used as a replacement for the X.25
            level two framing technique in cases where synchronous
            communication is not practical.

            For more information on X.25/AFT contact:

                 Research Department
                 Hayes Microcomputer Products, Inc.
                 705 Westech Drive
                 Norcross, Georgia   30092

            This implementation of AFT supports all features of revision
            two of the protocol.  A method is provided to select which
            of the possible options are to be used.  The implementation
            has three components:

                 1) Option Selection
                 2) Frame Transmission
                 3) Frame Reception

            The interface to the user of AFT was chosen to allow use of
            the software in many different environments.  As provided
            this software requires additional machine dependant software
            to provide a full AFT implementation.  The transmit and
            receive routines have been implemented in such a way that
            they may be called either within interrupt service routines
            as characters are sent and received or they may be called
            from non-interrupt routines which fill or empty queues used
            by the software doing the hardware dependant portion of the
            I/O.

            This implementation provides no actual routines to do I/O
            since this is highly machine dependant.

            In this program the terms bytes and characters are used as
            synonyms for eight bit groups of data which are known as
            octets in X.25.  This program assumes that the
            implementation of type 'char' is an eight bit value.  Also











            the type 'int' is assumed to be at least 16 bits in size.

            An attempt has been made to only use those features of C
            which are common to nearly all implementations.  This code
            was actually tested using Microsoft C version 4.0.

            Some abbreviations used in this program are:
            
                 FCS  Frame Check Sequence
                 LEN  Length
                 OPT  Option
                 RX   Receive
                 SUB  Substituted
                 TX   Transmit
            

            

            

            Interface to External Routines

            The following routines make up the interface to the AFT
            implementation.  It is assumed that the user is familiar
            with the C language.

            

            aft_options(ebdt, transparency_level, suffix_len,
                        suffix, max_rx_len)

            This routine selects the options to be used for AFT
            communication.  It must be called at least once before any
            other AFT routines are used.  It may be called again later
            to change the previously selected options.  This should only
            be done at a time when no frames are being sent or received.

            'ebdt' is a flag (0=false, non-zero=true) which determines
            whether the eight-bit data transparency option is to be used
            on transmit and receive.  The EBDT option should only be
            used in cases where the communication path does not transfer
            the high order bit of characters transparently.  This option
            must be selected identically on both the sending and
            receiving sides of the link.  Use of this feature adds an
            extra 14% overhead to the communications.

            'transparency_level' takes on one of three values. Zero
            indicates that basic transparency is to be used.  This
            should be selected when the communication path allows
            transparent transmission of all 256 possible characters. One
            indicates that flow control transparency is to be used.
            This should be selected when the transmission of X-on and X-
            off characters would cause the receiver to perform flow
            control which would prevent them from appearing within
            frames.  Two indicates that control-character transparency











            is to be used. This should be selected when the transmission
            path does not allow transparent transmission of some control
            characters.  Each higher numbered option adds more overhead
            to transmitted frames.

            'suffix_len' is the length of a string which will be
            appended to each frame when it is sent.  This feature is
            used to provide any extra characters which the receiving
            system may require to recognize the end of an input.  Zero
            should be used when no frame suffix is to be added which is
            the most common case.  The maximum suffix allowed is three
            characters.

            'suffix' is a pointer to the actual character string in
            which the suffix is stored.  This is only examined if the
            suffix length is non-zero.  This string may contain up to
            three characters which may each be any value.

            'max_rx_len' is the size of the buffer which will be used
            for receiving frames.  This length is used by the receive
            frame routines to prevent storing data past the end of the
            buffer.  Received frames which are too long will be
            discarded.  The receive buffer provided must be at least two
            characters larger than the maximum expected frame size.
            This is required since buffer is used for temporary storage
            of the two character frame check sequence.

            

            int aft_tx_start(length, buffer)

            This is the routine used to do the setup for transmitting a
            frame.  This routine returns a value of zero if a new frame
            cannot be started because a frame is already being sent, or
            a value of one if the request is accepted.  In either case
            this routine returns immediately.  The actual sending of the
            frame is done by aft_tx_char.

            'length' is the length of the frame to be sent.  The minimum
            valid frame length is two characters.  The maximum is
            limited only by the restrictions of the C compiler used.

            'buffer' is a pointer to the buffer holding the frame to be
            sent.  This buffer should contain only the address, control,
            and information fields for the frame.  The AFT routines will
            generate starting and closing flags, frame check sequence,
            and other characters required for transparency when the
            frame is sent.  AFT will not modify the contents of the
            buffer.  The buffer contents should not be modified by any
            other routines until transmission of the frame is completed
            or an incorrect frame may be sent.

            

            int aft_tx_char()











            This routine is used to obtain the next character to be sent
            in order to transmit a frame.  It returns characters to be
            sent as a value from zero to 255 in the low order byte of
            the returned integer and zero in the high order byte of the
            integer.  Once the final character of the frame has been
            sent the return value will be one in the high order byte and
            a flag character in the low order byte.

            This routine is designed to be either used as a non-
            interrupt routine to which is called in a loop to fill an
            outgoing buffer which will be sent by other software or
            called within an interrupt routine when a transmitter buffer
            empty condition occurs to provide the next character to be
            sent.  When used in an interrupt routine the caller may
            ignore the upper byte of the return value.  If this is done
            then the result will be to send continuous flags between
            frames.

            

            aft_tx_abort()

            This routine may be called to cause aft_send_char to abort
            the frame it is currently sending.  A lead-in character is
            sent followed by a flag to indicate that the receiver should
            ignore the frame.  It a frame is not being sent then no
            action is taken.

            

            int aft_tx_complete()

            This routine is intended to be used in cases where
            aft_tx_char is being called during interrupt service.  It
            provides a way for non-interrupt routines to poll for frame
            sending completion. It returns zero if a frame is currently
            being sent or one if no frame is being sent.  A frame is
            considered to be sent once aft_tx_char is about to return
            the frame complete code (0x017E) to its caller.  Instead of
            using this routine aft_tx_char may be easily modified to
            take any desired action when sending of a frame is
            completed.

            

            int aft_rx_start(buffer)

            This routine provides a buffer for the AFT software to use
            to receive a frame into.  This routine returns a value of
            zero if the buffer is not accepted because a receive
            operation is already in progress or a value of one if the
            buffer is accepted.  In either case this routine returns
            immediately to its caller.

            'buffer' is a pointer to the buffer into which the frame











            will be received.  This buffer will be filled one character
            at a time by aft_rx_char as characters for the frame are
            received.  Once the receive operation is completed this
            buffer will hold the received frame address, control, and
            information fields.  All flags, FCS, and extra transparency
            characters will have been removed.

            

            int aft_rx_char(c)

            This routine accepts a received character and adds it to the
            frame being received.  If aft_rx_start has not been called
            to provide a buffer for receive then the first few
            characters of the frame will be saved in a temporary buffer.
            This will prevent loss of data in cases where aft_rx_char is
            being called directly by the receive interrupt service
            routine.  This routine can also be called by a non-interrupt
            routine which obtains the characters from a received
            character queue.  A value of zero is returned if this
            character does not complete a frame.  A non-zero return
            value indicates that the character provided completed the
            received frame.  In this case the value returned is the
            length of the frame which is contained in the receive
            buffer.

            If an invalid FCS is received at the end of the frame then
            the frame will be discarded.  A frame of less than two bytes
            will also be discarded.

            'c' is the next character received from the communication
            port.

            

            aft_rx_error()

            This routine is called to indicate the occurrence of an
            error condition on the communication line.  Possible
            conditions may be framing error, break received, parity
            error (if in EBDT mode), time out (which is not required for
            AFT), or overrun.  When this routine is called AFT discards
            the frame currently being received and begins searching for
            the start of the next frame.

            int aft_rx_complete()

            This routine is used in cases where aft_rx_char is being
            called during interrupt service.  It provides a way for non-
            interrupt routines to poll for completion of a receive
            operation.  It returns zero if the receive operation has not
            completed and the received frame length if it has.  After
            this routine returns that a frame has completed then
            aft_rx_start should be called as quickly as possible to
            provide a new receive buffer.  If this is not done in time











            then the next incoming frame may be lost.  Instead of using
            this routine aft_rx_char may be easily modified to take any
            desired action when sending of a frame is completed.

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 19:39:41 GMT
From:      n2dsy@hou2d.UUCP (G.BEATTIE)
To:        comp.protocols.tcp-ip
Subject:   Asynchronous Framing Technique Software: AFT.C


/*
	Machine Independent Asynchronous Framing Technique (AFT)


            Version 1.0, by John Howell (N2FVN), Copyright August 7, 1987
               
            This software is free for non-commercial use.  All commercial
            rights are retained by the author or his designees.  Commercial 
            use without the explicit written permission of the author is
            prohibited.  This package is provided on an 'as is' basis 
            without warranty.
	

*/

		/* Macros */

#define	FLAG		0x007E
/* 
	This is the flag character which is used to start and end
	frames.  The send generates separate starting and ending flag
	characters, but the receiver can accept a single flag to end one
	frame and start another.
*/


#define	LEAD_IN		0x007D
/*
	This is the lead in character which is used when transparency is
	required.  When the receiver detects this character it takes the
	following character and exclusive ors it with 0x20 to produce
	the proper character.  This is used to allow the transmission of
	characters which would not otherwise be received properly.
*/


#define	TRANSPARENT(c)	(c ^ 0x20)
/*
	This is the function to be performed to convert a character into
	one which may be transmitted transparently.  This is also used
	to return a character to its original value since the function
	is its own inverse.
*/


#define	IDLE_CODE	(0x0100 + FLAG)
/*
	This is the idle code with is returned by aft_tx_char when it
	has no frame to send.  The high order byte indicates completion
	and the low order byte is a flag which might be sent if flags
	are to be used between frames as filler.
*/


#define	GENERATOR	0x8408
/*
	This is the generator polynomial for the frame check sequence.
	The polynomial is the standard CCITT polynomial.  It is in
	reverse bit order for faster calculation.  The polynomial is
	X**16 + X**12 + X**5 + 1.
*/


#define	EXPECT_FCS	0xF0B8
/*
	This is the expected final FCS for a correctly received frame.
*/


#define	OK		1
/*
	This is the return code used by some routines to indicate
	successful completion.
*/


#define	NO_GOOD		0
/*
	This is the return code used by some routines to indicate
	unsuccessful completion.
*/



/* Global declarations */


static char opt_ebdt;
/*
	This is a flag controlling the use of eight-bit data
	transparency on transmitted and receive frames.
*/


static char opt_transparency_level;
/*
	This is the transparency level to be used when transmitting
	frames (0-2).  Each increasing level causes more characters to
	be avoided when sending frames which allows them to be sent in
	situations where certain characters are not allowed.
*/


static char opt_suffix_len;
static unsigned char opt_suffix[3];
/*
	This is the suffix string to be added to the end of each frame
	sent.  Any character including a null is allowed.
*/


static unsigned int opt_max_rx_len;
/*
	This is the maximum size of a receive buffer.  It is used when
	receiving to make sure that a received frame does not go past
	the end of the buffer.  A received frame which is too long will
	be discarded.
*/

static unsigned char transparency_level [256] = {
	
	2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
	2, 1, 2, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 0, 0, 2,

	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9};
/*
	For each possible character this is the transparency level at
	which it should be encoded for transparency.  A value of nine is
	used for character which should never be encoded.
*/


		/* Variables and macros used by aft_tx_char */

static char tx_char_state;
/*
	This is the state of the transmission routine which handles
	transparency, delimiting of frames, and frame abort.  It is used
	to determine the next action to be performed by aft_tx_char when
	it is called.  State names are given by the 'TCS_' macros.
*/


#define TCS_IDLE		0
/*
	This state 

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 19:42:12 GMT
From:      n2dsy@hou2d.UUCP (G.BEATTIE)
To:        comp.protocols.tcp-ip
Subject:   Asynchronous Framing Technique Software: ASYNC.ASM


page 58,132
;	file: ASYNC.ASM
TITLE	ASYNC DRIVER FOR MSDOS
SUBTTL	DESCRIPTION
;
;	Loadable asyncrounous device driver for msdos.
;	Written by: Mike Higgins
;	Copyright (c) April 1984 by The Computer Entomologist.
;
;	Permission is hearby granted to use or distribute this software
;without any restrictions.  You may make copies for yourself or your
;friends. You may include it in any hardware or software product that you
;sell for profit.
;
;	This software is distributed as is, and is not guaranteed to work
;on any particular hardware/software configuration.  Furthermore, no 
;liability is granted with this software: the user takes responcibility for
;any damage this software may do to his system.
;
;	Nasy notices aside, if you have any questions about this software, you
;can reach me at the address below.  If you impliment any new features or
;find (and fix!) any bugs, I would be happy to hear from you.
;
;	Mike Higgins
;	The Computer Entomologist
;	P.O. Box 197
;	Duncans Mills, CA 95430
;
;	-Impliments FULL RS232 support for IBM PC and compatable async cards.
;	-Includes 128-byte buffers on input and output.
;	-Supports Xon/Xoff or hardware handshake. Hardware handshake uses
;	 DSR or CTS (to throttle output data) All handshake modes are
;	 treated separately, an can be used in combinations.
;	-The 8th bit (parity) can optionally be stripped off on input
;	 and/or output.
;	-The IOCTRL read and write function is used to query or change
;	 baud rates, bits/byte, parity, as well as enabling/disabling all
;	 the optional features mentioned above.  This eliminates the
;	 necesity of a program that has special knowledge of the system.
;	 A program to change these features need not know the location of
;	 the driver or special words in low memory, or even the port
;	 address of the UART.  Instead, all that is needed is the name of
;	 the device, and the format of an IOCTL write to this driver.
;
;		ASSEMBLY INSTRUCTIONS:
;	MASM ASYNC,ASYNC,ASYNC,NUL
;	LINK ASYNC,ASYNC,ASYNC,NUL
;	EXE2BIN ASYNC
;	COPY ASYNC.BIN A:    (IF NOT THERE ALREADY)
;		ADD THE FOLLOWING LINE TO A:CONFIG.SYS:
;	DRIVER=ASYNC.BIN
;		RE-BOOT YOUR SYSTEM AND IT'S THERE! NOTE: THIS DRIVER
;	DOES NOT GET ALONG AT ALL WITH BASICA OR MODE, AND POSSIBLY 
;	MANY OTHER PCDOS PROGRAMS THAT DO NOT CONFORM TO THE MSDOS 
;	STANDARDS.  BASICA IN PARTICULAR MUCKS UP ALL THE ASYNC CARD
;	INTERNAL REGESTERS, REDIRECTS THE HARDWARE VECTOR, AND IT
;	NEVER PUTS THEM BACK THE WAY THEY WERE.  IF YOU TRY TO USE
;	THIS DRIVER AFTER BASICA HAS BEEN IN MEMORY, THE DRIVER WILL
;	PROBABLY HANG YOUR SYSTEM.
;
;		***BUGS***
;
;	If your RS232 device continually sends data to the driver, the driver
;	will hang when your system boots. (The EPSON RX80 serial card sends
;	^Q's constantly and causes this).  The current solution is to leave
;	your device turned off until the system boots completely.  Then turn
;	the RS232 device on after the driver is ready for it, and everything
;	works as expected.
;
SUBTTL	DEFINITIONS
PAGE
;
;		DEVICE TYPE CODES
DEVCHR	EQU	08000h	;THIS IS A CHARACTER DEVICE
DEVBLK	EQU	0H	;THIS IS A BLOCK (DISK) DEVICE
DEVIOC	EQU	04000H	;THIS DEVICE ACCEPTS IOCTRL REQUESTS
DEVNON	EQU	02000H	;NON IBM DISK DRIVER
DEVSPC	EQU	010H	;CONSOLE ACCEPTS SPECIAL INTERUPT 29
DEVCLK	EQU	08H	;THIS IS THE CLOCK DEVICE
DEVNUL	EQU	04H	;THIS IS THE NUL DEVICE
DEVSTO	EQU	02H	;THIS IS THE CURRENT STANDARD OUTPUT DEVICE
DEVSTI	EQU	01H	;THIS IS THE STANDARD INPUT DEVICE
;
;		ERROR STATUS BITS
STSERR	EQU	08000H	;GENERAL ERROR, SEE LOWER ORDER BITS FOR REASON
STSBSY	EQU	0200H	;DEVICE IS BUISY
STSDNE	EQU	0100H	;REQUEST IS COMPLETED
;		ERROR REASON VALUES FOR LOWER ORDER BITS.
ERRWP	EQU	0	;WRITE PROTECT ERROR
ERRUU	EQU	1	;UNKNOWN UNIT
ERRDNR	EQU	2	;DRIVE NOT READY
ERRUC	EQU	3	;UNKNOWN COMMAND
ERRCRC	EQU	4	;CYCLIC REDUNDANCY CHECK ERROR
ERRBSL	EQU	5	;BAD DRIVE REQUEST STRUCTURE LENGTH
ERRSL	EQU	6	;SEEK ERROR
ERRUM	EQU	7	;UNKNOWN MEDIA
ERRSNF	EQU	8	;SECTOR NOT FOUND
ERRPOP	EQU	9	;PRINTER OUT OF PAPER
ERRWF	EQU	10	;WRITE FAULT
ERRRF	EQU	11	;READ FAULT
ERRGF	EQU	12	;GENERAL FAILURE
;
;		DEFINE THE BIT MEANINGS OF THE OUTPUT STATUS BYTE
;
LINIDL	EQU	0FFH	;IF ALL BITS OFF, XMITTER IS IDLE.
LINXOF	EQU	1	;OUTPUT IS SUSPENDED BY XOFF
LINEXP	EQU	2	;XMITTER IS BUISY, INTERUPT EXPECTED.
LINDSR	EQU	10H	;OUTPUT IS SUSPENDED UNTIL DSR COMES ON AGAIN
LINCTS	EQU	20H	;OUTPUT IS SUSPENDED UNTIL CTS COMES ON AGAIN
;
;		BIT DEFINITIONS OF THE INPUT STATUS BYTE
;
MODIDL	EQU	0FFH	;MASK TO CHECK BLOCKING BITS
MODERR	EQU	1	;INPUT LINE ERRORS HAVE BEEN DETECTED.
MODOFF	EQU	2	;DEVICE IS OFFLINE NOW.
MODOVR	EQU	4	;RECEIVER BUFFER OVERFLOWED, DATA LOST.
MODXON	EQU	8	;RX IS BLOCKED SINCE WE SENT XOFF (^S).
MODDTR	EQU	10H	;RX IS BLOCKED SINCE DTR IS LOW.
MODRTS	EQU	20H	;RX IS BLOCKED SINCE RTS IS LOW.
;
;		DEFINE THE BIT MEANINGS IN THE SPECIAL CHARACTERISTICS WORDS
;
;	THE FIRST SPECIAL WORD CONTROLS HOW THE INPUT FROM THE UART IS TREATED
;
INDTR	EQU	2	;DTR IS DATA-THROTTLE SIGNAL.
INRTS	EQU	4	;RTS IS DATA-THROTTLE SIGNAL.
INXON	EQU	8	;XON/XOFF IS USED TO THROTTLE INPUT DATA.
INHDP	EQU	020H	;HALF DUPLEX: INPUT CHARS ARE ECHOED.
INEST	EQU	0400H	;ERRORS CAUSE STATUS RETURNS.
INEPC	EQU	0800H	;ERRORS TRANSLATE TO CODES WITH PARITY BIT ON.
INSTP	EQU	01000H	;STRIP PARITY BIT OFF ON INPUT
;
;	THE SECOND SPECIAL WORD CONTROLS HOW THE OUTPUT TO THE UART IS TREATED
;
OUTDSR	EQU	2	;DSR IS USED TO THROTTLE OUTPUT DATA.
OUTCTS	EQU	4	;CTS IS USED TO THROTTLE OUTPUT DATA.
OUTXON	EQU	8	;XON/XOFF IS USED TO THROTTLE OUTPUT DATA.
OUTCSF	EQU	010H	;CTS IS OFFLINE SIGNAL.
OUTCDF	EQU	020H	;CARRIER DETECT IS OFFLINE SIGNAL
OUTDRF	EQU	040H	;DSR IS OFFLINE SIGNAL.
OUTSTP	EQU	01000H	;STRIP PARITY OFF ON OUTPUT.
;
;		DEFINE THE PORT OFFSETS AND IMPORTANT ASYNC BOARD CONSTANTS
;		LINE CONTROL REG DEFINITIONS
;
BITS5	EQU	0
BITS6	EQU	1
BITS7	EQU	2
BITS8	EQU	3
ONESTOP	EQU	0	;DEFAULT
TWOSTOP	EQU	4
nopar	equ	0
PARON	EQU	8
ODDPAR	EQU	0+paron	;DEFAULT
EVENPAR	EQU	10H+PARON
STICKPAR	EQU	20H	;(THIS IS STRANGE)
BREAKON	EQU	40H
DLAB	EQU	080H	;DIVISOR LATCH ACCESS BIT
;
;		MODEM CONTROL REG DEFINITIONS
DTR		EQU	1
RTS		EQU	2
OUT1		EQU	4
OUT2		EQU	8
LOOPBACK	EQU	10H
;
ALLINT	EQU	01111B	;ENABLE ALL INTERUPTS IN INTEN REGESTER.
TXBUF	EQU	0	;OFFSET TO TRANSMITTER BUFFER REGESTER
RXBUF	EQU	0	;DITO FOR RECEIVER (DIRECTION DIFERENTIATES FUNCS)
BAUD0	EQU	0	;BAUD DIVISOR REG (DLAB IN LCTRL DIFFERENCIATES)
BAUD1	EQU	1	;BAUD DIVISOR HIGH BYTE
INTEN	EQU	1	;INTERUPT ENABLE REGESTER
INTID	EQU	2	;INTERUPT IDENTIFICATION REGESTER.
LCTRL	EQU	3	;LINE CONTROL REGESTER
MCTRL	EQU	4	;MODEM CONTROL REGESTER
LSTAT	EQU	5	;LINE STATUS REGESTER
MSTAT	EQU	6	;MODEM STATUS REGESTER

;	BAUD RATE CONVERSION TABLE
;
BD50		EQU	2304
BD75		EQU	1536
BD110	EQU	1047
BD134	EQU	857
BD150	EQU	786
BD300	EQU	384
BD600	EQU	192
BD1200	EQU	96
BD1800	EQU	64
BD2000	EQU	58
BD2400	EQU	48
BD3600	EQU	32
BD4800	EQU	24
BD7200	EQU	16
BD9600	EQU	12
;

SUBTTL	DRIVER LIST HEAD
PAGE
;*************************************************************************
;
;	BEGENING OF DRIVER CODE.
;
DRIVER	SEGMENT
	ASSUME	CS:DRIVER,DS:DRIVER,ES:DRIVER
;	ORG	0	;DRIVERS START AT 0
ASYNC2:
	DW	ASYNC1,-1	;POINTER TO NEXT DEVICE: DOS FILLS THIS IN.
	DW	DEVCHR OR DEVIOC	;CHARACTER DEVICE
	DW	STRATEGY		;OFFSET TO STRATEGY ROUTINE.
	DW	REQUEST2		;OFFSET TO "INTERUPT" ENTRYPOINT.
	DB	"ASYNC2  "		;DEVICE NAME.
ASYNC1:
	DW	-1,-1		;POINTER TO NEXT DEVICE: END OF LINKED LIST.
	DW	DEVCHR OR DEVIOC	;THIS DEVICE IS CHARACTER IOCTL
	DW	STRATEGY		;STRATEGY ROUTINE
	DW	REQUEST1		;I/O REQUEST ROUTINT
	DB	"ASYNC1  "
;
SUBTTL DRIVER INTERNAL DATA STRUCTURES
PAGE
;
ASY_UNITS	EQU	2	;NUMBER OF UNITS THIS DRIVER IS BUILT FOR

UNIT	STRUC	;EACH UNIT HAS A STRUCTURE DEFINING IT'S STATE:
PORT	DW	?	;I/O PORT ADDRESS
VECT	DW	?	;INTERUPT VECTOR OFFSET (NOT INTERUPT NUMBER!)
ISRADR	DW	?	;OFFSET TO INTERUPT SERVICE ROUTINE
LINE	DB	?	;DEFAULT LINE CONTROL BIT SETTINGS DURING INIT,
			;OUTPUT STATUS BITS AFTERWORDS.
MODEM	DB	?	;MODEM CONTROL BIT SETTINGS DURING INIT,
			;INPUT STATUS BITS AFTERWARDS.
INSPEC	DW	?	;SPECIAL CHAR INPUT TREATMENT, HANDSHAKING MODE.
OUTSPEC	DW	?	;SPECIAL MODE BITS FOR OUTPUT
BAUD	DW	?	;CURRENT BAUD RATE DIVISOR VALUE
IFIRST	DW	?	;OFFSET TO FIRST CHARACTER IN INPUT BUFFER.
IAVAIL	DW	?	;OFFSET TO NEXT AVAILABLE BYTE.
IBUF	DW	?	;POINTER TO 128 BYTE INPUT BUFFER.
OFIRST	DW	?	;OFFSET INTO FIRST CHARACTER IN OUTPUT BUFFER
OAVAIL	DW	?	;OFFSET INTO NEXT AVAIL BYTE IN OUTPUT BUFFER
OBUF	DW	?	;POINTER TO 128 BYTE OUTPUT BUFFER
UNIT	ENDS

	;TABLE OF STRUCTURES FOR EACH ASYNCROUNOUS UNIT
			;ASYNC1 DEFAULTS TO THE COM1 PORT AND VECTOR,
b81n		equ	bits8 or onestop or nopar
dtrrts	equ	dtr or rts or out2	;seems to need out2 all the time!!!!!!!!
ASY_TAB1:
	UNIT	<3F8H,30H,ASY1ISR,B81N,DTRRTS,INDTR+INEST,OUTCTS,BD1200,0,0,IN1BUF,0,0,OUT1BUF>

			;ASYNC2 DEFAULTS TO THE COM2 PORT AND VECTOR,
			;NO PARITY, 8 DATA BITS, 1 STOP BIT,
			;AND 9600 BAUD.
ASY_TAB2:
	UNIT	<2F8H,2CH,ASY2ISR,B81N,DTRRTS,INDTR+INEST,OUTCTS,BD1200,0,0,IN2BUF,0,0,OUT2BUF>

		;IF THE BUFFER SIZE IS A POWER OF TWO, THE PROCESS OF KEEPING
		;THE OFSETTS WITHIN THE BOUNDS OF THE BUFFER IS GREATLY
		;SIMPLIFIED.  IF YOU MODIFY THE BUFFER SIZE, KEEP IT A
		;POWER OF 2, AND MODIFY THE MASK ACCORDINGLY.
BUFSIZ	EQU	128		;INPUT BUFFER SIZE
BUFMSK	EQU	127		;MASK FOR CALCULATING OFFSETS MODULO BUFSIZ
ISTOP	EQU	120		;TRY TO STOP RX WHEN IBUF IS THIS FULL
ISTART	EQU	100		;LET THE GUY SEND AGAIN WHEN THIS FULL
IN1BUF	DB	BUFSIZ DUP (?)
IN2BUF	DB	BUFSIZ DUP (?)
OUT1BUF	DB	BUFSIZ DUP (?)
OUT2BUF	DB	BUFSIZ DUP (?)
;
ASY_BAUDT	DW	50,BD50	;FIRST VALUE IS DESIRED BAUD RATE,
		DW	75,BD75	;SECOND IS DIVISOR REGISTER VALUE.
		DW	110,BD110
		DW	134,BD134
		DW	150,BD150
		DW	300,BD300
		DW	600,BD600
		DW	1200,BD1200
		DW	1800,BD1800
		DW	2000,BD2000
		DW	2400,BD2400
		DW	3600,BD3600
		DW	4800,BD4800
		DW	7200,BD7200
		DW	9600,BD9600
;
;	STRUCTURE OF AN I/O REQUEST PACKET STATIC HEADER
;
PACK	STRUC
LEN	DB	?	;LENGTH OF RECORD
PRTNO	DB	?	;UNIT CODE
CODE	DB	?	;COMMAND CODE
STAT	DW	?	;RETURN STATUS
DOSQ	DD	?	;UNUSED DOS QUE LINK POINTER
DEVQ	DD	?	;UNUSED DRIVER QUE LINK POINTER
MEDIA	DB	?	;MEDIA CODE ON READ/WRITE
XFER	DW	?	;XFER ADDRESS OFFSET
XSEG	DW	?	;XFER ADDRESS SEGMENT
COUNT	DW	?	;TRANSFER BYTE COUNT.
PACK	ENDS
;
;	THE FOLLOWING TWO WORDS IS THE STORAGE AREA FOR THE REQUEST PACKET
;	ADDRESS, SENT TO ME BY A STRATEGY ROUTINE CALL.
;		AS REQUESTED BY THE MSDOS DRIVER MANUAL, I AM "THINKING
;	ABOUT" THE FUTURE, SO I`M DESIGNATING THIS POINTER AS THE QUEUE
;	LIST HEAD FOR REQUESTS TO THIS DRIVER.
;
PACKHEAD	DD	0
;
;	THE STRATEGY ROUTINE ITSELF.
STRATEGY	PROC	FAR
			;SQUIRREL AWAY THE POINTER FOR LATER.
	MOV	WORD PTR CS:PACKHEAD,BX		;STORE THE OFFSET,
	MOV	WORD PTR CS:PACKHEAD+2,ES	;AND THE SEGMENT.
	RET
STRATEGY	ENDP
SUBTTL	REQUEST ROUTINES
PAGE
;	PHYLOSOPHICAL RUMINATIONS:
;		Why does MicroSoft INSIST on choosing names for things that
;	already have firmly defined meanings for OTHER things?  Take for
;	example, the MASM definition of a SEGMENT: It bears little relation
;	to the deffinition of a segment in the intel 8088 processor handbook.
;	This leads to a GREAT DEAL of confusion.  Many other assemblers on
;	other systems have constructs that are equivalent to MASM's SEGMENT,
;	they are often called PSECTS for Program SECTionS.  Perhaps the
;	people at Microsoft wanted a word that made more sence in English,
;	but I wish they had chosen SECTION instead of SEGMENT.
;		The example that it bringing all this to mind now is the
;	MicroSoft device driver documentation, which insists on calling
;	the following routine an "interupt routine".  Go read the intel
;	manual, you will find that an interupt routine is defined THERE as
;	a bunch of code that is jumped to by a special kind of event in
;	the hardware.  That is NOT what the people at MicroSquishy mean
;	this time either.  Depending on weather you describe these routines
;	in terms of what they do now, or in the "future", the following
;	routine should be called the "I/O request routine" or the "I/O
;	completion routine".   But NO, they had to deside to call this
;	the "interupt routine", and create another layer of confusion for
;	those of us who already know the traditional deffinition of this
;	relatively well known phrase.
;
;		I am herby refering to the "interupt routine" as the
;	"request routine", and nameing all my labels accordingly.
;
;		I/O REQUEST ROUTINES
REQUEST1:		;ASYNC1 HAS BEEN REQUESTED
	PUSH	SI	;SAVE SI SO YOU CAN
	MOV	SI,OFFSET ASY_TAB1	;GET THE DEVICE UNIT TABLE ADDRESS.
	JMP	GEN_REQUEST	;THE GENERIC DRIVER DOES THE REST.
REQUEST2:		;ASYNC2 HAS BEEN REQUESTED TO DO SOMETHING
	PUSH	SI	;SAVE SI
	MOV	SI,OFFSET ASY_TAB2	;GET UNIT TABLE TWO`S ADDRESS

GEN_REQUEST:
	PUSHF		;I REQUIRE DIRECTION FLAG CLEARED, SO I SAVE
	CLD		;THE FLAGS AND CLEAR THEM HERE.
	PUSH	AX		;SAVE ALL THE REGESTERS, YOU MAY NOT
	PUSH	BX		;NEED THEM ALL, BUT YOU WILL REGRET IT
	PUSH	CX		;IF YOU FORGET TO SAVE JUST ONE OF THEM.
	PUSH	DX
	PUSH	DI
	PUSH	BP
	PUSH	DS
	PUSH	ES
	PUSH	CS		;COPY THE CS REGESTER
	POP	DS		;INTO THE DS TO ACCESS MY DATA
	LES	BX,PACKHEAD	;RECOVER THE POINTER TO THE PACKET.
	MOV	DI,OFFSET ASY_FUNCS	;GET THE POINTER TO THE DISPATCH TABLE
	MOV	AL,ES:CODE[BX]	;GET THE FUNCTION REQUEST CODE,
	MOV	AH,0		;MAKE IT INTO A WORD,
	SAL	AX,1		;CONVERT TO A WORD OFFSET,
	ADD	DI,AX		;AND ADD TO THE TABLE START ADDRESS
	JMP	[DI]		;JUMP TO THE APPROPRIATE ROUTINE
;
;		TABLE OF OFFSETS TO ALL THE DRIVER FUNCTIONS
ASY_FUNCS:
	DW	ASYNC_INIT	;INITIALIZE DRIVER
	DW	EXIT		;MEDIA CHECK (BLOCK DEVICES ONLY)
	DW	EXIT		;BUILD BPB (BLOCK DEVICES ONLY)
	DW	IOCTLIN		;IOCTL INPUT
	DW	READ		;READ
	DW	NDREAD		;NON-DESTRUCTIVE READ
	DW	RXSTAT		;INPUT STATUS
	DW	INFLUSH		;FLUSH INPUT BUFFER
	DW	WRITE		;WRITE
	DW	WRITE		;WRITE WITH VERIFY
	DW	TXSTAT		;OUTPUT STATUS
	DW	TXFLUSH		;FLUSH OUTPUT BUFFER
	DW	IOCTLOUT	;IOCTL OUTPUT
;
;	EXIT FROM DRIVER REQUEST
;		CALL WITH AX= RETURN STATUS VALUE
EXITP	PROC	FAR
EXIT:
	LES	BX,PACKHEAD	;RETREIVE POINTER TO PACKET
	OR	AX,STSDNE	;SET THE DONE BIT IN IT.
	MOV	ES:STAT[BX],AX	;STORE THE STATUS BACK IN THE PACKET.

	POP	ES		;RESTORE ALL THE REGESTERS
	POP	DS
	POP	BP
	POP	DI
	POP	DX
	POP	CX
	POP	BX
	POP	AX
	POPF
	POP	SI
	RET
EXITP	ENDP
SUBTTL	READ DATA REQUEST ROUTINE
PAGE
;
;		ALL THE FOLLOWING ROUTINES ARE CALLED WITH THE SAME CONTEXT
;	FROM THE REQUEST ROUTINE:
;	- ES:BX POINTS TO THE I/O PACKET.
;	   ROUTINES CAN MUCK UP THESE TWO REGESTERS IF THEY WANT, AS EXIT
;	   WILL RESTORE THEM BEFORE IT TRIES TO SEND THE STATUS WORD BACK.
;	- CS: AND DS: POINT TO THE BEGENING OF THE DRIVER SEGMENT.
;	- DS:SI POINTS TO THE DEVICE UNIT TABLE DESCRIBING THE PARTICULAR
;	   PORT BEING ACCESSED.
;	- ALL OTHER REGESTERS ARE AVAILABLE FOR USE, THE EXIT ROUTINE
;	   RESTORES THEM ALL BEFORE RETURNING TO MSDOS.
;		ALL THE FOLLOWING ROUTINES SHOULD EXIT BY DOING A JMP
;	TO THE EXIT ROUTINE.  EXIT ASSUMES THAT AX
;	CONTAINS EITHER ZERO, OR THE ERROR BIT SET AND A VALID ERROR
;	RETURN VALUE IN THE LOW ORDER BITS.  EXIT SETS THE DONE BIT IN
;	THIS VALUE FOR YOU BEFORE IT RETURNS TO MSDOS.
;
SUBTTL	READ REQUEST ROUTINE
;		READ DATA FROM DEVICE
;
READ:
	MOV	CX,ES:COUNT[BX]		;GET THE REQUESTED NUMBER OF BYTES
	MOV	DI,ES:XFER[BX]		;DI IS OFFSET TO USER BUFFER
	MOV	DX,ES:XSEG[BX]		;SEGMENT IS LAST I NEED FROM PACKET,
	MOV	ES,DX			;NOW ES:DI POINTS TO USER BUFFER.
	CALL	START_IN	;TRY TO RESTART RX, ALL REGS PRESERVED
	TEST	MODEM[SI],MODERR OR MODOVR ;HAVE ANY LINE ERRORS OCCURED?
	JE	NO_LERR			;NOT LATELY.
	AND	MODEM[SI],NOT ( MODERR OR MODOVR ) ;YES, CLEAR THE BITS,
	MOV	AX,ERRRF		;AND RETURN ERROR INDICATION TO DOS
	JMP	EXIT
NO_LERR:

RLUP:
	CALL	GET_IN			;GET NEXT CHAR FROM INPUT BUFFER
	CMP	AH,0			;WAS THERE ONE?
	JE	TEST_READ		;YES, TEST FOR SPECIAL BITS
	JMP	RLUP			;NO, WAIT FOR A CHAR TO ARRIVE.
TEST_READ:
		;BEFORE RETURNING A CHARACTER TO MSDOS, I CHECK FOR ANY
		;SPECIAL PROCESSING I AM REQUIRED TO DO.  I DO AS MANY
		;OF THESE FUNCTIONS HERE AS POSSIBLE, TO SAVE THE
		;RECEIVER INTERUPT ROUTINE FROM HAVING TO DO THEM, AND
		;TO ALLOW INTELIGENT USE OF THE RING BUFFER.  FOR EXAMPLE,
		;CHARACTERS TO NOT ECHO-HALF-DUPLEX UNTIL THEY ARE READ
		;FROM THE BUFFER HERE, SO A PROGRAM THAT DISABLES ECHO
		;WHILE READING A PASSWORD WILL WORK EVEN IF THE USER TYPED
		;THE PASWORD IN BEFORE BEING PROMPTED FOR IT.
			;************************************
			;TEST FOR STRIPPING PARITY BIT
	TEST	INSPEC[SI],INSTP	;SHOULD I STRIP PARITY?
	JE	NO_STRIP		;NOPE.
	AND	AL,NOT 080H		;YES.
NO_STRIP:
			;**********************************8
			;TEST FOR HALF-DUPLEX MODE
	STOS	BYTE PTR [DI]		;BUT FIRST STORE CHAR IN USER BUFFER.
	TEST	INSPEC[SI],INHDP	;AM I IN HALF DUPLEX MODE?
	JE	NO_HALF			;NO.
HALF_WAIT:
	CALL	PUT_OUT			;YES, PUT THE CHARACTER IN OUTBUF.
	CMP	AH,0			;WAS THERE ROOM?
	JNE	HALF_WAIT		;NO, WAIT FOR IT.
	CALL	START_OUTPUT		;AND MAKE SURE THE XMITTER STARTS
NO_HALF:
		;ALTHOUGH MSDOS NEVER, TO MY KNOWLEDGE, ASKS FOR MORE THAN
		;ONE STUPID CHARACTER AT A TIME, I LOOP ON THE REQUEST SIZE
		;SO THAT THIS DRIVER WILL STILL WORK ON THAT GLORIOUS DAY
		;WHEN SOMEBODY ASKS FOR MORE THAN ONE.
	LOOP	RLUP			;KEEP GOING IF YOU WERE REQUESTED.
	MOV	AL,0			;RETURN NO ERRORS IN AX IF DONE.
	JMP	EXIT
SUBTTL	NON-DESTRUCTIVE READ REQUEST ROUTINE
PAGE
;		NON-DESTRUCTIVE READ FROM DEVICE
;
NDREAD:
	MOV	DI,IFIRST[SI]		;GET POINTER TO FIRST CHAR
	CMP	DI,IAVAIL[SI]		;IS THE BUFFER EMPTY?
	JNE	NDGET			;NO, GET ONE NON DESTRUCTIVELY.
	MOV	AX,STSBSY		;YES, RETURN DEVICE BUISY
	JMP	EXIT
NDGET:
	PUSH	BX			;SAVE AN EXTRA COPY OF BX.
	MOV	BX,IBUF[SI]		;GET BUFFER ADDRESS
	MOV	AL,[BX+DI]			;GET THE CHARACTER,
	POP	BX			;RECOVER BX AGAIN.
	MOV	ES:MEDIA[BX],AL		;RETURN IT IN THE REQUEST PACKET.
	MOV	AX,0			;RETURN NO ERRORS IN AX.
	JMP	EXIT
SUBTTL	INPUT STATUS REQUEST ROUTINE
PAGE
;		INPUT STATUS REQUEST
;
RXSTAT:
	MOV	DI,IFIRST[SI]		;GET POINTER TO FIRST CHAR
	CMP	DI,IAVAIL[SI]		;IS THE BUFFER EMPTY?
	JNE	RXFUL
	MOV	AX,STSBSY		;NO, RETURN STATUS BUISY.
	JMP	EXIT
RXFUL:
	MOV	AX,0			;YES, RETURN STATUS ZERO.
	JMP	EXIT
SUBTTL	INPUT FLUSH REQUEST ROUTINE
;		INPUT FLUSH REQUEST
;
INFLUSH:
	MOV	AX,IAVAIL[SI]		;GET THE POINTER TO THE NEXT EMPTY
	MOV	IFIRST[SI],AX		;CHAR AND POINT THE FIRST AT IT.
	MOV	AX,0			;AND RETURN DONE.
	JMP	EXIT
SUBTTL	WRITE REQUEST ROUTINE
PAGE
;		OUTPUT DATA TO DEVICE
;
WRITE:
	MOV	CX,ES:COUNT[BX]		;GET BYTE COUNT,
	MOV	DI,ES:XFER[BX]		;GET XFER ADDRESS OFFSET,
	MOV	AX,ES:XSEG[BX]		;GET XFER SEGMENT.
	MOV	ES,AX			;STORE IN ES NOW.
WLUP:
	MOV	AL,ES:[DI]		;GET THE NEXT CHAR,
	INC	DI			;AND INC DI PAST IT.
;
;		CHECK FOR STRIP PARITY ON OUTPUT.
;
	TEST	OUTSPEC[SI],OUTSTP	;IS THIS ENABLED?
	JE	NOOSTP			;NOPE
	AND	AL,NOT 080H		;YES, WACK OFF BIT SEVEN!
NOOSTP:
;
;		AFTER ALL THE SPECIAL OUTPUT PROCESSING, I DO A HARD WAIT
;		FOR A SLOT IN THE OUTPUT BUFFER.
WWAIT:
	CALL	PUT_OUT			;ATTEMPT TO PUT IN IN OUTPUT BUFFER
	CMP	AH,0			;DID IT WORK?
	JNE	WWAIT			;NO, KEEP TRYING.
	LOOP	WLUP			;YES, GO GET NEXT CHAR.
	CALL	START_OUTPUT		;START THE XMITTER IF NECC.
	MOV	AX,0			;RETURN SUCCESS
	JMP	EXIT
SUBTTL	OUTPUT STATUS REQUEST ROUTINE
;		OUTPUT STATUS REQUEST
;
TXSTAT:
	MOV	AX,OFIRST[SI]		;GET POINTER TO NEXT CHAR OUT
	DEC	AX			;SUBTRACT ONE FROM IT,
	AND	AX,BUFMSK		;MODULO 128.
	CMP	AX,OAVAIL[SI]		;IF THAT EQUALS THE INPUT PNTR,
	JNE	TXROOM
	MOV	AX,STSBSY		;THEN THE DEVICE IS BUISY.
	JMP	EXIT
TXROOM:
	MOV	AX,0			;OTHERWIZE THE DEVICE IS OK.
	JMP	EXIT
SUBTTL	I/O CONTROL READ REQUEST
PAGE
;
;		IOCONTROL READ REQUEST, RETURN LINE PARAMETERS
;
IOCTLIN:
	MOV	CX,ES:COUNT[BX]		;GET THE REQUESTED NUMBER OF BYTES
	MOV	DI,ES:XFER[BX]		;DI IS OFFSET TO USER BUFFER
	MOV	DX,ES:XSEG[BX]		;SEGMENT IS LAST I NEED FROM PACKET,
	MOV	ES,DX			;NOW ES:DI POINTS TO USER BUFFER.
	CMP	CX,14		;ONLY WORKS WHEN YOU GIVE ME AN
	JE	DOIOCIN		;14 BYTE BUFFER TO STOMP ON.
	MOV	AX,ERRBSL		;RETURN AN ERROR IF NOT 14 BYTES.
	JMP	EXIT
DOIOCIN:
	MOV	DX,PORT[SI]		;GET PORT NUMBER
	ADD	DX,LCTRL		;SLIDE UP TO LINE CONTROL
	MOV	CX,4			;SET UP FOR PORT LOOP.
GETPORT:
	IN	AL,DX			;GET NEXT BYTE FROM DEVICE
	STOS	BYTE PTR [DI]		;STORE THEM IN USER BUFFER
	INC	DX			;SKIP TO NEXT BYTE
	LOOP	GETPORT			;READ AND STORE 4 BYTES OF INFO

	MOV	AX,INSPEC[SI]		;GET THE SPECIAL INPUT BITS
	STOS	WORD PTR [DI]		;SEND BACK TO USER BUFFER
	MOV	AX,OUTSPEC[SI]		;GET THE SPECIAL OUTPUT BITS
	STOS	WORD PTR [DI]		;SEND BACK TO USER BUFFER
	MOV	AX,BAUD[SI]		;GET BAUD RATE DIVISOR
	MOV	BX,DI			;SAVE DI FOR A WHILE.
	MOV	DI,OFFSET ASY_BAUDT+2	;POINT AT BAUD RATE CONVERSION.
	MOV	CX,15			;JUST IN CASE, STOP AT 15 BAUDS
BAUDCIN:
	CMP	[DI],AX			;IS THIS THE BAUD I AM USING?
	JE	YESINB			;YES, RETURN THAT
	ADD	DI,4			;NO, SKIP TO NEXT ONE
	LOOP	BAUDCIN			;KEEP LOOKING.
YESINB:			;SEARCH SHOULD ALWAYS TERMINATE ON COMPARE
	MOV	AX,-2[DI]		;GET THE ASSOCIATED BAUD RATE
	MOV	DI,BX			;GET DI'S OLD VALUE BACK
	STOS	WORD PTR [DI]		;STORE THE BAUD RATE BACK.
	mov	ah,0
	mov	al,line[si]
	stos	byte ptr [di]
	mov	ah,0
	mov	al,modem[si]
	stos	byte ptr [di]
	MOV	AX,0			;RETURN NO ERRORS
	stos	word ptr [di]	;zero the extra word
	JMP	EXIT

;
;		FLUSH OUTPUT BUFFER REQUEST
;
TXFLUSH:
	MOV	AX,OAVAIL[SI]		;GET NEXT FREE BYTE OFFSET,
	MOV	OFIRST[SI],AX		;POINT THE FIRST BYTE OFFSET AT IT.
	MOV	AX,0
	JMP	EXIT
SUBTTL	I/O CONTROL WRITE REQUEST ROUTINE
PAGE
;		IOCONTROL REQUEST: CHANGE LINE PARAMETERS FOR THIS DRIVER
;
IOCTLOUT:
	MOV	CX,ES:COUNT[BX]		;GET THE REQUESTED NUMBER OF BYTES
	MOV	DI,ES:XFER[BX]		;DI IS OFFSET TO USER BUFFER
	MOV	DX,ES:XSEG[BX]		;SEGMENT IS LAST I NEED FROM PACKET,
	MOV	ES,DX			;NOW ES:DI POINTS TO USER BUFFER.
	CMP	CX,10			;ONLY WORKS WHEN YOU GIVE ME A
	JNL	DOIOCOUT		;atleast 10 BYTE BUFFER TO READ
	MOV	AX,ERRBSL		;RETURN AN ERROR IF NOT =>10 BYTES.
	JMP	EXIT
DOIOCOUT:
	MOV	DX,PORT[SI]		;GET PORT NUMBER
	ADD	DX,LCTRL		;SLIDE UP TO LINE CONTROL
	MOV	AL,ES:[DI]		;GET LINE CONTROL FROM USER BUF.
	INC	DI
	OR	AL,080H			;SET DLAB BIT FOR BAUD RATE
	OUT	DX,AL			;OUTPUT TO DEVICE
	INC	DX			;SKIP TO NEXT BYTE
	MOV	AL,ES:[DI]		;GET MODEM CONTROL FROM USER BUF.
	INC	DI
	OR	AL,08H			;MAKE SURE INTERUPTS ARE ENABLED.
	OUT	DX,AL			;SEND IT TO DEVICE.
	ADD	DI,2			;SKIP OVER THE STATUS BYTES
	MOV	AX,ES:[DI]		;GET THE SPECIAL INPUT BITS
	ADD	DI,2
	MOV	INSPEC[SI],AX		;STORE THE NEW BITS IN UNIT
	MOV	AX,ES:[DI]		;GET THE OUTPUT SPECIAL BITS
	ADD	DI,2
	MOV	OUTSPEC[SI],AX		;STORE THEM ALSO.
	MOV	AX,ES:[DI]		;GET THE REQUESTED BAUD RATE
	MOV	BX,DI			;SAVE DI FOR A WHILE.
	MOV	DI,OFFSET ASY_BAUDT	;POINT AT BAUD RATE CONVERSION
	MOV	CX,15			;JUST IN CASE, STOP AT 15 BAUDS
BAUDCOUT:
	CMP	[DI],AX			;IS THIS THE BAUD I AM USING?
	JE	YESOUTB			;YES, RETURN THAT
	ADD	DI,4			;NO, SKIP TO NEXT ONE
	LOOP	BAUDCOUT		;KEEP LOOKING.
	IN	AL,DX			;GET LINE CONTROL REGESTER AGAIN,
	AND	AL,NOT 080H		;CLEAR DLAB BIT.
	DEC	DX
	OUT	DX,AL			;AND WRITE IT BACK OUT.
	MOV	AX,ERRUM		;RETURN AN ERROR NUMBER IF
	JMP	EXIT			;BAUD RATE IS NOT IN TABLE.
YESOUTB:
	MOV	AX,2[DI]		;GET THE ASSOCIATED BAUD RATE
	MOV	BAUD[SI],AX		;STORE IT IN UNIT TABLE
	MOV	DX,PORT[SI]		;GET PORT ADDRESS AGAIN,
	OUT	DX,AL			;WRITE THE LOW BYTE,
	INC	DX			;SKIP TO NEXT ONE,
	MOV	AL,AH			;GET HIGH BYTE INTO AL
	OUT	DX,AL			;OUTPUT IT AS WELL.
	ADD	DX,LCTRL-BAUD1		;POINT AT THE LINE CONTROL REG.
	IN	AL,DX			;READ IT IN,
	AND	AL,NOT 080H		;CLEAR THE DLAB BIT.
	OUT	DX,AL			;OUTPUT IT BACK.
	MOV	AX,0			;RETURN NO ERROR
	JMP	EXIT
SUBTTL	RING BUFFER ROUTINES
PAGE
;		LOCAL ROUTINES FOR MANAGING THE RING BUFFERS ON INPUT
;	AND OUTPUT.  THE FOLLOWING FOUR ROUTINES ARE ALL CALLED WITH THE
;	SAME CONTEXT:
;
;	DS:SI	POINTS TO THE UNIT STRUCTURE FOR THIS UNIT
;	AL	IS THE CHARACTER TO BE PLACED IN OR REMOVED FROM A BUFFER
;	AH	IS THE RETURN STATUS FLAG: 0=SUCESS, -1=FAILURE
;
;	ALL OTHER REGESTERS ARE PRESERVED.
;
PUT_OUT	PROC	NEAR	;PUTS AL INTO THE OUTPUT RING BUFFER
	PUSHF
	CLI			;DISABLE INTERUPTS WHILE I HAVE OAVAIL
	PUSH	CX
	PUSH	DI
	MOV	CX,OAVAIL[SI]	;GET POINTER TO NEXT AVAILABLE BYTE IN
	MOV	DI,CX		;OUTPUT BUFFER.
	INC	CX		;INCRIMENT A COPY OF IT TO SEE IF THE
	AND	CX,BUFMSK	;BUFFER IS FULL.
	CMP	CX,OFIRST[SI]	;IS IT?
	JE	POERR		;YES, RETURN AN ERROR
	ADD	DI,OBUF[SI]	;NO, CALCULATE ACTUAL OFFSET OF CHAR
	MOV	[DI],AL		;AND STUFF THE CHARACTER INTO BUFFER
	MOV	OAVAIL[SI],CX	;UPDATE THE POINTER
	MOV	AH,0		;INDICATE SUCCESS
	JMP	PORET		;AND RETURN
POERR:
	MOV	AH,-1		;INDICATE FAILURE.
PORET:
	POP	DI
	POP	CX
	POPF		;RE-ENABLE INTERUPTS
	RET
PUT_OUT	ENDP

GET_OUT	PROC	NEAR	;GETS THE NEXT CHARACTER FROM OUTPUT RING BUFFER
	PUSHF			;JUST IN CASE, DISABLE INTERUPTS
	CLI			;WHILE IN THIS ROUTINE.
			;SURE YOU DISABLE INTERUPTS FIRST.
	PUSH	CX
	PUSH	DI
	MOV	DI,OFIRST[SI]	;GET POINTER TO FIRST CHARACTER TO OUTPUT
	CMP	DI,OAVAIL[SI]	;IS THE BUFFER EMPTY?
	JNE	NGOERR		;NO.
	MOV	AH,-1		;YES, INDICATE  FAILURE
	JMP	GORET		;AND RETURN
NGOERR:
	MOV	CX,DI		;SAVE A COPY OF THE POINTER
	ADD	DI,OBUF[SI]	;CALCULATE ACTUAL ADDRESS
	MOV	AL,[DI]		;GET THE CHAR INTO AL
	MOV	AH,0		;INDICATE SUCCESS.
	INC	CX		;INCRIMENT THE OFFSET
	AND	CX,BUFMSK	;MODULO 128
	MOV	OFIRST[SI],CX	;STORE BACK IN UNIT TABLE.
GORET:
	POP	DI
	POP	CX
	POPF
	RET
GET_OUT	ENDP

PUT_IN	PROC	NEAR	;PUT THE CHAR FROM AL INTO INPUT RING BUFFER
	PUSHF			;DISABLE INTS WHILE IN THIS ROUTINE
	CLI
	PUSH	CX
	PUSH	DI
	MOV	DI,IAVAIL[SI]	;GET POINTER TO NEXT AVAILABLE SLOT IN BUFFER
	MOV	CX,DI		;SAVE A COPY OF IT,
	INC	CX		;AND INCRIMENT THAT COPY (MODULO
	AND	CX,BUFMSK		;128) TO SEE IF THE BUFFER IS FULL.
	CMP	CX,IFIRST[SI]	;WELL, IS IT?
	JNE	NPIERR		;NO, THERE`S ROOM.
	MOV	AH,-1		;YES, INDICATE FAILURE
	JMP	PIRET		;AND RETURN
NPIERR:
	ADD	DI,IBUF[SI]	;CALCULATE ACTUAL ADDRES,
	MOV	[DI],AL		;STORE THE CHARACTER THERE
	MOV	IAVAIL[SI],CX	;UPDATE THE POINTER.
	MOV	AH,0		;AND INDICATE SUCCESS.
PIRET:
	POP	DI
	POP	CX
	POPF
	RET
PUT_IN	ENDP

GET_IN	PROC	NEAR	;GETS ONE CARACTER FROM INPUT RING BUFFER INTO AL
	PUSHF
	CLI		;DISABLE INTERUPTS WHILE I LOOK AT IFIRST.
	PUSH	CX
	PUSH	DI
	MOV	DI,IFIRST[SI]	;GET POINTER TO FIRST CHAR TO READ
	CMP	DI,IAVAIL[SI]	;IS THE BUFFER EMPTY?
	JE	GIERR		;THEN YOU CAN`T VERY WELL SQUEEZE WATER OUT OF IT
	MOV	CX,DI		;MAKE A COPY OF POINTER,
	ADD	DI,IBUF[SI]	;CALCULATE ACTUAL ADDRESS OF CHAR
	MOV	AL,[DI]		;GET THE CHAR INTO AL
	MOV	AH,0		;INDICATE SUCCESS
	INC	CX		;INCRIMENT THAT COPY OF YOUR POINTER,
	AND	CX,BUFMSK	;MODULO THE BUFFER SIZE,
	MOV	IFIRST[SI],CX	;SO YOU CAN UPDATE THE POINTER.
	JMP	GIRET
GIERR:
	MOV	AH,-1		;RETURN FAILURE INDICATOR
GIRET:
	POP	DI
	POP	CX
	POPF		;RE-ENABLE INTERUPTS BEFORE YOU RETURN
	RET
GET_IN	ENDP
SUBTTL	INPUT FLOW CONTROL CHECKING ROUTINES
STOP_IN	PROC	NEAR	;STOP INPUT IF BUFFER IS GETTING FULL
	PUSHF
	CLI
	PUSH	AX
	PUSH	DX
	MOV	AX,IAVAIL[SI]
	ADD	AX,BUFSIZ
	SUB	AX,IFIRST[SI]		;AX IS NOW THE # BYTES USED
	AND	AX,BUFMSK			;PUT IT IN THE RIGHT RANGE
	CMP	AX,ISTOP			;SHOULD WE STOP THE TURKEY?
	JL	S_IN_OK			;AX<STOP POINT IT'S OK
	TEST	INSPEC[SI],INXON	;IS XON/XOFF ENABLED?
	JE	S_IN_DTR			;NOPE, TRY DTR
	MOV	DX,PORT[SI]		;WAIT FOR THE TRANSMITTER
	ADD	DX,LSTAT			;HOLDING REG TO BE EMPTY
S_IN_LOP:
	IN	AL,DX			;GET THE REG VALUE
	TEST	AL,20H
	JE	S_IN_LOP			;LOOP UNTIL IT'S EMPTY
	MOV	DX,PORT[SI]		;NOW SENT THE DATA (^S)
	MOV	AL,'S' AND 1FH
	OUT	DX,AL
	OR	MODEM[SI],MODXON	;REMEMBER WE SENT THIS
	OR	LINE[SI],LINEXP	;WE ARE EXPECTING AN INTR
S_IN_DTR:
	MOV	DX,PORT[SI]		;POINT TO MODEM CONTROL REG
	ADD	DX,MCTRL
	TEST	INSPEC[SI],INDTR	;USING DTR FOR FLOW CONTROL?
	JE	S_IN_RTS			;NOPE, CHECK RTS
	IN	AL,DX
	AND	AL,NOT 1
	OUT	DX,AL
	OR	MODEM[SI],MODDTR
S_IN_RTS:
	TEST	INSPEC[SI],INRTS
	JE	S_IN_OK
	IN	AL,DX
	AND	AL,NOT 2
	OUT	DX,AL
	OR	MODEM[SI],MODRTS
S_IN_OK:
	POP	DX
	POP	AX
	POPF
	RET
STOP_IN	ENDP
;
START_IN	PROC	NEAR	;RESTART INPUT IF THERE IS SPACE
	PUSHF
	CLI
	PUSH	DX
	PUSH	AX
	TEST	MODEM[SI],MODIDL
	JE	Q_IN_OK
	MOV	AX,IAVAIL[SI]
	ADD	AX,BUFSIZ
	SUB	AX,IFIRST[SI]		;AX IS NOW THE # BYTES USED
	AND	AX,BUFMSK			;PUT IT IN THE RIGHT RANGE
	CMP	AX,ISTART			;SHOULD WE RESTART THE TURKEY?
	JG	Q_IN_OK			;AX>RESTART POINT DO IT LATER
	TEST	INSPEC[SI],INXON	;IS XON/XOFF ENABLED?
	JE	Q_IN_DTR			;NOPE, TRY DTR
	MOV	DX,PORT[SI]		;GET PORT ADDRESS
	ADD	DX,LSTAT			;POINT TO LSTAT
Q_IN_LOP:
	IN	AL,DX			;GET STATUS
	TEST	AL,20H			;HOLDING REG EMPTY?
	JE	Q_IN_LOP			;NOPE, WAIT FOR IT
	MOV	DX,PORT[SI]
	MOV	AL,'Q' AND 1FH
	OUT	DX,AL
	AND	MODEM[SI],NOT MODXON
	OR	LINE[SI],LINEXP
Q_IN_DTR:
	MOV	DX,PORT[SI]
	ADD	DX,MCTRL			;POINT TO MODEM CONTROL REG
	TEST	INSPEC[SI],INDTR	;DTR FLOW CONTROL ENABLED?
	JE	Q_IN_RTS			;NOPE, TRY RTS
	IN	AL,DX
	OR	AL,1				;TURN DTR ON
	OUT	DX,AL
Q_IN_RTS:
	TEST	INSPEC[SI],INRTS	;RTS FLOW CONTROL ENABLED?
	JE	Q_IN_OK			;NOPE, WE ARE DONE
	IN	AL,DX
	OR	AL,2				;TURN RTS ON
	OUT	DX,AL
Q_IN_OK:
	POP	AX
	POP	DX
	POPF
	RET
START_IN	ENDP
SUBTTL	INTERUPT SERVICE ROUTINES
PAGE
;		THE FOLLOWING ROUTINES ARE  WHAT I REALLY CALL AN INTERUPT
;	ROUTINE!  THESE ROUTINES ARE ONLY CALLED WHEN AN INTERUPT IS GENERATED
;	BY THE 8088, NOT BY A SOFWARE CALL THROUGH A LINKED LIST! ONE EASY
;	WAY TO TELL A REAL INTERUPT ROUTINE WHEN YOU SEE IT IS TO LOOK AT THE
;	LAST INSTRUCTION, WHICH IS AN "INTERUPT RETURN",  NOT A FAR RETURN
;	LIKE THE SO-CALLED MSDOS "INTERUPT ROUTINE" DOES.
;	THESE INTERUPT ROUTINES ARE ENVOKED WHENEVER A CHAR ARRIVES IN THE
;	UART, THE UART FINISHES SENDING A CHARACTER OUT, AN ERROR OCCURS
;	WHILE READING A CHARACTER INTO THE UART, OR THE MODEM STATUS LINES
;	CHANGE.

ASY1ISR:
	CLI
	PUSH	SI
	LEA	SI,ASY_TAB1	;POINT AT THE CORRECT TABLE FOR THIS UART,
	JMP	INT_SERVE	;JUMP INTO THE COMMON INTERUPT SERVER CODE.
ASY2ISR:
	CLI
	PUSH	SI
	LEA	SI,ASY_TAB2	;GET UNIT TABLE
;
;			IF YOU ADD MORE UNITS, YOU CAN ADD THEM HERE,
;			BUT DON'T FORGET TO ADD A JUMP INT_SERVE AFTER
;			ASY2ISR'S LEA INSTRUCTION!
;
;		THE FOLLOWING CODE IS THE COMMON SHARED CODE THAT ALL THE
;	ASYNC PORTS SHARE.  IT "KNOWS" WHICH ONE TO TALK TO BY REFERENCING
;	THE STRUCTURE POINTED TO BY CS:SI.

INT_SERVE:
	PUSH	AX	;PUSH ALL THE GP REGESTERS
	PUSH	BX
	PUSH	CX
	PUSH	DX
	PUSH	DI
	PUSH	DS	;SAVE THE DATA SEGMENT
	PUSH	CS	;SO YOU CAN LOAD CS
	POP	DS	;INTO DS AND FIND YOUR OWN STRUCTURES.
INT_EXIT:
	MOV	DX,PORT[SI]	;GET THE PORT ADDRESS OF THIS DEVICE
	ADD	DX,INTID	;SLIDE UP TO THE INTERUPT ID REGISTER
	IN	AL,DX		;GET THE INTERUPT REASON
	TEST	AL,1		;MAKE SURE IT IS VALID
	JNE	INT_DONE	;IT IS NOT.
	MOV	AH,0		;CONVERT IT TO A 16 BIT NUMBER
	ADD	AX,OFFSET INT_REASON	;ADD IT TO THE JUMP TABLE ADDRESS
	MOV	DI,AX		;PUT IT IN AN INDEX REGESTER,
	JMP	[DI]		;AND GO PROCESS THAT TYPE OF INTERUPT

INT_DONE:
	ADD	DX,LSTAT-INTID	;BECAUSE IT SEEMS TO BE NECESSARY,
	IN	Al,DX		;READ THE STATUS PORT BEFORE YOU EXIT.
	MOV	AL,020H		;OUTPUT A 20H TO THE UNDOCUMENTED INTERUPT
	OUT	020H,AL		;COMMAND PORT TO ENABLE FURTHER INTERUPTS?
	POP	DS	;RECOVER ALL THE REGESTERS
	POP	DI
	POP	DX
	POP	CX
	POP	BX
	POP	AX
	POP	SI
	IRET

;
;		JUMP TABLE OF INTERUPT REASONS. INTERUPT ID REGISTER
;		IS USED AS INDEX TO THIS TABLE.
INT_REASON:
	DW	INT_MODEM	;INT WAS CAUSED BY A MODEM LINE TRANSITION
	DW	INT_TXMIT	;INT WAS CAUSED BY A TX REGISTER EMPTY
	DW	INT_RECEIVE	;NEW CHARACTER AVAILABLE IN UART
	DW	INT_RXSTAT	;CHANGE IN RECEIVER STATUS REGESTER
SUBTTL	RECEIVER INTERUPT SERVICE ROUTINE
PAGE
;
;		THE INTERUPT SERVICE ROUTINES BELOW ALL HAVE THE
;	FOLLOWING CONTEXT:
;	-CS AND DS POINT TO THE DRIVER SEGMENT.
;	-DS:[SI] POINTS TO THE UNIT STRUCTURE FOR THE ASYNC LINE THAT
;		FIRED THE INTERUPT.
;	-AX BX CX DX AND DI ARE AVAILABLE FOR SCRATCH.  ALL OTHERS
;		MUST BE LEFT ALONE OR SAVED AND RECOVERED.
;	TO EXIT FROM AN INTERUPT SERVICE ROUTINE, THESE SERVERS MUST
;	JUMP TO INT_EXIT.
;
SUBTTL	RECEIVER INTERUPT SERVICE ROUTINE
INT_RECEIVE:	;THE UART HAS RECEIVED A NEW CHARACTER, I MUST COPY IT
		;INTO THE INPUT TYPEAHEAD BUFFER.
	MOV	DX,PORT[SI]	;POINT DX BACK AT THE RXBUF REGESTER
	IN	AL,DX		;GET THE CHARACTER
;
;			BEFORE I STORE THE CHARACTER BACK IN THE RING
;			BUFFER, I CHECK TO SEE IF ANY OF THE SPECIAL
;			INPUT SEQUENCES ARE ENABLED, AND IF THEY
;			HAVE BEEN FOUND IN THE INPUT.
;
;
;		CHECK FOR XON/XOFF
;
	TEST	OUTSPEC[SI],OUTXON	;IS XON/XOFF ENABLED?
	JE	NOXON			;NO, SKIP THIS WHOLE SECTION
	CMP	AL,'S' AND 01FH		;IS THIS A CONTROL-S?
	JNE	ISQ			;NO, CHECK FOR CONTROL-Q
	OR	LINE[SI],LINXOF		;DISABLE OUTPUT.
	JMP	INT_EXIT		;DON'T STORE THIS CHAR.
ISQ:
	CMP	AL,'Q' AND 01FH		;IS THIS A CONTROL-Q?
	JNE	NOXON			;NO, SKIP TO THE NEXT TEST.
	TEST	LINE[SI],LINXOF		;AM I WAITING FOR THIS ^Q?
	JE	INT_EXIT		;NO, DON'T STIR UP DRIVER.
	AND	LINE[SI],NOT LINXOF	;CLEAR THE XOFF BIT,
	CALL	START_OUTPUT
	JMP	INT_EXIT		;DON'T BUFFER ^Q'S

NOXON:
STUFF_IN:
	CALL	PUT_IN		;PUT THE CHARACTER IN THE RING BUFFER
	CMP	AH,0		;WAS THERE ROOM?
	JE	INT_RX_CHK
	OR	MODEM[SI],MODOVR	;NO, SET THE OVERFLOW BIT
INT_RX_CHK:
	CALL	STOP_IN		;STOP RX IF GETTING FULL
	JMP	INT_EXIT
SUBTTL	RECEIVER LINE STATUS INTERUPT ROUTINE
PAGE
;		THE LSTAT REGISTER DETECTED A RECEIVER ERROR CONDITION
INT_RXSTAT:
	ADD	DX,LSTAT-INTID	;READ THE REGESTER AND FIND OUT WHY
	IN	AL,DX
	TEST	INSPEC[SI],INEPC	;DO I RETURN THEM AS CODES?
	JE	NOCODE			;NO, WHAT ELSE?
	AND	AL,01EH			;YES, MASK OFF ALL BUT ERROR BITS,
	OR	AL,080H			;SET THE PARITY BIT TO MAKE IT
					;AN ILLEGAL CHARACTER,
	JMP	STUFF_IN		;AND PUT IT IN THE INPUT BUFFER.
NOCODE:
	OR	MODEM[SI],MODERR	;SET A STATUS BIT THAT WILL
					;NOTIFY MSDOS ON THE NEXT REQUEST
	JMP	INT_EXIT
PAGE
SUBTTL	MODEM STATUS INTERUPT SERVICE ROUTINE
;		THE MODEM STATUS REGESTER DETECTED A CHANGE IN ONE OF THE
;	MODEM LINES.  I COULD CHECK THE "DELTA BITS" TO SEE EXACTLY WHICH
;	LINE TRIGGERED THIS INTERUPT, BUT I JUST CHECK ALL OF THEM WHEN
;	I GET ANY MODEM STATUS INTERUPT.
INT_MODEM:
	ADD	DX,MSTAT-INTID	;READ THE MODEM STATUS REGESTER
	IN	AL,DX
			;*********************************
			;CHECK THE CARIER-DETECT BIT (CD)
	TEST	AL,080H		;IS CARRIER DETECT OFF?
	JNE	MSDSR		;NO, CHECK DSR NEXT
	TEST	OUTSPEC[SI],OUTCDF	;IS CD THE OFF-LINE SIGNAL?
	JE	MSDSR		;NO, IGNORE CD THEN.
	OR	MODEM[SI],MODOFF	;YES,SET OFLINE FOR NEXT READ REQUEST
			;**************************************
			;CHECK THE DATA-SET-READY BIT (DSR)
MSDSR:
	TEST	AL,020H		;IS DSR OFF?
	JNE	DSRON		;NO, GO CHECK TO SEE IF I WAS WAITING ON IT.
	TEST	OUTSPEC[SI],OUTDSR	;IS DSR THE OUTPUT DATA THROTTLE FLG?
	JE	DSROFF			;NO, MABY IT'S OFFLINE SIGNAL
	OR	LINE[SI],LINDSR		;YES, SUSPEND OUTPUT WAITING ON DSR
DSROFF:
	TEST	OUTSPEC[SI],OUTDRF	;IS DSR THE OFFLINE SIGNAL?
	JE	MSCTS			;NOPE.
	OR	MODEM[SI],MODOFF	;YES, SET FLAG FOR NEXT READ.
	JMP	MSCTS
DSRON:
	TEST	LINE[SI],LINDSR		;WAS I WAITING FOR DSR TO COME ON?
	JE	MSCTS			;NO, IGNORE IT.
	AND	LINE[SI],NOT LINDSR	;YES, CLEAR THE BIT, AND
	CALL	START_OUTPUT		;START OUTPUT BACK UP AGAIN.
			;****************************************
			;CHECK THE CLEAR-TO-SEND BIT (CTS)
MSCTS:
	TEST	AL,010H			;IS CTS OFF?
	JNE	CTSON			;NO, GO CHECK TO SEE IF ITS EXPECTED
	TEST	OUTSPEC[SI],OUTCTS	;IS CSR THE OUTPUT DATA THROTTLER?
	JE	CTSOFF			;NO, MABY IT'S OFFLINE SIGNAL
	OR	LINE[SI],LINCTS		;YES, SUSPEND OUTPUT.
CTSOFF:
	TEST	OUTSPEC[SI],OUTCTS	;IS CTS THE OFF-LINE SIGNAL?
	JE	INT_EXIT4		;NOPE.
	OR	MODEM[SI],MODOFF	;YES, SET FLAG FOR NEXT READ.
	JMP	INT_EXIT
CTSON:
	TEST	LINE[SI],LINCTS		;WAS I WAITING FOR THIS CTS?
	JE	INT_EXIT4		;NO, THERE'S NOTHING LEFT TO CHECK.
	AND	LINE[SI],NOT LINCTS	;YES, CLEAR THE BIT, AND
	CALL	START_OUTPUT		;START OUTPUT UP AGAIN.
INT_EXIT4:
	JMP	INT_EXIT
SUBTTL	TRANSMITTER INTERUPT SERVICE ROUTINE
PAGE
;		THE TRANSMITTER HOLDING REGESTER IS EMPTY, LOOK TO SEE IF
INT_TXMIT:	;THERE ARE MORE CHARS TO PRINT NOW.
	AND	LINE[SI],NOT LINEXP	;CLEAR INTERUPT EXPECTED BIT.
	CALL	START_OUTPUT		;START THE NEXT CHARACTER
	JMP	INT_EXIT

;ROUTINE TO START THE NEXT CHARACTER PRINTING ON THE UART, IF OUTPUT
;IS NOT BEING SUSPENDED FOR ONE REASON OR ANOTHER.
;THIS ROUTINE MAY BE CALLED FROM REQUEST ROUTINES, OR FROM INTERUPT
;SEVICE ROUTINES.
;	THIS ROUTINE DESTROYS AX AND DX.
;	SX MUST POINT AT THE UNIT STRUCTURE.
START_OUTPUT	PROC	NEAR
	PUSHF				;SAVE THE FLAGS SO I CAN
	CLI				;DISABLE INTERUPTS
	TEST	LINE[SI],LINIDL		;AM I IN HOLD OUTPUT MODE?
	JNE	DONT_START		;YES, DON'T SEND ANY MORE CHARS.
;	MOV	DX,PORT[SI]	;CHECK HOLDING REG STATUS
;	ADD	DX,LSTAT
;	IN	AL,DX
;	TEST	AL,20H		;IS IT EMPTY?
;	JE	DONT_START	;NOPE, TRY NEXT TIME
	CALL	GET_OUT		;CHECK TO SEE IF THERE IS A CHAR IN THE BUF
	CMP	AH,0		;WELL, WAS THERE?
	JNE	DONT_START	;NO, BUFFER IS EMPTY
	MOV	DX,PORT[SI]	;YES, POINT DX AT THE TX OUT REGISTER
	OUT	DX,AL		;SEND HIM THE CHARACTER
	OR	LINE[SI],LINEXP		;WARN EVERYBODY THAT I'M BUSY.
DONT_START:
	POPF
	RET
START_OUTPUT	ENDP

;		THE FOLLOWING LABEL DEFINES THE END OF THE DRIVER, SO I
;		CAN TELL DOS HOW BIG I AM.
ASYNC_END:
SUBTTL	INITIALIZATION REQUEST ROUTINE
PAGE
;
;		THE INITIALIZE DRIVER ROUTINE IS STORED AFTER THE "END"
;	OF THE DRIVER HERE SO THAT THIS CODE CAN BE THROWN AWAY AFTER
;	THE DEVICE HAS BEEN INITIALIZED.  THIS CODE IS ONLY CALLED TWICE:
;	ONCE TO INITIALIZE EACH OF THE ASYNC UNITS THAT THIS DRIVER
;	CONTAINS.  (HOPEFULLY, MSDOS DOESN'T WRITE ANYTHING ON TOP OF
;	THIS CODE UNIT BOTH UNITS ARE INITIALIZED.
;		THE CONTEXT OF THE INITIALIZE CODE BELOW IS THE SAME AS
;	ALL THE OTHER REQUEST ROUTINES EARLIER IN THE DRIVER.
;
;		INITIALIZE THE DRIVER AND DEVICE
;
ASYNC_INIT:
	MOV	AX,OFFSET ASYNC_END	;GET THE SIZE OF THE DRIVER
	MOV	ES:XFER[BX],AX		;SEND THAT BACK IN PACKET
	MOV	ES:XSEG[BX],CS		;SEND THE CODE SEGMENT ALSO.
				;I HAVE SATISFIED ALL THE REQIREMENTS OF THE
				;INIT FUNCTION TO RETURN IN THE I/O PACKET, SO
				;I CAN DESTROY THE CONTENTS OF ES:BX AND USE
				;THEM FOR OTHER THINGS.
	MOV	AX,0			;POINT ES AT THE VECTOR SEGMENT
	MOV	ES,AX			;SO CAN INITIALIZE THE VECTORS
	MOV	AX,ISRADR[SI]		;GET ADRS OF INTERUPT SERVICE ROUTINE
				;THE FOLLOWING CODE IS SPECIFIC TO THE IBM:
				;BASIC USES LOCATIONS 400 AND 402 TO FIND
				;THE PORT ADDRESSES OF COM1 AND COM2. IF I
				;ZERO THESE, THEN BASIC CANNOT MUCK UP THE
				;REGESTERS ON ME ANY MORE!  (IT STILL
				;DISABLES INTERUPTS, THOUGH.  BUMMER!)
	MOV	DI,400			;POINT AT THE ASYNC ADDRESS LIST
	CLD
	STOS	WORD PTR [DI]		;CLOBBER THE FIRST ONE,
	STOS	WORD PTR [DI]		;AND THE SECOND ONE.
				;NOW WE'RE BACK ON THE GENERIC MSDOS TRACK.
	MOV	DI,VECT[SI]		;GET ADRS OF VECOTR,
	STOS	WORD PTR [DI]		;STORE THE OFFSET THERE, THEN
	MOV	ES:[DI],CS		;THE SEGMENT IN THE FOLLOWING WORD.
	MOV	CX,DI			;GET THE VECTOR NUMBER,
	SUB	CL,022H			;SUBTRACT BIAS TO HARDWARE INTS,
	SAR	CL,1			;DIVIDE BY 4 TO CONVERT TO
	SAR	CL,1			;HARDWARE INTERUPT NUMBER.
	MOV	AH,1			;SHIFT A MASK BY THAT MUCH TO
	SAL	AH,CL			;CREATE INTERUPT ENABLE MASK BIT,
	NOT	AH			;WHICH IS ACTIVE LOW...
	IN	AL,021H			;GET SYSTEM HARDWARE INTERUPT MASK
	AND	AL,AH			;AND MY BIT OUT OF IT,
	OUT	021H,AL			;WRITE IT BACK OUT AGAIN.
	MOV	DX,PORT[SI]		;GET THE PORT ADDRESS OF THIS LINE
	ADD	DX,INTID
INT_CAN:
	IN	AL,DX			;GET INTERUPT ID REGESTER
	TEST	AL,1			;IF HE HAS ANYTHING TO COMPLAINE
	JNZ	INT_NONE		;ABOUT, READ THEM ALL AND IGNORE.
	ADD	DX,LSTAT-INTID		;JUST TO MAKE UART HAPPY, READ THE
	IN	AL,DX			;LINE STATUS AND
	ADD	DX,MSTAT-LSTAT		;THE MODEM STATUS TO
	IN	AL,DX			;"RESET INTERUPT CONTROL"
	ADD	DX,RXBUF-MSTAT		;READING THE RECEIVER MIGHT
	IN	AL,DX			;HELP ALSO.
	ADD	DX,INTID-RXBUF		;POINT BACK AT INTERUPT ID,
	JMP	INT_CAN			;AND DO THIS AGAIN.
INT_NONE:
	ADD	DX,LSTAT-INTID		;CALC ADDRESS OF LINE STATUS,
	IN	AL,DX			;INPUT IT OR SOMETIMES IT DOESN'T WORK

	ADD	DX,LCTRL-LSTAT		;CALC ADDRESS OF LINE CONTROL REG
	MOV	AL,LINE[SI]		;GET THE DEFAULT LINE 
	OR	AL,DLAB			;SET THE DIVISOR LATCH BIT
	OUT	DX,AL			;SET UP DEFAULT LINE CHARS
	SUB	DX,LCTRL		;POINT BACK AT FIRST PORT
	MOV	AX,BAUD[SI]		;GET DIVISOR VALUE FOR BAUD RATE
	OUT	DX,AL			;SEND LOW BYTE
	INC	DX			;INC TO HIGH BYTE PORT
	MOV	AL,AH			;GET HIGH BYTE,
	OUT	DX,AL			;AND SEND TO BOARD.
	ADD	DX,LCTRL-1		;POINT AT LINE CONTROL AGAIN,
	MOV	AL,LINE[SI]		;GET DEFAULT LINE CONTROL BITS AGAIN
	OUT	DX,AL			;SET THEM WITHOUT DLAB ON.
	MOV	LINE[SI],0		;RE-USE LINE OFFSET AS STATUS
	SUB	DX,LCTRL-INTEN		;POINT DX AT INTERUPT ENABLE PORT
	MOV	AL,ALLINT		;SET UP TO GET ALL POSSIBLE INTS
	OUT	DX,AL			;IN THE INTEN REGESTER.
	ADD	DX,MCTRL-INTEN		;POINT AT MODEM STATUS REGESTER
	MOV	AL,MODEM[SI]		;GET THE DEFAULT MODEM STATUS BITS,
	OUT	DX,AL			;AND SET THEM IN MCTRL.
	MOV	MODEM[SI],0		;RE-USE THIS BYTE FOR INPUT STATUS.
	TEST	INSPEC[SI],INXON	;IS INPUT THROTTLED WITH XON?
	JE	DONE_INIT		;NO, LEAVE HIM BE.
	MOV	AL,'Q' AND 01FH		;YES, SEND A CONTROL-Q
	MOV	DX,PORT[SI]		;TO THE DEVICE AT INIT TIME,
	OUT	DX,AL			;TO MAKE SURE IT WAKES UP.
DONE_INIT:
	MOV	AX,0			;RETURN NO ERRORS.
	JMP	EXIT

DRIVER	ENDS
	END

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 19:44:14 GMT
From:      mtunx!whuts!homxb!hou2d!n2dsy@rutgers.edu  (G.BEATTIE)
To:        tcp-ip@sri-nic.arpa
Subject:   Asynchronous Framing Technique Software: TEST1.C


/*
	This is a test program for the AFT system.

            Version 1.0, by John Howell (N2FVN), Copyright August 7, 1987
               
            This software is free for non-commercial use.  All commercial
            rights are retained by the author or his designees.  Commercial 
            use without the explicit written permission of the author is
            prohibited.  This package is provided on an 'as is' basis 
            without warranty.
*/

#include "stdio.h"

main()
{
	char ebdt, c, level, suff_str[10], suff_len;
	char in_str[256], out_str[256];

	int rx_max, in_len, out_len, i, match, tc;

	printf("AFT Test Program 1\n\n");

	printf("Eight-bit data transparency?");
	scanf("%1s",&c);
	ebdt = c == 'y' || c == 'Y';

	printf("Transparency level?");
	scanf("%d",&level);

	printf("Suffix?");
	get_array(suff_str, &suff_len);

	printf("Maximum receive length?");
	scanf("%d",&rx_max);

	aft_options(ebdt, level, suff_len, suff_str, rx_max);

	while (1) {

		printf("Frame to send?");
		get_array(out_str, &out_len);

		if (out_len == 0)
			exit(0);

		aft_tx_start(out_len, out_str);
		aft_rx_start(in_str);

		tc = aft_tx_complete();

		if (tc) {
			printf("ERR: Tx CMPL 1\n");
		}
		
		if (aft_rx_complete()) {
			printf("ERR: Rx CMPL 1\n");
		}
		
		do {

			i = aft_tx_char();

			if (tc != (i == 0x017e)) {
				printf("ERR: Tx CMPL 2\n");
			}
			
			tc = aft_tx_complete();

			if (i != 0x017e) {	
				printf("%4x ",i);

				in_len = aft_rx_char(i & 0x00ff);
				
				if (in_len != aft_rx_complete())
					printf("ERR: Rx CMPL 2\n");
					
				if (in_len != 0)
					printf("RX ");

			}

		} while ((i & 0xff00) == 0);

		printf("TX\n");

		if (!aft_tx_complete()) {
			printf("ERR: Tx CMPL 3\n");
		}
		
		aft_rx_error();
		
		match = 1;
		if (in_len != out_len) {
			printf(" ERR: in_len=%d  out_len=%d\n",
				in_len, out_len);
			match = 0;
		}
		
		for (i = 0; i < out_len; i++)
			if (in_str[i] != out_str[i])
				match = 0;
				
		if (!match) {
			printf(" ERR: RX mismatch\n");
			for (i = 0; i < in_len; i++) 
				printf("%2x ",in_str[i]);
			printf("\n");
		}
	}
}

get_array(buffer, len)
char *buffer;
int *len;
{
	char c;

	c = getc(stdin);
	*len = 0;
	while (1) {
		c = getc(stdin);
		ungetc(c, stdin);

		if (c == '\n')
			return;

		if (!scanf("%2x", buffer++)) 
			return;

		(*len)++;
	}
}
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 19:46:07 GMT
From:      n2dsy@hou2d.UUCP (G.BEATTIE)
To:        comp.protocols.tcp-ip
Subject:   Asynchronous Framing Technique Software: TEST2.C


/*
	This is a test program for the AFT system.

            Version 1.0, by John Howell (N2FVN), Copyright August 7, 1987
               
            This software is free for non-commercial use.  All commercial
            rights are retained by the author or his designees.  Commercial 
            use without the explicit written permission of the author is
            prohibited.  This package is provided on an 'as is' basis 
            without warranty.

	Send and receive frames.  Machine dependant for the PC with
	async driver installed.  Requires Microsoft C 4.0.
*/

#include "stdio.h"
#include "conio.h"
#include "dos.h"
#include "fcntl.h"
#include <sys\types.h>
#include <sys\stat.h>
#include "io.h"
#include "stdlib.h"

int async_handle;

main()
{
	char ebdt, c, level, suff_str[10], suff_len;
	char in_str[256], out_str[256];
	int out_busy;

	int rx_max, in_len, out_len, i, match, tc;

	printf("AFT Test Program 2\n");
	printf("Send and receive frames over COM1: using ASYNC driver.\n");

	async_handle = open("ASYNC1", O_RDWR | O_BINARY);

	if (async_handle == -1) {
		printf("Open of async driver failed. errno=%d\n", errno);
		printf("Make sure ASYNC.BIN is included in CONFIG.SYS.\n");
		exit(1);
	}

	printf("Eight-bit data transparency (y/n)?");
	scanf("%1s",&c);
	ebdt = c == 'y' || c == 'Y';

	printf("Transparency level (0-2)?");
	scanf("%d",&level);

	printf("Suffix string (HEX)?");
	get_array(suff_str, &suff_len);

	rx_max = sizeof(in_str) - 2;

	aft_options(ebdt, level, suff_len, suff_str, rx_max);
	aft_rx_start(in_str);
	out_len = 0;
	out_busy = 0;

	printf("Enter characters to fill transmit buffer.  Return to send.\n");
	printf("Enter empty line to exit.\n\n");

	while (1) {

		if (async_char_waiting()) {

			if (aft_rx_char(async_get_char())) {
				in_len = aft_rx_complete();

				printf("Frame received. Length=%d data:",
					in_len);

				for (i=0; i<in_len; i++)
					printf("%c",in_str[i]);
				printf("\n");

				aft_rx_start(in_str);
			}
		}

		if (kbhit() && !out_busy) {

			if ((c = getch()) == 0x0d) {
				if (out_len == 0)
					exit(0);

				printf("--  Sending.  Length=%d\n",
					out_len);

				aft_tx_start(out_len, out_str);
				out_busy = 1;
			}
			else {
				if (out_len == sizeof(out_str)) {
					printf("\007");
				}
				else {
					out_str[out_len++] = c;
					printf("%c",c);
				}
			}
		}

		if (out_busy && async_output_ready()) {
			
			if ((i = aft_tx_char()) < 256) {
				async_put_char(i);
			}
			else {
				out_busy = 0;
				out_len = 0;
			}
		}
	}
}


get_array(buffer, len)
char *buffer;
int *len;
{
	char c;

	c = getc(stdin);
	*len = 0;
	while (1) {
		c = getc(stdin);
		ungetc(c, stdin);

		if (c == '\n')
			return;

		if (!scanf("%2x", buffer++)) 
			return;

		(*len)++;
	}
}


async_char_waiting()
{
	union REGS inregs, outregs;

	inregs.h.ah = 0x44;	/* I/O control function */
	inregs.h.al = 0x06;	/* Input status */
	inregs.x.bx = async_handle;

	intdos(&inregs, &outregs);

	return outregs.x.ax != 0;
}


async_output_ready()
{
	union REGS inregs, outregs;

	inregs.h.ah = 0x44;	/* I/O control function */
	inregs.h.al = 0x07;	/* Output status */
	inregs.x.bx = async_handle;

	intdos(&inregs, &outregs);

	return outregs.x.ax != 0;
}


async_get_char()
{
	char c;

	if (read(async_handle, &c, 1) != 1) {
		printf("No data waiting for read!!!\n");
		return 0x7e;
	}

	return c;
}

async_put_char(c)
char c;
{
	if (write(async_handle, &c, 1) != 1)
		printf("Write failed!!!\n");
}

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 19:50:27 GMT
From:      karn@THUMPER.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   alternate source for new 4.3 files

I have placed copies of the new 4.3 networking files announced by Mike Karels
on flash.bellcore.com (128.96.32.20). They are available by anonymous FTP
under /pub/4.3. The latest version of bind (4.8) is also available under /pub
as /pub/bind.4.8.tar.Z.

Flash also has a complete set of RFCs, IENs and IETF working papers under
/pub/rfc, /pub/ien and /pub/ietf. All files are compressed with the unix
"compress" program.

This will hopefully be of interest to those on the east coast who would like
to help unload the cross-country ARPANET links.

Phil

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 19:50:48 GMT
From:      n2dsy@hou2d.UUCP (G.BEATTIE)
To:        comp.protocols.tcp-ip
Subject:   Asynchronous Framing Technique Software

The preceeding was brought to you by:

The Radio Amateur Telecommunications Society
206 North Vivyen Street 
Bergenfield, New Jersey  07621


Thanks,
            J. Gordon Beattie, Jr.
E-mail:    ihnp4!hou2d!n2dsy (Unix)  n2dsy@kd6th.a3100201.ampr
Telephone: 201-615-4168 (Office)     201-615-4669 (Office FAX)
Telephone: 201-387-8896 (Home)

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 20:55:00 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   MIL-STD vs. RFC

Recently, various people concerned with government RFPs have been
asking if my product conformed to the MIL-STDs.  I know the original
1983 MIL-STDs for IP and TCP, at least (1777 and 1778) were wrong (as
outlined in RFC 963 & 964).  I have no information which even hints
that they have been, or will be, corrected.  I have also been told by
authorities whose word I accept "where the RFCs and the MIL-STDs differ,
the RFCs are correct".

Accordingly, I have been telling these people "We conform to the RFCs,
and to the MIL-STDs to the extent that they are correct."  However, a case
has recently arisen where someone wanted more than just my word on it.
I gave them some people's names, and an organization or two.  At one of
the places they called, the person they spoke to (not someone closely
involved in Internet development) told them that they thought the
MIL-STDs superceded the RFCs.

Is there a document where the primacy of the RFCs is explicitly stated
(other than being implied in RFC 1011, "Official Internet Protocols")?
Is there an organization which I should direct these questions to?  A
person at that organization who considers it their business to answer
such, and is vested in some sort of formal authority that should be
accepted by the questioning parties?  I promise to only use it as a
last resort...

James VanBokkelen
FTP Software Inc.

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 21:00:48 GMT
From:      steiner@athena.mit.edu (Jennifer Steiner)
To:        comp.unix.wizards,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Kerberos documentation

Documentation on MIT Project Athena's authentication
service, Kerberos, is available for anonymous ftp on
"athena-dist.mit.edu", in ~ftp/pub/kerberos.

Documents include the paper given at the Winter 1988
Usenix Conference (text or postscript), a detailed
design document (text or postscript), and manual pages.

If you can't ftp, and would like a hardcopy, send your
request (and US/PTT mail address) to info-kerberos@athena.mit.edu.

We are currently running a beta test of the software.
When the beta test has been completed, we plan to put
the code in the public domain (except for the encryption
library, which probably can't be exported out of the U.S.).
I'll post a pointer when the code is available.

Please post any followup messages to comp.misc.

Jennifer Steiner
Project Leader, Kerberos Development
MIT Project Athena

--------

Below is the abstract from the Usenix paper:

In an open network computing environment, a workstation
cannot be trusted to identify its users correctly to network
services.  Kerberos provides an alternative approach whereby
a trusted third-party authentication service is used to verify
users' identities.  This paper gives an overview of the Kerberos
authentication model as implemented for MIT's Project Athena.
It describes the protocols used by clients, servers, and Kerberos
to achieve authentication.  It also describes the management and
replication of the database required.  The views of Kerberos as
seen by the user, programmer, and administrator are described.
Finally, the role of Kerberos in the larger Athena picture is
given, along with a list of applications that presently use
Kerberos for user authentication.  We describe the addition of
Kerberos authentication to the Sun Network File System as a
case study for integrating Kerberos with an existing application.

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 21:10:53 GMT
From:      mankin@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   TCP socket question

Hi,

Sockets are not really the provider of session service, though they
are the interface to the service.  And they don't provide a protocol.
For sockets to provide a session _protocol_ there would have to
be a session protocol data unit to be sent over TCP 
when establishing and tearing down the TCP connection.
But such a protocol is not defined separately in the DoD stack.  In
some ways, TCP contains its own session protocol, in the SYN and FIN
handshakes.  

It is a bug that 4.2 TCP connections can become ESTABLISHED and
receive data when the upper layer process is incapable of receiving
the data.  However, TCP has a good mechanism for dealing 
with the situation where its ULP does not consume the incoming data:  
it indicates a zero window to its TCP peer, which then must cease
to send, though it may send a periodic probe to see if the window has opened.

A TCP which has been given this zero window needs some way to throttle 
the process sending over it.  In UNIX, once the send queue gets filled
with the data that can't be sent, the system blocks further writes.  There
is no crash.  In your case, it looks like the Client sends an 11 byte message
that needs a reply from the Server, so the Client waits without being blocked.

The Recv-Q and Send-Q entries are in bytes.  The high-water mark is
an amount queued that determines when to indicate a zero window (receiving)
or block the write (sending).  The high-water mark is some multiple
of 1024, often 4096, depending on your version.  In 4.3 it is user-settable.

The file descriptor limit which caused your situation is
an implementation matter, nothing to do with the protocol definitions.
In 4.3, the fd limit went up to 100.  Even in 4.2-based systems,
one server can establish more than 26 simultaneous connections by
handing off the active sockets to children, then closing its own copies
of the file descriptors.

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 21:44:00 GMT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: MIL-STD vs. RFC

I  tell  you three times: "where the MIL-STDS and RFC's disagree,
the RFCs are correct".

The point  of  contact  for  standards  matters  is  Kevin  Ebel,
Ebel@DCA-EMS.ARPA, tell him I sent you *grin*.

Seriously  though - officially, the MIL-STDs superceded the RFCs,
however we (DCA and DCEC) are aware that the MIL-STDs  have  some
problems.  (Like IP not being able to deliver data to its ULP, or
was it TCP?  *grin*).  Our guidance has been to take the  average
of the RFCs and the MIL-STDs...  sort of...

Mike

(Umm,  if  you  get  guidance that is different than the above, I
would appreciate hearing details on who said it so I  can  either
get them or me straightened out.  )

I guess I ought to make it official:

Mike  StJohns,  Capt,  USAF,  DDN  Program, Defense Communication
Agency

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 21:59:31 GMT
From:      efb@nswed5.UUCP
To:        comp.protocols.tcp-ip
Subject:   BSD PING kills Mot/CMC card or code (Sys V.2)

We are using Motorola SYS-1131 (VME Bus) MC68020 host running Mot/AT&T
V68 / SysV 5.2.2 ( not going 5.3 for 30-90 days, problem may still be
there ).  We use the tcp-ip suite from CMC (2.1.5) telnet, ftp, rlogin,
rsh on the CMC enp-10 card ( believe onboard IP ) which DIES with the
daemon's still running, IMMEDIATELY, upon sending the PING packets from
my BSD Sun OS 3.3 (4.2).  I have muted ping and hasten to think what will
jump up next to hurt me.  Any tips / fixes will be well received.

[ To the '*you* should be running version xx of ' set, we are tax funded
operation and take anything we can get in whatever year Congress allows
us ( if ever ) to buy it.]  We have inbound ARPA Mail - ONLY.

 Everett F. Batey II         }   {UUCP:  sun!tsunami!nswed5!efb
 USNSWSES - Code 4V33        }   {ARPA:  efbatey@NOBBS.UCSB.EDU
 Blg 1214                    }   {       efbatey@[26.17.0.46]
 After   HOSTS.TXT.726                   efbatey@NSWSES.ARPA
 Port Hueneme,CA  93043-5007 }   {DDD:   805/982-5881 983-1220(ans)

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 88 23:14:02 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
To:        comp.protocols.tcp-ip
Subject:   Fibre local loops (was: Rumors about the... )


    Who do you know who has a 56k trunk in his home now?  I was talking
    about backbone connectivity (where the fiber is already laid),
    not local loop.
    
Actually, BOCs are starting to offer it for about $200/mo, plus mileage
or message unit charges.  If you know some tricks (like how to take
out an echo-supressor over a digital loop), you can get local digital
service fairly inexpensively.

    By the way, at least some local phone companies are providing local
    loop fiber now.  They figure it is more cost effective, considering
    growth and weather resistance.

I assume we are talking about business and not residential here.  A lot
of universities that have their own digital switches (MIT has a 5ESS
and McGill has a SL-1) have fibre loops at DS-1 or DS-3 rates.

-Philip 

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 88 04:01:02 GMT
From:      karels@OKEEFFE.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: release of updated network sources for 4.3BSD

How embarassing!  You're quite right about the byte-order problem
in ip_output when fragmenting, and your fix is exactly right.  Curiously,
I tested that between machines with two byte orders, but my home machine
now uses network byte order.  I guess I should go back to vaxen.

The inet.tar files on ucbarpa have been updated with the fix this evening.
(And yes, I tested it *both* ways this time.)

		Mike

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 88   10:30 CDT
From:      B32357%ANLVM.BITNET@CORNELLC.CCS.CORNELL.EDU
To:        TCP-IP @ SRI-NIC.ARPA
Subject:   BITNET mail follows
Date: 8 April 1988, 10:30:27 CDT
From: Linda Winkler             312-972-7236         B32357   at ANLVM
      Argonne National Laboratory
      Building 221 B-236
      9700 S. Cass Ave.
      Argonne, IL 60439
To:   TCP-IP   at SRI-NIC.ARPA


How does one disable IP forwarding?  I have a complex network
where a lot of hosts are sending UDP packets which other hosts
(non-gateways) relay to their default gateways.
Does anyone know where I can good write-up on routed?
LINDA
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 88 07:48:54 GMT
From:      gnu@hoptoad.UUCP (John Gilmore)
To:        comp.protocols.tcp-ip
Subject:   Shortest domain address in the world?

It seems to me that you (Johan Vromans) may have the shortest fully
qualified domain address in the world -- 8 characters:

	jv@mh.nl

Do you know of anyone with a shorter address?

	John Gilmore

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Apr 88 14:04:48 EDT
From:      "Alan R. Hill" <ahill@cc7.bbn.com>
To:        hpda!hpcupt1!hpcuhb!hpindda!dwall@ucbvax.berkeley.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: IP/X.25 Call User Data ...
	The field you are discussing is the protocol ID field and should
be set to the appropriate value for the protocol you intend to utilize.
The BBN PSNs currently support 0xCC for DDN Standard Service (Interoperable)
and 0xCD for ISO.

Alan

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 88 14:30:50 GMT
From:      milazzo@RICE.EDU (Paul Milazzo)
To:        comp.protocols.tcp-ip
Subject:   Re: The case for SLIP CRCs

Larry Swift asks:

   "Are you talking about checksums or CRC's?  They're not the same."

I'm not sure to which mention you refer, but I'll try to clear up any
ambiguities.  My original message discussed four distinct data
integrity tests, in the following order:

1) I used the phrase "link-level checking" to mean any data integrity
   test applied at the Data Link layer.

2) I used the phrase "UDP checksumming" to mean the IP header checksum
   algorithm as applied to UDP datagrams, with 0 meaning "no checksum".

3) I used the phrase "IP checksum algorithm" to mean the checksum
   algorithm described on p. 14 of RFC 791, applied to IP headers and
   TCP segments.

4) Finally, I used the phrase "link-level CRC" to mean any of the class
   of polynomial error-detecting codes known as Cyclic Redundancy
   Codes, applied at the Data Link layer.

Previous messages dismissed the need for Data Link layer integrity
tests with the argument that the existing TCP and UDP checksums provide
an end-to-end integrity test, and that with such a test, hop-by-hop
tests are unnecessary.  The point of my message was to question
RFC 791's description of the effectiveness of the IP header checksum
algorithm:  "experimental evidence indicates it is adequate".  MY
experimental evidence indicates otherwise.

I hope these clarifications answer your question.

                                Paul G. Milazzo <milazzo@rice.EDU>
                                Dept. of Computer Science
                                Rice University, Houston, TX

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 88 14:44:11 GMT
From:      rajaei@ttds.UUCP (Hassan Rajaei)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI does not mean X.25

In article <76.008873@adam.DG.COM> <LYMAN_CHAPIN%ICE9.CEO.DG.COM@adam.DG.COM> writes:
>
>Evidently there are still people who see "OSI" and hear "X.25" and
>"connections".  ** THIS IS NOT A VALID ASSUMPTION! **
>
>You can have OSI with a Transport protocol similar to TCP (ISO 8073)
>and a connectionless internetwork protocol (ISO 8473) even more similar
>to IP.  You do not have to have X.25.  You do not have to have PTTs.
>You do not have to have network connections.  There is NO part of OSI

I am really glad you mentioned this. There has been a confusion between
OSI model and X.25 protocol for a long time just because X.25 was the only
available implementation of OSI. 

The OSI model is so general that you may do any thing with it (except the
overhead!).  If there is not an standard protocol available for your need
within the model, that doesn't mean the model itself is incapabel of doing
that. In spite of many standard protocols available for OSI at present 
time, I believe we need many new ones in future even for the low layers
like physical, link and network.

The existing standars for low layers are incapable of handling the ultra
super speed networks of the future (FDDI can handle just 150 Mbps). The
same is true with X.25 and its IP X.75 which are not only limited by speed
but rather make the network very vulnerable because of their connection-
oriented behaviour throughout the network (internetworks). As Lyman Chapin
said the limitation is not in the model but in the protocols. 

There is much to be done for OSI model to be accepted (or rejected!) world
wide, both with new standard protocols and implementations. 


Hassan Rajaei
The Royal Inst. of Technology
Stockholm Sweden
rajaei@tds.kth.se

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 88 15:30:00 GMT
From:      B32357@ANLVM.BITNET
To:        comp.protocols.tcp-ip
Subject:   BITNET mail follows

Date: 8 April 1988, 10:30:27 CDT
From: Linda Winkler             312-972-7236         B32357   at ANLVM
      Argonne National Laboratory
      Building 221 B-236
      9700 S. Cass Ave.
      Argonne, IL 60439
To:   TCP-IP   at SRI-NIC.ARPA


How does one disable IP forwarding?  I have a complex network
where a lot of hosts are sending UDP packets which other hosts
(non-gateways) relay to their default gateways.
Does anyone know where I can good write-up on routed?
LINDA

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 88 17:58:00 GMT
From:      sandrock@uxc.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Checksums, CRC's, and NFS


RMS (Record Management Services) on VMS does a CRC on the entire file
both before and after it is transfered. We found this out the hard way
when we had a flakey UNIBUS adapter in our VAX/780 which caused most
large DECnet file transfers out our DEUNA to fail with the message that
the DAP level CRC check had failed. (DAP = Data Access Protocol). Would
have had a lot of bad data around without this check, since the network
itself was operating correctly and no other errors were ever reported.

Mark Sandrock, (sandrock@b.scs.uiuc.edu)

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 88 18:04:48 GMT
From:      ahill@CC7.BBN.COM ("Alan R. Hill")
To:        comp.protocols.tcp-ip
Subject:   Re: IP/X.25 Call User Data ...


	The field you are discussing is the protocol ID field and should
be set to the appropriate value for the protocol you intend to utilize.
The BBN PSNs currently support 0xCC for DDN Standard Service (Interoperable)
and 0xCD for ISO.

Alan

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 88 18:11:06 GMT
From:      murayama@CS.UCL.AC.UK (Yuko Murayama, 387-7050 ext.3695)
To:        comp.protocols.tcp-ip
Subject:   a question on the IEEE802.1 Part B


I have looked at Draft M of the IEEE Systems Management
standard (Jan.87) and wonder if there is any standard
scheme for coding the ManufacturerID which is described as

"a string of not more than 3 octets that identifies the
manufacturer".

Yuko Murayama

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 88 20:33:37 GMT
From:      narayan@tandem.UUCP (Narayan Mohanram)
To:        comp.protocols.tcp-ip
Subject:   Out of Band data in 4.3

In tcpinput, I noticed that there was support for SO_OOBINLINE. But
it has not been carried through to tcp_usrreq (). The case
PRU_RCVOOB, needs to create mbufs, and chain them on to the original
mbuf chain (m_copy) up to so_oobmark. This will cause soreceive
to do the right thing when it is doing an soreceive MSG_OOB. 

This fix does not seem to exist even in the new 4.3 updates recently
posted





THE SUPREME DALEK from SCAROS

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Apr 88 19:11:06 +0100
From:      Yuko Murayama (387-7050 ext.3695) <murayama@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Cc:        murayama@Cs.Ucl.AC.UK
Subject:   a question on the IEEE802.1 Part B

I have looked at Draft M of the IEEE Systems Management
standard (Jan.87) and wonder if there is any standard
scheme for coding the ManufacturerID which is described as

"a string of not more than 3 octets that identifies the
manufacturer".

Yuko Murayama
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 88 02:08:56 GMT
From:      droms@BKNLVMS.BITNET
To:        comp.protocols.tcp-ip
Subject:   Summary of responses to "NFS over the Internet"



I received enough requests for a summary of repsonses to my earlier
posting to warrant posting the summary to the net.  As Barry Shein
suggests, "the concept is not nearly as wild as [it might seem]".

- Ralph Droms
  Computer Science Department
  Bucknell University
  droms@bknlvms.bitnet

-----
From:   edu%"bhoward@sol.engin.umich.edu" 31-MAR-1988 13:46

at one point, i mounted hoser.berkeley.edu:/usr/src or /usr/src/X
(not certain anymore which) from sol.engin.umich.edu  this was last
summer and throughput was low, but it worked.  i don't recall doing
anything special, simply did a mount hoser:directory /n/hoser/directory

            bruce
-----
From:   EDU%"bzs%bu-cs.bu.edu@buita.BU.EDU"  1-APR-1988 04:48

As far as NFS over a serial line I tried it one evening over our 9.6Kb
Cypress line between BU and UCB. It really wasn't bad, NFS is not a
particularly high overhead protocol, the info being exchanged is
fairly similar to what gets exchanged in an FTP session (DIR,GET,PUT
etc.) Of course this disregards transmission problems which I didn't
seem to have that evening, the question was thruput.

It's probably an intuitive confusion that because NFS is so useful and
neat that it must therefore demand massive bandwidth (or perhaps
people are mixing the thought with ND, the diskless protocol?)

Doubtless you'd want your binaries local but as a very easy to use
"ftp" (eg. snooping around directories, copying stuff, file
management) it's really not bad on a relatively slow line in my
experience, perhaps a little slower than FTP but being able to use the
native OS interface to the remote file system can make it worthwhile.

Note that there are various timeout parameters etc that would need to
be tuned (can be set on a per mount basis) for smooth performance, but
the concept is not nearly as wild as seems to be presented here.

    -Barry Shein, Boston University
-----
From:   EDU%"pdb@SEI.CMU.EDU"  1-APR-1988 12:29

I've done it.  (I only lose on one qualification - I had it running between
two LANs, and the traffic had to cross the ARPANET to get between them.
But I administer both those LANs.)

--Pat.
-----
From:   edu%"hedrick@aramis.rutgers.edu"  1-APR-1988 17:19

We run NFS between departments all the time.  In different buildings
through 2 gateways.  We also know people who have mounted our disks
across the Arpanet, but this was done just as a hack, for a few
minutes.  Note that when we do it between our departments, we require
that all the departments involved coordinate their uid allocation,
since otherwise there are security problems.
-----
From:   NET%"roy%phri@uunet.UU.NET"  2-APR-1988 11:56

    I remember reading a while ago that Rob Liebschutz (liebschutz@ig.com
and/or liebschutz@bionet-20.arpa) and Mel Pleasant (pleasant@rutgers.edu) had
tried remote mounting an NFS file system at Intelligenetics in California from
Rutgers in New Jersey over the Internet.  Supposedly they had no problems.
You might try asking Rob or Mel for more details.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
-----
From:   EDU%"sy.Ken@CU20B.COLUMBIA.EDU" 30-MAR-1988 11:38

We use NFS disk mounts between here and another machine (the exact
whereabouts I can't tell you, but it's not on this campus), separated
by a T1 circuit.  Seems to work quite well, although is, of course,
a bit slower than you would get off the direct ether.

As for disjoint administrations, we are Columbia University, and the
disks we mount belong to the NYSER Network Information machine.

/Ken
-------
From:   EDU%"sy.Ken@CU20B.COLUMBIA.EDU" 30-MAR-1988 16:32

OK, well, that's not us, I guess...  however, the technical (mechanical)
aspects of such a hookup work well.  The NYSER disks look like real local
disks to us, and even with the distance separating us, we get pretty
decent response time.  Can't say anything about administrative aspects
concerning common roots and all that, though... /Ken
-------
From:   GOV%"cpw%sneezy@LANL.GOV" 30-MAR-1988 19:57

As a lark, I mounted an NFS filesystem in La Jolla, CA.  The linkage was:

[Client]-ethernet (Los Alamos, NM)
       |
    IP router -- ethernet
            |
             IP router -- 19.2 serial line -- IP router
                              |
                              ethernet - [File Server]
                                (La Jolla, CA)

By the way, one could consider this a security breach.  In fact one did,
after I told them about it.  This is a pet gripe of mine:  Sun ships their
systems WIDE OPEN, and its up to the user to shut them down.  I think it
should be the other way around.

wood, cornett philip  (cpw@lanl.gov)

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 88 17:10:31 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
To:        comp.protocols.tcp-ip
Subject:   Re: IP/X.25 Call User Data ...

I'm sure that Jon Postel already mentioned this but someone seems to
have missed it: The 0xCC in the Call User Data is required in RFC-877,
and mentioned in [I think] CSNET report DN-5.

-Philip

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 88 18:27:21 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
To:        comp.protocols.tcp-ip
Subject:   Re: Checksums, CRC's, and NFS

>>places (i.e. over noisy asynch lines)?? If important files get bit
>
>The point I was trying to make and a lot of people missed is:
>>An async line is not usually noisy. You do not have to
>>automatically put a CRC on it. You probably don't use a
>>CRC between your terminal and the TTY MUX on the host. That's
>>because it's not necessary in 99% of the cases.

Of course the DCE/DTE wire does not need line error detection.  It
doesn't have 50 volt ring signals in adjacent copper pairs or have
to travel through many relays, frequency boosters, or CODECs.  And
it is only a few meters long, not several kilometers.

>>The same holds true for async lines in general. They don't
>>normally have a noise problem. If you have a serious noise
>>problem, you shouldn't be using a simple async scheme. Buy a
>>paid of decent modems and let them do the work. (E.g.
>>today you can buy a pair of telebit trailblazers for $1345.)

When I was living in a dorm years ago, I had line noise every time
the compressor is someones refrigerator started.  Dial-up lines do
indeed have noise.  And I certainly didn't have $1300 to drop on
a modem either (the one I had was an AJ rep's demo model).

>If you need a special case for your special environment, fine. 
>However, don't claim that a protocol that doesn't have it is
>broken.

What the hell is wrong with a little robustness?  I think we can all
recount stories where a little builtin robustness has saved our
butts at unexpected times.  It might seem excessive now, but prove
invaluable later.

>No one seems to feel the need to put a CRC around the TCP/IP packet
>that is handed to the ethernet. Yet, given a broken ethernet board, you
>could be just as likely to have a corrupt packet as with SLIP without a
>CRC
>
>--rick

A computer's buss is hardly as hostile as a telephone line.  A mile of
copper pair is a great inductor in a thunderstorm...

-Philip

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Apr 88 01:17:15 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: computing network loads

> ... A token ring on the
> other hand can be very predictable in it's performance.

Until the token gets lost or corrupted, of course.
-- 
"Noalias must go.  This is           |  Henry Spencer @ U of Toronto Zoology
non-negotiable."  --DMR              | {allegra,ihnp4,decvax,utai}!utzoo!henry

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 88 09:31:00 PST
From:      "TERVAX::EFBATEY" <efbatey%tervax.decnet@nswses.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        efbatey
Subject:   Guide me to UU-PC
Thanks  .. yes I know this it the TCP-IP list for real communications ..
what list or center of wisdom might know where to find PC - UU_DOS (for
DEC RB-100+

 Everett F. Batey II         }           {UUCP:  sun!tsunami!nswed5!efb
 USNSWSES - Code 4V33        }           {ARPA:  efbatey@NOBBS.UCSB.EDU
 Blg 1214                    }           {       efbatey@26.17.0.46
   After HOSTS.TXT.726       }           {       efbatey@NSWSES.ARPA
 Port Hueneme,CA  93043-5007 }           {DDD:   805/982-5881
------
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 88 17:31:00 GMT
From:      efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY")
To:        comp.protocols.tcp-ip
Subject:   Guide me to UU-PC

Thanks  .. yes I know this it the TCP-IP list for real communications ..
what list or center of wisdom might know where to find PC - UU_DOS (for
DEC RB-100+

 Everett F. Batey II         }           {UUCP:  sun!tsunami!nswed5!efb
 USNSWSES - Code 4V33        }           {ARPA:  efbatey@NOBBS.UCSB.EDU
 Blg 1214                    }           {       efbatey@26.17.0.46
   After HOSTS.TXT.726       }           {       efbatey@NSWSES.ARPA
 Port Hueneme,CA  93043-5007 }           {DDD:   805/982-5881
------

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 00:58:47 GMT
From:      karels@OKEEFFE.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: Out of Band data in 4.3

You're wrong.  The case PRU_RCVOOB no longer has anything to do with
out-of-band data if SO_OOBINLINE is set.  As out-of-band data is never
removed from incoming packets, it is not stored in the protocol
and is not retrieved from there.  Calling recv with MSG_OOB with
the SO_OOBINLINE option set is wrong.

		Mike

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 09:49:30 GMT
From:      earle@mahendo.Jpl.Nasa.Gov (Greg Earle)
To:        comp.protocols.tcp-ip
Subject:   Domain name, domain name, what shalt thou be, domain name?

[ This is probably not the best place for this.  I couldn't come up with
  a better one, though, other than `Namedroppers'.  Apologies in advance ... ]

I have an interesting possible scenario, and would like to solicit suggestions
regarding choosing a domain to reside under.  To wit: 

Currently, I access the known Universe and my beloved Internet connection via
an account on this machine [mahendo.JPL.NASA.GOV].  Let's say I am about to
begin work for the `Moon' company.  The Moon company has a registered domain,
Moon.COM.  There are several sub-domains under Moon.COM, for simplicity's
sake let's choose geographically based ones - West.Moon.COM, East.Moon.COM, &c.
I will be provided with a machine in order to perform my job duties.  Under
ordinary circumstances, I could expect to name this machine `gregsbox', and
nestle comfortably under the name `gregsbox.West.Moon.COM' with an MX record
handled by Moon.COM.  On the other hand, say the loss of my Internet connection
proves too great to handle (*sniff*).  I then cajole the good folks at JPL who
administer the JPL.NASA.GOV domain into letting me set up a SLIP link with
them.  Now, this becomes easy, since JPL.NASA.GOV is neatly subdivided into
Class B subnets.  Merely by choosing a machine on the backbone net without
an existing subnet farm, a TrailBlazer SLIP link between the my machine and
somebackbonebox.JPL.NASA.GOV gets me onto a new JPL-Net subnet.  Thus, just
by running `routed' I become known to the rest of the world (by proxy) because
of their current subnet set-up.  So, if I chose, I could also easily nestle
into `gregsbox.JPL.NASA.GOV' with some Internet address containing 128.149.s.h.

In other words, from a *connectivity* and *network* standpoint, such a 
circumstance would point to being a member of the JPL domain.  But from an
*organizational* standpoint (i.e., who I *work* for), it would point to
staying inside the Moon.COM domain.

Given this scenario, how does one choose which domain to reside in?  N.B.:
I realize that with some point-to-point links such as this, that there are
plenty that retain the organizational-oriented domain name.  But given that
the network address would be one that is under JPL's network domain (i.e.,
`128.149' is JPL-Net's and JPL-Net's alone), I don't know how this would
affect this decision.  Any help?!?
-- 
	Greg Earle		earle@mahendo.JPL.NASA.GOV
	Indep. Sun consultant	earle%mahendo@jpl-elroy.ARPA	[aka:]
	(Gainfully Unemployed)	earle%mahendo@elroy.JPL.NASA.GOV
	Lake View Terrace, CA	...!{cit-vax,ames}!elroy!jplgodo!mahendo!earle

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 1988 16:58-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        martinea@SKL-CRC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: NFS Implementations
According  to  the  documentation I got with the uVax, ULTRIX 2.0
has NFS in it.  I'll admit I haven't tried it yet though.  Mike
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Apr 88 16:23:00 EDT
From:      Ed Kodinsky <KODINSK@MITVMA.MIT.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   TN3270 Source Code

I apologize for disturbing the whole net, but I would like to know
from where I might be able to a@obtain the public domain source code
for TN3270.  May I FTP it from si@ri or berkeley?

Thank you in advance for your help!

Ed
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Apr 88 18:30 CST
From:      <OWEN%AUDUCVAX.BITNET@CUNYVM.CUNY.EDU> (Larry Owen)
To:        tcp-ip@sri-nic.arpa
Subject:   mac-level bridges and internet addresses
Here's a real rookie question:

I know (or at least am laboring under the assumption) that all hosts
(connections) on a given physical network must (should?) use the same
network number in their internet address.  What about MAC-level bridges
(Lan Bridge 100's, Vitalink Translans, and the like)?  Are all ethernet
segments connected by these devices on a single net (for purposes of
internet addressing), or can each segment use a different network
(or subnet) number?

                                                Thanks in advance,

                                                Larry Owen
                                                Academic Computing Services
                                                Auburn University
                                                OWEN@AUDUCVAX.BITNET

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 14:00:09 GMT
From:      gnu@hoptoad.uucp (John Gilmore)
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums, CRC's, and NFS

mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) wrote:
> A gut feel is that a VRC/LRC combination for error detection is just as reliable
> as a CRC for detection of errors *and* saves 5 instructions per byte assuming
> the use of a CRC table.  

That would be nice for sending 8-bit data in 9-bit bytes, but we don't have
the vertical check bit except on tapes and other 9-bit media (or when sending
7-bit data).

If people are serious about fixing the checksums (sounds like a good
idea), howabout adding an IP option for full-packet 32 bit CRC?  Any
site could ignore the option, but at least all the ones that used it
would interoperate and check each others' checksums.  The first site,
gateway, or whatever that implemented the option would throw away a
packet whose CRC was bad.

That would not work when passed through gateways which modify the IP
options (e.g. source routing) but don't implement the CRC option.
Another option would be a CRC that protected only the user-data field,
relying on the IP header checksum for the header.  Not as good, but
easier to retrofit.
-- 
{pyramid,pacbell,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
  I forsee a day when there are two kinds of C compilers: standard ones and 
  useful ones ... just like Pascal and Fortran.  Are we making progress yet?
	-- ASC:GUTHERY%slb-test.csnet

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 16:00:34 GMT
From:      n2dsy@hou2d.UUCP (G.BEATTIE)
To:        comp.protocols.iso,comp.protocols.tcp-ip,rec.ham-radio.packet
Subject:   Asynchronous Framing Technique


OK Folks !

I have received several notes and messages about the
distribution of our software and documents via the net.
Let's understand a few basic points here:

ISSUE: I don'thave access to ftp to outside systems from hou2d.

If someone has such a package with source for a 3B1 and sends me a
DISK, I will get it going.  I think I can get a network connection
at NJIT, but I will entertain other offers.

ISSUE: Hate mail for using the net for distribution.

The response has been as follows:
2 mailer generated messages signalling error.
2 human generated messages saying No Good.
6 human generated messages saying Thanks.

I wished every comment I make on the net could fair this well!
One interesting note: one of the messages that said "Don't do
it" came from an individual who doesn't like AFT and is
PUSHING SLIP...

I will re-examine the distribution mechanism and see what makes sense.
I will probably forward out the code through "comp.protocols.iso"
in the future.  I will continue to send out documents and announcements
via several groups.

Comments?


Thanks,
            J. Gordon Beattie, Jr.
E-mail:    ihnp4!hou2d!n2dsy (Unix)  n2dsy@kd6th.a3100201.ampr
Telephone: 201-615-4168 (Office)     201-615-4669 (Office FAX)
Telephone: 201-387-8896 (Home)

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 88 00:31:00 PST
From:      "TERVAX::EFBATEY" <efbatey%tervax.decnet@nswses.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        efbatey
Subject:   Re 1200 PCs on PCNFS - NZ
Recently, I added some HP Vectras (semi-AT-Clones) with DEC 802.3 cards and
a previously very quiet ( even with RWHODs running ) ethernet, visiting
Sun_3, 2 Decnet MV_IIs, 3 DECSERVER-200s and a DELNI and I WAS DISAPPOINTED
by the traffic() reports.  The PC_802.3 cards, it is my surmise, being of
low iq, need several extra howdoyoudos to swap stories with the host than
I would find reasonable from a more costly host ..

I am sure from the last few days traffic here that someone has done some
good calculations.  All conventional wisdom I read / heard urges no more
than 20-40 Suns (vv PCs) on a leg (then a dual enet gateway).  While low
end pc's ask far fewer favors of their server .. generally .. smarter 386
type PCs and others based on type of load may be very burdensome.

Expect as many PCs could be served per leg BUT I'd do some serious data
gathering before trying over 30 PCs on one leg .. speculate that is do-
able based on connections allowed.  You might pass your question on to
our SoCal SUN List la-slug@{ elroy | jpl-mil }.JPL.NASA.GOV and to keves@
ucsd.edu.  Those are quite a few Sun people with some serious experience.

Sorry can't remember if la-slug is on elroy or jpl-mil.  /Ev/

 Everett F. Batey II         }           {UUCP:  sun!tsunami!nswed5!efb
 USNSWSES - Code 4V33        }           {ARPA:  efbatey@NOBBS.UCSB.EDU
 Blg 1214                    }           {       efbatey@26.17.0.46
   After HOSTS.TXT.726       }           {       efbatey@NSWSES.ARPA
 Port Hueneme,CA  93043-5007 }           {DDD:   805/982-5881
------
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 16:40:39 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: Domain name, domain name, what shalt thou be, domain name?


Greg Earle:

Domain names are totally independent of networks.  If the
JPL network manager was agreeable there is no reason you
couldn't have "gregsbox.West.Moon.COM" connected to 128.149.s.h.

--jon.

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 17:31:37 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
To:        comp.protocols.tcp-ip
Subject:   Re:  Domain name, domain name, what shalt thou be, domain name?

(I think you were right about namedroppers being more appropriate...)

Anyway, you are mixing apples and oranges.  A name (even a domain name)
can be arbitrarily bound to an address.  The fact that you are on JPL's
subnet has no bearing on what domain you put your host into...

-Philip

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 19:10:50 GMT
From:      bruce@cognos.uucp (Dwayne Bruce)
To:        comp.protocols.tcp-ip
Subject:   cmu-tcp

From nrcaer!gandalf!ml Wed Mar 30 22:36:11 1988
To: cognos!bruce
Subject: CMU-TEK TCP/IP and SLIP
Status: RO

Hi Dwayne, could you forward this to the appropriate newsgroup?



I have some comments and question about CMU-TEK TCP/IP for VMS.

I've been trying to get it connected to Amateur Packet radio using a
  PC as a gateway.  It works, but the CMU-TEK TCP/IP seems to have a
  very short (5sec) TCP segment timer.  This causes A LOT of unnecessary
  retransmit traffic on the packet radio link, and leads to even longer
  packet delays than would occur otherwise.  Can anybody think of a
  fix for this that doesn't involve modifying the source (we don't have
  a BLISS compiler!!).  The CMU-TEK TCP sets the high-reliability flag
  in the IP datagrams, which causes the gateway to use AX.25 connected
  mode rather than datagram mode, thus increasing packet delays.
  Again, I'd like to be able to tell it (VMS) the TOS.

Has anybody written a SLIP driver for the CMU-TEK TCP/IP that I could have?
  The ethernet card that I'm using on the PC is borrowed, and is overkill
  for our local packet radio network anyway!!

In case you haven't already guessed, the PC is running the KA9Q code,
  version 871225.12.

Thanx in advance
Marcus Leech
VE3MDL
...utzoo!dciem!nrcaer!gandalf!ml
VE3MDL@VE3JF



> Please reply to above, Marcus Does not have Usenet access.-- 
Dwayne Bruce                                     P.O. Box 9707
Cognos Incorporated                              3755 Riverside Dr.
VOICE:  (613) 738-1440   FAX: (613) 738-0002     Ottawa, Ontario
UUCP: decvax!utzoo!dciem!nrcaer!cognos!bruce     CANADA  K1G 3Z4

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 19:47:44 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Domain name, domain name, what shalt thou be, domain name?

>A name (even a domain name) can be arbitrarily bound to an address.
It is worth recalling one respect in which this is not quite accurate.

A typical site needs a simple way to generate an INADDR-ARPA database
from its name->address database.  A many-many map from SOA zones to
networks makes it hard to automate this generation.

I think it very undesirable to have lots of hosts with one authority
for their name->address translation and a different one for
address->name translation.  In some cases it's necessary, I suppose,
but the number of such hosts should be minimized so as to maximize the
modularity of the database.  A much cleaner scheme is to have a host's
real domain name directly depend upon its network number, and instead
have a pointer record in the other domain allowing an alias.  The
domain system as presently defined is sufficiently general to allow
both schemes; which one gets used becomes a question of taste and
pragmatics.

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 20:23:00 GMT
From:      KODINSK@MITVMA.MIT.EDU (Ed Kodinsky)
To:        comp.protocols.tcp-ip
Subject:   TN3270 Source Code


I apologize for disturbing the whole net, but I would like to know
from where I might be able to a@obtain the public domain source code
for TN3270.  May I FTP it from si@ri or berkeley?

Thank you in advance for your help!

Ed

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 22:24:32 GMT
From:      martinea@SKL-CRC.ARPA (Mike Martineau)
To:        comp.protocols.tcp-ip
Subject:   NFS Implementations



I am looking for NFS implementations (client, server, or both) 
which run on the following computing architectures:

	1.  VAX/VMS
	2.  VAX/UTLRIX
	3.  IBM PC (or clones)/MS-DOS
	4.  IBM PC (or clones)/XENIX
	5.  MacIntosh

If anybody is aware of any such implementations (either commercial
or public domain) could you please send me a mail message.  If there
is a sufficient number of replies I will summarize to the net.

Thanks,


Michael Martineau
Project Engineer
Software Kinetics Ltd.
Stittsville, Ontario, Canada

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 22:32:43 GMT
From:      jkrey@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: a question on the IEEE802.1 Part B

Yuko,

These are the same as the high order bits assigned to manufacturers
or other organizations by the IEEE when one acquires a block of
Ethernet addresses.  See RFC-1010, pages 12-15.

Joyce and --jon.

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 22:43:43 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  Domain name, domain name, what shalt thou be, domain name?

Note, though, that if your host name is `home.MegaCorp.COM' but is
really attached to `res.ear.ch.EDU', but the ch.EDU server does not
also serve for MegaCorp.COM, when MegaCorp.COM (or COM in general) is
unreachable, ch.EDU sites will not be able to figure out who you are.
Having experienced a miniature version of this situation (the official
UMD.EDU servers are one broadband-hop away from the Computer Science
Department cable, and the local construction folks like nothing better
than to cut through broadband cables while pretending to dig up parking
lots :-) ), where none of our `cs.umd.edu' machines could call any
`umd.edu' machines---which includes all our multi-user hosts---by
name.  (Fortunately, we still had call by address, if not by value :-) )

Chris

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 22:52:33 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  Domain name, domain name, what shalt thou be, domain name?

Oh dear, I just mailed a sentence fragment.  What I had meant to
say is that not being able to address your machines by name tends
to be an unhappy situation.

(Just look what happens when you allow yourself to be distracted
by grammatical arguments occurring in your office.  Bam, you send
off a letter chock full o' grammatical errors.)

Chris

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 88 23:58:00 GMT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: NFS Implementations

According  to  the  documentation I got with the uVax, ULTRIX 2.0
has NFS in it.  I'll admit I haven't tried it yet though.  Mike

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 88 00:30:00 GMT
From:      OWEN@AUDUCVAX.BITNET (Larry Owen)
To:        comp.protocols.tcp-ip
Subject:   mac-level bridges and internet addresses

Here's a real rookie question:

I know (or at least am laboring under the assumption) that all hosts
(connections) on a given physical network must (should?) use the same
network number in their internet address.  What about MAC-level bridges
(Lan Bridge 100's, Vitalink Translans, and the like)?  Are all ethernet
segments connected by these devices on a single net (for purposes of
internet addressing), or can each segment use a different network
(or subnet) number?

                                                Thanks in advance,

                                                Larry Owen
                                                Academic Computing Services
                                                Auburn University
                                                OWEN@AUDUCVAX.BITNET

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 88 02:54:26 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
To:        comp.protocols.tcp-ip
Subject:   Re:  Domain name, domain name, what shalt thou be, domain name?

(I will be happy to move this discussion to a more appropriate list, if you
wish to continue this "in public".)

	A typical site needs a simple way to generate an INADDR-ARPA database
	from its name->address database.  A many-many map from SOA zones to
	networks makes it hard to automate this generation.

IN-ADDR.ARPA records are undeniable a kludge and an afterthought.  It seemed
that the inverse query was implausible computationally for doing address to
name mappings.  There is no clean solution.  A mapping that is optimized in
one direction can be very hard to compute inversely (such as hashing).

	I think it very undesirable to have lots of hosts with one authority
	for their name->address translation and a different one for
	address->name translation.  In some cases it's necessary, I suppose,
	but the number of such hosts should be minimized so as to maximize the
	modularity of the database.  A much cleaner scheme is to have a host's
	real domain name directly depend upon its network number, and instead
	have a pointer record in the other domain allowing an alias.  The
	domain system as presently defined is sufficiently general to allow
	both schemes; which one gets used becomes a question of taste and
	pragmatics.

If JPL is willing to give him a subnet number, then handling address to
name translation as well shouldn't be putting them out.  What is "desirable"
and "clean" is not always convergent with what is necessary.  Creating "fake"
names to facilitate solutions is hardly a "clean" approach.

Having a host's name depend on its address is an intolerable restriction.
It completely negates the distributed capability of the domain name system.

In the example, you should be able to have:

$ORIGIN s.49.128.in-addr.arpa.
1		IN	PTR	(some name for 1)
2		IN	PTR	(some other name for 2)
...		IN	PTR	(...)
h		IN	NS	Some-Server.Sun.Com.
...		IN	PTR	(...)

in JPL's nameserver for s.49.128.in-addr.arpa and have it point to one
of Sun's nameservers and make it authorative for that particular host.
This would allow the "proper" administration of the name.  But as I said,
you could just as easily have JPL administer the mapping locally.

-Philip

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 88 07:25:12 GMT
From:      erik@retix.retix.COM (Erik Forsberg)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI does not mean X.25

In article <1157@ttds.UUCP> rajaei@ttds.UUCP (Hassan Rajaei) writes:
>I am really glad you mentioned this. There has been a confusion between
>OSI model and X.25 protocol for a long time just because X.25 was the only
>available implementation of OSI. 
>
>The OSI model is so general that you may do any thing with it (except the
>overhead!).  If there is not an standard protocol available for your need
>within the model, that doesn't mean the model itself is incapabel of doing
>that. In spite of many standard protocols available for OSI at present 
>time, I believe we need many new ones in future even for the low layers
>like physical, link and network.
>
>The existing standars for low layers are incapable of handling the ultra
>super speed networks of the future (FDDI can handle just 150 Mbps). The
>same is true with X.25 and its IP X.75 which are not only limited by speed
>but rather make the network very vulnerable because of their connection-
>oriented behaviour throughout the network (internetworks). As Lyman Chapin
>said the limitation is not in the model but in the protocols. 
>
>There is much to be done for OSI model to be accepted (or rejected!) world
>wide, both with new standard protocols and implementations. 
>
Please make a distinction between the OSI MODEL and the protocols
specified by ISO that implements services defined by the ISO model.

I don't think you can do anything with the OSI model. Just because
you invent your own protocol, which happens to provide some service
defined by the OSI model, doesn't really make this new protocol an
OSI protocol. There will be just confusion and interoperability problems
if every new protocol claims to be an "OSI protocol". Before it could
be considered as a protocol to be used to implement a service as defined
by OSI, it should become an ISO standard. Otherwise, it's not too useful
for the majority of the worlds data communications users.

Anyway, there certainly is a place for new protocols for new, higher
performing LAN technologies. But, even the existing ISO 8073/8473
protocol combinations are quite performing. (This is the ISO Class 4
Transport protocol operating over a connection-less network service,
almost identical with DoD IP). For example, by eliminating overhead
imposed by non-perfect hardware, this protocol combination has proven
able to have a substained transport layer user data throughput of more
than 2000 packets per second (each packet 1024 bytes) which is approximately
16 Megabits/second (this is measured on a VAX 8650). Now, if you add
some well-known, supposedly reasonable Ethernet controllers on an
otherwise idle Ethernet network, performance drops to a measly 60-180
packets per second, it is my opinion that controller hardware technology,
computer buses and software used to interface with the host operating
system needs some large improvements.

I do not understand why so many believes that X.25 is the only way to
implement OSI. It is certainly true that the european continent started
work in ISO, specifying the Connection-oriented network service as
examplified by X.25, but I think the US has been as successfull in
providing equally good protocols when Local Area Networks are
the primary technology of interest. Now, there are very reasonable
standards in how to inter-connect multiple Local Area Networks using
these venerable and perfectly working X.25's as provided by any Public
Data Network service provider (in most any country of the world).

One of the major problems is that there is no natural way to interoperate
between networks using ISO 8473 (IP) or ISO 8208 (X.25) as the network layer.
There will always be limitations when such attempts are made (there are
several proposals discussed as of this time).

-- 
----------------------------------------------------------------------------
Erik Forsberg, Retix, 2644 30th Street, Santa Monica CA 90405 (213) 399-2200
UUCP: {cepu,ttidca,rutgers,oliveb}!retix!erik, erik@retix.com

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 88 08:31:00 GMT
From:      efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY")
To:        comp.protocols.tcp-ip
Subject:   Re 1200 PCs on PCNFS - NZ

Recently, I added some HP Vectras (semi-AT-Clones) with DEC 802.3 cards and
a previously very quiet ( even with RWHODs running ) ethernet, visiting
Sun_3, 2 Decnet MV_IIs, 3 DECSERVER-200s and a DELNI and I WAS DISAPPOINTED
by the traffic() reports.  The PC_802.3 cards, it is my surmise, being of
low iq, need several extra howdoyoudos to swap stories with the host than
I would find reasonable from a more costly host ..

I am sure from the last few days traffic here that someone has done some
good calculations.  All conventional wisdom I read / heard urges no more
than 20-40 Suns (vv PCs) on a leg (then a dual enet gateway).  While low
end pc's ask far fewer favors of their server .. generally .. smarter 386
type PCs and others based on type of load may be very burdensome.

Expect as many PCs could be served per leg BUT I'd do some serious data
gathering before trying over 30 PCs on one leg .. speculate that is do-
able based on connections allowed.  You might pass your question on to
our SoCal SUN List la-slug@{ elroy | jpl-mil }.JPL.NASA.GOV and to keves@
ucsd.edu.  Those are quite a few Sun people with some serious experience.

Sorry can't remember if la-slug is on elroy or jpl-mil.  /Ev/

 Everett F. Batey II         }           {UUCP:  sun!tsunami!nswed5!efb
 USNSWSES - Code 4V33        }           {ARPA:  efbatey@NOBBS.UCSB.EDU
 Blg 1214                    }           {       efbatey@26.17.0.46
   After HOSTS.TXT.726       }           {       efbatey@NSWSES.ARPA
 Port Hueneme,CA  93043-5007 }           {DDD:   805/982-5881
------

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 88 15:01:00 GMT
From:      WWB.MDC@OFFICE-1.ARPA (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Packet level accounting in IP routers?

This is a multifaceted question, and I am asking "What do vendors have", "what 
do vendors think of doing this", "what is going on with protocol standards in 
this area, if anything", and "what philosophy of approach, design, policy, 
etc., should apply", with regard to the following issue:

In the not too distant future, there will be a direct cost associated with 
usage of MILNET, charged on a per-packet basis.  There is some perception that 
the same will be true of the operational Defense Research Internet, though I 
know of no official statements to this effect.  Whatever the case, the relevant
point is that there will apparently be a specific charge which will become part
of the cost base for contract pricing on certain common types of contracts.  
Those of you who are familiar with the arcana of government contracting will 
appreciate that these figures are auditable by various authorities, a fact 
which has a large number of serious implications.

Some people here see it as a problem that the use of a LAN and gateway to 
MILNET (or any net with similar charging algorithm) would result in a cost to 
the sponsor which, from the government side, cannot be allocated to specific 
projects, because the charging information will be generated on a per-port 
basis.  This is bad because a significant number of projects nowadays, and 
especially in the pipeline, are generating connectivity and data communication 
requirements of this type.  Thus there is a concern that if the traditional 
management approach (more or less dictated by audit considerations) is 
employed, it might be necessary to have one physical interconnection for each 
contract.  I trust it is not necessary to explain in complete detail why this 
is bad.  A large defense contractor (like this one) might end up having to have
tens or hundreds or thousands of interconnections.  Remember that there is also
to be a per-port charge, not to mention all the RFS, TSR, NCR, NCD, etc., 
paperwork that would have to be done.

On the other hand, shared gateways are much cheaper.  But at present it is not 
evident that there is a way of allocating cost for shared gateways which would 
be satisfactory to the government auditors.  The port used by the gateway would
have to be paid for by one service component, including charges attributable to
other programs which might be contracted with other components, or may be 
subject to different allowable pricing and cost recovery rules.

The perceived bottom line here is that there is an implicit requirement for 
packet-level accounting of IP traffic, and ultimately ISO IP traffic likewise, 
through such a multiple-use interface.  It isn't obvious to me how this can be 
solved completely right without protocol alterations, probably at the IP level 
- an accounting code IP option.  But I think that is politically infeasible.  
The existing protocols can be left intact if the accounting is done on the 
basis of source and destination IP addresses, and I think this may be an 
adequate solution.  However, this still requires some protocol development, as 
well as implementation work.

I imagine such an accounting scheme working in the following manner.  The IP 
router servicing the government network interconnection would extract 
source/destination (depending on direction) IP addresses and keep packet counts
and perhaps other counts tabulated on this basis.  At some interval it 
transmits these values to some configuration determined place or places where a
long-term accounting database is maintained.  This transmission would be 
formatted according to some protocol yet to be specified.  The target host of 
the transmission runs some server software which receives these transmissions 
and stores them in an accounting database, from which reports are developed as 
needed.

So, many questions suggest themselves:  Is anyone already doing this?  Is any 
vendor already selling IP gateways that provide such functionality, using this 
or any other design?  Is any vendor willing to volunteer to implement some 
simple scheme of this sort?  Is my design concept valid?  Does anyone have a 
better one?  Has anyone ever developed or published suitable protocols in the 
TCP/IP framework for communicating the accounting data?  ISO CLNS/GOSIP?  Has 
anyone gone through this issue with DCAA, local DCAS people, or other such 
authorities, and what did they say?  (etc.)

All sorts of relevant comments are solicited.

Thanks,
Bill Barns / McDonnell Douglas / Internet: WWB.MDC@OFFICE-1.ARPA

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 88 15:06:40 GMT
From:      martinea@SKL-CRC.ARPA (Mike Martineau)
To:        comp.protocols.tcp-ip
Subject:   Executable image of PC-IP


I am looking for an executable image of PC-IP for a 3-COM board
so that I can run the netwatch program.  I am short of disk space
and time to compile the PC-IP sources that I have.  Any help
would be greatly appreciated.  Please mail responses directly
to me.

Thanks.

Michael P. Martineau
Project Engineer
Software Kinetics Ltd.
Stittsville, Ontario, Canada

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 88 16:17:21 GMT
From:      map@GAAK.LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   mac-level bridges and internet addresses


   Date:     Mon, 11 Apr 88 18:30 CST
   From: <OWEN%AUDUCVAX.BITNET@CUNYVM.CUNY.EDU> (Larry Owen)
   X-Original-To:  tcp-ip@sri-nic.arpa, OWEN

   ...

   I know (or at least am laboring under the assumption) that all hosts
   (connections) on a given physical network must (should?) use the same
   network number in their internet address.  ...
This is not true.  We have an Ethernet here with hosts on both
18.0.0.0 and 128.30.0.0 without (many) problems.  However, the two
groups of hosts do not talk to one another.  This could be arranged in
several ways, but we don't have any need.  There is no conceptual
reason why one physical network cannot be several logical (sub-)nets.

	Mike Patton
	Network Hacker
	MIT LCS

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 88 19:22:12 GMT
From:      Doug_Nelson@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: mac-level bridges and internet addresses

Larry, to answer your question, a set of ethernet segments connected
by MAC level bridges is indeed one logical network for the purposes
of internet addressing.  We are running a large class B+ network
with 20 or so MAC bridges, spanning our entire campus.
 
Running the network this way certainly simplifies our local routing
problem.  It has its own headaches, but there are other benefits,
such as being able to run Decnet, etc., over the same wire.
 
Doug Nelson                     den@serv1.cl.msu.edu
Computer Laboratory             08071den@msu.bitnet
Michigan State University

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 88 22:57:11 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  mac-level bridges and internet addresses

>We have an Ethernet here with hosts on both
>18.0.0.0 and 128.30.0.0 without (many) problems.

One must be very careful when running multiple IP networks on the same
cable.  For example, it makes it much more likely that a misbehaving
gateway will cause a broadcast storm aka "meltdown."  Typical example:
suppose that 128.30.0.0 is 8-8 subnetted, and that subnet 128.30.3.0 is
on the shared cable.  Suppose also that both IP networks have gateways to
the arpanet or something.

Suppose some host on 128.30.3.0 sends an IP broadcast (as an Ethernet
broadcast) to its subnet broadcast address, say to 128.30.3.255.  A
gateway between 18.0.0.0 and the arpanet, say 18.0.0.1 (but NOT also
configured to be on 128.30.3.0), receives the packet, notes "this is a
packet for host 3.255 on net 128.30.0.0" (please observe that since
this gateway does not itself have any interfaces on 128.30.0.0, it
doesn't know what the subnet mask of that network is and hence can't
recognize this as a subnet broadcast), sends it to a gateway on
128.30.3.0, who explodes it onto the cable.  The first gateway gets
another copy, forwards that packet, etc.  As Chuck Hedrick noted in a
recent message to tcp-ip, it is essential that gateways pay attention
to whether the packet arrived as a media broadcast; unfortunately, many
gateways (e.g.  4.3BSD) do not.  A fortiori, unless you're willing to
also have gateways drop ALL packets sent as Ethernet broadcasts (which
I am not), or are willing to insist that any gateway on a physical
network know about all the nets on that cable (which I don't see how
you can do), you must also forbid topologies such as the one above.

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 88 01:51:33 GMT
From:      jcw@wdl1.UUCP (John C Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: Out of Band data in 4.3

Mike Karels,
  Adding a response unrelated to your response to someone else's article,
with the net listening in, I believe qualifies as indirect communication
--assuming this note comes to your attention.

  I can ping your hosts to death, but my mail comes bouncing back.  (This ought
to be a song!)

  Question (of possible interest to others): When is the book on UNIX BSD 4.3
Internals coming out?  Title, publisher, etc.?

Regards (and thanks for the net's indulgence),
John
jcw@ford-wdl1.arpa

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 88 02:25:36 GMT
From:      n2dsy@hou2d.UUCP (G.BEATTIE)
To:        comp.protocols.tcp-ip,comp.protocols.iso,rec.ham-radio.packet
Subject:   Asynchronous Framing Technique


/*
	Machine Independent Asynchronous Framing Technique (AFT)


            Version 1.0, by John Howell (N2FVN), Copyright August 7, 1987
               
            This software is free for non-commercial use.  All commercial
            rights are retained by the author or his designees.  Commercial 
            use without the explicit written permission of the author is
            prohibited.  This package is provided on an 'as is' basis 
            without warranty.
	

*/

		/* Macros */

#define	FLAG		0x007E
/* 
	This is the flag character which is used to start and end
	frames.  The send generates separate starting and ending flag
	characters, but the receiver can accept a single flag to end one
	frame and start another.
*/


#define	LEAD_IN		0x007D
/*
	This is the lead in character which is used when transparency is
	required.  When the receiver detects this character it takes the
	following character and exclusive ors it with 0x20 to produce
	the proper character.  This is used to allow the transmission of
	characters which would not otherwise be received properly.
*/


#define	TRANSPARENT(c)	(c ^ 0x20)
/*
	This is the function to be performed to convert a character into
	one which may be transmitted transparently.  This is also used
	to return a character to its original value since the function
	is its own inverse.
*/


#define	IDLE_CODE	(0x0100 + FLAG)
/*
	This is the idle code with is returned by aft_tx_char when it
	has no frame to send.  The high order byte indicates completion
	and the low order byte is a flag which might be sent if flags
	are to be used between frames as filler.
*/


#define	GENERATOR	0x8408
/*
	This is the generator polynomial for the frame check sequence.
	The polynomial is the standard CCITT polynomial.  It is in
	reverse bit order for faster calculation.  The polynomial is
	X**16 + X**12 + X**5 + 1.
*/


#define	EXPECT_FCS	0xF0B8
/*
	This is the expected final FCS for a correctly received frame.
*/


#define	OK		1
/*
	This is the return code used by some routines to indicate
	successful completion.
*/


#define	NO_GOOD		0
/*
	This is the return code used by some routines to indicate
	unsuccessful completion.
*/



/* Global declarations */


static char opt_ebdt;
/*
	This is a flag controlling the use of eight-bit data
	transparency on transmitted and receive frames.
*/


static char opt_transparency_level;
/*
	This is the transparency level to be used when transmitting
	frames (0-2).  Each increasing level causes more characters to
	be avoided when sending frames which allows them to be sent in
	situations where certain characters are not allowed.
*/


static char opt_suffix_len;
static unsigned char opt_suffix[3];
/*
	This is the suffix string to be added to the end of each frame
	sent.  Any character including a null is allowed.
*/


static unsigned int opt_max_rx_len;
/*
	This is the maximum size of a receive buffer.  It is used when
	receiving to make sure that a received frame does not go past
	the end of the buffer.  A received frame which is too long will
	be discarded.
*/

static unsigned char transparency_level [256] = {
	
	2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
	2, 1, 2, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 0, 0, 2,

	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
	9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9};
/*
	For each possible character this is the transparency level at
	which it should be encoded for transparency.  A value of nine is
	used for character which should never be encoded.
*/


		/* Variables and macros used by aft_tx_char */

static char tx_char_state;
/*
	This is the state of the transmission routine which handles
	transparency, delimiting of frames, and frame abort.  It is used
	to determine the next action to be performed by aft_tx_char when
	it is called.  State names are given by the 'TCS_' macros.
*/


#define TCS_IDLE		0
/*
	This state indicates that no frame is being sent.  Calls to
	aft_tx_char while in this state return the idle code and calls
	to aft_tx_complete return one.  This is the only state in which
	a call to aft_tx_start is valid.
*/


#define TCS_START_FLAG		1
/*
	This state indicates that the starting flag for a frame should
	be sent when aft_tx_char is next called.  This state is entered
	when aft_tx_start accepts a frame to be sent.
*/


#define TCS_GET_NEXT_CHAR	2
/*
	This state indicates that the next character to be sent should
	be gotten by calling tx_ebdt.  Before being sent the character
	will be checked against a table to see if a substitution is
	required.  If so then the current character is saved and a
	lead-in character is sent.
*/


#define TCS_SUBSTITUTE_CHAR	3
/*
	This state indicates that the next character to be sent is the
	encoded value of the current character.  This is used for
	transparency purposes.
*/


#define TCS_SUFFIX		4
/*
	This state is used when the closing flag has been sent to
	indicate the need to send any additional defined suffix
	characters at the end of the frame.  Once all suffix characters
	have been sent the transmitter returns to the TCS_IDLE state.
*/


#define TCS_ABORT_LEAD_IN	5
/*
	This state indicates that the caller has decided to abort the
	frame before it has been completely sent.  A lead in character
	followed by a flag will be sent to indicate that the receiver
	should discard the frame.
*/


#define TCS_ABORT_FLAG		6
/*
	The lead-in character has been sent to abort the current frame.
	A flag will be now sent to complete the abort sequence.
*/


static unsigned char tx_encode_char;
/*
	This is the character to be sent after it is encoded for
	transparency.  The value is saved here while waiting for
	aft_tx_char to be sent after it has returned the transparency
	lead-in character.
*/


static char tx_suffix_count;
/*
	This is a count of the number of suffix characters which have
	been sent so far at the end of the frame.
*/


		/* Variables and macros used by  tx_ebdt */

static char tx_ebdt_state;
/*
	This is the state of the eight bit data transparency routines.
	The value is actually a count of the number of characters which
	have each contributed their high order bit to the tx_ebdt_char.
	It is reset back to zero when the ebdt character is sent.
*/


static unsigned char tx_ebdt_char;
/*
	This is the character being built up from the high order bits of
	other characters during transmission when eight-bit data
	transparency is enabled.  This will be sent once either seven
	bits have been collected or the frame ends.
*/


		/* Variables and macros used by tx_data */

static char tx_data_state;
/*
	This is the state of the routines which get data from the
	transmit buffer, calculate the frame check sequence, and send
	the frame check sequence.  State names are given by the 'TDS_'
	macros.
*/


#define TDS_GET_FROM_BUFFER	0
/*
	This state indicates that the next character to be sent should
	be gotten from the transmit buffer.  The FCS is updated based on
	the character gotten.  Once all characters from the buffer have
	been sent the FCS will be sent.
*/


#define TDS_FCS_ONE		1
/*
	This state indicates that sending of characters from the buffer
	has completed and that the next character to be sent is the
	first half of the frame check sequence.
*/


#define TDS_FCS_TWO		2
/*
	This state indicates that the first half of the FCS has been
	sent and so the second half should be sent next.
*/


#define TDS_COMPLETE		3
/*
	This state indicates that sending of the FCS is complete.
*/



static unsigned char *tx_buffer;
static unsigned int tx_len_remaining;
/*
	tx_buffer is a pointer to the next character to be sent from the
	transmit buffer provided by the caller of aft_tx_start.  It is
	incremented as each character is used from the buffer.  The
	length remaining field is decremented as each character is used.
	When it reaches zero all characters from the supplied buffer
	have been sent and FCS transmission may begin.
*/


static unsigned int tx_fcs;
/*
	This is the two bytes of the frame check sequence (FCS) to be
	sent at the end of the frame being transmitted stored in reverse
	bit order for easier transmission.  The FCS is initialized to
	all ones before the frame is transmitted.  As the frame is sent
	the FCS is calculated using the algorithm specified in CCITT
	X.25 using each character as it is obtained from the transmit
	buffer.
*/


		/* Variables and macros for aft_rx_char */

static unsigned char rx_char_state;
/*
	This is the state of the main reception routine.  It is used to
	determine the next action performed by aft_rx_char when it is
	called.  State names are given by the 'RCS_' macros.
*/


#define RCS_IDLE			0
/*
	This state indicates that no buffer has been provided for
	reception.  Received characters are ignored while in this state.
*/


#define RCS_START_FLAG			1
/*
	This state indicates that a buffer has been provided to the
	receive routines and we are waiting to receive the opening flag
	for a frame.  Non-flag characters will be ignored in this state.
*/


#define RCS_AWAIT_NEXT_CHAR		2
/*
	This state indicates that the opening flag has been received and
	characters are being received into the frame buffer.  If the
	character received is the ending flag then the frame size and
	FCS are verified otherwise the chracter is passed to the
	eight-bit data transparency routine for processing.
*/


#define RCS_AWAIT_SUBSTITUTE_CHAR	3
/*
	This state indicates that we have received a lead in character
	and are now expecting another character which will decoded and
	sent to the EBDT routines.  If the character received is a flag
	then this indicates that the sender is aborting the frame so it
	should be discarded.
*/


static int rx_ebdt_state;
/*
	This is the number of characters received since the last eight
	bit data transparency character.  This will reach eight when the
	next EBDT character is received.  If the frame ends with this
	count non-zero then the character just received is the EBDT
	character for a group of less than seven bytes.
*/


static unsigned char rx_ebdt_save[7];
/*
	This array is used to buffer a maximum of seven characters when
	eight bit data transparency is being used.  When the EBDT
	character is received then each saved character is modified to
	have the correct eighth bit and transferred to the receive
	buffer.
*/


static unsigned char *rx_buffer;
/*
	rx_buffer holds the pointer to the start of the receive buffer.
*/


static int rx_len, rx_final_len;
/*
	rx_len is the number of characters received so far in the
	current frame.  rx_final_len is initialized to zero and set to
	the final frame length once the frame has been completely
	received.
*/


static unsigned int rx_fcs;
/*
	This is the two bytes of the receive frame check sequence stored
	in reverse bit order.  It is calculated as characters are
	received using the same method as that used for tx_fcs.  At the
	end of the frame this must match the expected value or the frame
	is invalid.
*/






aft_options(	o_ebdt, o_transparency_level, 
		o_suffix_len, o_suffix, o_max_rx_len)

char o_ebdt;			/* Eight-bit data xparency (nonzero) */
char o_transparency_level;	/* zero to two */
char o_suffix_len;		/* zero to three */
char o_suffix[3];		/* suffix string to be sent */
int  o_max_rx_len;		/* size of rx buffers */
{
	int count;		/* Suffix character count */

	/* Initialize internal state variables */

	tx_char_state = TCS_IDLE;

	rx_char_state = RCS_IDLE;
	rx_final_len = 0;

	/* Save selected options */

	opt_ebdt = o_ebdt;
	opt_transparency_level = o_transparency_level;
	opt_suffix_len = o_suffix_len;
	
	for (count = 0; count < sizeof(opt_suffix); count++)
		opt_suffix[count] = o_suffix[count];

	opt_max_rx_len = o_max_rx_len;
}



int aft_tx_start(length, buffer)

unsigned int length;		/* length of the buffer */
unsigned char *buffer;		/* buffer pointer */
{

	/* Only allow if transmitter is idle and frame is valid */

	if ((tx_char_state != TCS_IDLE) || (length < 2))
		return NO_GOOD;

	/* Set internal state variables for transmission */

	tx_data_state = TDS_GET_FROM_BUFFER;

	tx_buffer = buffer;		/* Save pointer to next char */
	tx_len_remaining = length;

	tx_fcs = 0xFFFF;		/* Set all FCS bits to one. */

	tx_ebdt_state =			/* No EBDT char being built */
	tx_ebdt_char = 

	tx_suffix_count = 0;		/* No suffix characters sent yet. */

	/* 
		Now that all is ready the state can be changed.  This
		could not be done before since aft_tx_char might have
		been called before setup was complete.  It is assumed
		that since the state is a 'char' it can be assigned
		while interrupts are enabled since it will be changed
		with a single write to memory.

		The state is set so that the starting flag will be the
		next character sent.
	*/

	tx_char_state = TCS_START_FLAG;

	return OK;			/* successful return */
}



int aft_tx_char()
{
	int c;		/* The character to be sent */

	/*
		This routine is responsible for returning each character
		to be sent over the communication line.  It handles
		generation of starting and ending flags, data
		transparency, suffix character generation, and frame
		abort generation.  tx_ebdt is called to determine data
		characters to be sent.
	*/

	switch (tx_char_state) {

		case TCS_IDLE:
			c = IDLE_CODE;
			break;

		case TCS_START_FLAG:
			/*
				We are starting to send out a new frame.
				Send out the starting flag before any
				data.
			*/
			c = FLAG;
			tx_char_state = TCS_GET_NEXT_CHAR;
			break;

		case TCS_GET_NEXT_CHAR:
			c = tx_ebdt();		/* Get next character */

			if (c == IDLE_CODE) {
				/*
					The entire frame has been sent.  
					Delimit with a flag.
				*/
				c = FLAG;

				if (opt_suffix_len > 0)
					tx_char_state = TCS_SUFFIX;
				else
					tx_char_state = TCS_IDLE;
			}
			else {
				if (transparency_level[c]
				    <= opt_transparency_level) {
					/*
						This character cannot be 
						sent.  Use transparency.
					*/
					tx_encode_char = c;
					c = LEAD_IN;
					tx_char_state = TCS_SUBSTITUTE_CHAR;
				}
			}
			break;

		case TCS_SUBSTITUTE_CHAR:
			c = TRANSPARENT(tx_encode_char);
			tx_char_state = TCS_GET_NEXT_CHAR;
			break;

		case TCS_SUFFIX:
			c = opt_suffix[tx_suffix_count++];

			if (tx_suffix_count >= opt_suffix_len)
				tx_char_state = TCS_IDLE;

			break;

		case TCS_ABORT_LEAD_IN:
			c = LEAD_IN;
			tx_char_state = TCS_ABORT_FLAG;
			break;

		case TCS_ABORT_FLAG:
			c = FLAG;
			tx_char_state = TCS_IDLE;
	}

	return c;
}


static int tx_ebdt()
{
	int c;				/* Character to be returned */

	/*
		This routine handles eight-bit data
		transparency.  If enabled the high order bit of
		each character returned by tx_data is removed
		and added to an eight-bit data transparency
		character.  Once this character has collected
		seven bits or the frame ends this character is
		sent.  Doing this allows the receiver to recover
		the high order bits from the previous characters
		sent.
	*/

	if (!opt_ebdt) {
		/*
			If eight bit data transparency is not being 
			used then this is just a pass through.  If 
			this option is never used then this routine 
			may be completely eliminated for efficiency.
		*/
		c = tx_data();
	}
	else {
		if (tx_ebdt_state == 7) {
			/*
				There is a full collection of seven 
				high order bits ready to be sent.
			*/
			c = tx_ebdt_char;
			tx_ebdt_char =
			tx_ebdt_state = 0;
		}
		else {
			c = tx_data();

			if (c != IDLE_CODE) {
				/*
					Append the high order bit from 
					the character to be sent to the 
					EBDT character.
				*/

				tx_ebdt_char = (tx_ebdt_char << 1) + 
							((c & 0x80) != 0);

				c = c & 0x7F;
				tx_ebdt_state++;
			}
			else {
				/*
					The end of the frame has been 
					reached.  If there have been any 
					high order bits collected then 
					send one last EBDT character.
				*/
				if (tx_ebdt_state != 0) {
					c = tx_ebdt_char << 
						(7 - tx_ebdt_state);

					tx_ebdt_char =
					tx_ebdt_state = 0;
				}
				else {
					c = IDLE_CODE;
				}
			}
		}
	}
 return c;
}


static int tx_data()
{
	int c;				/* Character to be returned */
	char tx_bits, bit_count;	/* For FCS calculation */

	/*
		The next character is obtained from the transmit 
		buffer and the FCS calculated.  Once all character 
		from the buffer have been sent, the FCS is also sent.
	*/

	switch (tx_data_state) {

		case TDS_GET_FROM_BUFFER:

			c = *(tx_buffer++);

			/* FCS calculation */

			tx_bits = c;
			for (bit_count = 0; bit_count < 8; bit_count++) {
				if ((tx_fcs ^ tx_bits) & 1)
					tx_fcs = (tx_fcs >> 1) ^ GENERATOR;
				else
					tx_fcs = tx_fcs >> 1;
				tx_bits = tx_bits >> 1; 
			}

			if (--tx_len_remaining == 0)
				tx_data_state = TDS_FCS_ONE;

			break;

		case TDS_FCS_ONE:
			/*
				Send the first character of the
				frame check sequence.  The bits
				are inverted before sending.
			*/
			c = (~tx_fcs) & 0x00ff;;
			tx_data_state = TDS_FCS_TWO;
			break;

		case TDS_FCS_TWO:
			/*
				Send the second character of the
				frame check sequence.  The bits
				are inverted before sending.
			*/
			c = (~tx_fcs) >> 8;
			tx_data_state = TDS_COMPLETE;
			break;

		case TDS_COMPLETE:
			c = IDLE_CODE;
			break;
	}

	return c;
}


aft_tx_abort()
{
	/*
		If aft_send_char is being called from within an
		interrupt service routine and this routine is
		intended to be used then interrupts must be
		disabled when this routine is called.

		The current state is changed to cause an abort
		sequence to be sent to receiver.
	*/

	switch (tx_char_state) {

		case TCS_START_FLAG:
			tx_char_state = TCS_IDLE;
			break;

		case TCS_GET_NEXT_CHAR:
			tx_char_state = TCS_ABORT_LEAD_IN;
			break;

		case TCS_SUBSTITUTE_CHAR:
			tx_char_state = TCS_ABORT_FLAG;
			break;

		default:
			break;
	}
}


int aft_tx_complete()
{
	return (tx_char_state == TCS_IDLE);
}



int aft_rx_start(buffer)
unsigned char *buffer;
{
	/*
		Provide a buffer to start receiving the next
		frame into.  If we are already receiving then
		the request is rejected.
	*/

	if (rx_char_state != RCS_IDLE)
		return NO_GOOD;

	/*
		Save the pointer to the buffer and set up for receive.
	*/

	rx_buffer = buffer;

	aft_rx_error();		/* Reset the receive routines */

	rx_char_state = RCS_START_FLAG;

	return OK;
}


aft_rx_error()
{
	/*
		Return to the condition of waiting for the starting flag.  
	*/

	rx_len =
	rx_final_len =
	rx_ebdt_state = 0;

	rx_fcs = 0xffff;

	if (rx_char_state != RCS_IDLE)
		rx_char_state = RCS_START_FLAG;
}


int
aft_rx_complete()
{
	return rx_final_len;
}


int aft_rx_char(c)
unsigned char c;
{

	/*
		Add the next character to the receive buffer
		depending on the current state.
	*/

	if (opt_ebdt) {
		/*
			Ignore the high order bit of the
			character if it cannot be received
			transparently.
		*/
		c = c & 0x7f;
	}

	switch (rx_char_state) {

		case RCS_IDLE:
			/*
				If no buffer has been provided
				then ignore characters.
			*/
			break;

		case RCS_START_FLAG:
			/*
				In this state we are hunting for
				a flag.  If this is a flag then
				the receive operation may begin.
			*/

			if (c == FLAG)
				rx_char_state = RCS_AWAIT_NEXT_CHAR;

			break;

		case RCS_AWAIT_NEXT_CHAR:

			if (c == LEAD_IN) {
				rx_char_state = RCS_AWAIT_SUBSTITUTE_CHAR;
			}
			else {
				if (c == FLAG) {

					rx_finish_ebdt();

					/*
						If the frame is
						too short or the
						FCS is not
						correct then the
						frame is
						discarded.
					*/

					/* For FCS */
					rx_final_len = rx_len - 2; 

					if (rx_final_len >= 2 && 
					    rx_fcs == EXPECT_FCS)
						rx_char_state = RCS_IDLE;
					else
						aft_rx_error();
				}
				else {
					rx_ebdt(c);
				}
			}
			break;

		case RCS_AWAIT_SUBSTITUTE_CHAR:
			/*
				Handle the character which
				follows a lead-in character.  If
				it is a flag then this is a
				frame abort and so the frame is
				ignored.  Otherwise translate
				the character and add it to the
				buffer.
			*/

			if (c != FLAG) {
				rx_ebdt(TRANSPARENT(c));
				rx_char_state = RCS_AWAIT_NEXT_CHAR;
			}
			else {
				aft_rx_error();
			}
 break;
	}

	return rx_final_len;
}



rx_ebdt(c)
unsigned char c;
{
	int bit_count;

	/*
		This routine handles received characters which
		have passed the normal substitution process.  It
		handles the eight-bit data transparency by
		saving characters until the transparency
		character is detected and then adding the
		correct high order bit to each of the
		characters.
	*/
	if (!opt_ebdt) {
		rx_data(c);
	}
	else {

		if (rx_ebdt_state >= 7) {
			
			for (bit_count = 0;
				(bit_count < 7) &&
				(rx_ebdt_state != 0);
				bit_count ++) {

				c = c << 1;
				rx_data(rx_ebdt_save[bit_count] | 
					(c & 0x80));
			}

			rx_ebdt_state = 0;
		}
		else {
			rx_ebdt_save[rx_ebdt_state++] = c;
		}
	}
}


rx_finish_ebdt()
{
	unsigned char c;
	int bit_count;

	/*
		This routine finishes any pending EBDT conversion
		when the end of the frame is detected.
	*/

	if (opt_ebdt && rx_ebdt_state > 0) {
		c = rx_ebdt_save[--rx_ebdt_state];

		for (bit_count = 0;
			(bit_count < rx_ebdt_state) &&
			(rx_ebdt_state != 0);
			bit_count ++) {

			c = c << 1;
			rx_data(rx_ebdt_save[bit_count] | 
				(c & 0x80));
		}

		rx_ebdt_state = 0;
	}
}


rx_data(c)
unsigned char c;
{
	int bit_count;
	unsigned char rx_bits;

	/* FCS calculation */

	rx_bits = c;
	for (bit_count = 0; bit_count < 8; bit_count++) {
		if ((rx_fcs ^ rx_bits) & 1)
			rx_fcs = (rx_fcs >> 1) ^ GENERATOR;
		else
			rx_fcs = rx_fcs >> 1;

		rx_bits = rx_bits >> 1; 
	}

	if (rx_len == opt_max_rx_len) {
		aft_rx_error();
	}
	else {
		*(rx_buffer + (rx_len++)) = c;
	}
}

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 88 02:31:24 GMT
From:      davew@gvgpsa.GVG.TEK.COM (David C. White)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Looking for users of David Systems equipment

The following is posted on behalf of the systems manager in our
corporate MIS group.  I also have concerns about this equipment
because their system is being proposed for the T1 link to the
new building we are moving into late this summer and the MIS
telecommunications person is pushing it real hard even though
it only does 1.2Mbit/sec over twisted pair.  I've never heard
of the company, so if anyone has any direct experience with this
equipment of knows anything about it, I certainly would appreciate
hearing from you.
------------------------------------------------------------------
The company is:

David Systems, Inc.
701 East Evelyn Avenue
Sunnyvale, California 94086

The product is David Information Manager.  The main unit is called a 
David Manager, and you connect David-Sets (telephones with the ethernet,
and RS232 connections on them) to it via, are you ready for this, the
David-Link (a twisted pair of wires).  The questions I have are:

o  Is anybody using all three, telephone, RS232, and ethernet modes at
   one station?  Especially any type of high traffic station like a
   VAX/VMS or UNIX workstation?

o  Then there is the question about the T1 bridge part.  Is anybody 
   using it?  And especially is anybody using use the multiple T1
   bridge capability?  The David Manager can handle multiple T1 circuits.
   The question is if you use three T1 circuits do you get 9 MBits/second
   throughput?


-- 
Dave White	Grass Valley Group, Inc.   PHONE: +1 916.478.3052
P.O. Box 1114  	Grass Valley, CA  95945    davew@gvgpsa.gvg.tek.com

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Apr 88 08:33:00 EDT
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        Bill Barns  <WWB.MDC@office-1.arpa>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Packet level accounting in IP routers?
Bill,

Regarding packet-level accounting, and the auditability of shared
gateway connections, etc.:

There's an alternative approach, that I heard suggested by a
(technically-oriented, not contract or financial) Government
official.  That is to consider the cost of the network attachment
to be part of the corporation's infrastructure or overhead -- an
indirect cost -- like any utility.  That actually seems like a
pretty good idea.  After all, an indirect cost is one that you
incur that benefits a number of contracts, and is such that you
can't reasonably allocate it directly among those contracts.
Electricity typically fits that bill; some companies allocate
phone service to contracts, while some consider it an indirect
cost; ditto with postage.  So it's probably not unreasonable to
consider the cost of being attached to the Internet an indirect
cost that you bear in order to be "in the business".  (I'm sure
all of our contracts and legal people would have opinions on
this; I'll bet they mostly don't read TCP-IP though!)

Ken Pogran
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 88 12:33:00 GMT
From:      pogran@CCQ.BBN.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting in IP routers?

Bill,

Regarding packet-level accounting, and the auditability of shared
gateway connections, etc.:

There's an alternative approach, that I heard suggested by a
(technically-oriented, not contract or financial) Government
official.  That is to consider the cost of the network attachment
to be part of the corporation's infrastructure or overhead -- an
indirect cost -- like any utility.  That actually seems like a
pretty good idea.  After all, an indirect cost is one that you
incur that benefits a number of contracts, and is such that you
can't reasonably allocate it directly among those contracts.
Electricity typically fits that bill; some companies allocate
phone service to contracts, while some consider it an indirect
cost; ditto with postage.  So it's probably not unreasonable to
consider the cost of being attached to the Internet an indirect
cost that you bear in order to be "in the business".  (I'm sure
all of our contracts and legal people would have opinions on
this; I'll bet they mostly don't read TCP-IP though!)

Ken Pogran

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 88 14:47:47 GMT
From:      garrett@udel.EDU (Joel Garrett)
To:        comp.protocols.tcp-ip
Subject:   tn3270 for WIN/TCP 3.x...

Is there some implementation of tn3270 available for VMS systems running
WIN/TCP?  I guess if there is some source available for a BSD 4.3 tn3270
it might run under Eunice 4.3 BSD, but is there som
ething available that will
compile under VAX C using only the stuff that comes with stand-alone WIN/TCP?

					Thanks in advance,
					Joel Garrett
					Research Associate
					CCM
					University of Delaware
					Newark, DE  19716

					garrett@udel.edu

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 88 15:18:36 GMT
From:      glenn@XN.LL.MIT.EDU (Glenn Adams)
To:        comp.protocols.tcp-ip
Subject:   SLIP working group?


>   It's straightforward to turn on UDP checksumming
>   on a Sun, at worst you can fault them for not making it easier:
 
>	   % adb -w -k /vmunix /dev/mem
>	   udpcksum?W 1
>	   $q

Perhaps someone has pointed it out already, but Sun's NFS doesn't
use the standard udp_output() routine which allows enabling checksums
via the udpcksum variable.  Instead, they chose to bypass udp_output(),
building UDP packets in ku_fastsend() (/sys/rpc/kudp_fastsend.c).  This
routine has no provision for enabling checksums such as does udp_output().

I rewrote ku_fastsend() for Sun 3.2, but haven't done so for recent Sun
releases, primarily because I don't have the more recent sources.  I think
we should make a lot of noise to Sun to at least code in checksumming
similar to udp_output(), giving the system manager the decision to enable
or disable checksums.  By the way, performance tests which I performed
on my modified ku_fastsend(), indicated that the addition of checksumming
only resulted in a 2% decrease in performance.  I don't believe they (SUN)
have actually tried it as they won't provide any data to back up their claim
that checksumming is a big performance loss.

Personally, I think Sun's decision to exclude checksums is quite
unconscionable.

Glenn Adams

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 88 16:54:48 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting in IP routers?

In article <MDC-WWB-DH962@OFFICE-1> WWB.MDC@OFFICE-1.ARPA (Bill Barns) writes:

>requirements of this type.  Thus there is a concern that if the traditional 
>management approach (more or less dictated by audit considerations) is 
>employed, it might be necessary to have one physical interconnection for each 
>contract.
> [...]
>On the other hand, shared gateways are much cheaper.  But at present it is not 
>evident that there is a way of allocating cost for shared gateways which would 
>be satisfactory to the government auditors.  The port used by the gateway would
>have to be paid for by one service component, including charges attributable to
>other programs which might be contracted with other components, or may be 
>subject to different allowable pricing and cost recovery rules.
>
>The perceived bottom line here is that there is an implicit requirement for 
>packet-level accounting of IP traffic, and ultimately ISO IP traffic likewise, 
>through such a multiple-use interface.

	I don't agree with the premise that government accounting
requires separate physical connections per contract.

	I assume that we are speaking of separate departments within
your company, each of which has one or more separate contracts with
separate charging, either fixed price or cost plus.

	You say that the auditors require per-packet charging to
fairly allocate costs. Do they require each dept to pay a separate
rent or to install separate phone systems or to buy their own
furniture and pencils?  They do not.

	Network costs could be set up as an overhead charge.  Links to
outside networks like the internet are flat rate and this cost could
be allocated to each dept based on a formula.  The only trick if there
is one is the formula, but every organization has a formula for
allocating basic telephone service with cost-per-message added on as
needed [long distance billing, for example].  So long as your formula
approximately distributes actual costs to all departments and only
recovers actual costs and a share of other overhead, it should be
acceptable to auditors.

	If MILnet goes to packet charging, and I don't see how they
can do it, those costs could still be approximately redistributed
according to a formula based on number of nodes, type of nodes, etc.

	[flame on]  There is absolutely no reason that network access
charges should be packet based.  It makes no sense on a local area
network like Ethernet and no sense in a packet internet.  Users will
not understand the charges (as well as contract auditors) and you
won't be able to justify them.  "Well, let's see your diskless
workstation used 45k NFS packets last month."  "What do you mean, all
I did was read netnews!"

	Local area networks do not cost you on a per-packet basis and
you don't need to recover on a per-packet basis.  Per packet only
works on (virtual) terminal networks, networks of the past.  [flame
off]

	Kent England, Boston University

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 88 20:29:27 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting in IP routers?

In article <21618@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:
>	[flame on]  There is absolutely no reason that network access
>charges should be packet based.  It makes no sense on a local area
>network like Ethernet and no sense in a packet internet.  Users will
>not understand the charges (as well as contract auditors) and you
>won't be able to justify them.  "Well, let's see your diskless
>workstation used 45k NFS packets last month."  "What do you mean, all
>I did was read netnews!"
>
>	Local area networks do not cost you on a per-packet basis and
>you don't need to recover on a per-packet basis.  Per packet only
>works on (virtual) terminal networks, networks of the past.  [flame
>off]

I can't believe I'm about to argue for the grey suits, but here
it is.

It costs a certain amount of money to install/maintain an ethernet.
Ethernet's have a certain maximum number of packets they can
pass over a period of time.  That ratio gives you a first guess
at the cost per packet.

The same holds true for some phone line which is being rented from
the phone company which gives you 9600bps or 56k or t1 or whatever.
That phone line costs x, you can do at most y through the line, so
x/y gives you a cost per packet.

The place where it's more obvious is a net that DOES charge per
packet, like I understand X.25 nets do.  As was pointed out rather
eloquently from a gentleman in Australia, a charge per packet gives
a different style of protocol than not having the charge.
-- 
<---- David Herron -- The E-Mail guy            <david@ms.uky.edu>
<---- or:                {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<----
<---- I don't have a Blue bone in my body!

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 88 21:04:44 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?

Hey, we all know that SUN is just a hardware company.  We gotta figure where
we can get the source and fix it ourselves.

phil wood (cpw@lanl.gov)

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 01:24:44 GMT
From:      donegan@stanton.TCC.COM (Steven P. Donegan)
To:        comp.protocols.tcp-ip
Subject:   Re: mac-level bridges and internet arg

In article <8804120427.AA11751@ucbvax.Berkeley.EDU>, OWEN@AUDUCVAX.BITNET (Larry Owen) writes:
> I know (or at least am laboring under the assumption) that all hosts
> (connections) on a given physical network must (should?) use the same
> network number in their internet address.  What about MAC-level bridges
> (Lan Bridge 100's, Vitalink Translans, and the like)?  Are all ethernet
> segments connected by these devices on a single net (for purposes of
> internet addressing), or can each segment use a different network
> (or subnet) number?
> 
In our network (at the physical cable level) there are many different network
protocols, internet addresses etc. I don't see any reason to force any one
protocol or internet address (anyone with any horror stories?). We have a
continuously growing number of sites connected via MAC level bridges and
have had no problems getting any ethernet device from any vendor to cross the
'boundaries'. So my experience shows that:

A) You do not HAVE to use the same internet address (or protocol) on a single
   physical media.

B) You do not HAVE to use different internet addresses for different segments
   connected via a MAC level bridge.

C) For management purposes you may WANT to implement different internet prefixes



-- 
Steven P. Donegan
Sr. Telecommunications Analyst
Western Digital Corp.
donegan@stanton.TCC.COM

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 01:26:44 GMT
From:      donegan@stanton.TCC.COM (Steven P. Donegan)
To:        comp.protocols.tcp-ip
Subject:   Re: Executable image of PC-IP


Michael, I have a copy of the PC/IP binaries for the 3-COM 3c501 board. If
that is what you need drop me a line and let me know.
-- 
Steven P. Donegan
Sr. Telecommunications Analyst
Western Digital Corp.
donegan@stanton.TCC.COM

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Apr 88 11:27:10 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Mike Muuss <mike@BRL.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   "... and statistics" (Re: [Phil Dykstra: more interesting numbers] )

I think the Internet community would be better served if you could compare
these gateways in some way.  I want to point out that the LSI11 gateways on
the arpanet/milnet border will drop packets and count them for reasons other
than congestion, such as '1822 host dead' or 'net unreachable'.  Also the
"average" throughput is a measure of packets actually offered over the course
of the day or week reporting period, so that 10 packets per second really
means 864,000 packets in one day, not that the machine is somehow limited to
10 packets per second.  While I can cite higher numbers over the 15 minute
periods the statistics are sampled, both for arpanet-milnet gateways, and more
so for ethernet-ethernet gateways, that still is a measure of handling offered
load rather than limitation.  There is also no indication whether the packets
are long and saturate the communication lines, or short and saturate the
gateway processor.

Specifically on the msg from phil@brl...

     Some recently obtained per node averages for gateways:

     The seven BBN ARPA/MILNET Core gateways:
        10.04 packets/sec       5.78 % drop rate

(These gateways connect 2 wide area packet switch nets which have 56 kb and
9.6 kb lines.)

(As a comparison, here are 2 lsi11 gateways' statistics from yesterday)
(               tot sent    avr/sec(day)    peak/sec(15min) drop(day) )
(MILBBN          1.5e6       19.61           34.30             2.01%  )
(CORPE(lan-lan)  1.4e6       18.16           50.01             0      )

     The NSFNET Backbone "Fuzzball" gateways:
        15.55 packets/sec       0.18 % drop rate

(These 5(?) gateways connect to each other with 56 kb lines.)

     The Bld 394 BRL gateway:
        ~20 packets/sec         ~0.8 % drop rate


I would also look for more pleasing statistics from the arpa/mil gateways now
that the processors have all been upgraded from dec lsi 11/23 to 11/73.

Mike Brescia
BBNCC Gateway Development Group
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Apr 88 11:59:44 -0400
From:      satlas@PARK-STREET.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA
Cc:        satlas@PARK-STREET.BBN.COM
Subject:   Processor Upgrade of LSI-11 Mailbridges Complete

  On Tues (4/12/88) MILSRI gateway was upgraded to an 11/73 processor.
This completes the upgrade of all Mailbridges and EGP servers to
11/73s.  Many thanks to Bob Enger for finding hardware donors and for
coordinating the installation effort.  Also thanks to the following
people for the donation of processors and memory.

Phil Karn      Bellcore                7 processors
Paul Pomes     U of Illinios           1 processor 3 memory boards
Bob  Enger     Contel                  1 processor 3 memory boards
Dan Tappan     BBN                     1 processor 1 memory board
Bill Nesheim   Thinking Machines       1 processor 1 memory board
Mike Petry     U of Maryland           2 processors

  The upgrade has made a dramatic change in the performance of these
gateways and should help all of us who use the INTERNET.

   Dates of Upgrade 

   GATEWAY   DAY    
   ------------------

   BBN2      11/09/87
   PURDUE    11/18/87
   ISI       11/23/87
   MILDCEC   11/23/87
   YUMA      01/12/88
   AERO      01/13/88
   MINET     03/22/88
   MILBBN    03/22/88
   MILSAC    03/29/88
   MILISI    03/30/88
   MILARPA   03/31/88
   MILLBL    04/06/88
   MILSRI    04/12/88

Stephen Atlas
BBNCC







-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 07:45:05 GMT
From:      mike@BRL.ARPA (Mike Muuss)
To:        comp.protocols.tcp-ip
Subject:   [Phil Dykstra:  more interesting numbers]


----- Forwarded message # 1:

Received: from brl-smoke.arpa by SEM.BRL.ARPA id aa10255; 31 Mar 88 21:59 EST
Received: from brl-spark.arpa by SMOKE.brl.ARPA id aa16517; 31 Mar 88 21:55 EST
Date:     Thu, 31 Mar 88 21:45:08 EST
From:     Phil Dykstra <phil@BRL.ARPA>
To:       datacom@BRL.ARPA
Subject:  more interesting numbers
Message-ID:  <8803312145.aa04086@SPARK.BRL.ARPA>

Some recently obtained per node averages for gateways:

The seven BBN ARPA/MILNET Core gateways:
	10.04 packets/sec	5.78 % drop rate

The NSFNET Backbone "Fuzzball" gateways:
	15.55 packets/sec	0.18 % drop rate

The Bld 394 BRL gateway:
	~20 packets/sec		~0.8 % drop rate

The vast majority of our dropped packets are comming from the
currently sick Proteon Ring, so this value would normally be
much lower.

The 394 gateway is currently handling over 1.5 Million packets/day.
The 328 gateway is probably similar.  [I will have better data for
BRL in a few weeks.]

That's a lot of packets!

- Phil

----- End of forwarded messages

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 09:17:22 GMT
From:      dp@nwyrkr.UUCP
To:        comp.protocols.tcp-ip
Subject:   A poem

THOUGHTS ON THE DEMISE OF THE ARPANET

The Arpanet is going away,
Hey, nonny, hey, hey, hey,
We'll miss you, boys,
But that's OK.

You need your dollars,
Your hardware too,
To build the network
That's right for you.

So take your IMPS,
Your TACS and spares,
Your long-haul lines,
Your other wares,

Go back to the Pentagon,
Close your doors,
Come up with something
That costs us more.

And when you're finished
Sit back and smile.
Yes, our defenses 
Are right in style.

Truly, colonels,
It's good to know
That soc.singles
Has room to grow.

	-- dorothy parker

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 11:38:08 GMT
From:      rath@tuvie (Rath Martin)
To:        comp.sys.mac,comp.protocols.tcp-ip
Subject:   Need TCP/IP for MacII, HELP !!!


We URGENTLY need TCP/IP software for a Mac II with an EtherTalk Card.
The most probfable candidate would be NCSA Telnet V2.1e. Maybe some
kind soul could send it to us (binhexed). 

Thanks a lot !!!  

Martin Rathmayer, TU Vienna, EDP-Center

		      				MAIL: rath@tuvie.uucp

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 13:31:49 GMT
From:      gross@GATEWAY.MITRE.ORG (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re:  [Phil Dykstra:  more interesting numbers]

Mike, Phil,

Fascinating numbers.  Do we understand why the mailbridges have such a
higher drop rate?  

Until recently, of course, the 7 mailbridges were still clunky old LSI
11/23's.  That would account for some performance difference since I
believe the NSFnet Fuzzies are 73's.  However, the IETF Adopt-A-Core-Gateway
program finally caught up to the mailbridges a couple weeks ago, so they
should all be 73's now too.  What is the date for your numbers?

Or is it that the mailbridges (indeed all core gateways) simply spend too
much time processing routing updates and not enough time forwarding
packets.  Almost half the core traffic seems to be routing updates.  That
means for every other packet, the gateway has to go off and spend cycles
thinking about something besides packet forwarding.  (Oh where are those
Butterflies?)

Phill Gross

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 14:51:00 GMT
From:      zweig@uiucdcsp.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting in IP route


Who pays for the packets containing the accounting information?

(Seriously. I see lots of ovrhead with this scheme, and even gov't
auditors should know that everyone would rather pay according to a
possibly unfair approximate formula than pay (fairly) for the overhead
of a weird scheme with per-packet charges all over the place.)

Johnny Zweig
Univ. of Ill. at Urbana-Champaign
Dept. of Computer Science
(generic standard vanilla disclaimer...)

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 15:19:27 GMT
From:      garrett@udel.EDU (Joel Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 for WIN/TCP 3.x...

I've received quite a few requests for any response I get on TWG's support
for tn3270.  I've tried sending mail to the people who asked, but our local
mailer has bounced most of the attempts, so I'll just post my findings here.

I talked with several people at TWG yesterday afternoon and came up with
the following information:

Yes, the current release of Eunice does have tn3270, but I don't think it is
the version that supports VM/XA.

They said that there probably wasn't a way to get the Eunice executable to
run with the runtime executive that comes with WIN/TCP (REX) either.

However, they did say that they would be including tn3270 with WIN/TCP v3.3
which should be out sometime this summer. (I know, 3.2 isn't even out yet,
but they said that should be out in May)  In the meantime I guess we'll all
just have to go through some intermediate machine which does support tn3270.

					Hope this info helps,

					Joel

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 15:27:10 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   "... and statistics" (Re: [Phil Dykstra: more interesting numbers] )


I think the Internet community would be better served if you could compare
these gateways in some way.  I want to point out that the LSI11 gateways on
the arpanet/milnet border will drop packets and count them for reasons other
than congestion, such as '1822 host dead' or 'net unreachable'.  Also the
"average" throughput is a measure of packets actually offered over the course
of the day or week reporting period, so that 10 packets per second really
means 864,000 packets in one day, not that the machine is somehow limited to
10 packets per second.  While I can cite higher numbers over the 15 minute
periods the statistics are sampled, both for arpanet-milnet gateways, and more
so for ethernet-ethernet gateways, that still is a measure of handling offered
load rather than limitation.  There is also no indication whether the packets
are long and saturate the communication lines, or short and saturate the
gateway processor.

Specifically on the msg from phil@brl...

     Some recently obtained per node averages for gateways:

     The seven BBN ARPA/MILNET Core gateways:
        10.04 packets/sec       5.78 % drop rate

(These gateways connect 2 wide area packet switch nets which have 56 kb and
9.6 kb lines.)

(As a comparison, here are 2 lsi11 gateways' statistics from yesterday)
(               tot sent    avr/sec(day)    peak/sec(15min) drop(day) )
(MILBBN          1.5e6       19.61           34.30             2.01%  )
(CORPE(lan-lan)  1.4e6       18.16           50.01             0      )

     The NSFNET Backbone "Fuzzball" gateways:
        15.55 packets/sec       0.18 % drop rate

(These 5(?) gateways connect to each other with 56 kb lines.)

     The Bld 394 BRL gateway:
        ~20 packets/sec         ~0.8 % drop rate


I would also look for more pleasing statistics from the arpa/mil gateways now
that the processors have all been upgraded from dec lsi 11/23 to 11/73.

Mike Brescia
BBNCC Gateway Development Group

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 15:59:44 GMT
From:      satlas@PARK-STREET.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Processor Upgrade of LSI-11 Mailbridges Complete


  On Tues (4/12/88) MILSRI gateway was upgraded to an 11/73 processor.
This completes the upgrade of all Mailbridges and EGP servers to
11/73s.  Many thanks to Bob Enger for finding hardware donors and for
coordinating the installation effort.  Also thanks to the following
people for the donation of processors and memory.

Phil Karn      Bellcore                7 processors
Paul Pomes     U of Illinios           1 processor 3 memory boards
Bob  Enger     Contel                  1 processor 3 memory boards
Dan Tappan     BBN                     1 processor 1 memory board
Bill Nesheim   Thinking Machines       1 processor 1 memory board
Mike Petry     U of Maryland           2 processors

  The upgrade has made a dramatic change in the performance of these
gateways and should help all of us who use the INTERNET.

   Dates of Upgrade 

   GATEWAY   DAY    
   ------------------

   BBN2      11/09/87
   PURDUE    11/18/87
   ISI       11/23/87
   MILDCEC   11/23/87
   YUMA      01/12/88
   AERO      01/13/88
   MINET     03/22/88
   MILBBN    03/22/88
   MILSAC    03/29/88
   MILISI    03/30/88
   MILARPA   03/31/88
   MILLBL    04/06/88
   MILSRI    04/12/88

Stephen Atlas
BBNCC

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 17:03:27 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  [Phil Dykstra: more interesting numbers]

Phil, et al,

From Mike Minnich's data presented at a recent IAB meting and other
sources such as the LSI-11 reports issued by BBN, I suspect Phil's
numbers are total aggregate and include ICMP and routing overheads.
As you point out, between 40 and 60 percent of all mailbridge traffic
is overhead, while the NSFNET backbone overhead is much lower. While
the NSFNET backbone fuzzballs do use the 11/73, they are memory
limited, not CPU limited. I would be surprised if this were not the
case for the mailbridges, at least those using the 11/73. As reported
in the SIGCOM 87 paper and in another submitted to SIGCOM 88, I would
like to believe the difference in drop rates is due to the design of
the NSFNET backfuzz selective-preemption and source-quench schemes.

Dave

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 18:08:28 GMT
From:      smb@ulysses.homer.nj.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP working group?

Has anyone modified the SLIP driver to do ``fair queueuing''?  SLIP links
are sufficiently slow that a file transfer operation can make remote logins
exceedingly unpleasant.  A queuer that favored short packets, or perhaps
one that did per-hostport queueing, would be helpful.  (I know -- what I'm
really asking for is type-of-service support, but then I'd have to change
all of my applications, and perhaps my TCP/IPs, to request it.)


			--Steve Bellovin
			ulysses!smb
			smb@ulysses.att.com

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 88 20:55:16 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  "... and statistics" (Re: [Phil Dykstra: more interesting numbers] )

Folks,

Further to Mike Brescia's comments, the mailbridges are connected to
virtual-circuit networks that may have some pretty stiff ideas on
flow control, while the NSFNET backfuzz are connected only to each other
via DDCMP serial lines and to Ethernets at each site. While the mailbridges
can get beat up rather badly if some j-random host or gateway keels, the
backfuzz can get blown up by a co-Ether Cray. My point is that the (seven)
NSFNET critters face a quite different environment than the mailbridges
and each may have predominantly different drop mechanisms. Nevertheless,
I continue to think that engineered selective-preemption, source-quench
and priority queueing disciplines could help improve mailbridge service
in significant ways and (you saw this coming) consideration for these
issues should be incorporated into their successors, both of the LSI-11
mailbridges and the NSFNET backfuzz.

Dave

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 00:40:31 GMT
From:      mike@BRL.ARPA (Mike Muuss)
To:        comp.protocols.tcp-ip
Subject:   Re:  "... and statistics" (Re: [Phil Dykstra: more interesting numbers] )

The BRL Gateway mentioned in Phil's message is a DEC PDP-11/70 running
the BRL-GATEWAY software under the LOS operating system.  It has
3 InterLan Ethernet interfaces, one ProNet-10 ring interface, one
ProNet-80 ring interface, and two ACC LH/DH-11 1822 interfaces, one
running to MILNET IMP 29 via a 480,000 bps ECU link, and the other
directly to BRLNET IMP #1.  This is BRL-GATEWAY #1;  gateway #2 is
similar, with a substitution of a Hyperchannel for the ProNet-80,
and only 1 Ethernet.  The remaining 6-7 gateways on our campus are
much simpler (typically a ProNet-10, an LH/DH, and an ethernet), and
are built on smaller processors (11/24, 11/34, 11/44).

The rates mentioned were average rates, intended merely to give folks
some impression of the levels of inter-building traffic on our campus.
We have measured 200 packets/sec as the maximum switching rate of our
gateways, when link-limiting is not a factor (ie, using Ethernet or
ProNet on both sides of the gateway when testing).  This is a round-trip
measure, ie, each packet traverses an interface in the gateway 4 times
(we use FLOODPING for this statistic). Many would prefer to claim this
as a peak rate of 400 packets/sec (2 interface traversals per "packet",
counting the ping responses as a second packet) -- we would say "400
monodes/sec" in this case.

This is not an attempt to put down the work of others, merely to report
on behavior of older gateways at BRL.  Clearly, the new commercial gateways
have performance several times higher than this, and clearly, it is not
a sensible idea to consider the purchase of PDP-11/70 systems for use
as gateways.  However, it makes a nice retirement job for our old friends,
the 11/70s.

Also, note that our campus is "traffic rich", with two Cray computers
(a Cray X-M/P48 and a Cray-2) that talk TCP/IP, and with 6 Alliant FX/8
super-minis, along with over 100 other machines, many of which exchange
high resolution 24-bit-deep color graphics images over the network on a
regular basis.

	Best,
	 -Mike

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 02:31:40 GMT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: [Phil Dykstra: more interesting numbers]

> Almost half the core traffic seems to be routing updates.

How true is that statement? The stats I have seen come from core
gateways. Hardly a representative sample. Ignoring mailbridge traffic,
one expects "real" traffic to go to and from "hosts", where hosts are
non-core gateways to LANs, NSFnet, etc.  An interesting statistic is
last week's traffic stats for the purdue LSI-11 EGP core server:

GWY         RCVD           RCVD     IP       % IP         DEST   % DST
NAME        DGRAMS         BYTES    ERRORS  ERRORS       UNRCH   UNRCH
PURDUE   7,184,830 1,097,986,642       101   0.00%      27,954   0.39%

GWY         SENT           SENT    DROPPED    % DROPPED
NAME        DGRAMS         BYTES   DGRAMS        DGRAMS
PURDUE   7,557,696 1,424,771,755    24,090        0.32%

That's an average of 11.9 and 12.5 pps respectively. The funny thing
is, Purdue directs all its traffic out through its Butterfly gateway;
the only Purdue traffic traveling through the LSI-11 would be
misrouted packets.

If we assume that an EGP connection exchanges one hello/I-H-U packet
every 60 seconds, and one fragmented and one unfragmented NR update in
place of a hello/I-H-U every 180 seconds, one expects 9 EGP packets
every 180 seconds, 4 to the LSI, 5 from it. In addition, if we (over)
estimate the number of EGP peers the 11 maintains at 260, egp traffic
accounts for 260*(4/180) = 5.8 pps RCVD, 260*(5/180) = 7.2 pps SENT.
Certainly GGP doesn't consume the remaining 5 pps.  Who is responsible
for the remaining traffic?

Thomas Narten

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 03:07:54 GMT
From:      rhorn@infinet.UUCP (Rob Horn)
To:        comp.protocols.tcp-ip
Subject:   SLIP CRC's and other reliability

The practical engineering decision that CRC's are needed is based
upon: assumptions about how SLIP will be used, assumptions about the
environment that it will be used in, and cost (time, money, etc.)
assumptions.  To restate the often discovered and forgotten: IP
checksums are mostly a network performance optimization.  Transmission
errors that escape IP checksums usually escape TCP and vice versa.
(Note: I am already assuming that those concerned with reliability use
TCP.  This is only 95% correct.)  So adding checksums to SLIP must be
justified on network performance, not error detection.

My concern is error detection.  I think Rick Adams major mistake
is in assuming that SLIP will only be used over voice channels,
hence using modems.  The errors characteristic of voice channel +
modem are dropouts and random error bursts.  A checksum is almost
as good as a CRC at detecting these, so TCP works well.

My assumption is that SLIP will be used over not only voice
channels, but also muxes of many kinds, data PBX's, etc.  The
errors characteristic of these are dropouts, random error bursts,
duplications, and transpositions.  Checksums are very vulnerable
to transpositions.  Any even stride byte transposition will
escape detection.  Much more serious, TCP will probably also fail
to detect it.  I have experienced such errors with checksummed
links through failing multiplexors.

I think that a failure which escapes TCP is very serious and an
option to detect it is very important.  CRC's will catch
transpositions.  I only ask that CRC be available as a checking
option.  I see no need to burden a simple system with LAPB or
whatever.  If the CRC fails, just trash the packet.  The cost of
this is minor:  a few days programming and a few instructions per
byte.

If you look at costs further, a more cost effective way to
enhance reliability is forward error correction (FEC).  Instead
of retrying, spend cycles to fix damaged packets without retry. 
This is worthwhile whenever the incremental cost of FEC is less
than the cost of retransmission.  For a small system, time is
what counts.  Ten thousand instructions is nothing when compared
to a retransmission.  For a multi-user host, the tradeoff is not
obvious.

I have been contemplating a two-way interleaved (255,253)
Reed-Solomon FEC with assumed nulls for message length matching. 
This code would fix:
  a) any single erroneous byte
  b) any two erroneous bytes with odd stride (including
     transposition)
Other errors would result in either incorrect fixes or error
detection.  The incorrect fixes will trigger TCP checksum error
detection, including transposition cases.  My first complexity
estimate is that this FEC would take about twice as much CPU as a
16-bit CRC (for undamaged packets) and would add 32 bits of FEC
per 506 bytes of message instead of 16 bits of CRC.  More robust
FEC's exist if someone has good data on what errors need
correction.  This FEC alone will make a very big difference to a
marginal voice or asynch digital channel.  It can be cheaper than
the cost difference between an error correcting modem and a
normal modem to let the CPU spin a dozen extra instructions per
byte.

I have implemented LAPB on asynch and I think that FEC+IP+TCP
would be faster, more reliable, and less software.

-- 
				Rob  Horn
	UUCP:	...harvard!adelie!infinet!rhorn
		...ulowell!infinet!rhorn, ..decvax!infinet!rhorn
	Snail:	Infinet,  40 High St., North Andover, MA

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 03:28:17 GMT
From:      jonathan@comp.vuw.ac.nz (Jonathan)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.os.minix
Subject:   advice wanted: Ethernet cards for IP/TCP + Minix

I need some advice on Ethernet boards and free (cheap?) TCP/IP
implementations for IBM PC/AT clones. Source for the TCP is a must.
The background is as follows:

Some graduate students here are starting projects to implement IP/TCP
over Ethernet on Minix.  We currently have a couple of XT clones with
3C501 (3Com Etherlink) Ethernet boards, and source for PC/IP. We are
sure that these will work together, though we have not yet installed
PC/IP.

We are about to get some more hardware for this project: AT clones
(commodore PC-40s) and some kind of Ethernet boards.  We have found
local suppliers for two boards: 3c505 (3Com Etherlink+), and a Western
Digital board.  PC/IP does not have drivers for these cards.  We also
know KA9Q (sp?) exists, but don't know what cards it has drivers for.

Does anyone know of drivers for these TCP implementations for either board?
Also, could anyone comment on which boards (or software) would be
least troublesome for  Minix?

One specific thing that concerns me is DMA. The WD board doesn't do
DMA; I don't know about the 3Com board.  Would moving data to and from
the ethernet board via programmed I/O loops cause serious problems for
Minix? Eg: do we have to disable interrupts? Could we lose asynch TTY
interrupts? Will it kill response time?

I know DMA is slower on ATs, but with a multi-tasking OS, there are
considerations other than raw throughput.

(I shouldn't have to say this, but mail any replies to me.  If there
is sufficient interest, I will summarise to the net.)

Thanks in advance,

	Jonathan Stone
	Programmer/Student
	Comp Sci Dept
	Victoria University
-- 
                                      |`Toto, I have a feeling we're
sane mailers: jonathan@comp.vuw.ac.nz |  not in Kansas anymore ...''
UUCP path: ...!uunet!vuwcomp!jonathan |      - Dorothy,arriving in Oz

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 04:36:27 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?

Steve,

Yes, if what you mean by "fair queueing" (a term I find mesleading at best)
is multiple priority queues in the conventional sense, the fuzzball gateways
used on the NSFNET Backbone and at several other spots scattered over the
US and Europe do that for all network links, including SLIP. The scheme is
based on the Precedence field of the IP header, plus a few naughty tricks
based on port number (when the precedence field is zero). Having used the
scheme a lot on slow (9600 bps) serial links with SLIP and other link
protocols, I can't say you should all go rush out and implement it. As
implemented in the fuzzballs, priority scheduling ruthlessly shoves interactive
traffic to the head of the queue, even if bulk-transfer (FTP, mail) traffic
ends up waiting indefinitely at the end, then timing out. Then, little
things like miscellaneous UDP and ICMP (ping) services sometimes stop
working. Obviously, fancier service disciplines can be designed which would
be more "fair," but the fuzzies have not yet learned those tricks.

My point is not to discourage innovation in this area or even to conclude
the fuzzball scheme does not work right; on the contrary, most of the time
it works like a bandit. However, I do want to point out that the fairness
issue is much more complex than you might suspect and deserves careful study
in its own right. One of the most fertile experimental breeding swamps may
well be hoked-up SLIP drivers for exactly the service you describe. After
all, there are hundreds of times more Unix systems out there than fuzzballs.

Dave

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 12:49:00 PDT
From:      eva@TWG.COM
To:        garrett <garrett@louie.udel.edu>
Cc:        tcp-ip@sri-nic.arpa, dcrocker@TWG.COM
Subject:   Wollongong's TN3270

 

Your message of yesterday concerning Wollongong's EUNICE and TCP products
for VMS, contained some information that I would like to correct. We are
currently investigeting how this incorrect information was relayed to you
and we apologize for the confusion. However...


Here are the true facts:
 

1/  TN3270 is available with EUNICE release 4.3.1 (from September 1987).
    As released, it has two known minor bugs, which we picked up from the 
    Berkeley sources. They will be fixed in new EUNICE mainten
ance release 
    coming up in June.

2/  TN3270 is currently available only with EUNICE, not WIN/TCP. It requires
    "libcurses" library which is not supported under WIN/TCP, due to the 
    requirement for a UNIX license.

3/  There is no WIN/TCP release 3.3 scheduled for this summer. The release 
    following after 3.2 will be 4.0, which will be compatable with VMS 5.0.
    We do not yet have an announced release date for WIN/TCP 4.0.


				Eva Mitter
				EUNICE Project Leader 
				Software Engineering

				The Wollongong Group

				eva@twg.com
                                     


-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 11:13:00 EST
From:      <enger@bluto.scc.com>
To:        "big-lan" <big-lan@suvm.acs.syr.edu>
Cc:        <tcp-ip@sri-nic.arpa>,<info-appletalk@andrew.cmu.edu>, <info-proteon@uxc.cso.uiuc.edu>,<info-vax@kl.sri.com>
Subject:   F I B R O N I C S    Experiences Wanted



			     F I B R O N I C S


We are considering the use of Fibronics FINET to link multiple ethernet
segments within the same building.  We will be running DECnet, XNS, TCP/IP, 
Appletalk/Ethertalk, and perhaps LAT. 

If anyone has experience using the FINET product (or can suggest an 
alternate) we would greatly appreciate your comments.  Please respond 
directly to us, we will summarize to the net if there is interest, or to 
individual requesters.  Thanks.

Bob Enger
CONTEL Federal Systems
enger@bluto.scc.com
301-840-4040


-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 07:21:35 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Packet level accounting in IP routers?


Yes, but the problem is that those network elements cost the same
amount if you don't use them.

I dunno, there's something wrong with these cost accounting arguments,
but I can't quite put my finger on it.

Maybe that's it, you can't ever reclaim the unused capacity of a
network, all idle time is lost forever, so why charge someone simply
for making it not idle? Something like that. Back to the 1040...

	-Barry Shein, Boston University

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 13:08:42 GMT
From:      tsmith@USNA.MIL ("Tim G. Smith", Mechanical)
To:        comp.protocols.tcp-ip
Subject:   Re:  Packet level accounting in IP routers?


	Kent England, Boston University writes
	
< 	You say that the auditors require per-packet charging to
< fairly allocate costs. Do they require each dept to pay a separate
< rent or to install separate phone systems or to buy their own
< furniture and pencils?  They do not.

  That depends who you work for.

< 	If MILnet goes to packet charging, and I don't see how they
< can do it, those costs could still be approximately redistributed
< according to a formula based on number of nodes, type of nodes, etc.

  Talk to the bean counters- it is not a case of IF, it is a case of
WHEN. I also think it will be an administrative nightmare to handle
the billing but that is not my problem.

< 	[flame on]  There is absolutely no reason that network access
< charges should be packet based.  It makes no sense on a local area
< network like Ethernet and no sense in a packet internet.

  I tend to disagree- the gateways and the point to point links are
running at higher and higher capacity. Some folks only use the MILnet
to get and send small amounts of mail. Others use to FTP humongous
files around and get news.  Everyone bitches when the response times
spiral and everyone gets hurt by it. I think everyone would like to
see increased network bandwith. What should be done to raise the money
to expand the network?  Should the folks who use the network only
sparingly have to bear the cost of the people who use the net heavily? 

<   Users will  not understand the charges (as well as contract
< auditors) and you  won't be able to justify them.  "Well, let's see
< your diskless  workstation used 45k NFS packets last month."  "What
< do you mean, all  I did was read netnews!"

  Well I guess we will have to do some educating.

< 	Network costs could be set up as an overhead charge.  Links to
< outside networks like the internet are flat rate and this cost could
< be allocated to each dept based on a formula.  The only trick if there
< is one is the formula, but every organization has a formula for
< allocating basic telephone service with cost-per-message added on as
< needed [long distance billing, for example].  So long as your formula
< approximately distributes actual costs to all departments and only
< recovers actual costs and a share of other overhead, it should be
< acceptable to auditors.

  Yes there will be problems but that is life- chock full of problems.
I would rather see a flat rate for internal (ie localy owned) network
traffic. 

  An analogy is trucks on toll roads. Do trucks pay more than
motorcycles to use the road? Yes- because the maintenance the road
will require for each truck that uses it is significantly greater than
the maintenance required by a motorcycle using the road. (Tell me is
your long distance bill on your telephone flat rate?)

< 	Local area networks do not cost you on a per-packet basis and
< you don't need to recover on a per-packet basis.  Per packet only
< works on (virtual) terminal networks, networks of the past.  [flame
< off]

  Sure they do. If you want to know the cost per packet of the network
you take the cost of the network (hardware, phone lines, maintenance)
divided by the total number of packets using it. That gives the cost
per packet. 

I think we all need to remember that the Internet is a research project
(a successful one it appears)- that is why its cost has been
subsidized so heavily. We all have to face the fact that we are using
the Internet just like we use telephones, mail, and other tools
essential to our work. If we want to keep the service we are going to
have to pay for it. If we don't want to pay for it then I suppose that
we can all go back to using whatever we used before there was an
Internet.

  Before I get flamed to death just let me say...

I am not looking forward to the impending switch to per packet
charges. I would rather see the flat rate continued. But if per packet
charging will result in better service than so be it. I also can
understand the reasoning that went into the decision to make the
change. I think we all are going to have to simply learn to live with
it. 

		Tim Smith
	E-Mail :<tsmith@usna.mil>
	US mail:Tim Smith
		CADIG mailstop: 11G
		US Naval Academy
		Annapolis, MD 21402
					

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 13:37:39 GMT
From:      glenn@XN.LL.MIT.EDU (Glenn Adams)
To:        comp.protocols.tcp-ip
Subject:   Sun NFS UDP Checksum Fix


As many of you know, Sun NFS's use of UDP excludes checksumming the
UDP packet.  For lossy link layers such as SLIP, or for problem
Ethernet controllers, this can result in getting garbage data
when using remote mounted file systems.

A modified version of kudp_fastsend.o is now available via anonymous FTP
from XN.LL.MIT.EDU that employs UDP checksumming.  Place this file in
/sys/OBJ, saving your old object file, prior to building the kernel.

The UDP checksumming is controlled by a global variable, kudpcksum, which
is enabled by default.  Note well that this only controls the GENERATION
of checksums on transmitted NFS packets, it DOES NOT control the detection
of checksum errors on received packets or non-NFS packets. To enable the
latter, use adb to set the udpcksum variable to non-zero.  By default, this
latter variable is set to zero by Sun, thus disabling tests for checksum
errors on incoming packets.  It should be enabled to allow symmetrical
checksumming on NFS.

This fix will work on SUN OS versions 3.2 through 3.5.

Glenn Adams
MIT Lincoln Laboratory

Internet: Glenn@XN.LL.MIT.EDU
UUCP: {ames,cmcl2,decvax,harvard,mit-eddie}!ll-xn!glenn

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 16:13:00 GMT
From:      enger@BLUTO.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   F I B R O N I C S    Experiences Wanted

 


			     F I B R O N I C S


We are considering the use of Fibronics FINET to link multiple ethernet
segments within the same building.  We will be running DECnet, XNS, TCP/IP, 
Appletalk/Ethertalk, and perhaps LAT. 

If anyone has experience using the FINET product (or can suggest an 
alternate) we would greatly appreciate your comments.  Please respond 
directly to us, we will summarize to the net if there is interest, or to 
individual requesters.  Thanks.

Bob Enger
CONTEL Federal Systems
enger@bluto.scc.com
301-840-4040

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 16:28:37 GMT
From:      neerma@COD.NOSC.MIL (Merle A. Neer)
To:        comp.protocols.tcp-ip
Subject:   public domain tcp/ip

I am looking for a public domain tcp/ip package
for PC DOS with a driver for 3COM 3C505.

Please reply to : neerma at nosc.mil

Thanks in advance,
Merle
-------
-------

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 16:49:42 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
To:        comp.protocols.tcp-ip
Subject:   Re:  Packet level accounting in IP routers?

I remember being told once by a telco person that 80% of the toll
collected on long lines was just to pay for the accounting process
itself (this was in the days when they sent the armoured truck to
pick up the AMA tapes).  I don't know how much this has changed.

I can easily see a significant amount of gateway resources (bandwidth,
memory, CPU) being eaten up just by accounting, which would mean
getting a more expensive box...  so you would pay more to get what
you get now.  For this reason, I think the flat-rate charge is a good
idea (but then I also favour rate-of-return over price-capping).

-Philip

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 17:15:33 GMT
From:      cyrus@hi.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   packet lengths



I have been comparing the lengths of packets specified in IP headers
against actual packet lengths.  What I am seeing, ignoring IP packets
smaller than the minimum packet size, is that a fair number of machines
send out packets that are 1-3 bytes longer than is specified by the
IP length.  Although this does not hurt anything, I am wondering
why this is.  Is it because some machines short/long/quad align the
end of the packet before sending?

Also, this phenomenon appears to be protocol dependent.  For example,
I saw several 4.3 machines doing this when sending out timed packets
and routed packet, but not with other packets.  I've seen our IP/TCP
Imagen sending out UDP packets doing this.

Although this does not hurt anything, I am just curious as to the reason
why.


-- 
    @__________@    W. Tait Cyrus   (505) 277-0806
   /|         /|    University of New Mexico
  / |        / |    Dept of Electrical & Computer Engineering 
 @__|_______@  |       Parallel Processing Research Group (PPRG)
 |  |       |  |       UNM/LANL Hypercube Project
 |  |  hc   |  |    Albuquerque, New Mexico 87131
 |  @.......|..@    
 | /        | /     e-mail:      
 @/_________@/        cyrus@hc.dspo.gov

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 19:49:00 GMT
From:      eva@TWG.COM
To:        comp.protocols.tcp-ip
Subject:   Wollongong's TN3270


 

Your message of yesterday concerning Wollongong's EUNICE and TCP products
for VMS, contained some information that I would like to correct. We are
currently investigeting how this incorrect information was relayed to you
and we apologize for the confusion. However...


Here are the true facts:
 

1/  TN3270 is available with EUNICE release 4.3.1 (from September 1987).
    As released, it has two known minor bugs, which we picked up from the 
    Berkeley sources. They will be fixed in new EUNICE mainten
ance release 
    coming up in June.

2/  TN3270 is currently available only with EUNICE, not WIN/TCP. It requires
    "libcurses" library which is not supported under WIN/TCP, due to the 
    requirement for a UNIX license.

3/  There is no WIN/TCP release 3.3 scheduled for this summer. The release 
    following after 3.2 will be 4.0, which will be compatable with VMS 5.0.
    We do not yet have an announced release date for WIN/TCP 4.0.


				Eva Mitter
				EUNICE Project Leader 
				Software Engineering

				The Wollongong Group

				eva@twg.com
                                     

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 88 22:04:12 GMT
From:      mark@intek01.UUCP (Mark McWiggins)
To:        comp.unix.xenix,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Bell Technologies 386 RFS "Cheap Ethernet"

Just got a mailing from Bell Technologies advertising their 386 Unix
($495 complete with manuals and an unlimited-user license).  I've
been reading about the price for months, but what caught my eye this
time was this:

	"UNIX from Bell Technologies ships Ethernet ready with a
	complete RFS distributed file system -- just plug in a low-cost
	Ethernet card and go!"

That's exactly what we'd like to do, preferably booting diskless nodes
across the network, and running DOS Merge 386 underneath.

Are you doing anything like this?  Does it work?  What kind of Ethernet
card are you using and how much did it cost?  (I haven't found out yet
what Bell considers "low-cost".)

Please E-mail (I don't have read access to comp.dcom.lans) and I'll
summarize for the net.  Thanks in advance.
-- 

Mark McWiggins			UUCP:		uunet!intek01!mark
DISCLAIMER: I could be wrong.	INTERNET:	mark@intek01.UUCP
						(206) 641-5014

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 88 01:55:53 GMT
From:      reschly@BRL.ARPA ("Robert J. Reschly Jr.")
To:        comp.protocols.tcp-ip
Subject:   Re: "... and statistics" (Re: [Phil Dykstra: more interesting numbers] )


Mike writes:
>  ... Many would prefer to claim this as a peak rate of 400 packets/sec
> (2 interface traversals per "packet", counting the ping responses as a
> second packet) -- we would say "400 monodes/sec" in this case.

   Actually that should be "monograms" not "monodes".  The term
"monogram" is derived from the simile between "diodes" and "datagrams",
and their one-legged cousins.  (Ask Ron Natalie about "monodes" if
you're interested).

				Later,
				    Bob

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 88 06:45:30 GMT
From:      roode@orc.olivetti.COM (David Roode)
To:        comp.protocols.tcp-ip
Subject:   bad press for NSFNET

The April 1988 issue of Data Communications magazine on p. 78 has an
entry called "Kludgey NSF RT-based network?"  It says it turns out
each NSFNET T1 backbone switch will consist of from 3 to 9 RT's linked
via a token ring.  Local campuses will interface to one of the RT's
via Ethernet and backbone trunks will be handled by multiple RT's.  A
dedicated RT will handle routing.

The article then goes on to quote an unnamed 'key university network
manager' who bemoans the 115 amps of current the switch will consume
and the 32,500 BTU/h of cooling required.  The article says power
consumption was confirmed by the NSFnet operators, but says they
referred the issue of heat dissipation to IBM.

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 88 16:55:20 GMT
From:      wbe@bbn.com (Winston B Edmond)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting in IP routers?

Barry Shein writes:
>
>Yes, but the problem is that those network elements cost the same
>amount if you don't use them.
>
>I dunno, there's something wrong with these cost accounting arguments,
>but I can't quite put my finger on it.
>
>Maybe that's it, you can't ever reclaim the unused capacity of a
>network, all idle time is lost forever, so why charge someone simply
>for making it not idle? Something like that. Back to the 1040...

Indeed.  The best charging scheme will probably be like the phone,
electricity, and other utility bills: a basic charge for providing service at
some level plus additional charges depending on usage and time of day
(expected network loading).  The problem is that in order to do the
"depending on usage" part, one must implement per packet accounting, even if
some usage is covered by the monthly flat rate.
 -WBE

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 88 21:43:09 GMT
From:      tsudik@MALIBU.USC.EDU (Gene Tsudik)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting in IP routers?

Alternatively, a "best" charging scheme could be like the payphone scheme
used in some European countries. There you pay for some fixed number of minutes
and get a card (sorta like a debit card) and then you use it over time.
One could simularly have a scheme where a machine (organization) buys X
megabytes of data and uses it over time thus minimizing the extraneous 
traffic associated with accounting packet needed per connection.

The scheme of course would have to be a little more complex than that. 
Per connection charges should also be available but discouraged.

Gene Tsudik

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Apr 88 04:12:25 EDT
From:      Bruce Crabill <BRUCE%UMDD.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   TCP state diagram mistake
This is probably a rediscovery of an old mistake, but in RFC-793 (TCP
Protocol Specification) in the TCP Connection State Diagram on page 23,
the transition from the SYN-SENT state to the SYN-RECEIVED state by the
reception of a bare SYN, indicates that this should case a bare ACK to
be sent.  However, on page 32 (Simultaneous Connection Synchronizaton)
and text on page 68, it would appear that the correct thing to do is to
send a SYN,ACK.  If this is a known problem, is there an RFC or other
location where known problems are kept?

                                       Bruce
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 88 04:13:08 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  bad press for NSFNET

The reporter called me a month or so ago with the same quote. I told him that,
even if the quote were correct, it had nothing to do with the functionality
or performance of the net and was probably quoted out of context. Consider this:
it could have been worse in the case of some other publications known to me.
In the past I have had tailfeathers singed myself with publications quoting
me out of context, so I have some sympathy for the quotee.

Geeze, is it really 115 Amps?

Dave

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 88 04:22:21 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Packet level accounting in IP routers?

Gene,

You have discovered the Farecard used in the Washington Metro Underground (tube).
You should ask a Washington dweller how well the Farecard dispensing machines
work.

Dave

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Apr 1988 12:12:29 EST
From:      Ittai Hershman <ittai@vx2.GBA.NYU.EDU>
To:        Mills@udel.edu
Cc:        Gene Tsudik <tsudik%malibu.usc.edu%cse.usc.edu@oberon.usc.edu>, bbn.com!wbe@bbn.com, tcp-ip@sri-nic.arpa
Subject:   Re: Packet level accounting in IP routers?
Perhaps this should go to RISKS instead :-)   When I was down at the TCP/IP
Interoperability Conference in December, I found a few hours to go into town
and meet a friend for lunch.  I have a farecard I keep in my wallet which I
use whenever I'm in DC -- miraculously it still worked.  Well my friend
decided to drag me to a State Dept press conference and I went through some
metal detector.  When I got back to the Metro station to return to Arlington,
I discovered the farecard would not work (my Am Ex card was fine, and the
farecard was readable in the station office's computer, but not by the
turnstile).

Maybe it was just a fluke, since I'm sure many State Dept employees ride the
Metro, or maybe they have lead-lined wallets...  Anyway, the discussion of
farecards on the TCP-IP list was just too hard to pass up.

-Ittai
-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 1988 12:04-EDT
From:      CERF@A.ISI.EDU
To:        kwe@BU-CS.BU.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Packet level accounting in IP routers?
Kent,

Your flames seem a bit excessive (but I suppose that's a tautology...).

In networks like the Internet there are components such as the gateways,
wide area network switches, and shared trunks whose costs could reasonably
be allocated on the basis of usage. When multiple administrations (such
as DOE, DOD, NSF, HHS, etc.) share facilities, it is important to be
able to demonstrate that costs are related to services rendered (used) in
some fashion. The reason is that each agency quite properly could be
asked by Congress, for instance, to show that it obtained its fair share
of the facility (based on what it paid for).  One might, as you suggest,
some up with a formula for sharing some of the fixed cost of the network
(a sort of base price you pay to be connected to the system at all).

The issue of accounting becomes more significant as the services
rendered become less research/experimental and more like commodities.
Telephone services such as the Federal Telephone System run by the GSA
are cost-allocated in accordance with usage and one doesn't find it odd
to pay for telephone calls on the basis of time and distance. 

The parameters for packet nets may be different than for telephone
voice service (maybe no distance charges). The important thing for
the parties involved is to be able to demonstrate that there is a
reasonable sharing of costs. I'm no longer with the government, so I
certainly can't speak for the agencies involved, but I'm extrapolating
from experiences I had at DARPA from 1976-82 when questions about 
access to ARPANET and sharing of costs were considered.

One attractive thing about basing charges on usage is that as total
usage goes up, it may be possible to make capital investments to increase
capacity in a way that doesn't specifically require that all parties make
an agreement to acquire more equipment - the service provider can
buy it on the basis of increased usage and spread the cost in a reasonably
equitable fashion. I'm not saying you couldn't do it on the basis of
ports or nodes - the ARPANET did it that way for years - but thenit
seemed to me a little harder to distribute the cost of adding a larger
scale packet switch somewhere.

In any case, the present focus on accounting is, in my view, important
and valid and we should work to help the government folks find reasonable
ways to implement it.

Vint
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 88 08:12:25 GMT
From:      BRUCE@UMDD.BITNET (Bruce Crabill)
To:        comp.protocols.tcp-ip
Subject:   TCP state diagram mistake

This is probably a rediscovery of an old mistake, but in RFC-793 (TCP
Protocol Specification) in the TCP Connection State Diagram on page 23,
the transition from the SYN-SENT state to the SYN-RECEIVED state by the
reception of a bare SYN, indicates that this should case a bare ACK to
be sent.  However, on page 32 (Simultaneous Connection Synchronizaton)
and text on page 68, it would appear that the correct thing to do is to
send a SYN,ACK.  If this is a known problem, is there an RFC or other
location where known problems are kept?

                                       Bruce

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Apr 88 18:48:29 -0400
From:      haverty@CCV.BBN.COM
To:        CERF@A.ISI.EDU
Cc:        kwe@BU-CS.BU.EDU, tcp-ip@SRI-NIC.ARPA, haverty@CCV.BBN.COM
Subject:   Re: Packet level accounting in IP routers?
Vint et al,

One way we have found useful to think about accounting and charging in
networks is to think of the network as a business.  It has customers
today, and offers a set of services to those customers with some charging
policy ($0.45 an "ounce"?).  In order to deliver those services it needs
to acquire capital assets (lines, switches, satellites), and provide
operations services (operators, field service, administrators).  It can
make a business decision between providing the services to its
customers by use of its own assets (e.g., buy a satellite) or by use
of services obtained from somewhere else (e.g., use dial-up trunks
to provide service).

At any point in time, the charter of the business is to provide the services
to its clients at least cost, and to allocate those costs across the clients.

Here's where it gets sticky.   Clients' needs change, as new technology
is introduced (e.g., 3D color workstations), and available communications
technology changes as well as technology advances (fiber, etc.).  Thus in
order to stay in business, the network must plan to invest in new
technologies, and must make smart business decisions about what to do
and when in order to keep costs low, and remain competitive in the
"marketplace".

In addition to these 'engineering' kinds of decisions, the network must
make 'marketing' decisions.  For example, it might price a new service
"unfairly" low, in order to encourage clients to upgrade (maybe mail
should be cheaper if one uses the full domain server system?).  There are
also costs associated with "marketing", such as advertising (NIC management
bulletins?)

The point is that there is a large body of science and practice with 
elements such as depreciation, revenue, IR&D, etc which allows someone
to place the network management into a business context.

The real question is the one which the CEO of this hypothetical business
has to answer - what is my business plan, how will I market my services,
what should I invest in to remain competitive, etc.  In the government
network context, one should probably add the constraint that the network
be non-profit, because of the limited competition and 'infrastructure'
nature of the network.

As far as charging algorithms go, that is the province of the hypothetical
marketing department - how do I price my product.  In the context of
the current mail discussion, I think it is best to assume that somehow
all of the costs must be recovered by charges, including costs for
investments for the future.  The real question is how to use a pricing
policy to encourage the desired behavior.  Perhaps triple charges for 
any host failing to obey a quench?  

As someone else pointed out, this is a real hot topic right now, and in 
fact I think it is a not insignificant flaw in the research activities 
that the methodology for 'chargeback' was not developed as part of
the network architecture from day one.  No one has 'the right answer' as
far as I can see.  

Are there any MBAs or business school students who need a good meaty
research area out there?????

Jack
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 88 16:04:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting in IP routers?

Kent,

Your flames seem a bit excessive (but I suppose that's a tautology...).

In networks like the Internet there are components such as the gateways,
wide area network switches, and shared trunks whose costs could reasonably
be allocated on the basis of usage. When multiple administrations (such
as DOE, DOD, NSF, HHS, etc.) share facilities, it is important to be
able to demonstrate that costs are related to services rendered (used) in
some fashion. The reason is that each agency quite properly could be
asked by Congress, for instance, to show that it obtained its fair share
of the facility (based on what it paid for).  One might, as you suggest,
some up with a formula for sharing some of the fixed cost of the network
(a sort of base price you pay to be connected to the system at all).

The issue of accounting becomes more significant as the services
rendered become less research/experimental and more like commodities.
Telephone services such as the Federal Telephone System run by the GSA
are cost-allocated in accordance with usage and one doesn't find it odd
to pay for telephone calls on the basis of time and distance. 

The parameters for packet nets may be different than for telephone
voice service (maybe no distance charges). The important thing for
the parties involved is to be able to demonstrate that there is a
reasonable sharing of costs. I'm no longer with the government, so I
certainly can't speak for the agencies involved, but I'm extrapolating
from experiences I had at DARPA from 1976-82 when questions about 
access to ARPANET and sharing of costs were considered.

One attractive thing about basing charges on usage is that as total
usage goes up, it may be possible to make capital investments to increase
capacity in a way that doesn't specifically require that all parties make
an agreement to acquire more equipment - the service provider can
buy it on the basis of increased usage and spread the cost in a reasonably
equitable fashion. I'm not saying you couldn't do it on the basis of
ports or nodes - the ARPANET did it that way for years - but thenit
seemed to me a little harder to distribute the cost of adding a larger
scale packet switch somewhere.

In any case, the present focus on accounting is, in my view, important
and valid and we should work to help the government folks find reasonable
ways to implement it.

Vint

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 00:49:00 PST
From:      "TERVAX::EFBATEY" <efbatey%tervax.decnet@nswses.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        efbatey
Subject:   Packet accounting and a place to do it
I salute BARRY S.'s thought that it might be a little more complex to account
the use by packets, by sites, by ... .  Moreover, the internet, a-political as
it is, is a place where intellectual processes are nurtured.  Some of those
might not be nurtured should a carelessly adopted plan evolve to choke off
contributions of those automatically excluded by some carelessly adopted plan.
------
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 88 17:12:29 GMT
From:      ittai@VX2.GBA.NYU.EDU (Ittai Hershman)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting in IP routers?

Perhaps this should go to RISKS instead :-)   When I was down at the TCP/IP
Interoperability Conference in December, I found a few hours to go into town
and meet a friend for lunch.  I have a farecard I keep in my wallet which I
use whenever I'm in DC -- miraculously it still worked.  Well my friend
decided to drag me to a State Dept press conference and I went through some
metal detector.  When I got back to the Metro station to return to Arlington,
I discovered the farecard would not work (my Am Ex card was fine, and the
farecard was readable in the station office's computer, but not by the
turnstile).

Maybe it was just a fluke, since I'm sure many State Dept employees ride the
Metro, or maybe they have lead-lined wallets...  Anyway, the discussion of
farecards on the TCP-IP list was just too hard to pass up.

-Ittai

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 88 18:47:13 GMT
From:      wesommer@athena.mit.edu (William Sommerfeld)
To:        comp.protocols.tcp-ip
Subject:   Re:  bad press for NSFNET

In article <8804170013.aa05021@Huey.UDEL.EDU> Mills@UDEL.EDU writes:
>Geeze, is it really 115 Amps?

Well, if you believe what's printed on the back of the boxes, the IBM
Reduced Taxes[1] desktop model is rated at 7.5 amps at 120VAC.  The floor
model is rated at 10 amps.  The floor model has more expansion slots
as well as room for up to three disk drives; the desktop model only
has room for one internal disk.

With 9 CPU's, that would be 67.5 or 90 amps total.  RT's tend to run
hot; you're not supposed to run them for very long (more than 5
minutes or so) with the cover off, or else they reportedly melt down.
The CPU chips are mounted in massive heat sinks which are directly in
the blast of a 4" fan.

Four RT/PC's tend to keep a 10' x 20' room nice and toasty warm...

						- Bill

[1] so called because it is rumoured that IBM gives more of them away
than they sell...

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 88 22:48:29 GMT
From:      haverty@CCV.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting in IP routers?

Vint et al,

One way we have found useful to think about accounting and charging in
networks is to think of the network as a business.  It has customers
today, and offers a set of services to those customers with some charging
policy ($0.45 an "ounce"?).  In order to deliver those services it needs
to acquire capital assets (lines, switches, satellites), and provide
operations services (operators, field service, administrators).  It can
make a business decision between providing the services to its
customers by use of its own assets (e.g., buy a satellite) or by use
of services obtained from somewhere else (e.g., use dial-up trunks
to provide service).

At any point in time, the charter of the business is to provide the services
to its clients at least cost, and to allocate those costs across the clients.

Here's where it gets sticky.   Clients' needs change, as new technology
is introduced (e.g., 3D color workstations), and available communications
technology changes as well as technology advances (fiber, etc.).  Thus in
order to stay in business, the network must plan to invest in new
technologies, and must make smart business decisions about what to do
and when in order to keep costs low, and remain competitive in the
"marketplace".

In addition to these 'engineering' kinds of decisions, the network must
make 'marketing' decisions.  For example, it might price a new service
"unfairly" low, in order to encourage clients to upgrade (maybe mail
should be cheaper if one uses the full domain server system?).  There are
also costs associated with "marketing", such as advertising (NIC management
bulletins?)

The point is that there is a large body of science and practice with 
elements such as depreciation, revenue, IR&D, etc which allows someone
to place the network management into a business context.

The real question is the one which the CEO of this hypothetical business
has to answer - what is my business plan, how will I market my services,
what should I invest in to remain competitive, etc.  In the government
network context, one should probably add the constraint that the network
be non-profit, because of the limited competition and 'infrastructure'
nature of the network.

As far as charging algorithms go, that is the province of the hypothetical
marketing department - how do I price my product.  In the context of
the current mail discussion, I think it is best to assume that somehow
all of the costs must be recovered by charges, including costs for
investments for the future.  The real question is how to use a pricing
policy to encourage the desired behavior.  Perhaps triple charges for 
any host failing to obey a quench?  

As someone else pointed out, this is a real hot topic right now, and in 
fact I think it is a not insignificant flaw in the research activities 
that the methodology for 'chargeback' was not developed as part of
the network architecture from day one.  No one has 'the right answer' as
far as I can see.  

Are there any MBAs or business school students who need a good meaty
research area out there?????

Jack

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 00:41:34 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Packet level accounting in IP routers?

Ittai,

Well, in nine years Farecard machines munched not my oxide, but did munch the
printer ribbons so I seldom knew how much money was left. I learned the trick
of running an unreadable card through the machine anyway. If it spit the card
back out, there was more than $2 on it. If it kept it there was less and you could get
the card back by cancelling the transaction.

The above trick is not well known and may rescue one of you someday. Try
putting a Farecard through a credit-card reader. With this I promise to shut up.

Dave

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Apr 88 11:15 PDT
From:      Michael Stein                        <CSYSMAS@UCLA-CCN.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Packet level accounting in IP routers?
> The "per packet accounting" load could be limited by using sampling
> techniques, like the US Postal Service does when allocating costs
> to government departments.  Regards - Craig

Is the overhead of counting packets really that high?

I would assume that any IP router would have a "total" packet
counter included in its overhead (1 counter).

How much overhead would be added to count packets to each
"interface" on the router (may already exist) and then "bill"
each interface for it's count of packets?

This doesn't divide the counts by host (IP address), possibly the
hosts could be trusted to do that.  (You would know the total).
Hosts need accounting anyway, so that they can charge the packets
back to the actual user anyway (assuming multiuser host).

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 04:43:58 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Packet level accounting in IP routers?


>Are there any MBAs or business school students who need a good meaty
>research area out there?????
>
>Jack

I agree wholeheartedly. As much as people like to tell themselves they
understand the issues I honestly think this is the kind of thing for
which professionals exist who can perhaps raise the level of the
discussion beyond "is not" -- "is too".

There are several models to look at (utility, infrastructure etc.)

Just wandering around the machine room with a meter and wondering
where to stick it is not the obvious answer. There are good reasons,
for example, that you are not charged for every use of the road you
drive on to go to the corner grocer but instead the costs are built
into a larger structure.

At the very least it would be interesting to hear what the goals are
that people expect to accomplish with their proposed chargeback
models, it's nice to have explicit goals and see if the models
actually achieve them.

	-Barry Shein, Boston University

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Apr 88 11:31:14 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        bruce%umdd.bitnet@cunyvm.cuny.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: TCP state diagram mistake

Bruce,

    There is actually a move afoot to write a Host specification
document ala RFC 1009 (the Gateway specification).  One of the sections
in this document will be devoted to TCP.  I'm responsible for writing
the first draft of that section, and I plan to incorporate a list of
known problems in the TCP RFC.

    Anyone who has a list of errors they've found in the TCP specification
is encouraged to send those errors to me so they can be noted in the
RFC.

Craig

PS: Bob Braden is editor-in-chief of this effort.
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Apr 88 8:58:58 EDT
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Accounting
Jack and Barry have both said it right; a charging mechanism (tariff) is more
than the rules for collecting money - it is also the concrete specification of
a policy (and the only policy statement that really counts).  Policies can be
made to encourage or discourage connection to a network, encourage or
discourage use of a network, or favor some classes of users over others.  A
proposed tariff has to be examined to see whether it supports or contradicts
other "statements" of policy.  For example, when DCA took over the ARPANET from
ARPA in the mid-70's they adopted a "per-port" tariff because it was simple and
predictable.  The instantaneous response of the user community was the
invention of a class of devices called "port expanders" which had no logical
justification other than local cost minimization under the tariff, with a
negative side-effect of making troubleshooting harder.  Those are the kinds of
effects which the folks formulating a tariff must be sensitive to.  For every
proposed tariff someone should ask, "If I had to pay according to this tariff,
what would I do to minimize my own cost?" If we don't like the answer, the
tariff should not be implemented.

Alex
 
-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 1988 10:58-EDT
From:      CERF@A.ISI.EDU
To:        mckenzie@LABS-N.BBN.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Accounting
Alex,

I disagree with your assertion that the port expander was motivated by
the per-port tariff on DDN/ARPANET. In fact, it was motivated by the fact that
an IMP could only support 4 host ports at the time and we needed more
connections but could not afford to pay for an entire IMP (the cost per
port for a 4 port IMP was high; now IMPs can support many more ports
at less cost per port).

Vint
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 1988 10:59-EDT
From:      CERF@A.ISI.EDU
To:        mckenzie@LABS-N.BBN.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Accounting
Addendum:

It was CAPITAL cost, not operational cost, that motivated the port expander,
in case it wasn't clear in my earlier response.

Vint
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 08:49:00 GMT
From:      efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY")
To:        comp.protocols.tcp-ip
Subject:   Packet accounting and a place to do it

I salute BARRY S.'s thought that it might be a little more complex to account
the use by packets, by sites, by ... .  Moreover, the internet, a-political as
it is, is a place where intellectual processes are nurtured.  Some of those
might not be nurtured should a carelessly adopted plan evolve to choke off
contributions of those automatically excluded by some carelessly adopted plan.
------

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 12:58:58 GMT
From:      mckenzie@LABS-N.BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Accounting

Jack and Barry have both said it right; a charging mechanism (tariff) is more
than the rules for collecting money - it is also the concrete specification of
a policy (and the only policy statement that really counts).  Policies can be
made to encourage or discourage connection to a network, encourage or
discourage use of a network, or favor some classes of users over others.  A
proposed tariff has to be examined to see whether it supports or contradicts
other "statements" of policy.  For example, when DCA took over the ARPANET from
ARPA in the mid-70's they adopted a "per-port" tariff because it was simple and
predictable.  The instantaneous response of the user community was the
invention of a class of devices called "port expanders" which had no logical
justification other than local cost minimization under the tariff, with a
negative side-effect of making troubleshooting harder.  Those are the kinds of
effects which the folks formulating a tariff must be sensitive to.  For every
proposed tariff someone should ask, "If I had to pay according to this tariff,
what would I do to minimize my own cost?" If we don't like the answer, the
tariff should not be implemented.

Alex
 

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 13:50:15 GMT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting in IP routers?


>The problem is that in order to do the
>"depending on usage" part, one must implement per packet accounting, 
>even if some usage is covered by the monthly flat rate.
> -WBE

The "per packet accounting" load could be limited by using sampling
techniques, like the US Postal Service does when allocating costs
to government departments.  Regards - Craig

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 14:56:26 GMT
From:      neerma@COD.NOSC.MIL (Merle A. Neer)
To:        comp.protocols.tcp-ip
Subject:   request for token ring experiences

We are planning to install an IBM token ring with PS/2s
and IBM mainframes.  Eventually there could be up to 200
PS/2s on the net.  I'd be interested in hearing from
those that have had IBM token ring experience to see
what kind of problems we might enounter.

Reply to : neerma at nosc.mil

Thanks,
Merle.
-------
-------

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 14:58:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Accounting

Alex,

I disagree with your assertion that the port expander was motivated by
the per-port tariff on DDN/ARPANET. In fact, it was motivated by the fact that
an IMP could only support 4 host ports at the time and we needed more
connections but could not afford to pay for an entire IMP (the cost per
port for a 4 port IMP was high; now IMPs can support many more ports
at less cost per port).

Vint

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 14:59:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Accounting

Addendum:

It was CAPITAL cost, not operational cost, that motivated the port expander,
in case it wasn't clear in my earlier response.

Vint

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 15:13:38 GMT
From:      alexew@watdcsu.waterloo.edu (A.E.Wielhouwer - Computing Services)
To:        comp.protocols.tcp-ip
Subject:   Kinetic FastPath


Could someone please post or send me a synopsis of the capabilities of
the Kinetics FastPath box and any equivalent systems in terms of:

1) connecting AppleTalk networks together - performance, addressing, 
   special user knowledge and software considerations, etc.

2) using TCP-IP services from MACs - performance, addressing, special
    user knowledge, etc.

By addressing, I am refering to 'how do I call a MAC on another net through
the box' and whether or not each MAC requires an IP address, etc.

Any info you may have would be appreciated. I'd like a user's opinion rather
than a vendors.  Thanks in advance.
 

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 15:31:14 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: TCP state diagram mistake


Bruce,

    There is actually a move afoot to write a Host specification
document ala RFC 1009 (the Gateway specification).  One of the sections
in this document will be devoted to TCP.  I'm responsible for writing
the first draft of that section, and I plan to incorporate a list of
known problems in the TCP RFC.

    Anyone who has a list of errors they've found in the TCP specification
is encouraged to send those errors to me so they can be noted in the
RFC.

Craig

PS: Bob Braden is editor-in-chief of this effort.

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 17:36:16 GMT
From:      n2dsy@hou2d.UUCP (G.BEATTIE)
To:        rec.ham-radio,rec.ham-radio.packet,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   RATS Open Systems Environment (ROSE) Forum at the 1988 Dayton Hamvention




	       The Radio Amateur Telecommunications Society

			 206 North Vivyen Street

		      Bergenfield, New Jersey  07621


			       201-387-8896

       The Radio Amateur Telecommunications Society (RATS) is proud to present

	      a	forum at the 1988 Dayton Hamvention called:

       ROSE: Open Systems Networking in	the RATS Open Systems Environment

       The talk	will focus on the reality of Open Systems
       Networking in Amateur Radio.  The Society has been involved
       in the development of mail/file/directory servers and
       networking software based on international communications
       standards.

       Radio Amateurs who are telecommunications professionals or
       packet radio users will find this talk especially
       interesting and enlightening, but the novice networker will
       have no trouble following the presentation.

       * Software Distribution

       Currently, the beta version of the ROSE X.25 Packet Switch
       and the release of the ROSErver/Packet Radio MailBox System
       are available.  The Society will	distribute the latest
       releases	of its software	at the session.	 Bring 5-1/4 or	3-
       1/2 inch	diskettes for software and documentation.  Remember
       RATS distributes	its software for free!	Come and get it!

       * Where to Find RATS at Dayton

       Members of RATS will be present in the PAC-COMM Packet Radio
       Systems booth (Booth 277/278).  Members will be able to
       demonstrate and copy software for you to	take home and use.
       Handouts	describing our activities and frequencies of
       operation will be distributed at	the packet forum on Friday
       afternoon from 1-5.  We also are	planning to be available
       for the Packet Get-Together at McNasty's	on Saturday
       evening.


       The RATS	ROSE Forum

       Time:   9:30 - 11:00

       Place:  ROOM 1 (check your programme to be sure)

       The forum will consist of three three 30	minute talks.  Each
       will explore an aspect of the Open Systems implemented by
       the Radio Amateur Telecommunications Society (RATS).
       Questions will be taken by each speaker.

       Schedule

       09:30   Review of Open Systems Networks and Protocols

	       - Presented by J. Gordon	Beattie, Jr., N2DSY

		 This talk will	provide	an overview of a network
		 based on Open Systems.	 The specific protocols
		 and user services will	be defined alone with the
		 network management and	planning dependencies found
		 in a cooperative network.

       10:00   The ROSE	X.25 Packet Switch

	       - Presented by Thomas A.	Moulton, W2VY

		 This talk will	concentrate on the OSI Network Services
		 and how the ROSE X.25 Switch will support the users of
		 "vanilla" AX.25, OSI Applications, TCP/IP and Net/ROM.

       10:30   The ROSErver Mail, File and Directory Server

	       - Presented by Andrew R.	Funk, KB7UV

		 This talk will	concentrate on OSI Application Services
		 and how the ROSErver/Packet Radio Mail	Box System will
		 provide these services	to users and other systems.

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 18:15:00 GMT
From:      CSYSMAS@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting in IP routers?

> The "per packet accounting" load could be limited by using sampling
> techniques, like the US Postal Service does when allocating costs
> to government departments.  Regards - Craig

Is the overhead of counting packets really that high?

I would assume that any IP router would have a "total" packet
counter included in its overhead (1 counter).

How much overhead would be added to count packets to each
"interface" on the router (may already exist) and then "bill"
each interface for it's count of packets?

This doesn't divide the counts by host (IP address), possibly the
hosts could be trusted to do that.  (You would know the total).
Hosts need accounting anyway, so that they can charge the packets
back to the actual user anyway (assuming multiuser host).

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 23:05:00 GMT
From:      berger@clio.las.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: bad press for NSFNET


Would anybody care to compare the old ARPA IMP boxes to this scheme?

			Mike Berger
			Department of Statistics 
			Science, Technology, and Society
			University of Illinois 

			berger@clio.las.uiuc.edu
			{ihnp4 | convex | pur-ee}!uiucuxc!clio!berger

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 23:14:38 GMT
From:      ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?

In article <8804150036.aa13833@Huey.UDEL.EDU> Mills@UDEL.EDU writes:
>Steve,
>
>Yes, if what you mean by "fair queueing" (a term I find mesleading at best)
>is multiple priority queues in the conventional sense, the fuzzball gateways
 ... do that for all network links, including SLIP. The scheme is
>based on the Precedence field of the IP header, plus a few naughty tricks
>... I can't say you should all go rush out and implement it. 
>... in the fuzzballs, priority scheduling ruthlessly shoves interactive
>traffic to the head of the queue, even if bulk-transfer (FTP, mail) traffic
>ends up waiting indefinitely at the end, then timing out.
One might imagine something based on 'deadline scheduling', where a 'deadline
to transmit', at which point some other layer will presumably retransmit.
Theoretically (don't ask me - I can't prove it - I just heard it from an
operating systems talk at another institution four years ago.) you can meet
all the deadlines by picking the packet with the closest deadline first.
[This assumes that all the deadlines can be met -- if they can't then you
have a network enginerring problem which is beyond the scope of this message]

Still not happy with interactive response?  Then fragment those big packets
and get the SLIP at the other end to unfragment them!
Vendors everywhere will thank you for fully testing conformance of their
TCP/IP implementations.
-- 
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 88 23:19:26 GMT
From:      geoff@fernwood.mpk.ca.us (Geoff Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   Thoughts on why packet accounting will be A Good Thing.


Packet accounting will make us use "our" networks more efficiently.  Packet 
accounting will derail the virtual gravy train of network pork bellying we've 
grown accustom on "our" network.  Packet accounting will engender new 
protocols which give us The Look and Feel of today's full duplex, character 
at-a-time, remote echo telnets & rlogins with local echo transmit-when-needed 
efficiency.

Look how packet accounting networks such as Telenet & Tymnet have developed 
vs. "our" networks sans accounting.  Packet accounting network users usually 
send terminal traffic line at a time and do local character echoing at the PAD 
or user telnet level.  "Our" networks send telnet/rlogin traffic character at 
a time and echo at the remote host.  No doubt "their" network is making a 
better use of its bandwidth (although "ours" may currently be `nicer' to use 
-- but at what cost?).  We never really had the incentive to develop austere 
networking protocols because "our" network was usage and cost sensitive 
"free".  Whether your IMP port sent 1 or a 1,000,000 packets a day, week or 
year, the cost was the same.

Old Time Network Boys will remember the ARPANET's attempt in the early 70's at 
local echoing of telnet with RCTE via NCP.  As i recall from that time, the 
purpose of RCTE was for the users in Hawaii, London/UK & Oslo/Norway to 
receive fast/local-like character echoing, not really to cut down on network 
traffic.  I think the TIPs (what today's TACs were previously called), Tenex 
and MIT-Multics were the only hosts to implement RCTE.  RCTE was never fully 
debugged and used in an operational mode (and i recall Mit-Multics only used 
RCTE to turn off echoing for passwords at login time).  It did not seem to 
survive the NCP to TCP/IP transition.  R.I.P RCTE

Network bandwidth conservation is not only A Good Thing for "our" networks, 
but is an important efficiency in some networking technologies which have very 
finite amounts of bandwidth available to them such as packet radio, cellular 
and satellite.  With these technologies in the commercial market place, it's 
not always possible to throw more capacity to gain bandwidth.  There is only 
so much radio spectrum available.  We need to be so ever parsimonious with our 
existing bandwidth/spectrum as possible.

Perhaps packet accounting will bring about the networking equivalent of the 
70s energy crisis.  Fuel efficiency considerations and non OPEC sources of 
energy suddenly became the seminal issues of the day.  Research and 
development ensued for more efficient motors.  Alternate forms for fuel were 
explored and some developed such as synthetic.  May necessity be "our" mother 
of invention too.
__
  Geoff Goodfellow    fernwood!Geoff@sri-unix.arpa   ..!sri-unix!fernwood!Geoff

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 02:02:52 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Thoughts on why packet accounting will be A Good Thing.


By the same token (pardon me) we could argue to raise the fares on on
Rte 128 (for the w. coast, 101) until that messy thing called rush
hour just stops. Of course, the sudden absence of employees will be a
mere artifact of these nice, manageable highways, it is ignorable.

I don't know about software engineering by dear resource, it's not
self-evident to me. Computing resources have gotten really cheap
lately and I daresay they have engendered better software, not worse.

For once in history it is becoming clear who will serve whom (you
can't tell me that JCL wasn't an attempt to make man serve the
computer rather than the other way around.)

Let's be real careful, that's all, I ain't sayin' yes and I ain't
sayin' no...

	-Barry Shein, Boston University

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 03:17:57 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
To:        comp.protocols.tcp-ip
Subject:   Re:  Thoughts on why packet accounting will be A Good Thing.


	4. Charge for higher level services based upon the service
	(eg. charge for local logins at one rate, remote logins at
	another rate, based upon connect time, as other services develop
	their charging units should also develop, distributed data base
	access based upon queries etc.)

As long as we are being open-minded (and perhaps a tad unrealistic),
why not charge on the basis of utility derived from a service?  I know
this is extremely subjective, but I have always been opposed to paying
for a service by the service-unit (say packets or message-units) when
the actual quality can vary tremendously.  Should you pay as much for
network usage when the latency and/or lossage is high?  Or for SYNs
sent to a host that is unreachable because their IMP crashed?

If we all had extremely current, well-behaved TCPs then we wouldn't
have to worry about paying for packets that are redundant (say the
RTT calculation is off and you start retransmitting prematurely).  But
most of us are constrained to use commercial software that is of
varying quality and functionality.

I guess I'm moaning about a problem without presenting any sort of
solution, but I feel it is something to be considered.

As an aside, I would like to see "collect" packets (charged to
destination) for mailing lists.  There is no reason that the people
who provide these enormously useful mailing lists (_not_ soc.singles)
and invest time and resources should be further penalized.  Maybe
FTP clearing houses as well...

-Philip

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 05:59:05 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        rec.ham-radio,rec.ham-radio.packet,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   TCP/IP at Dayton and Trenton

The KA9Q Internet Protocol Package will also be described and
demonstrated at both the Trenton Computer Festival and at the Dayton
Hamvention.  This package is now estimated to be in the hands of at
least several thousand people around the world, and it is enjoying
rapidly increasing popularity on amateur packet radio. It presently
supports the following proven, industry standard protocols:

Applications:

	Telnet - remote login and "chatting"
	FTP - File transfer (binary or text)
	SMTP - Mail transfer

Transport/Session:

	TCP - Transmission Control Protocol
	UDP - User Datagram Protocol

Network:

	IP - Internet Protocol
	ICMP - Internet Control Message Protocol

Link/Subnet:

	ARP - Address Resolution Protocol
	Ethernet - 3Com 3C-501 interface driver
	AX.25 - packet radio (both connected and unconnected modes)
	SLIP - asynchronous point-to-point links

The primary machine supported is the IBM PC (and clones). Versions are also
available for the Apple Macintosh, Commodore Amiga, and UNIX System V.

The entire package, which includes complete C source code and
documentation, is copyrighted by myself and others, but it is completely
FREE for noncommercial use. I encourage you to make copies for your
friends back home; this minimizes the number of copies I have to make.

I will bring a limited supply of copies, but bring your own blank disks
if you want to be sure of getting a copy. The package fits on one
high-density 1.2 meg 5.25" floppy, two 720K 3.5" floppies, or three 360K
5.25" floppies. I should be able to handle all three formats at both
Trenton and Dayton.

For those of you with Internet access, you may obtain the package by
anonymous FTP from louie.udel.edu (10.0.0.96) under /pub/ka9q.

73, Phil Karn, KA9Q

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 10:18:00 GMT
From:      WANCHO@SIMTEL20.ARPA ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   Accounting

Last year I sent out a message outlining the pitfalls and problems
with the per-packet chargeback algorithm to be levied on the MILNET
hosts and gateways.  No response at that time.  Since then, the
ARPANET Lives message came out, hinting at the imposition of similar
charges for ARPANET hosts, followed recently by Bill Barnes' query.
That combination must have triggered a sympathetic reaction.

Let me point out several points to ponder:

1.  Unlike the ARPANET, the MILNET backbone users have been offered
not one single carrot/reason for the charges, such as the promise of
an improved, high-speed backbone.  The ONLY reason is to divide the
EXISTING cost of the MILNET backbone among the services based on the
usage by each service.  (Service means Army, Navy, Air Force, etc.)

2.  The mods to the PSN software have been in-place for over a year
with delayed monthly charge reports being produced as a paper exercise
only to check for accuracy and format.  All that is required at this
point to implement the scheme is the declaration of the date on which
the paper charges become real.  It would then be up to each service to
pay the bills, possibly going back to charge each facility connected
to the backbone - the reports are supplied at that level.  I suspect
that the effort to change the rates charged would be trivial as that
would be a post-processing change.  But, the effort required to change
the underlying traffic collection algorithm would certainly be
non-trivial at this point.

3.  The algorithm itself is flawed (in my opinion): it is based on
charges only for outgoing packets, and TAC access (including connect
time, not just packet charges - in BOTH directions).  That severely
penalizes hosts which act as mailing list distribution points, those
which offer anonymous ftp access, and those which allow telnet access,
particularly from TACs.

4.  Geoff is right.  Given the rates and charging algorithm, we will
find expedient solutions: shut down our mailing list redistributions,
disallow all ftp and telnet access, including outgoing ftp and telnet,
and move off the backbone...

To answer Bill's query: the network applications programs on the hosts
connected directly or indirectly to the corporate gateway(s) would
have to tag each outgoing packet with a cost center code which is then
counted and stripped at the gateway(s) prior to entering the backbone.
I know it's absurd, but that is the "correct" method to keep the bean
counters happy.

--Frank

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 10:25:01 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  Thoughts on why packet accounting will be A Good Thing.

Barry,
Your comment about the fares on Rte 128 ring too close to home
here in No. VA where you cannot ride the 'freeways' during
rush hour (on I66) unless you have 4 or more in the car.  Recent
sentiment expressed in the paper indicates that this will not
go away, but willexpand in concept.  We are also going to build
a private tole road.

So, if with hiways, why not networks.  Pay and 'packet pool'!

dennis

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 13:28:09 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Thoughts on why packet accounting will be A Good Thing.


>So, if with hiways, why not networks.  Pay and 'packet pool'!
>
>dennis

Because we don't have a cartel forcing the price up on bits? (joke)

Dennis, it's not a moral imperative or something that one can prove
easily is right or wrong. I guess the problem is simply that whatever
one does they are forced to engage in a form of social engineering.

Unless the charges are so trivial that they can be ignored (in which
case they won't have any effect on traffic volume) it will become a
decision factor. Some folks have pointed out how this can be a good
thing and I was trying to point out that this can also be a bad thing.

I guess my views come down to whether we are metering the right thing,
not really any PollyAnna view that someone won't pay the bill.

For example, why not charge for the length of cable used to hook
someone up, by the foot? That's a more direct cost than packet usage,
wire costs, bandwidth only costs when you don't have enough (that is,
what value is an unused wire?) If charging by the foot doesn't ring
true with you then now you have insight into my feelings about
metering packets.

Places to charge:

	1. One-time at point of hookup or, similarly, "rental of
	equipment" (eg. flat monthly rate.)

	2. Per packet

	3. Taxation model (thou shalt contribute N% of your overhead
	to networking.) This is probably the current model even tho
	it's not obvious to the casual observer (eg what agencies spend
	on networks they don't spend on other research costs, it's a
	witholding tax...) I realize that PSN hookups are charged and
	can more resemble (1), but that's a small part of the picture.

	4. Charge for higher level services based upon the service
	(eg. charge for local logins at one rate, remote logins at
	another rate, based upon connect time, as other services develop
	their charging units should also develop, distributed data base
	access based upon queries etc.)

I am sure there are others, I just don't see what's so compelling
about packets as the charging unit other than it seems simple and
straightforward (as many have pointed out, it really isn't very simple
nor straightforward once we consider the details of implementation.)

Personally I tend towards the taxation model which could be expanded
because it gibes with my view of network as infrastructure rather than
utility. Even the traditional public utilities have recognized these
sorts of alternate models (eg. 800 numbers) to per-unit charging.

	-Barry Shein, Boston University

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Apr 1988 18:37:41 LCL
From:      GRFXLS@SUVM.ACS.SYR.EDU
To:        TCP-IP@SRI-NIC.ARPA
I'm sorry if I am at the wrong group. I'd like to find out where I could
get parts for AT&T7300. I am looking for a power supply and 20 MB harddisk.
Please, send me a mail if you have any information about it.

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 14:12:29 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting

Just because you see a packet doesn't mean that it arrived at the
destination.  For this reason counting packets in a lossy network is
very unfair to the subscriber.  The only place in IP/TCP/UDP where you
can actually measure delivered packets is in TCP or UDP (only at the
destination in the case of UDP).  This makes accounting in a datagram
based network non-trivial.  Perhaps this is why the PTTs have adopted VC
based networks.  At least they know when a packet has been delivered to
the host (or at least the edge of their network) and can charge
reliably.

Has anyone thought to define the measure of service delivered? Is it
really the number and size of packets delivered? Off the top of my head
I cannot think of another measure but that does not mean that there
isn't one.  Maybe a definition of service is in order before a
discussion of service measurment. 

Brian Lloyd, President
Sirius Systems, Inc.
19200 Tilford Way, Germantown, MD 20874 
(301) 540-2066
brian@wb6rqn.uucp
Share and enjoy!

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 15:33:59 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        rec.ham-radio,rec.ham-radio.packet,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: TCP/IP at Dayton and Trenton

In article <1054@thumper.bellcore.com> karn@thumper.bellcore.com (Phil R. Karn) writes:
>The KA9Q Internet Protocol Package will also be described and
>demonstrated at both the Trenton Computer Festival ...
>The entire package, which includes complete C source code ...
>I will bring a limited supply of copies, but bring your own blank disks
>if you want to be sure of getting a copy. ...

I'll give Phil a few copies of my Turbo C porting kit on 5 1/4 360 K
disks.

The porting kit is updated to version 871225.18, and is on clutx.clarkson.edu
[128.153.4.3] in pub/Ka9q/kit.arc via anonymous ftp.
-- 
char *reply-to-russ(int network) {
if(network == BITNET) return "NELSON@CLUTX";
else return "nelson@clutx.clarkson.edu"; }

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 15:48:19 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  Thoughts on why packet accounting will be A Good Thing.

Plug:

  A proposal for X.3-style line buffering, echo control, output flushing etc.
  has just been published as RFC 1053.  It works pretty well for X.25 networks
  and can probably do the same on wide-area TCP networks.

	Stuart Levy, Minnesota Supercomputer Center

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 16:38:27 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?

Ralph,

There are lots of schemes to deal with the unfairness issue I mentioned,
the most attractive of which may be based on schedule-to-deadline
principles you mention. While fragmentation can be used to reduce
latency, you have to be careful how the fragmentation is done. Those
implementations I know about transmit all fragments of a gram one after
the other, which would defeat the purpose. Fuzzballs (and maybe others
I don't know about) requeue the datagram (with updated fragmentation info)
after each fragment transmission. This results in a two-tier discipline;
FB(n) (FIFO order in each priority queue) for grams less than the MTU
and RR (round-robin in each priority queue) otherwise. Yes, the thought
has struck me that actual queue priority could be adjusted for each
fragment and also elapsed time on the queue.

Dave

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 17:55:09 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re:  Thoughts on why packet accounting will be A Good Thing.

And there is also an IDEA016 "Telnet local edit option" from the people
at Cray.  Just what us vendor type people love.  Multiple standards to
do the same thing.  Well, not quite the same thing.  While RFC1053 proposes
a PAD view of the world, IDEA016 proposes a unix view of the world (complete
with local handling of signals).

Personally, I'd like to mix up the two, and add some tops20-like features,
like a full break mask, and some things that haven't ever existed, like
a full echo mask.  Oh well, I guess I just get to wait and see what happens.

Bill Westfield
cisco Systems
-------

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 18:50:41 GMT
From:      randy@LARRY.CS.WASHINGTON.EDU (Randy)
To:        comp.protocols.tcp-ip
Subject:   Re: packet lengths

What do you mean by "actual packet lengths"? If you mean the length field
specified by the ethernet header, then be aware that the smallest legal
ethernet packet is 64 bytes (counting header and checksum). If the
IP part of the ethernet packet is smaller than 48 bytes (64- header), then
the packet will be padded with garbage.

Randy Day.
Internet (ARPA): randy@cs.washington.edu
CSNET: randy%washington@relay.cs.net
UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randy

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 18:54:48 GMT
From:      geof@imagen.UUCP (Geof Cooper)
To:        comp.protocols.tcp-ip
Subject:   Re: packet lengths


 > I have been comparing the lengths of packets specified in IP headers
 > against actual packet lengths.  What I am seeing, ignoring IP packets
 > smaller than the minimum packet size, is that a fair number of machines
 > send out packets that are 1-3 bytes longer than is specified by the
 > IP length.

The Ethernet requires that packets be an integral number of 16-bit words
long.  The Ethernet also has a minimum packet size of 60 bytes.  Any IP
packet that is less than 60 bytes in length (including ethernet header)
will be padded to 60 bytes.  The IEEE 802.3 length field would allow
you to explicitly set the ethernet length, but Ethernet doesn't.

- Geof Cooper

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 20:02:56 GMT
From:      sung@mcnc.org (Wayne Sung)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   bad packets passing through bridges

I had been following the checksum issue on tcpip with some interest when
we started seeing what obviously were bad addresses showing up in our
bridges. The most annoying thing was that these were not being flagged as
having CRC errors on my own network monitor (just a plain programmable
enet board with various test programs running) even though I am checking
almost every error I know about. After collecting many megs of packet traces
I finally caught one. Note that the beginning part of the packet (after the
XX's) don't correspond to any manufacturer codes. But since it is in the head
of the packet, all bridges duly noted the second 6 bytes as source addresses.
This bad address allowed us to trace back to where the packet was generated.

I can't say exactly yet how this is happening. It seems two packets have been
amalgamated but the nearest bridge did not flag that as an error. Then it
sent this "packet" out to the whole system, since the destination is not local
(or exists!) This also possibly explains something else we have been seeing -
addresses that are absolutely known to be remote nonetheless show up local. If
packets can get shifted by 6 bytes then what was a destination shows up as a
source.

If you would like more specific info send me mail.


                       v-------------------------
7E7C00  XXXX XXXX XXXX 5500   54BF 09FF 02A0 F403  _9_*_~U_T?___ t_
        ---v note 1
7E7C10  FFFC 01AA FF2A FF82   2A2A 0081 D4AA 8090  _|_*_*__**__T*__
                       v-------------------------
7E7C20  0401 FF00 15C1 0800   2001 2995 0800 2001  _____A__ _)___ _
        -------------v note 2
7E7C30  2879 0800 4500 0398   D250 039D FF11 D130  (y__E___RP____Q0
7E7C40  806D 8832 806D 8829   BABA AAAA 0000 0000  _m_2_m_)::**____
7E7C50  0000 0004 4440 4000   0000 0000 4440 0155  ____D@@_____D@_U
7E7C60  5555 5555 5440 0000   0000 4045 5554 4444  UUUUT@____@EUTDD
7E7C70  4044 5444 4444 4040   4044 4445 5555 5555  @DTDDD@@@DDEUUUU
7E7C80  5555 5554 4444 4444   4444 5455 5454 4440  UUUTDDDDDDTUTTD@
7E7C90  4044 5555 5555 5555   5400 0000 0000 0000  @DUUUUUUT_______
7E7CA0  0000 0000 0000 0000   0000 0000 0000 0000  ________________
7E7CB0  0005 5555 5555 5555   5555 D5D5 5540 0000  __UUUUUUUUUUU@__
7E7CC0  0000 0000 0000 0000   0000 0005 5555 5555  ____________UUUU
7E7CD0  5555 5555 5555 5555   5555 5555 AAAA AAAA  UUUUUUUUUUUU****
7E7CE0  AAAA AAAA AAAA AAAA   A8A8 A8AA AAA8 AAAA  ********(((**(**
7E7CF0  AEEA AAEA AAA8 8888   88AA AAAA AAAA AAAA  .j*j*(___*******
7E7D00  AAAA AAAA AAAA AAAA   AAAA AAAA AAAB FFFE  *************+_~
7E7D10  AAEE EAAA AAAA AAAA   AAAA AAAA AAAA AAAA  *nj*************
7E7D20  AAAA AEFF EEFF FFFE   EA88 8088 8888 8888  **._n__~j_______
7E7D30  8888 8888 8888 8888   8880 8080 0080 8080  ________________
7E7D40  00AA AAAA AAAA EAEA   EFFF FFFF FAA8 8888  _*****jjo___z(__
7E7D50  8888 8888 8888 8888   8888 8AAA EAEE EAFF  ___________*jnj_
        .....more of the same.....

note 1: what obviously is a bad ethernet header
note 2: what turns out to be a perfectly good ethernet header
        plus some ip header

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 21:15:36 GMT
From:      robert@SPAM.ISTC.SRI.COM (Robert Allen)
To:        comp.protocols.tcp-ip
Subject:   4.3 TCP sockets revisited.


    Last year I asked some questions about TCP sockets under 4.2-4.3BSD
    UNIX, concerning a dynamic alternate routing capability.  Specifically
    I was concerned that under 4.2 routes are closely tied to the TCP
    sockets using that route, such that if the route dies then the TCP peers
    at the sockets also time out and die, forcing the application using
    the sockets to restart the sockets.  Rumor had it that 4.3 would solve
    some of these problems, because the TCP timers could last long enough
    for a new route to be obtained.  The part of the problem which was perhaps
    not addressed under 4.3 was the caching of only a single 'good' route at
    a time.

    Now I have heard that the Sun Internetwork Router (based on XNS) under
    the newer versions of SunOS supports load sharing, which leads me to
    believe that Sun must also support redundant routes in the routing tables.
    I have a need for highly responsive route switching under the socket layer
    in the work I'm doing, where the physical layer tends to be poor or non-
    existant on a per-route basis over time.  If the functionality has not been
    implemented yet I have an interest in trying it myself, but I don't want
    to re-invent the wheel, Sooo...

    My questions are:

	(a) Has Sun implemented what I call here "dynamic redundant routing"?
	    If so, under which releases of the OS?
	    If so, is it only for the Internetwork Router?

	(b) If Sun has not implemented it, has Berkeley, or someone else?

	(c) If Sun has not implemented it, how are they doing load sharing
	    over the I.R.?  Did I hear a wrong rumor?


    Please call, write or post to the net. 

    Thanks,

    Robert Allen,
    robert@spam.istc.sri.com	415-859-2143

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 21:22:14 GMT
From:      engle@wdl1.UUCP (David Engle)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet accounting and a place to do it

>... .  Moreover, the internet, a-political as
>it is, is a place where intellectual processes are nurtured.  Some of those
>might not be nurtured should a carelessly adopted plan evolve to choke off
>contributions of those automatically excluded by some carelessly adopted plan.

A good example of what could be easily eliminated by a per packet billing 
system is the archival storage facilities around the net.  How many sites
are going to maintain files for anonymous ftp or gratuitous mailing to
others, if it costs the site "real" money to do so.

Dave						engle@ford-wdl1.arpa

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 21:42:44 GMT
From:      david@elroy.Jpl.Nasa.Gov (David Robinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Accounting

In article <WANCHO.12391659408.BABYL@SIMTEL20.ARPA>, WANCHO@SIMTEL20.ARPA ("Frank J. Wancho") writes:
> 3.  The algorithm itself is flawed (in my opinion): it is based on
> charges only for outgoing packets, and TAC access (including connect
> time, not just packet charges - in BOTH directions).  That severely
> penalizes hosts which act as mailing list distribution points, those
> which offer anonymous ftp access, and those which allow telnet access,
> particularly from TACs.

This offers interesting accounting problems for sites that serve as a gateway
for other organizations and networks.  The number of networks that are
gatewayed through a particular organization is growing.  How will
NSFnet and CSnet handle the chargebacks to their users?  Same for
Bitnet mail relays.  I can see the unfortunate situations where these
other networks shut off external Mail and FTP access to the Internet.
Also how does one charge back between Arpanet and Milnet?  Will the
long hinted seperation of the nets by the mailbridges be put into effect?
-- 
	David Robinson		elroy!david@csvax.caltech.edu     ARPA
				david@elroy.jpl.nasa.gov	  ARPA
				{cit-vax,ames}!elroy!david	  UUCP
Disclaimer: No one listens to me anyway!

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 88 22:18:04 GMT
From:      cyrus@hi.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   IP UDP/TCP port numbers


What is the algorithm used by TCP and UDP to pick port numbers?  Specifically
I would like to know how the op sys picks src/dst port numbers.  

Let's say I have a socket between two machines.  How does the op sys keep
from picking port (socket) numbers that are defined in the RFC (RFC 1010)
or by UN*X in /etc/services?

The reason I ask is because will watching packets fly around on our
local network, I have seen machines use port numbers that should be
used ONLY for certain applications (who, timed, smtp, etc.).

TCP port numbers seem to be ok, but UDP port numbers seem to be totally
random.  I have seen many UDP packets in which BOTH the source AND
destination ports are zero (0).  According to UDP RFC (RFC 768), only
the src port can be zero "if not used".  The "destination port has a meaning
within the context of a particular internet destination address."  Ok,
what does this mean?  Under what circumstances can the op sys pick port
numbers (specifically dst port) that have predefined meanings?

Below is some example output from my monitoring:

	     UDP packets
	src port 0, dst port 1
	src port 0, dst port 3
	src port 0, dst port 6
	src port 0, dst port 8
	src port 0, dst port 12
	src port 0, dst port 'DISCARD'		DISCARD = 9
	src port 0, dst port 'RJE'		RJE = 5
	src port 0, dst port 'CHARGEN'		CHARGEN = 19
huh? -> src port 0, dst port 0
	src port 0, dst port 'ECHO'		ECHO = 7

What is going on?  I would appreciate it if someone could enlighten me
because I must be missing something.

-- 
    @__________@    W. Tait Cyrus   (505) 277-0806
   /|         /|    University of New Mexico
  / |        / |    Dept of Electrical & Computer Engineering 
 @__|_______@  |       Parallel Processing Research Group (PPRG)
 |  |       |  |       UNM/LANL Hypercube Project
 |  |  hc   |  |    Albuquerque, New Mexico 87131
 |  @.......|..@    
 | /        | /     e-mail:      
 @/_________@/        cyrus@hc.dspo.gov

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 88 02:19:21 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  Thoughts on why packet accounting will be A Good Thing.

Barry, I agree with your sentiments.  I also tend towards the taxation
model and the view of networks as infrastructure or a 'utility'.
At Los alamos, where I was before moving east, we charged for network
connect time and port charges.  Other methods of charging were always
discussed, but it was hard to get concensus.  The 'rich' users did not
care about what you charged.  They just justified more money for their
work.  the 'poor' users could not get more money and were forced into
antisocial behavior, i.e. they quit using the network and went out
and bought microcomputers.  Afterall, you can compute anything on
a micro that you can on a cray, it just takes more time.  When
'time' is the color of your money, then you spend time instead of
dollars.


dennis

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 88 02:52:54 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   record arpanet traffic


I believe that the nattached indicates that the Arpanet is carrying
record traffic these days.  At least in the 2.5 years I have been
watching, this is a record.

dennis

>From sullivan@venera.isi.edu Tue Apr 19 17:15:39 1988
Received: from KAUAI.MCL.UNISYS.COM by LANAI.MCL.UNISYS.COM [3.2Unisys/Domain/jbp/2.4] 
	id AA19827; Tue, 19 Apr 88 17:15:38 EDT
Received: from venera.isi.edu by KAUAI.MCL.UNISYS.COM [3.2Unisys/Domain/jbp/2.4] 
	id AA29781; Tue, 19 Apr 88 17:14:45 EDT
Posted-Date: Tue, 19 Apr 88 14:03:47 PDT
Message-Id: <8804192103.AA22370@venera.isi.edu>
Received: from LOCALHOST by venera.isi.edu (5.54/5.51)
	id AA22370; Tue, 19 Apr 88 14:03:48 PDT
To: Traffic-People@venera.isi.edu
Cc: Sullivan@venera.isi.edu
Subject: Traffic Graph - APR07
Date: Tue, 19 Apr 88 14:03:47 PDT
From: Kathleen Sullivan <sullivan@venera.isi.edu>
Status: R




                           TOTAL TRAFFIC
                     PACKETS PER WEEK (MILLIONS)
1988*    0.0 *
JAN07  171.8 **************************************
JAN14  189.4 ******************************************
JAN21  179.1 ****************************************
JAN28  216.3 ************************************************
FEB04  218.4 ************************************************
FEB11  226.6 **************************************************
FEB18  213.7 ***********************************************
FEB25  214.8 ************************************************
MAR03  240.1 *****************************************************
MAR10  227.5 **************************************************
MAR17  238.3 *****************************************************
MAR24  222.1 *************************************************
MAR31  232.6 ***************************************************
APR07  265.0 **********************************************************

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 88 23:03:00 PST
From:      "TERVAX::EFBATEY" <efbatey%tervax.decnet@nswses.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        efbatey
Subject:   Need Mail / TCP-IP for HP3000 under MPE V

------------------------------------------------------------------------
# Date:     Wed, 20 Apr 88 19:06:41 PDT
# From:     efbatey (4V33,x5881 Everett F Batey II) @ tervax
# Reply-To: <efbatey@NSWSES.ARPA>
# Subject:  HP3000/MPE_V/HP-Office to TCP-IP
# Comment: < USNSWSES*SOCALSunLUG*DECUS*805/982-5881/983-1220 >

I have 2 dozen P3000s with HP'sMPE_V operating system and HP Office / Desk.
All my other hosts talk DECNet AND / OR TCP-IP .. I need a mail bridge and 
preferrably full TCP/IP Mail and TELNET/FTP .. I would probably commit a major
felony for some good leads .. enet cards to replace RS232 and software ...

         ------------------------------------------------------------
         | Everett F. Batey II    } { UUCP:  sun!tsunami!nswed5!efb |
         | USNSWSES - Code 4V33   } { ARPA:  efbatey@NOBBS.UCSB.EDU |
         |   After HOSTS.TXT.726  } {        efbatey@NSWSES.ARPA    |
         ------------------------------------------------------------

------
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 88 23:18:00 PST
From:      "TERVAX::EFBATEY" <efbatey%tervax.decnet@nswses.arpa>
To:        "vivian" <vivian@sri-nic.arpa>
Cc:        efbatey
Subject:   I'm getting rejected posted tcp-ip ..
Would you post this one for me .. Thanks .. Ev

Reply-To: <efbatey@NSWSES.ARPA>
Subject:  HP3000/MPE_V/HP-Office to TCP-IP
Comment: < USNSWSES*SOCALSunLUG*DECUS*805/982-5881/983-1220 >

I have 2 dozen HP3000s with HP's MPE_V operating system and HP Office / Desk.
All my other hosts talk DECNet AND / OR TCP-IP .. I need a mail bridge and 
preferrably full SMTP Mail and TELNET/FTP .. I would probably commit a major
felony for some good leads .. enet cards to replace RS232 and software ...

         ------------------------------------------------------------
         | Everett F. Batey II    } { UUCP:  sun!tsunami!nswed5!efb |
         | USNSWSES - Code 4V33   } { ARPA:  efbatey@NOBBS.UCSB.EDU |
         |   After HOSTS.TXT.726  } {        efbatey@NSWSES.ARPA    |
         ------------------------------------------------------------

------
-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 88 17:27:00 GMT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   Whither chargeback policies?

Hang on, this is getting a little too far down in the bits.

Let's ignore the implementation details (counting packets, counting
PSNs, etc) for the moment, and concentrate on what this whole business
is designed to accomplish:

1) Generate some revenue to fund (and expand?) the operational
   network, and
2) Provide some negative feedback (that's a technical term, not a
   normative statement) so that users will make "efficient" use of
   the available network resources.

Let us further assume, that (1) will take care of itself (with the
help of the bean counters who are going to be fixing the rates anyway)
and that our job is to decide what kind of things really need to be
charged back so that (2) will be both fair and effective.

I submit that, at the moment, the two most critical resources on the
Internet are:
a) Long distance trunk bandwidth, in particular (but not limited to)
   the three transcontinental ARPANET trunks, and
b) Gateway CPU time (level-3 routers), in particular (but not limited
   to) the core gateways and ARPANET <=> MILNET "mailbridges".

I would add ARPANET/MILNET PSN overhead, but that's beating a dead
horse, no offense to the martyrs at BBN who keep that code running.

These are also, of course, the two worst-imaginable places to try to
intsert accounting telemetry, precisely because they are so
overloaded.  Nevertheless, if we are going to have to start paying
money per usage for some resource, I for one would prefer to be paying
for these.  Perhaps some of the income can be used to increase the
numbers of trunks and core gateways until they can adaquately handle
the load.

The point someone made a few days ago about examining the incentive
implications of a policy before implementing it is well taken.  For
example, I'd hate to see the above musings turned into a general
charge for router CPU time that encouraged everybody to connect
networks with level-2 bridges.

I applaud the idea of getting a Real Economist to analyze this mess
so that we can giggle at his-or-her ideas rather than each other's.

Lastly, if we're going to use highway analogies, let's not forget US
1A southbound through the Sumner Tunnel to Boston, where the traffic
routinely backs up so badly, in spite of the toll, that it's -faster-
to go 10 miles out of the way on state highways and city streets than
to take the direct route.  Much of the traffic is people who are
either paying by the mile (taxis from Logan Airport) or people who are
using the Tunnel simply because they don't know any other route.  It
happens that just last week I found myself TELNETing from MIT to a
site in CT (to which we have a high speed three-hop link via NSFNet)
via the ARPANET to Pittsburg and whoknowshow from there because the
routing software couldn't tell which route was faster.

I'm not sure how to implement a penalty charge for stupid software,
but it'd probably be a good thing if we could; picture
vendor-of-your-choice being told that ever single customer site would
be hit with a surcharge until they fixed their broken software!
People who think this is a joke should remember Paul Mockapetris's
claim that a bug in bind v4.5 was eating up about a KL-10's worth of
CPU time on the root domain servers last July.

--Rob

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 88 17:33:58 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: bad press for NSFNET


	I found the Data Comm article intriguing.  I haven't heard
anything on usenet or the internet regarding the new NSFnet router
architecture.  Could someone point me toward a journal article, trade
rag article, or other source where I could learn something about how
these new RTs route?

	If there is nothing in print, I would like to invite someone
from MERIT or other knowledgable developer to post something about how
these RTs work compared to some plain vanilla (:-) router like a
cisco, a proteon, a fuzzball, or homegrown router.

	Any takers?

	Kent England, Boston University

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 88 18:10:49 GMT
From:      wbe@bbn.com (Winston B Edmond)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet accounting and a place to do it

David Engle writes:
>A good example of what could be easily eliminated by a per packet billing 
>system is the archival storage facilities around the net.  How many sites
>are going to maintain files for anonymous ftp or gratuitous mailing to
>others, if it costs the site "real" money to do so.

This particular problem could be solved with "reverse billing": Create a
means for a server and a client to negotiate billing charges.  In the case of
file archive servers, the server would ask the network to reverse the billing
charges.  The network then asks the client if it is willing to accept the
charges for the file transfer.  The client accepts by informing the network
that it will accept charges for packets from the server, and the network
informs the server that billing costs for that connection have been accepted
by the client.  It is important that the billing entity (the network) mediate
this interaction so that hosts cannot unilaterally shift charges to other
hosts.

The main problem with this method is that it depends on having an
identifiable "connection" that is recognizable by the network billing
routines.
 -WBE

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 88 18:46:39 GMT
From:      espo@bpa.BELL-ATL.COM (Bob Esposito)
To:        comp.protocols.tcp-ip
Subject:   Internetworking with TCP/IP


	I received my copy just last week from Prentice Hall and its
	really a comprehensive view of the TCP/IP technology and
	the Internet.

	Although I'm only half-way finished, I would suggest getting
	a copy for your technical reference library.  It has some great
	appendices explaining terms, RFC references and much more.

	Douglas Comer did a fine job with this one!!!


-- 
Bob Esposito, Bell of Pennsylvania     uucp: {rutgers|cbmvax|bellcore}!bpa!espo
A Bell Atlantic Company              domain: espo@bpa.bell-atl.com
Philadelphia, PA.                     phone: +1 215 466 6831
===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 88 20:24:14 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Packet Accounting (long)

I have some further comments on the per packet accounting policy
issue.  I have excerpted comments from Vint Cerf, Jack Haverty, and
Barry Shein in my rather longish reply.
-----------------------------------------------------------------
	From CERF@A.ISI.EDU Sun Apr 17 12:06:31 1988
	Kent,
	Your flames seem a bit excessive (but I suppose that's a tautology...).

Given.  I am beginning to think that flames on lists like tcp-ip are
out-of-date and that I should never flame on a list with an audience
as large and diverse as this list.  This reply is an effort to douse
the flame and sound like a reasonable person.
	
	The issue of accounting becomes more significant as the
	services rendered become less research/experimental and more
	like commodities.  Telephone services such as the Federal
	Telephone System run by the GSA are cost-allocated in
	accordance with usage and one doesn't find it odd to pay for
	telephone calls on the basis of time and distance.
	
Well, distance is an historical rationale for charging.  I subscribed
at one time to Satellite Business Systems' long-distance service.
They charged a rate that was distance insensitive, arguing that since
it was satellite service, distance was not a true cost basis.  On the
other hand, time is still an obvious resource in a switched circuit
network.  There is no technical reason to do it one way or the other.
You pick a method that your customers and auditors will find
acceptable.  My basic argument is that chargeback is isolated from
network technology, except as used in arguments of equitability and
fairness. 

	The parameters for packet nets may be different than for
	telephone voice service (maybe no distance charges). The
	important thing for the parties involved is to be able to
	demonstrate that there is a reasonable sharing of costs.  One
	attractive thing about basing charges on usage is that as
	total usage goes up, it may be possible to make capital
	investments to increase capacity in a way that doesn't
	specifically require that all parties make an agreement to
	acquire more equipment - the service provider can buy it on
	the basis of increased usage and spread the cost in a
	reasonably equitable fashion.

Equity seems to be a key concept here.  Of course, equity depends on
the perception of those involved and implies that the rationale is
understandable and "natural".  The idea of using ramping usage charges
as a capitalization tool had not occurred to me; it is an idea with merit.
		

	From haverty@CCV.BBN.COM Sun Apr 17 18:55:17 1988
	Vint et al,
	In addition to these 'engineering' kinds of decisions, the
	network must make 'marketing' decisions.  For example, it
	might price a new service "unfairly" low, in order to
	encourage clients to upgrade (maybe mail should be cheaper if
	one uses the full domain server system?).  There are also
	costs associated with "marketing", such as advertising (NIC
	management bulletins?)
	
	As far as charging algorithms go, that is the province of the
	hypothetical marketing department - how do I price my product.
	In the context of the current mail discussion, I think it is
	best to assume that somehow all of the costs must be recovered
	by charges, including costs for investments for the future.
	The real question is how to use a pricing policy to encourage
	the desired behavior.

I think your point about looking at chargeback as a marketing issue is
particularly apropo.  I think that puts the best light on the subject.
Your argument begs the question, though, of "Will the charges from my
external network vendor [the Internet] unduly constrict or restrict my
ability to implement my own internal chargeback policy?"  It should not.

There is a difference, in my thinking, between the actual installation
and recurring cost structure of something like a LAN and an artificial
recovery model like a per-packet charge.  Actual costs to install and
maintain a LAN are fixed on a per-network and per-node basis rather
than a per-packet basis.  Of course, you can use either model to
recover cost, but my point is that per-network, per-node is more
natural and much easier to administer.  I argue that the bean-counters
should not be allowed to extend an improper model to LAN cost
recovery.  We should try to get them to accept another model, by
arguing in their own financial or marketing terms.  This assumes that
we stay ahead of user bandwidth need and that there is always
sufficient (I would recommend excessive) amounts of bandwidth, so that
the question of scarce resources is not involved in the LAN model.  If
your Ethernet backbone is limited, go to FDDI, but don't adopt a new
and restrictive cost model just to get through a temporary phase of
technology transition.  Is this whole issue of chargeback merely a
temporary phase?  Once we have "unlimited" bandwidth again, will the
arguments for chargeback evaporate or will we be left with an obsolete
legacy to overcome when wide area networks are as open as today's
local area networks?  Don't hamstring the technology of tomorrow with
an inadequate policy today.  Another way to put this is to say, let's
decouple the WAN chargeback from the LAN chargeback issue.  Both costs
need recovery, but with different models.
	
	From: bzs@BU-CS.BU.EDU (Barry Shein)
	At the very least it would be interesting to hear what the
	goals are that people expect to accomplish with their proposed
	chargeback models, it's nice to have explicit goals and see if
	the models actually achieve them.
---------------------------------------------------
	
Seems we have some goals already:

	o  complete cost recovery
	o  simple recovery formula
	o  "natural" and "understandable" algorithm for cost recovery
	o  equitable allocation of costs across our client base
	o  capital recovery/generation for investment in new technology
	o  decoupling between WAN cost recovery model and LAN cost
	   recovery model


I hope this helps forward the discussion.

	Kent England, Boston University

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 88 22:33:14 GMT
From:      daveb@llama.rtech.UUCP (Crack?  No thanks, I've got a new CD player)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong's TN3270

In article <8804182349.AA29557@ucbvax.Berkeley.EDU> eva@TWG.COM writes:
>2/  TN3270 is currently available only with EUNICE, not WIN/TCP. It requires
>    "libcurses" library which is not supported under WIN/TCP, due to the 
>    requirement for a UNIX license.

This is specious.  There are a number of PD curses packages lying
around. There must be another real reason.  Could it be... 

-dB
{amdahl, cpsc6a, mtxinu, ptsfa, sun, hoptoad}!rtech!daveb daveb@rtech.uucp

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Apr 88 06:36 PDT
From:      Michael Stein    <csysmas@UCLA-CCN.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   packet charging (the EFT model?)
Instead of a "WILL/WONT PAY" protocol (which only works on
connections) how about something else:

Suppose that it was possible to send packets containing "money"?

This might be the IP level equivalent of "reverse charges" (since
IP packets aren't related like traffic on a connection).

The idea is that the "network" charges for packets sent (not
new), but will also allow a packet to transfer "money" from the
sender to the target  This could show up as a charge on the bill
to the sender and a "refund" on the bill of the target.

Thus a UDP request to a name server should contain the money
for the reply (or else it's likely there won't be a reply).

It is clearly possible to build a "reverse charge" connection
level protocol on top of this by having one side request
(demand?) "money" to continue.

Note however that much more is possible:

  o either side could pay the whole cost or they could
    split it in any way

  o this also works for 3 (or more) party traffic (it's possible
    to receive "money" and send it out to someone else).

  o this also works across time, I can send payment now for
    something you will do later (time to renew your subscription
    to TCP-IP?)

  o since "money" is general, other net-wide resources could
    also be handled

This can't be practical, can it?

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 88 23:55:34 GMT
From:      ospwd@emory.uucp (Peter Day {EUCC})
To:        comp.protocols.tcp-ip
Subject:   RIP, gated


How can I get more specific information about the Routing Information
Protocol (RIP) used by Proteon, and gated, a demon which translates
between RIP and EGP, the External Gateway Protocol?
     
Although I would like the details of the protocols, I at least need as
complete a functional description as I can get.

Please send replies directly to me and I will summarize for the
list.
     
Thanks,
Peter Day
Emory University
Bitnet: ospwd@emuvm1
CSnet: ospwd@emoryu1.arpa
UUCP: ...!gatech!emoryu1!ospwd

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 00:28:40 GMT
From:      bob@ultra.UUCP (Bob Beach)
To:        comp.protocols.tcp-ip
Subject:   Maximum sized IP packets

In looking through the IP RFC, I noticed that IP allows up to a 64K byte
datagram. I was wondering how many implementations of TCP/IP are
actually capable of handling such a large datagram. Such a datagram would
have to fragmented since no subnets that I know of support packet sizes
that big, so I guess the real question is: what implementations can reassemble
a 64K IP datagram that has been previously fragmented. 

A second question is: if the 64K datagram size is, in the words of the RFC
"impractical", what is "practical"? 4K, 8K? I have heard rumors that many
implementation don't support reassembly at all. Is this true?

A third question is: given some implementation can reassemble 128 (or so)
576 byte packets into one big 64K datagram, how likely is it that all
128 would arrive at the destination node. The destination could be either a
host on the Internet or on a local Ethernet. 

-Bob Beach
 Ultra Network Technologies

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 10:07:00 PST
From:      <art@acc.arpa>
To:        "kwe" <kwe@bu-cs.bu.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   NSFNet Routers

>	I found the Data Comm article intriguing.  I haven't heard
>anything on usenet or the internet regarding the new NSFnet router
>architecture.  Could someone point me toward a journal article, trade
>rag article, or other source where I could learn something about how
>these new RTs route?

There is a document from MERIT titled "Management and Operation of the
NSFNET Backbone Network" that describes the new NSFNet backbone.

>	If there is nothing in print, I would like to invite someone
>from MERIT or other knowledgable developer to post something about how
>these RTs work compared to some plain vanilla (:-) router like a
>cisco, a proteon, a fuzzball, or homegrown router.

There was a presentation by IBM at the last IETF mtng, and I'll try to
summarize from memory.

The NSFNet Router nodes will consist of a cluster of IBM PC/RTs running
a BSD 4.3 derivitive.  The RTs will be interconnected via token ring.
Most of the RTs will be Packet Switching Processors (PSP) and will
typically be connected to the high speed serial backbone trunks or to
Ethernets of the regional networks.  Each of the PSPs will route using
it's local kernel routing table.  A couple of the RTs will be running
an SPF based routing protocol derived from the DEC routing protocol that
ANSI is submitting to ISO.  These Routing Control Processors (RCP) will
pass the current routing information to each of the PSPs for updating
of their local routing tables.  I believe that the backbone will talk EGP
to the regionals. (somebody correct me if I'm wrong)

					Art Berggreen
					art@acc.arpa

------
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 04:08:41 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   another thought on packet charging


[I think this gets more interesting in the second half]

How exactly does packet accounting work? Being as it's so low level
does it just charge the source address? Or do we distinguish between
servers and clients (for example) to direct charges?

Case 1:

You FTP to my system to get a file. You are the client. I guess it
seems clear that you should pay so "charge the client" seems
reasonable.

Case 2:

I connect to your system to deliver mail being forwarded through me. I
am the client. But it seems you should pay for the packets, no? Charge
the client doesn't seem right.

We won't even talk about UDP.

If we just charge on source address then I guess I still end up paying
to give you your mail or expand a mailing list etc.

Does anyone have a proposed set of rules that are better than these?

[SECOND HALF]

About the only thing that comes to my mind is a meta-protocol (ICMP?)
sort of like a WILL YOU/WONT YOU:

	WILL YOU PAY? ->
	<- YES/NO

	I WILL PAY->
	<- GOOD

which occurs on each connection ramp-up.

Hmm, perhaps we can extend the ethernet "cocktail party" metaphor to a
"picking up the check" metaphor. Maybe should add "DUTCH TREAT?".

(does this lead to bistro mathematics?! [see Douglas Adams].)

	-Barry Shein, Boston University

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 05:22:25 GMT
From:      phil@BRL.ARPA (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  [Phil Dykstra: more interesting numbers]

The numbers that I posted for the NSFNET fuzzies the the ARPA/MILNET
Core gateways were for the week ending 21 March 88 (and came via Dave
Mills).  Only one of the mailbridges and five EGP speakers had been
upgraded to 11/73's at that time.  It would be interesting to see
how they have improved.

The numbers for the BRL gateway came from ~48 hours ending 30 March 88.
That gateway has three ethernets, one 10 Mbit proteon ring, and two
1822 IMP connections (one MILNET, one local).  Packet counts were
half of in+out and included everything to/from the interfaces - EGP,
ICMP, etc., included.  If I had been posting to this list originally
I would have spoken a bit more carefully.

To answer/comment-on a few replys:

> Mike Brescia
> ... "average" throughput is a measure of packets actually offered over the
> course of the day or week reporting period, ....
> ... is a measure of handling offered load rather than limitation.

Good point.  They were all long term averages.  For the record I believe
that we all agree that "one packet" goes both in and back out of a gateway.
Most vendors seem to count that as two, for obvious reasons.

> Phill Gross
> Do we understand why the mailbridges have such a higher drop rate?

Mike Brescia mentioned a few possible reasons.  Another, which I have
heard about but don't know any details of, is a claim that the Core
gateways maintain max queue lengths of eight packets per destination
subnet (I would presume to avoid overloading the PSN's).  That probably
causes many more drops than a more generous gateway would have (unless
there are only PSN's connected to it and they return the favor).

> Dave Mills
> I would like to believe the difference in drop rates is due to the design
> of the NSFNET backfuzz selective-preemption and source-quench schemes.

I note however that your numbers went from good to excellent.  I am hoping
to be able to test that theory by playing the same game locally.

- Phil
<phil@brl.arpa>

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 05:25:03 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on Apollo Domain systems

I am bringing up an Ethernet LAN running TCP/IP.  One of the hosts is
an Apollo Domain system that runs BSD4.2.  Can anyone provide me with
the following information:

1.  What Ethernet interfaces are supported (we were told to get a
    3Com Etherlink+)?
2.  What additional software is required, if any?  (obviously a driver
    for the Etherlink+ is needed.)
3.  What are the formats for the /etc/hosts /etc/networks/ and
    /etc/gateways files?

Please reply directly to me.  Thanks.

Brian Lloyd, President
Sirius Systems, Inc.
19200 Tilford Way, Germantown, MD 20874 
(301) 540-2066
brian@wb6rqn.uucp
Share and enjoy!

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 05:25:37 GMT
From:      phil@BRL.ARPA (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  [Phil Dykstra: more interesting numbers]

> Who is responsible for the remaining traffic?

Good question.  I would wager a bet that it is the old GGP induced
"extra-hop" problem.  Speaking EGP on the MILNET side of the world
I can't verify this in your case, but here is an example of this very
bad phenomena in action on this half of the core system.

Several weeks ago a typical set of EGP routes received from MINET-GW
(a MILNET Core EGP speaker) looked like this (summarized by number of
routes per gateway):

 # routes  Example net     Gateway
   307     10.0.0.0        26.0.0.106       Random "mailbridge"
    19     128.165.0.0     26.3.0.75        EGP speaker (YUMA-GW)
    18     128.171.0.0     26.1.0.65        EGP speaker (AERO-GW)
     7     128.56.0.0      26.3.0.29        BRL gw1
     6     128.20.0.0      26.2.0.29        BRL gw2
     4     128.115.0.0     26.6.0.21
     4     128.102.0.0     26.4.0.16
     3     128.60.0.0      26.20.0.8
     3     128.229.0.0     26.0.0.103
     2     129.43.0.0      26.0.0.88
     2     128.47.0.0      26.5.0.60
     2     128.122.0.0     26.0.0.58
     1     192.5.13.0      26.2.0.55
     1     192.31.98.0     26.5.0.129
    ... many more single route entries ...

The mailbridge 26.0.0.106 happened to be the "choice of the day" for
routes via the ARPANET.  Seeing a very large number of routes to a
single mailbridge is quite common; it changes every few hours or days.
[I would like by the way to hear if this is load balanced on a per
peer basis or something, or if everyone on a given EGP speaker gets
the same selection.]

But the real problem is the 37 routes to the Core EGP speakers!  We
got these routes by polling the MINET gateway, and MINET did what
it was supposed to do - never gave ITSELF as a route to anything.
Any exterior gateway which advertised its routes to MINET came out
correctly.  However, >>> any exterior gateway which advertised its
routes to YUMA and/or AERO but not to MINET (i.e. not to the EGP
peer that we polled), showed up as reachable via (one of) the EGP
peer(s) that they spoke to! <<<

This is a serious problem, because besides the sillyness of inducing
an extra "hop" to reach those networks, it also directs a large amount
of traffic to the Core EGP speakers - something which BBN(?) has been
trying to avoid!  Thus to answer Thomas Narten's question (I gather
that the machine in question is an ARPA-side Core EGP speaker): The
traffic is probably "extra-hop problem" induced.

How It Happens (in brief - those that know this can skip it):

Internal to the Core system GGP is used to communicate route information.
A GGP speaker can only say "I CAN REACH netX", not HOW. EGP on the other
hand says "I CAN REACH netX VIA gateY."  When you speak EGP to one of
the Core EGP speakers, he learns how to reach your nets VIA your
gateway.  If you ask that same EGP speaker how to get to netX you will
get the "correct" answer - gateY.  However, if you ask a *different* EGP
speaker, his knowledge of the network in question came via GGP in which
the first Core EGP speaker simply said "I CAN REACH netX."  The HOW
part, i.e. the gateway that advertised netX in the first place has been
dropped (due to this GGP limitation).  Thus someone receiving this
information will end up (needlessly) sending packets to the Core EGP
speaker netX was advertised to, rather than to the gateway that
advertised it.

How To Avoid the Problem:

You can prevent others from getting extra-hop routes to YOU by advertising
your nets to all available EGP speakers.  You can avoid getting extra-hop
routes to someone else by polling all available EGP speakers for routes
and favoring those routes that DON'T point to an EGP speaker.  [The real
solution of course is to fix GGP.]

Of course if everyone did the above the EGP speakers would be all the
more loaded.  One could also question at that point why there was more
than one EGP speaker.  One the other hand, licking the extra hop problem
might get a lot of unnecessary non-EGP traffic off of the EGP speakers.
It's hard to tell where the balance would lie.  [It is interesting to
note in the recent timetable how the EGP speakers were upgraded before
most of the mailbridges were.]

My apologies for such a long winded answer, but has been a long time
since anyone discussed this problem on this list.

- Phil
<phil@brl.arpa>

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 1988 10:02-EDT
From:      CLYNN@G.BBN.COM
To:        ultra!bob@AMES.ARC.NASA.GOV
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Maximum sized IP packets
Bob,	I have sent and reassembled datagrams up to about 28K bytes
on the TOPS-20;  I never tried the 64K experiment.  The size of the
datagram makes the probability of at least one lost fragment
approach 1.0.  In such cases, the reuse of IP ID by the transport
layer (e.g., TCP, UDP) is very important, and the way the network
driver sends the group should be considered carefully (e.g., leaving
a little time between successive fragments (both to prevent back-to-
back packets and to give others a chance to use the resources));
the relationship between IP TTL and transport retransmission timeouts
and exactly how IP reassembly timeout is handled makes a big difference.

What is practical depends on the environment, and the implementation(s).
There is "no problem" across the ARPANET or MILNET as they have high end-
to-end reliability;  there is a problem across the ARPANET and the MILNET
(the gateway queues between them).  There should not be significant problems
across a (segmented) lan.  If monstergrans are IMPORTANT, we can write the
software to get them through, but there is a high penalty in wasted
bandwidth and cpu cycles if retransmissions are required.

Charlie
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 07:03:00 GMT
From:      efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY")
To:        comp.protocols.tcp-ip
Subject:   Need Mail / TCP-IP for HP3000 under MPE V


------------------------------------------------------------------------
# Date:     Wed, 20 Apr 88 19:06:41 PDT
# From:     efbatey (4V33,x5881 Everett F Batey II) @ tervax
# Reply-To: <efbatey@NSWSES.ARPA>
# Subject:  HP3000/MPE_V/HP-Office to TCP-IP
# Comment: < USNSWSES*SOCALSunLUG*DECUS*805/982-5881/983-1220 >

I have 2 dozen P3000s with HP'sMPE_V operating system and HP Office / Desk.
All my other hosts talk DECNet AND / OR TCP-IP .. I need a mail bridge and 
preferrably full TCP/IP Mail and TELNET/FTP .. I would probably commit a major
felony for some good leads .. enet cards to replace RS232 and software ...

         ------------------------------------------------------------
         | Everett F. Batey II    } { UUCP:  sun!tsunami!nswed5!efb |
         | USNSWSES - Code 4V33   } { ARPA:  efbatey@NOBBS.UCSB.EDU |
         |   After HOSTS.TXT.726  } {        efbatey@NSWSES.ARPA    |
         ------------------------------------------------------------

------

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 13:27:03 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   64K octet datagrams

Sirius Systems' implementation of TCP/IP for the Convergent Technologies
workstations (the product is called Internet-CT) theoretically will
support 64K octet datagrams if you allocate sufficient memory to hold
such a datagram at service installation time (the size of the memory
pool is user configurable when the transport service is installed,
usually at system boot time).

We have never run into a situation where anyone wanted to send a
datagram that big and have never tried to send one that big but there is
nothing in the code to prevent it either.

Brian Lloyd, President
Sirius Systems, Inc.
19200 Tilford Way, Germantown, MD 20874 
(301) 540-2066
brian@wb6rqn.uucp
Share and enjoy!

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 13:36:00 GMT
From:      csysmas@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   packet charging (the EFT model?)

Instead of a "WILL/WONT PAY" protocol (which only works on
connections) how about something else:

Suppose that it was possible to send packets containing "money"?

This might be the IP level equivalent of "reverse charges" (since
IP packets aren't related like traffic on a connection).

The idea is that the "network" charges for packets sent (not
new), but will also allow a packet to transfer "money" from the
sender to the target  This could show up as a charge on the bill
to the sender and a "refund" on the bill of the target.

Thus a UDP request to a name server should contain the money
for the reply (or else it's likely there won't be a reply).

It is clearly possible to build a "reverse charge" connection
level protocol on top of this by having one side request
(demand?) "money" to continue.

Note however that much more is possible:

  o either side could pay the whole cost or they could
    split it in any way

  o this also works for 3 (or more) party traffic (it's possible
    to receive "money" and send it out to someone else).

  o this also works across time, I can send payment now for
    something you will do later (time to renew your subscription
    to TCP-IP?)

  o since "money" is general, other net-wide resources could
    also be handled

This can't be practical, can it?

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 14:02:00 GMT
From:      CLYNN@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Maximum sized IP packets

Bob,	I have sent and reassembled datagrams up to about 28K bytes
on the TOPS-20;  I never tried the 64K experiment.  The size of the
datagram makes the probability of at least one lost fragment
approach 1.0.  In such cases, the reuse of IP ID by the transport
layer (e.g., TCP, UDP) is very important, and the way the network
driver sends the group should be considered carefully (e.g., leaving
a little time between successive fragments (both to prevent back-to-
back packets and to give others a chance to use the resources));
the relationship between IP TTL and transport retransmission timeouts
and exactly how IP reassembly timeout is handled makes a big difference.

What is practical depends on the environment, and the implementation(s).
There is "no problem" across the ARPANET or MILNET as they have high end-
to-end reliability;  there is a problem across the ARPANET and the MILNET
(the gateway queues between them).  There should not be significant problems
across a (segmented) lan.  If monstergrans are IMPORTANT, we can write the
software to get them through, but there is a high penalty in wasted
bandwidth and cpu cycles if retransmissions are required.

Charlie

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 15:00:30 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   bad press for NSFNET

In response to Kent England:
?>       If there is nothing in print, I would like to invite someone
?> from MERIT or other knowledgable developer to post something about how
?> these RTs work compared to some plain vanilla (:-) router like a
> cisco, a proteon, a fuzzball, or homegrown router.
The routing algorithm internal to the backbone is an implementation of
the ANSI IS-IS Intradomain routing proposal.  In a nutshell, it is an
SPF variant with stable link metrics (assigned by "system management,"
which could be human or electronic).  Reachability of routers and
networks are flooded throughout the backbone.
 
EGP is used to pass reachability info between the backbone, the
regionals, and the ARPAnet.  Various filtering tricks are used to
try to ensure that ARPA routes don't leak out into the regionals,
for example.  Tables of potential EGP announcements are used to
ensure that bogus info is not imported from the regionals.
 
The routing algorithm is documented in ANSI X3S3.3/87-150R, which
we will be making available for anonymous FTP once the NSFnet
Info Services machine is in production.  Local adaptations of
the algorithm to DOD IP and the EGP mechanisms will likely be
published in a paper once the panic subsides a little.
 
Dave Katz, Merit/NSFnet

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 15:46:51 GMT
From:      dennis@pastram.UUCP (Dennis Norkus)
To:        comp.databases,comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc
Subject:   DDN,LAN and Advanced Revelation.


We are in the process of developing a system on a Local Area Network using
Advanced Revelation as the DBMS. Passenger movement requirements will come
in from Installation Transportation Offices through the Defense Data Network
(DDN) to the LAN. Requests for service and offers for service will be a file
transfer  process with approximately 10 carriers/associations in the 
Washington D.C. area.  Without getting into any more specifics, we would be
interested in hearing about any general type problems one might think
we'll encounter or your opinions regarding: Novell LAN, Advanced Revelation,
DDN.
--
Dennis Norkus 		uucp: pastram!dennis   
			arpa: kanti@optimis-pent.arpa

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 16:14:01 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

In article <SRA.12391999638.BABYL@XX.LCS.MIT.EDU> SRA@XX.LCS.MIT.EDU (Rob Austein) writes, and I edit:
...
>2) Provide some negative feedback (that's a technical term, not a
>   normative statement) so that users will make "efficient" use of
>   the available network resources.
 ...
>I submit that, at the moment, the two most critical resources on the
 ...
>  Perhaps some of the income can be used to increase the
>numbers of trunks and core gateways until they can adaquately handle
>the load.

Another possibility: Charge users heavily for the use of the
bottlenecks (whatever they may be at the time).  Use the resultant
income to FIX the bottlenecks.  Theoretically (and in a perfect world :-)
this will result in a network in which the load is spread evenly and
there are no bottlenecks.

Implications:
  o Short term bottlenecks due to down equipment should not be charged for,
    unless they recur, at which point they become long term bottlenecks.
  o The cost model is apparent to anyone who wants to do some pinging.  Of
    course, they'll pay for their curiosity.
  o A site could easily run up a big bill unless the accounting is done in
    a timely manner.  Without timely negative feedback, you can get into
    oscillations.
  o This still doesn't address who pays for which packets, just the amount
    charged for each packet.
  o Maybe a nominal fee for each packet to cover general costs?

    
-- 
char *reply-to-russ(int network) {
if(network == BITNET) return "NELSON@CLUTX";
else return "nelson@clutx.clarkson.edu"; }

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 16:45:55 GMT
From:      rsalz@bbn.com (Rich Salz)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong's TN3270

In article <8804182349.AA29557@ucbvax.Berkeley.EDU> eva@TWG.COM writes:
>2/  TN3270 is currently available only with EUNICE, not WIN/TCP. It requires
>    "libcurses" library which is not supported under WIN/TCP, due to the 
>    requirement for a UNIX license.
VMS has had a curses library for over a year (that's as far back as I go
with VMS).  While it has some bugs, it is quite possible to work around
them and write full-screen character-at-a-time programs without too
much pain.  We've got some in the Cronus project.

Better double-check what the "real" reason is.
	/rich $alz
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 16:48:07 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Internetworking with TCP/IP

In article <582@bpa.BELL-ATL.COM> espo@bpa.BELL-ATL.COM (Bob Esposito) writes:
>
>	I received my copy just last week from Prentice Hall and its
>	really a comprehensive view of the TCP/IP technology and
>	the Internet.
>
>	Douglas Comer did a fine job with this one!!!

	Comer's books are available from the Library of Computer and
Information Sciences (LCIS) book club.  I bring this up because some
people were having trouble getting Stallings book set in a timely
fashion.  I'm not sure that people will have trouble with Comer's
books, but it might be a good idea to look into LCIS if they are going
to do a good job tracking unix/tcp-ip leterature.

	I subscribe, but have no other interest in LCIS.

	Kent England, Boston University

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 16:55:52 GMT
From:      jwabik@shamash.UUCP (Jeff Wabik)
To:        comp.protocols.tcp-ip
Subject:   Which version does Sun run?

Does anyone know which version of tcp-ip is implemented in the standard
Sun OS (Sun UNIX 3.x) ?  802.2?  802.2/snap?  802.3?

Thanks in advance .. 

	-Jeff

---
Jeff A. Wabik    UUCP: {rosevax,umn-cs,meccts,ems}!shamash!jwabik  
  ____  ____     ARPA: jwabik@ub.d.umn.edu    NSFNET: jwabik@shamash.cdc.com
 / ___||___ \   
| |___  ___| |   Control Data Corporation - Better living through 64 bits.
 \____||____/  
		  	   Live long and program.

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 17:14:25 GMT
From:      haas@utah-gr.UUCP (Walt Haas)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet accounting and a place to do it

It seems to me that the most sensible way to do packet accounting is
the way that the public networks (Telenet, Tymnet) do it - that is,
all packets on a virtual circuit are charged to whoever established
that VC unless the call was placed and accepted as "collect", in which
case the recipient pays for it.  So if I had a public-domain database
of general interest, I could make it available to anyone for anonymous FTP
without concern that there would be a sudden explosion of my network
packet charges - because whoever called in to copy my data would end up
paying for the haulage.

To be perfectly honest, I can't see any reason to reinvent a wheel
that currently works just fine.

Cheers  -- Walt Haas    haas@cs.utah.edu    utah-cs!haas

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 18:07:00 GMT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   NSFNet Routers


>	I found the Data Comm article intriguing.  I haven't heard
>anything on usenet or the internet regarding the new NSFnet router
>architecture.  Could someone point me toward a journal article, trade
>rag article, or other source where I could learn something about how
>these new RTs route?

There is a document from MERIT titled "Management and Operation of the
NSFNET Backbone Network" that describes the new NSFNet backbone.

>	If there is nothing in print, I would like to invite someone
>from MERIT or other knowledgable developer to post something about how
>these RTs work compared to some plain vanilla (:-) router like a
>cisco, a proteon, a fuzzball, or homegrown router.

There was a presentation by IBM at the last IETF mtng, and I'll try to
summarize from memory.

The NSFNet Router nodes will consist of a cluster of IBM PC/RTs running
a BSD 4.3 derivitive.  The RTs will be interconnected via token ring.
Most of the RTs will be Packet Switching Processors (PSP) and will
typically be connected to the high speed serial backbone trunks or to
Ethernets of the regional networks.  Each of the PSPs will route using
it's local kernel routing table.  A couple of the RTs will be running
an SPF based routing protocol derived from the DEC routing protocol that
ANSI is submitting to ISO.  These Routing Control Processors (RCP) will
pass the current routing information to each of the PSPs for updating
of their local routing tables.  I believe that the backbone will talk EGP
to the regionals. (somebody correct me if I'm wrong)

					Art Berggreen
					art@acc.arpa

------

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 18:14:57 GMT
From:      bob@loihi.hig.hawaii.EDU (Bob Cunningham)
To:        comp.protocols.tcp-ip
Subject:   RG58C/U hard to get?

Two years ago I had to wait 8+ months to get a few thousand feet of
RG58C/U (the real stuff, Belden number 8262).  Since then I've been
getting good delivery...until my last order that I've been waiting
four months for.

We can and do use RG58A/U in lieu, but there are some places where I
really want to use C/U.  Is this a common problem, or might it be just
the Belden distributor here?  If you get reliably-good delivery, who do
you order from?


Bob Cunningham
bob@loihi.hig.hawaii.edu

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 18:29:06 GMT
From:      sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden)
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

The biggest single argument against chargeback is that is does NOT take
into account the value of the network as a substrate for some greater
activity. In terms of the volume of business on the DARPA side of the
Internet, I suspect that the biggest users, who are, most probably,
the biggest contributors to the evolution of the network, are hardly
the deepest pockets, and this includes the many universities and research
groups that provide software such as the recent TCP/IP updates to Unix,
without charge to the users. There is no fair way to measure this
contribution (unless we put it to a quorum), or to predict from where will
the next significant contribution come.

If the network were an end in and of itself, a chargeback policy based
on usage would be quiet reasonable. Under a Libertarian system of government
it would also make sense, but many other programs aimed at a greater good
are not billed on the basis of usage but on the basis that the good to
society represents a greater "fairness" than billing on a usage basis.

A previous author, in criticizing my highway analogy, actually argued
in favor of my point by noting that toll road was less utilized than
the alternate routes which were subsidized by taxation rather than
usage tax (except indirectly, by gasoline taxes). The arguement here
is that there is a societal good which justifies the expenditure of
public funds without regard to direct usage. In the sense that this
benefits all of us, independent of our ability to pay, one might
argue that it is more benevolent than a system which is more "fair".

The problem with many policy-makers is that they love to deal with
numbers and go to great pains to quantitize any problem so that they
can deal with it using well established (if unimaginative), numeric
systems. There is a qualitative issue here, which deals with our
economic and technologic competitive edge as a function of information
sharing, which cannot easily be reduced to a scalar. We have an obligation
to study that thoroughly before we institute the policies of some
pencil pusher who needs to show some federal budgeteer a black line that
puts them in the clear and forces the rest of us to deal within the
limits of short sighted policy-makers.

I agree that a study should be done, but participants should not be
limited solely to knife wiedling accountants and the clever technocrats
who have demonstrated that we have the technology to institute such
as system as packet accounting, but also to those people who are able
to see how our future as developers and users of this technology
and as a nation, would be best served.

Sean McLinden
Decision Systems Laboratory
University of Pittsburgh

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 20:39:15 GMT
From:      ted@blia.BLI.COM (Ted Marshall)
To:        comp.protocols.tcp-ip
Subject:   Re: packet lengths

In article <8804191854.AA00089@apolling.imagen.uucp>, geof@imagen.UUCP (Geof Cooper) writes:
> The Ethernet requires that packets be an integral number of 16-bit words
> long.

Sorry, no. An integral number of 8-bit octets, not 16-bit words. Quoting from
page 19 of the version 1.0 Ethernet specification:

	Figure 6-1 shows the five fields of a frame: the addresses of the
	frame's source and destination, a type field [...], a data field
	[...], and the frame check sequence [...]. Of these five fields,
	all are of fixed size except the data field which my contain any
	integral number of octets between the minimum and maximum values
	^^^^^^^^^^^^^^^^^^^^^^^^^ [ ^'s are mine. TM]
	specified below (see 6.2.5).

Figure 6-1 shows the layout of a frame and also of an octet (showing 8 bits,
transmitted LSB first).

I don't have a copy of the 2.0 spec, but I don't think they changed this. If
they did, DEC is breaking the spec; I know that the VAX/VMS Ethernet cards and
drivers allow odd-byte-count length packets to be sent.

That is not to say that every Ethernet interface manufacturer built their
unit so that it can transmit an odd number of bytes. In fact, I believe that
there are some that can only transmit multiples of 4 bytes.

In general, no Ethernet protocol should be used that depends on the data
link layer to report exactly the number of bytes in the packet since
short packets must be padded to the minimum size.

-- 
Ted Marshall       ...!ucbvax!mtxinu!blia!ted <or> mtxinu!blia!ted@Berkeley.EDU
Britton Lee, Inc., 14600 Winchester Blvd, Los Gatos, Ca 95030     (408)378-7000
The opinions expressed above are those of the poster and not his employer.

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 88 20:41:02 GMT
From:      wbe@bbn.com (Winston B Edmond)
To:        comp.protocols.tcp-ip
Subject:   Re: another thought on packet charging

Barry Shein writes:
>Does anyone have a proposed set of rules that are better than these?
>
>[SECOND HALF]
>
>About the only thing that comes to my mind is a meta-protocol (ICMP?)
>sort of like a WILL YOU/WONT YOU:

This (transfer of charges on request) is essentially what I proposed in my
previous message.  The main difference is that I claim the protocol should be
between the hosts and the network (the entity collecting the billing
information) and not between the hosts directly.  What's important to the
host trying to reverse the charges is that the network says billing has been
transferred, not that the other host has made a promise to accept the bill.
-WBE

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Apr 88 08:45:03 PST
From:      geoff@fernwood.mpk.ca.us (Geoff Goodfellow)
To:        tcp-ip@sri-nic.arpa
Subject:   re: packet charging (EFT model), others.
i'd like to propose that methods of reverse charging or the negotiation thereof
become known as The Internet Buck Passing Protocol.
geoff


-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 1988 07:57-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        haas@GR.UTAH.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Packet accounting and a place to do it
	
    Date: 21 Apr 88 17:14:25 GMT
    From: haas@gr.utah.edu  (Walt Haas)
    To: tcp-ip@sri-nic.arpa
    Subject: Re: Packet accounting and a place to do it
    
    It seems to me that the most sensible way to do packet accounting is
    the way that the public networks (Telenet, Tymnet) do it - that is,
    all packets on a virtual circuit are charged to whoever established
    that VC unless the call was placed and accepted as "collect", in which
    case the recipient pays for it.  ....
    
    Cheers  -- Walt Haas    haas@cs.utah.edu    utah-cs!haas
    
	      --------------------
		
One small problem with this approach - during the life of a TCP
connection, many X.25 connections may come and go.  The X.25
connections may be closed down due to idleness or resource
reallocation, and may be reopened from either end of the pipe.  Also,
an X.25 connection may carry data from more than one TCP session.  And
it may also have UDP traffic mixed in.  Who gets the bill?

Mike
-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 03:14:53 GMT
From:      fedor@NISC.NYSER.NET (Mark S. Fedor)
To:        comp.protocols.tcp-ip
Subject:   Re: bad press for NSFNET


	Kent,

	Your are indeed brave!  The NSFNet routing scheme (RT routing)
	is not for the week of heart!  I could mail you relevant papers
	if you need them.

	Mark`

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Apr 88 10:49:15 PDT
From:      Mark Crispin <MRC@PANDA.PANDA.COM>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Packet accounting
     Walt Haas' idea certainly makes the most amount of sense, provided
that the concept of a "VC" under IP can be clearly identified to the
accounting processes.  It's a bit harder for UDP than TCP, but it still
can be done.  It is important that only packets which are delivered to
the destination are charged.  I won't worry about packets getting dropped
at a site's LAN -- if they have a too-high drop rate then it's their own
responsibility to fix their LAN/gateway!!!

     This seems to be a reasonable model for a typical "service host":
 . Telnet - accept collect calls (since the site is presumably already
	billing the customer and network charges can be easily added to
	the bill ala CompuServe, etc.)
 . FTP - accept collect calls for login FTP.  Create a *new* FTP service
	for non-login (ANONYMOUS) FTP that does not accept collect calls.
 . Mail - do not accept collect calls for ordinary mail.  Create a *new*
	mail service for bulk-distribution (mailing list, newsgroup,
	etc.) mail which does accept collect calls.

     The idea behind such a model is that the service host is charged
for network traffic only when those charges can be clearly passed on to
a customer of that service host.  When an external agent is benefiting
from access to the service host (e.g. ANONYMOUS FTP) that agent foots
the bill.  In mail, I follow the model of postal mail in that the sender
puts the stamp on the mail.  The "bulk-distribution" service is sort of
a misnomer; a better name would be "collect mail".  A site which doesn't
want such mail can simply not offer the service; of course such a site
may miss out on mailing lists, newsgroups, file transfer via mail, etc.
It would be up to the site to decide upon how to handle the charging.
One way would be to have a more limited list of recipients of collect
mail than for ordinary mail.

     The technical problems in all of this are relatively straightforward:
1) the accounting mechanism must be in place and it must be clear to all
   parties who is paying for the datagrams!!  Some mechanism is needed to
   handle those datagrams that don't neatly fit into a "VC" model.
2) FTP and Mail probably need to be split into two additional services.

     I am also assuming that it must be clear to all concerned that
accounting begins and ends at the DDN.  You won't be charged for packets
the DDN drops, but if your gateway drops lots of packets that's tough.

-- Mark --
-------
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 04:15:36 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Maximum size IP packets

Our PC/DOS TCP/IP will only assemble packets smaller than the MTU of
the attached networks.  We decided that anything fancier than that
would waste too much memory for essentially no benefit.  It helps
that the smallest MTU any of our interfaces use is about 1K bytes,
well above the IP requirement of 576.

Mobygrams fail miserably in the face of *any* packet loss, because none
of the IPs I know anything about allow retransmissions with the same IP
identification value.  All the fragments of a particular retransmission
of a mobygram must survive the net before it can be re-assembled.  In PCs
in particular, you can't get below a certain level of packet loss due to
cheap network interfaces, so you're stuck.

NFS is the only conspicuous user of mobygrams that I know of, and I think
that Van Jacobsen and Mike Karels have demonstrated that Sun's choice of
fragmented UDP mobygrams, unchecksummed, was a costly way to achieve
high throughput.

James VanBokkelen
FTP Software Inc.

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 05:31:19 GMT
From:      GRFXLS@SUVM.ACS.SYR.EDU
To:        comp.protocols.tcp-ip
Subject:   (none)


I'm sorry if I am at the wrong group. I'd like to find out where I could
get parts for AT&T7300. I am looking for a power supply and 20 MB harddisk.
Please, send me a mail if you have any information about it.

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 06:43:36 GMT
From:      mouse@mcgill-vision.UUCP (der Mouse)
To:        comp.protocols.tcp-ip
Subject:   Re: BITNET mail follows (really: IP forwarding)

In article <8804090447.AA06537@ucbvax.Berkeley.EDU>, B32357@ANLVM.BITNET writes:
> Subject: BITNET mail follows

Can't someone do something about this?  It's got to be one of the least
informative subject lines in existence, right up there with "(none)".
Can't the BITNET gateway be kludged to recognize when it's about to
generate a posting with this subject and do something more useful?

> How does one disable IP forwarding?

This depends on the gateway machine software.  For Berkeley UNIX, 4.3
at least, there's a kernel variable called ipforwarding which can be
set to 0 to disable forwarding.  To change it, use adb:

% adb -w -k /vmunix /dev/mem
_ipforwarding/W 0			<- in running system
_ipforwarding?W 0			<- in kernel file
$q

Changes made to the running system take effect immediately but go away
at next reboot; changes made to the kernel file are permanent but don't
take effect until next reboot.  (Well, permanent until you rebuild an
new kernel and install it.  To fix it *really* permanently, change the
initialization in netinet/ip_input.c (or you may be able to use a
config file line

options		"IPFORWARDING=0"

).)

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Apr 88 14:16:56 EST
From:      Bob Alston <RWA100S%ODUVM.BITNET@CUNYVM.CUNY.EDU>
To:        pcip lists <pcip-l@byuadmin>, pcip list <pcip@udel.edu>, Telnet list <telnet@ncsa.uiuc.edu>, tcp-ip list <tcp-ip@sri-nic.arpa>
Subject:   Help with Netware compatible (hardware independent) pc-tcp/ip
We at ODU Computing Services are looking for a hardware topologically
independent tcp/ip solution for our Novell Networks.  We have an
ethernet based TCP/IP backbone that we would like to be able to take
advantage of from several existing and proposed Novell pc networks using
IBM Token Ring, 3COM 501 Ethernet, SMS Arcnet, and other asstd. hardware
topologies.  I have seen the Micom-Interlan (Netware) TCP/IP gateway, but
have concerns about its performance.  Also, I have seen several workstation
based solutions (ie Excelan, Ungermann-Bass, etc.), but we already have a
substantial hardware investment in other pc network interface cards
(token ring, ethernet, etc. as mentioned above) and also have heard that
the aformentioned workstation based solutions are prohibitively expensive.
I have heard rumors of a netbios based solution and I would be very interested
in learning more.  Please send me any and all info you can share.  I will
be glad to post the responses to the lists.

                 Thanks in Advance
                 Bob Alston
                 Old Dominion University
                 Norfolk, VA
                 BITNET: RWA100S@ODUVM
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 11:02:15 GMT
From:      rich@RICE.EDU (Richard Murphey)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on Apollo Domain systems

Hi Brian,

I have an office mate who is using a couple of Apollos in his lab.
They are in the process of getting an ethernet with TCP-IP up and
running. His name is John Halter and his address is jah@rice.edu.
I'll see what information I can get regarding their solution so far.


rich

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 11:09:20 GMT
From:      jsloan@wright.EDU (John Sloan)
To:        comp.protocols.tcp-ip
Subject:   Re: bad press for NSFNET

Apart from the Datacomm article, all the wide area networks, including
NSFNET, got a lot of bad, or at least interesting, press in the
_The_Chronicle_of_Higher_Education_, 6 April 1988, A11.

The gist of the article is that the WANS (NSFNET, ARPANET and BITNET are
specifically mentioned) are victims of their own success, and that they
don't have the financial resources (and all that implies: staff,
equipment, etc.) to support the exploding growth in their use. It
mentions too the cost of local (campus-wide) area networking, and
that many universities are finding it expensive to support, also in part
because of the growth in usage.

The _Chronicle_ is a trade rag for the education industry. University
administrators read it routinely. The thing that concerns me is that
they'll only see the bottom line, not the fact that most of these
problems are occurring because the networks are immensely popular.

I just co-wrote a proposal for a more extensive campus network, and this
article came out right when we fielded the proposal to the
administration. Great. In times when university administrators are more
bean-counters than educators (and, admittedly, perhaps necessarily so)
this is probably going to make selling networking more difficult.

-- 
John Sloan, The SPOTS Group    Wright State University Research Building
CSNET: jsloan@SPOTS.Wright.Edu  3171 Research Blvd., Kettering, OH 45420
UUCP: ...!cbosgd!wright!jsloan          +1-513-259-1384  +1-513-873-2491
Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 14:57:00 GMT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Packet accounting and a place to do it


	
    Date: 21 Apr 88 17:14:25 GMT
    From: haas@gr.utah.edu  (Walt Haas)
    To: tcp-ip@sri-nic.arpa
    Subject: Re: Packet accounting and a place to do it
    
    It seems to me that the most sensible way to do packet accounting is
    the way that the public networks (Telenet, Tymnet) do it - that is,
    all packets on a virtual circuit are charged to whoever established
    that VC unless the call was placed and accepted as "collect", in which
    case the recipient pays for it.  ....
    
    Cheers  -- Walt Haas    haas@cs.utah.edu    utah-cs!haas
    
	      --------------------
		
One small problem with this approach - during the life of a TCP
connection, many X.25 connections may come and go.  The X.25
connections may be closed down due to idleness or resource
reallocation, and may be reopened from either end of the pipe.  Also,
an X.25 connection may carry data from more than one TCP session.  And
it may also have UDP traffic mixed in.  Who gets the bill?

Mike

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 16:03:17 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

Sean, I agree with you arguments whole heartedly!  Your argument
is essentially that the communications cabpability provided by
networks like the Arpanet provide a higher level good than just
commuications.  This is often thought of as 'infrastructure' in
some circles, where the infrastructure is what allows society
as a whole to operate at a higher level than it could otherwise.

How does one pay for infrastructure?  Usually thru some means other
than usage, although that could be a part of the rate structure.  More
often infrastructure is paid for thru taxes of some form.  Taxes,
as we all know, are also often used to provide societal gains, and
not all pay according to use (perhaps inversely? :-).  I suspect
that usage charges on the Arpanet will cause unknown sociological
behavior which may turn out to be worse for the government than
for the research community as a whole, and what started out as
a way to solve a simple budgeting problem may well end up creating
a more complicated infrastructure problems which will work against
DARPA's desire to foster scientific research in the US and aid the
competitiveness of other countries.

dennis

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 17:49:25 GMT
From:      geof@imagen.UUCP (Geof Cooper)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: packet lengths


 > Your statement that the Ethernet (IEEE 802.3 as well?) requires packets to
 > be in integral number of 16-bit words long is incorrect.

On reference to the original Ethernet 1 spec, I stand corrected.  The packet
length is an integral number of octets.  I must have been thinking of the
3MB experimental ethernet, as you say.

- Geof

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 18:10:40 GMT
From:      wbe@bbn.com (Winston B Edmond)
To:        comp.protocols.tcp-ip
Subject:   Re: packet charging (the EFT model?)

Michael Stein writes:
>Instead of a "WILL/WONT PAY" protocol (which only works on
>connections) how about something else:
>
>Suppose that it was possible to send packets containing "money"?

This sounds like a good, general solution.  If I understand it right, billing
by the network ALWAYS go to the sender of the packet, but the "money"
transferred becomes a promise to pay from one host to another.  Thus, at the
end of the month, the host administrator will get a bill for network
services, pays the bill, and has X dollars in Accounts Receivable from other
hosts sending "money", and Y dollars in Accounts Payable the host has
promised to send to other hosts.

You will need to figure out how to say "I'll pay up to D dollars", since the
cost of a message may well depend on the Internet path it takes between the
hosts.  It may also be difficult to "make change", since the price of the
packets to return money may cost more than the amount to be refunded.

However, if you want the end-of-the-month bill from the networks to directly
reflect the "money" exchanged, then I caution again that the final exchange
of money or billing charges should be between the billed client and the
billing entity (the network) in order to prevent counterfeiting, empty
promises, and even ordinary billing errors.  This means the protocol for
paying wouldn't a high level protocol like IP, but an enhancement to the
network level protocols.

The Automatic Teller networks have solved this kind of reliable money
transfer, so perhaps we don't need to reinvent everything.
 -WBE

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 19:10:28 GMT
From:      ms6b+@ANDREW.CMU.EDU (Marvin Sirbu)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet level accounting in IP routers?

There is lots of good economics research on how to price for services which are
mostly based on fixed capital investments.  Consider local phone service:  you
need a wire from your house to the local telephone central office whether you
make one call or many calls.  On the other hand, the computer which sets up
calls grows in proportion to the number of calls made, while the cost of the
switch matrix is proportional to total length of all calls. Inter-office trunk
requirements depend upon the volume of calling minutes in the peak hour. Thus
optimal local phone prices should probably have some component which is based
on connection cost (to cover the local loop), some component based on call
frequency, and some component based on call minutes.  Moreover, these rates
should be different in peak hours than in off peak hours, because only peak
hour traffic stimulates the need for more trunks.  Using pricing to shift usage
from peak to off peak hours reduces the peak trunk requirements.  Long distance
telephone rates already make use of this simple fact.

Computer service bureaus have long since learned these theories and have
implemented them in their pricing policies.

Two particularly good articles are:

Mitchell, Bridger M., "Economic Issues in Usage Sensitive Pricing," The RAND
Corporation P-6530, 1980, and
Park, Rolla Edward, and Bridger Mitchell, "Optimal Peak-Load Pricing for Local
Telephone Calls," RAND, R-3404-1-RC, March 1987.

A more accessible article is:
Mitchell, "Optimal Pricing of Local Telephone Service," American Economic
Review, Sept, 1978, and

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 19:13:09 GMT
From:      brad@interlan.UUCP (Brad Kemp)
To:        comp.protocols.tcp-ip
Subject:   Re: packet lengths

In article <8804191854.AA00089@apolling.imagen.uucp> geof@imagen.UUCP (Geof Cooper) writes:
>
> > I have been comparing the lengths of packets specified in IP headers
> > against actual packet lengths.  What I am seeing, ignoring IP packets
> > smaller than the minimum packet size, is that a fair number of machines
> > send out packets that are 1-3 bytes longer than is specified by the
> > IP length.
>
>The Ethernet requires that packets be an integral number of 16-bit words
>long.  The Ethernet also has a minimum packet size of 60 bytes.  Any IP
>packet that is less than 60 bytes in length (including ethernet header)
>will be padded to 60 bytes.  The IEEE 802.3 length field would allow
>you to explicitly set the ethernet length, but Ethernet doesn't.

The Ethernet 2.0 spec states:

	...Of these five fields, all are fixed size except the
	data field, which may contain any integral number of octets
	between the minimum and maximum values specified below (see 6.2.5)

		Ethernet 2.0 pg 25

This means that odd length packets are legal.  IEEE 820.3 also specifies 
an intregral number of octets. (pg 26  3.2.7) Most impelemntations of
protocols pad to an even byte length to keep their more braindamaged 
bretheren from puking. IP only cares about the octets specified in its
length field, the pad octets are ignored

	Brad Kemp
	MICOM-Interlan
	{ulowell,mit-eddie}!interlan!brad

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 19:27:13 GMT
From:      emv@starbarlounge (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: packet charging (the EFT model?)


In article <8804220957.AA26052@ucbvax.Berkeley.EDU> csysmas@OAC.UCLA.EDU (Michael Stein) writes:
>Instead of a "WILL/WONT PAY" protocol (which only works on
>connections) how about something else:
>
>Suppose that it was possible to send packets containing "money"?
>
Fake "money" is too easy to "print".  Me and my PC can decipher
the money protocol and send out bogus cash at our leisure.

Schemes like this violate the principle that hosts are not to be
trusted.


Edward Vielmetti, U of Michigan mail group.

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 20:16:52 GMT
From:      cavanaug@ncrcce.StPaul.NCR.COM (John David Cavanaugh)
To:        comp.protocols.tcp-ip
Subject:   Telnet Commands in 3270 Data Stream


I wonder if anyone can help me with a protocol question.  Suppose you have
a Telnet connection that has been put into 3270 mode either by the 3270 Regime
option or a la tn3270 (Terminal Type, Binary, and End of Record options).
When you get a 3270 data stream, you look for IAC EOR to mark the end of it.
The question is:  What do you do when you find some other Telnet command
(e.g. IAC AO) before you find the EOR?  I can imagine four choices:

1.   Ignore the command (doesn't seem like a good idea).
2.   Handle the command immediately (the problem with this is that a lot
     of the Telnet commands don't have much meaning in 3270 mode).
3.   Save the command and do it after you find the EOR (doesn't seem right).
4.   Throw away the whole data stream and send an error message back to the
     user (which hoplessly messes up some poor data entry clerk's session).

My understanding is that Telnet commands "shouldn't" appear in the middle
of the data stream.  Is this correct?  Does any implementation of tn3270 or
the 3270 Regime option put commands there?

Thanks in advance for your help.  Reply to:

John Cavanaugh                          John.Cavanaugh@StPaul.NCR.COM
NCR Comten, Inc.
2700 Snelling Ave. N
St. Paul, MN  55113
   (612) 638-2822                       The opinions expressed ...

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 22:19:37 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  Whither chargeback policies?

Barry, 
In New Mexico we had a saying (and I am sure it applys to other
states as well) that one should vote early and often! :-)

I agree with suggestions made by some that a study of the possible
outcomes of varioius policies on charging would be an interesting
thing to do.  Such a study could help convince those that make
such decisions that certain policies might not be worth pursuing.
After all, many decisions get made because of 'hot buttons' that
might be better avoided than pushed.

I would be glad to organize a group of people that would like to
meet in DC or whereever to discuss such a study, make up an
agenda, parcel out assignments, and the reassemble to put the
paper together.

dennis

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 88 22:30:52 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Whither chargeback policies?


The way I've heard it is:

	Vote Often, Vote Early,
		Vote for James Michael Curly!

(Curly was a notorious ward-healer who became mayor of Boston in the
1930's I believe, they still talk about those "good ole days" when
corruption went to the -right- people.) Well, at least it scans...

I would be interested in attending a meeting in DC (or wherever) to
discuss such issues. Assembling an invitees list would be interesting
although for starters it might just need "activists", others can be
contacted once several of us figure out how to start saying the same
things.

I believe this upcoming election might make this an opportune time to
start, a new administration might be more receptive to new-sounding
programs such as computer networking. It would be hard to imagine any
broad-based objection to it (other than those of a particularly
privatizing bent, which should be addressed.)

	-B

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 88 09:50:00 PST
From:      "TERVAX::EFBATEY" <efbatey%tervax.decnet@nswses.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        efbatey
Subject:   Micom-Interlan NST-100 with 1200b 3124EH Modem
---------------            
Reply-To: <efbatey@nswses.arpa>

         I have a half dozen Micon-Interlan NTS-100 Telnet / Rlogin
         servers (V2.0 Boot Feature Packs).  Any one of them
         interfacing my Micom 3124EH-S1 Hayes-Clone or different 3124
         suffer from a common problem.

         Conditions are 1200 baud, DTE-set, XON/XOFF IN, XON/XOFF
         OUT, using the vi editor, a screen busy process (best, but not
         only demo). 
         
         An inbound caller is executing commands which solicit more
         output while the output (to users terminal crt).  Output to
         remote terminal from last command is in progress (user TYPE
         AHEAD).  User gets rudely awakened when the { BSD or SysV
         host | network | NTS-100 } exits. 
         
         The process on the host terminates.  The user is greeted by
         Serv_prompt> without even a courtesy { 'buffer overflow' |
         'if only XON/XOFF really worked' | 'if server had more spool
         space' } message.
         
         I bought nearly a year ago from the newly formed Micom .AND.
         Interlan which now barely admit the other exists. Interlan
         keeps trying but they seem to be an East coast company and
         will not even log onto my system to witness my problem. 
         
         Anyone with any experience or suggestions IS INVITED.  I'll
         buy lunch.
         
         ------------------------------------------------------------
         | Everett F. Batey II    } { UUCP:  sun!tsunami!nswed5!efb |
         | USNSWSES - Code 4V33   } { ARPA:  efbatey@NOBBS.UCSB.EDU |
         |   After HOSTS.TXT.726  } {        efbatey@NSWSES.ARPA    |
         ------------------------------------------------------------
------
-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 88 02:18:37 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, jwabik@shamash.UUCP
Subject:   Re: Which version does Sun run?


In article <6140@shamash.UUCP> jwabik@shamash.UUCP (Jeff Wabik) writes:

> Does anyone know which version of tcp-ip is implemented in the standard
> Sun OS (Sun UNIX 3.x) ?  802.2?  802.2/snap?  802.3?

The wording of this question is not perhaps as precise as it might be.
TCP/IP as a protocol suite covers OSI layers 3 and above.  The 802
things you cite are at layers 2 and below.  So whether or not of 802.2
is used, with or without SNAP's, is not really a matter of the version
of TCP/IP.  The way IP works is that there is a standard for how to
run it on each particular type of network medium.  This is referred to
as an "encapsulation", since normally what happens is that the IP
packets get encapsulated in a packet appropriate to the medium.  So
whether 802.2 is used is a question of the particular encapsulation
used, not the version of IP used. 

There is an official IP encapsulation for 802-type networks.  It is
defined by RFC 1042.  It supports 802.2 LLC and SNAP over 802.3, .4,
and .5 networks.  However this is a new RFC, defined primarily for the
benefit of IBM token ring and similar new 802 technologies.  In fact
the "traditional" TCP/IP medium is Ethernet, as opposed to 802.3, and
this is what Sun supports.  Of course there's very little difference
between Ethernet and 802.3.  The main one is that what Ethernet calls
a type field, 802.3 calls a length field.  The IP encapsulation for
Ethernet uses the type field to identify the packets as IP packets.
This encapsulation has a bare minimum of overhead.  The Ethernet
headers are put immediately in front of the IP headers.  So you've
just got Ethernet addresses and a type code identifying the packet as
IP.  No LLC or SNAP type stuff is used.  (There is also a different
Ethernet type code used for a secondary protocol called ARP.  This
protocol is used to map from IP address to Ethernet address.  This
protocol is officially considered part of the Ethernet encapsulation
specification.)  Suns normally use this Ethernet encapsulation, not
the newer 802-style encapsulation.

Of course the defined Ethernet types are large enough that they do not
form legal 802.3 packet lengths, so in fact there's no reason that a
single cable can't carry both types of protocol.  Indeed in theory one
could have two separate (and non-communicating) TCP/IP networks on the
same cable, one using the traditional Ethernet encapsulation, and the
other using the new 802-style encapsulation.  However so far I haven't
seen 802-style encapsulations used on Ethernet or 802.3, except by HP
(who designed a different encapsulation that apparently only HP and
cisco implemented) and cisco (who implement all three encapsulations:
Ethernet, the HP version, and the new 802.3 standard).  In general the
TCP/IP community is really using Ethernet version 2, not IEEE, except
to the extent that IEEE happens to be compatible with Ethernet.  This
may change over time, as other 802 networks become more common.  At
the moment the same is true of DECnet, XNS, and other network
protocols that we see on our cables.

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 88 10:13:00 PDT
From:      eva@TWG.COM
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re: Wollongong's TN3270


Especially to: "Crack? No thanks, I've got a new CD player" <...!daveb>

We are not aware of the existence of curses in the PD. In my article I wrote
"currently available", which really means the state of out products at this
"currently available", which really means the state of our products at this
time. Definitely, it does not mean we will do it this way till the final day 
of existence of our solar system...

We are pursuing the option in our WIN/TCP, which will allowe you to have
TN3270 without any UNIX license.

By the way...
Which PD curses are your favorite and where are the sources?

Eva
The Wollongong Group

The Wollongong Group


-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Apr 88 10:58:13 EDT
From:      jbvb@vax.ftp.com (James Van Bokkelen)
To:        RWA100S@ODUVM.BITNET
Cc:        pcip@UDEL.EDU, telnet@ncsa.uiuc.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Help with Netware compatible (hardware independent) pc-tcp/ip
None of them use NETBIOS to encapsulate IP datagrams, but there are several
Novell-compatible, hardware- (but not media-) independent versions of TCP/IP
for the IBM PC that are either commercially supported, or widely available
in the public domain.

Our product for the IBM 802.5 Token Ring calls the IBM-supplied software
driver (the ASI interface), and can share it with other programs (Banyan
Vines, Novell Netware).  IBM's PC product might be able to manage the same
trick, but I don't know of anyone who has tried it.

A number of Novell's OEMs have modified their versions of Netware so that
they support our Packet Driver spec.  This allows our Generic Ethernet
version to share the interface with Netware. (Or you can ask Karl Auerbach
for the CMU version he posted about on pc-ip a week or two ago.  It also
uses the spec.) 

Regrettably, none of the versions of Netware that support the Packet Driver
spec run on the 3C501, but there may be a workaround:  The 3C501 is so simple
(I'm being nice) that it is possible for two pieces of software using it
to co-exist:  You can run a TCP/IP package that is careful about restoring
the interrupt vector, as long as you don't try to use the LAN program while
the TCP/IP has the card.  I know this works with our PC/TCP or the CMU freeware
and 3Com's 3+, it would be worth trying with Netware.

For Arcnet, you could try Philip Prindeville's version of the CMU code, which
has also been mentioned on pc-ip.  I don't know if you could manage the
"co-existence" trick with Netware, or not.

Of course, this approach requires IP routers to forward normal IP packets
back and forth across the various networks.  Keep in mind that encapsulating
IP in NETBIOS datagrams requires at least one IP router, too.  Somebody has
to get the packets onto and off of your normal-IP backbone (?) Ethernet,
and the NETBIOS-space, however it is mapped to the various LANs, is at
least one subnet on its own.  If you aren't totally committed to Netware,
you might try looking up Banyan and asking them how they'd solve your problem.

James VanBokkelen
FTP Software Inc.
-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 88 09:38:58 GMT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Which version does Sun run?

In article <6140@shamash.UUCP> jwabik@shamash.UUCP (Jeff Wabik) writes:

> Does anyone know which version of tcp-ip is implemented in the standard
> Sun OS (Sun UNIX 3.x) ?  802.2?  802.2/snap?  802.3?

Charles's observations are correct; the standard SunOS kernel provides
support for TCP/IP over Ethernet/802.3. Sun does offer TCP/IP using
snap over 802.2 (as defined in RFC1042) layered on either 802.3 or
802.4 using the Sunlink OSI product, which also comes with TP4/CLNS.

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 88 17:13:00 GMT
From:      eva@TWG.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong's TN3270



Especially to: "Crack? No thanks, I've got a new CD player" <...!daveb>

We are not aware of the existence of curses in the PD. In my article I wrote
"currently available", which really means the state of out products at this
"currently available", which really means the state of our products at this
time. Definitely, it does not mean we will do it this way till the final day 
of existence of our solar system...

We are pursuing the option in our WIN/TCP, which will allowe you to have
TN3270 without any UNIX license.

By the way...
Which PD curses are your favorite and where are the sources?

Eva
The Wollongong Group

The Wollongong Group

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 88 22:26:00 EST
From:      <enger@bluto.scc.com>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   WHY are those mailbridges dropping so many packets????


Folks:

I must disagree with some of the remarks made about the recent mailbridge and
EGP core server upgrades.  I think the efforts of the IETF and the
Adopt-A-Gateway donors have made a noticable improvement. 

I can recall a time when there were delays on the order of tens of seconds
just to get an interactive character echo when crossing from Arpanet to
Milnet.  In some cases these were EGP/GGP extra hop delays, in others it would
seem to be entirely attributable to the mailbridges.  I haven't encountered
anything like that lately, have you? 

Recent "ping" testing from MY host to the Arpanet side of the mailbridges
doesn't reveal any dramatic delays or loss rates.  I have run ping sessions
that have sent out 500 packets without seeing one dropped, and obtained
sub-second response in all cases. I'll admit sub-second response is not that
much to be proud of, but it beats the old 30 second delays.

It has been observed that the mailbridge gateways' packet drop rates are high.
Someone conjectured that the cause might STILL be insufficient CPU cycles.
The consistently "low" delays seen from my host would seem to indicate that
the units are NOT that short on CPU horsepower.  Another person suggested that
the mailbridges may be I/O bound due to all the overhead-type traffic.  Being
I/O bound should lead to queuing (delays), and if excessive, packet loss.  I
don't seem to be seeing large ammounts of this when MY host pings the net-10
side of the mailbridges.  So why are the official loss figures so high?

In reviewing the graphs of the mailbridge long term packet drop rates, some
persons have indicated that it looked like the drop rate INCREASED after the
CPU upgrades!  One explanation for this is as follows:  the faster CPU now
allows the mailbridge to ACCEPT much more traffic from the subnets; but it is
still somehow limited in the rate at which it can SEND traffic into the
subnets.  When the packets cannot be sent, they are dropped.

Why can't the packets be sent?  Supposedly one of the major reasons is
complying with the 8-in-flight rule (RFNM blocking). Once a mailbridge has
taken a packet off of an input queue and "routed" it, it supposedly has no
place to keep the packet if it cannot immediately be placed in the output
queue.  To make matters worse, a packet is considered "in-flight" when it is
placed into the output queue, NOT when it has finally made its way through the
output queue and the 1822 interface, and into the PSN.  Thus, large numbers of
packets are being dropped even when there may be space in memory in which they
could be held, if either the 8-in-flight rule, or the design of the mailbridge
software were changed to allow it. 

I am told that PSN 7 frees the Arpanet from the 8-in-flight limitation;
blocking the host at the link layer when it has exhausted its quota of PSN
buffering.  The mailbridges, however, use revision controlled software which
cannot be tinkered with to remove the RFNM counting.  If the counting were
removed, the mailbridge could better use what memory it has, as well as more
of its quota of the buffering available in the PSN.  I am told the Arpanet EGP
servers have already been freed from the RFNM chains.  Ah, but what about the
Milnet side? It still runs PSN 6 software.  What can be done on gateways'
interfaces to the Milnet? 

Since the mailbridges are dropping lots of packets due to their "rfnm
blocking", one might ask why are they being blocked?  What's holding up those
acknowledgements? 

Regardless of how rapidly a mailbridge can place packets into a subnet, in the
long term a mailbridge can't successfully unload traffic at a rate faster than
the next "IP entity" can accept it.  That rate will be affected by the entity's
horsepower and I/O limitations. 

Many of us run down the mailbridges for being antiquated junk.  However,
consider what the mailbridge may be sending to: a busy EGP core server (due to
GGP extra hop traffic), or some other busy or underpowered gateway or host,
such as a VAX 750 or worse (possibly with *USERS* to further degrade things).
Even a good "IP entity" though, can't accept data faster than its interface
rate (~56Kbps at most, the same as the mailbridges).  If the interface is
receiving traffic from another source besides the mailbridge (pretty likely
for EGP servers and  gateways), then the mailbridge can't send to it at full
speed. 

For whatever reason, if the mailbridge can't deliver a traffic flow at the
same rate as it is receiving it, it will eventually have to drop some of the
packets of that flow.  Unless the traffic source is somehow flow controlled,
the source will continue to send at a rate faster than the rate at which the
mailbridge can unload it.  Given sufficient time (to fill up available
queuing), this would seem to mandate dropping at the mailbridge. 

To obtain lower drop rates (which will conserve the bandwidth of the source
subnet) we must exert some form of flow control on the sender.  Since the
mailbridge software is revision controlled (and destined for the Smithsonian
anyway) it isn't likely that it will be enhanced.  So implementation of Dr.
Mills' sophisticated queue management/source quench systems will probably have
to wait for the next generation of mailbridges.  What can be done in the mean
time? 

It would seem that a good way to stamp out excess packet loss (and wastefull
retransmissions on the source subnet) is to stamp out old style TCP.  Maybe we
should have a campaign to promote the use of Jacobson/Karrels-TCP? 

Bob Enger

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 88 18:38:25 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
To:        comp.protocols.tcp-ip
Subject:   Re:  Whither chargeback policies?


	The way I've heard it is:
	
		Vote Often, Vote Early,
			Vote for James Michael Curly!
	
	(Curly was a notorious ward-healer who became mayor of Boston in the
	1930's I believe, they still talk about those "good ole days" when
	corruption went to the -right- people.) Well, at least it scans...

Is Curly the one who was re-elected while doing time because of a federal
conviction?   Something to do with putting too many friends and relatives
on the city payroll?  (Maybe that was Hurley)  Ah, Boston...

	I believe this upcoming election might make this an opportune time to
	start, a new administration might be more receptive to new-sounding
	programs such as computer networking. It would be hard to imagine any
	broad-based objection to it (other than those of a particularly
	privatizing bent, which should be addressed.)
	
This is a good point.  And from the sound of it, you might already have
certain such groups in mind?

-Philip
	

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 88 20:47:12 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
To:        comp.protocols.tcp-ip
Subject:   Re: Packet accounting and a place to do it


	Date: 21 Apr 88 17:14:25 GMT
	From: haas@gr.utah.edu  (Walt Haas)
	Subject: Re: Packet accounting and a place to do it
	To: tcp-ip@sri-nic.arpa
	
	It seems to me that the most sensible way to do packet accounting is
	the way that the public networks (Telenet, Tymnet) do it - that is,
	[ ... ]	

	To be perfectly honest, I can't see any reason to reinvent a wheel
	that currently works just fine.

Not everyone is thrilled with the fairness of billing under Telenet.
It doesn't reflect the (sometimes) wild variations in quality of
service.  The longer it takes my packet to get to its destination, the
less I'm willing to pay...

Anyway, why accept that existing models are sufficient and therefore
refuse any possibility of inventing a superior method?  The wheel is
fine, but there are someplaces it just can't go.  So we need the
hovercraft too.

The MILnet is not a public utility, and should not be run as one. A
research facility model is more appropriate.

-Philip

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 88 03:26:00 GMT
From:      enger@BLUTO.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   WHY are those mailbridges dropping so many packets????



Folks:

I must disagree with some of the remarks made about the recent mailbridge and
EGP core server upgrades.  I think the efforts of the IETF and the
Adopt-A-Gateway donors have made a noticable improvement. 

I can recall a time when there were delays on the order of tens of seconds
just to get an interactive character echo when crossing from Arpanet to
Milnet.  In some cases these were EGP/GGP extra hop delays, in others it would
seem to be entirely attributable to the mailbridges.  I haven't encountered
anything like that lately, have you? 

Recent "ping" testing from MY host to the Arpanet side of the mailbridges
doesn't reveal any dramatic delays or loss rates.  I have run ping sessions
that have sent out 500 packets without seeing one dropped, and obtained
sub-second response in all cases. I'll admit sub-second response is not that
much to be proud of, but it beats the old 30 second delays.

It has been observed that the mailbridge gateways' packet drop rates are high.
Someone conjectured that the cause might STILL be insufficient CPU cycles.
The consistently "low" delays seen from my host would seem to indicate that
the units are NOT that short on CPU horsepower.  Another person suggested that
the mailbridges may be I/O bound due to all the overhead-type traffic.  Being
I/O bound should lead to queuing (delays), and if excessive, packet loss.  I
don't seem to be seeing large ammounts of this when MY host pings the net-10
side of the mailbridges.  So why are the official loss figures so high?

In reviewing the graphs of the mailbridge long term packet drop rates, some
persons have indicated that it looked like the drop rate INCREASED after the
CPU upgrades!  One explanation for this is as follows:  the faster CPU now
allows the mailbridge to ACCEPT much more traffic from the subnets; but it is
still somehow limited in the rate at which it can SEND traffic into the
subnets.  When the packets cannot be sent, they are dropped.

Why can't the packets be sent?  Supposedly one of the major reasons is
complying with the 8-in-flight rule (RFNM blocking). Once a mailbridge has
taken a packet off of an input queue and "routed" it, it supposedly has no
place to keep the packet if it cannot immediately be placed in the output
queue.  To make matters worse, a packet is considered "in-flight" when it is
placed into the output queue, NOT when it has finally made its way through the
output queue and the 1822 interface, and into the PSN.  Thus, large numbers of
packets are being dropped even when there may be space in memory in which they
could be held, if either the 8-in-flight rule, or the design of the mailbridge
software were changed to allow it. 

I am told that PSN 7 frees the Arpanet from the 8-in-flight limitation;
blocking the host at the link layer when it has exhausted its quota of PSN
buffering.  The mailbridges, however, use revision controlled software which
cannot be tinkered with to remove the RFNM counting.  If the counting were
removed, the mailbridge could better use what memory it has, as well as more
of its quota of the buffering available in the PSN.  I am told the Arpanet EGP
servers have already been freed from the RFNM chains.  Ah, but what about the
Milnet side? It still runs PSN 6 software.  What can be done on gateways'
interfaces to the Milnet? 

Since the mailbridges are dropping lots of packets due to their "rfnm
blocking", one might ask why are they being blocked?  What's holding up those
acknowledgements? 

Regardless of how rapidly a mailbridge can place packets into a subnet, in the
long term a mailbridge can't successfully unload traffic at a rate faster than
the next "IP entity" can accept it.  That rate will be affected by the entity's
horsepower and I/O limitations. 

Many of us run down the mailbridges for being antiquated junk.  However,
consider what the mailbridge may be sending to: a busy EGP core server (due to
GGP extra hop traffic), or some other busy or underpowered gateway or host,
such as a VAX 750 or worse (possibly with *USERS* to further degrade things).
Even a good "IP entity" though, can't accept data faster than its interface
rate (~56Kbps at most, the same as the mailbridges).  If the interface is
receiving traffic from another source besides the mailbridge (pretty likely
for EGP servers and  gateways), then the mailbridge can't send to it at full
speed. 

For whatever reason, if the mailbridge can't deliver a traffic flow at the
same rate as it is receiving it, it will eventually have to drop some of the
packets of that flow.  Unless the traffic source is somehow flow controlled,
the source will continue to send at a rate faster than the rate at which the
mailbridge can unload it.  Given sufficient time (to fill up available
queuing), this would seem to mandate dropping at the mailbridge. 

To obtain lower drop rates (which will conserve the bandwidth of the source
subnet) we must exert some form of flow control on the sender.  Since the
mailbridge software is revision controlled (and destined for the Smithsonian
anyway) it isn't likely that it will be enhanced.  So implementation of Dr.
Mills' sophisticated queue management/source quench systems will probably have
to wait for the next generation of mailbridges.  What can be done in the mean
time? 

It would seem that a good way to stamp out excess packet loss (and wastefull
retransmissions on the source subnet) is to stamp out old style TCP.  Maybe we
should have a campaign to promote the use of Jacobson/Karrels-TCP? 

Bob Enger

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 1988 21:28-EDT
From:      CERF@A.ISI.EDU
To:        perry@MCL.UNISYS.COM
Cc:        sean@CADRE.DSL.PITTSBURGH.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Whither chargeback policies?
Dennis,

we pay a tax on gasoline which goes to maintain the Interstae Highway
system. Gas usage is related to road usage - though how much of the
use is on interstantes and how much on local roads isn't clear cut.

I still think a usage-related charge is preferable to the fully
subsidized free good we have today; there isn't any negative feedback on
use, so we have congestion.

Vint
-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 88 22:33:06 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  WHY are those mailbridges dropping so many packets????


    Maybe we
	should have a campaign to promote the use of Jacobson/Karels-TCP? 
	
	Bob Enger
	
	
What do you mean, "maybe"?

  Bob Braden

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 1988 03:41-EDT
From:      CERF@A.ISI.EDU
To:        bzs%bu-cs.bu.edu@BU-IT.BU.EDU
Cc:        perry@MCL.UNISYS.COM, sean@CADRE.DSL.PITTSBURGH.EDU tcp-ip@SRI-NIC.ARPA
Subject:   Re: Whither chargeback policies?

Barry (Shein):

The reason I like the notion of trying to find a charge-back
scheme is that it puts some motivation for efficient use into the
loop.

For cases where the need for or utility of service exceeds
revenues generated, it is possible to subsidize (like lifeline
service on the telephone system).  I like that because it makes
the subsidy visible and forces a decision about providing the
subsidy to those who need it.

It would be nice to discover that at some point these services
could be provided commercially at affordable rates so that the
system need not be run by the government at all.  At the moment,
I have the feeling that commercial rates would be prohibitive -
but if there is an economy of scale, it might be that the
commercial rates could be reduced if the entire Internet traffic
were added to existing commercial traffic.  I haven't looked at
that at all recently and we'd need some statistics (which is why
working on charge-back schemes is good - we may learn enough to
figure out make the system pay for itself).

Vint
-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 01:28:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

Dennis,

we pay a tax on gasoline which goes to maintain the Interstae Highway
system. Gas usage is related to road usage - though how much of the
use is on interstantes and how much on local roads isn't clear cut.

I still think a usage-related charge is preferable to the fully
subsidized free good we have today; there isn't any negative feedback on
use, so we have congestion.

Vint

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Apr 88 09:45:26 -0400
From:      haverty@CCV.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA
Cc:        CERF@A.ISI.EDU, sean@CADRE.DSL.PITTSBURGH.EDU, haverty@CCV.BBN.COM
Subject:   Re: Whither chargeback policies?
It's encouraging to see a discussion like this happening.  I think
it may be useful and/or important to note the distinction between
cost-recovery and "cost"-feedback.  All of a network's costs must be
recovered somehow, and mechanisms must be in place to collect the
data about costs to support collecting the needed funds.  Basing
that scheme on end-user usage is only one scheme, which is in favor
right now - the analogy on the interstates might be if every vehicle's
odometer reading was reported to some accounting system that produced
bills.  Cost feedback is a separable question, though closely related.
The goal is to encourage efficiency and reduce waste usually, but also
may be to encourage certain kinds of use that the benevolent network
owner wants to promote.  Feedback may be in the form of inconvenience
(slow network performance, long gas lines at the pumps), or money, or
availability (a T1 circuit to your campus, an interstate interchange
at your town).

My suspicion is that a mix of such techniques is needed.  As people
have noted, a blanket usage-based scheme might tend to stifle new
ideas or uses; a free-networking approach drives costs out of sight
for the benefactor.  Maybe we need a scheme which promotes new ideas,
but assures that efficiency gets introduced along the way to large
scale usage of any particular idea?

This sounds like a topic which needs wide input and thinking.  Does
it make sense to hold a session of some kind at the upcoming TCP/IP
conference in Santa Clara this summer?   Dan Lynch's shows seem
to be drawing a good mix of academic, industry, government, and
user representation.  Dennis Perry - maybe in addition to pulling
together that paper you mentioned, you could pull together a session
to present results and a large dose of open discussion?

Jack
-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 03:23:38 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Whither chargeback policies?


This is coming down to "do we form bread lines, or do we bake more bread?"

Some of it is a futures issue, given a reasonable "taxation" scheme
could we keep ahead (or reasonably in line with) the traffic or do we
consign ourselves to needing negative feedback to control usage?

Even the Interstate Highway system recognizes that you need more
highways going in/out of NYC than Coldwater Flats, which would seem to
help. This is a two-edged sword, you justify more highways to NYC
because there's more gas taxes collected there, but you still have the
freedom to have a highway through Coldwater Flats (a tributary or exit
or whatever makes sense) even if they could never justify such a think
given a fair-share payback scheme.

Maybe that's part of the problem, how do you deal with a few
researchers who are deserving (that is, would get access at a larger
institution) but won't generate enough packet charges to justify
(payback) a net connection, the volume clout is just not there? Leave
them out in the cold? Tell them to request special and specific
subsidy from their funding source?

Can some of that be reflected in the bandwidth they and others get?

I think part of the idea of infrastructure includes subsidizing
otherwise unprofitable ventures, like a highway exit to Coldwater
Flats, on the assumption that most everyone needs minimal access,
while still being able to respond appropriately to large needs.

	-Barry Shein, Boston University

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 07:41:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?


Barry (Shein):

The reason I like the notion of trying to find a charge-back
scheme is that it puts some motivation for efficient use into the
loop.

For cases where the need for or utility of service exceeds
revenues generated, it is possible to subsidize (like lifeline
service on the telephone system).  I like that because it makes
the subsidy visible and forces a decision about providing the
subsidy to those who need it.

It would be nice to discover that at some point these services
could be provided commercially at affordable rates so that the
system need not be run by the government at all.  At the moment,
I have the feeling that commercial rates would be prohibitive -
but if there is an economy of scale, it might be that the
commercial rates could be reduced if the entire Internet traffic
were added to existing commercial traffic.  I haven't looked at
that at all recently and we'd need some statistics (which is why
working on charge-back schemes is good - we may learn enough to
figure out make the system pay for itself).

Vint

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 10:05:50 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

Vint, I belive that you gasoline tax illustrate the point I was 
trying to make, namely, usage charges are ignored by those who
can afford it, e.g. they buy low efficiency automobiles like
laborginis.  It is not clear how much charging it takes to make
a difference.  Even with HOV in norther VA on I66 and other roads,
many, if not most, people still prefer to drive one to an automobile.
I posit that usage charges, to affect behvaior, will have to be
unreasonably high.  And then when they affect behavior, that behavior
will become 'antisocial', that is, they will not use the system
they way that is optimal, so efficiency becomes an issue again.

My experience says that port charges, connect time, etc are not
unreaonable type of charges.  Volume usage charges are counter productive
and drive people to find other means of solving their problems.  After all,
how much communications does it take to do the research you are involved
in.  Do you stop your research just because you cannot afford to
pay the network charges?  I suspect what will happen is you will
pick up the telephone and play telephone tag with someone, a much
less efficient way to communicate your research ideas.  Or you
may resort to no communication and just publish your results without
feedback from you peers. Both of these alternatives are 'antisocial'
behvior in that it is the opposite behavior expected from developing
the net in the first place.

But you might say, what about users who are using resources attached
to the net?  Again, if you talk to the operators of those resources,
you will find that most of them do not care about the net except
to provide service to their customers.  They can provide better
direct service then a general purpose net can, and probably
cheaper.  And the efficiency issue arrises here as well.  If volume
sensive charging were in effect, users of supercomputer centers
may well ask for printouts to be done at the center and mailed
to the user in order to avoid large charges for printouts.  This
results in time delay and increased cost to the research, where the cost
in this case is the time it takes to turn around a compuation from
one set of inputs to another.

Again, connect time is one thing, volume sensitive charging is another.
When ISDN becomes fully functional, it may become feasible to
build a high speed network that is build around circuit switches instead
of packet switches and one will get rid of the idea of dedicated 
lines.   You just dial up what you need, use it for the time
you need it, and then hang up.  Just like the telephone service today,
you do not get charged for how fast you talk (volume of data), but
how long you talk (time) plus some type of port charge (basic monthly
fee).

In dedicated line systems, like the Arpanet, etc., there is no
contention for a port in current implementations.  Perhaps the
gateways or PSNs could refuse virtual circuit connections based
upon load so that connect time has some value associated with it, such
as some level of service.  

The issue is not an easy one, but I don't think one should run down
the road without exploring the issues.  The DoD is already experiencing
people moving off the DDN because of the expense required for the service
provided.  Many are setting up their own networks, because the
commong network does not work well for them.  What are they using?
Well, the Navy is setting up a UUCP type of network based on dial
up lines and 9.6 kbit/s service!  It isolates them from other, it is
inefficient, etc., but it was done because of perceived problems with
upcoming usage charges on Milnet and performance issues that such
charging would generate. 

enough for now,
dennis

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 10:15:05 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

Vint, one of the reasons that DARPA is haveing problems with paying
for the Arpanet, is the charging mechanism which is in place. There
are many connections which would like to pay for their port 
charge, but cannot because DARPA has no way currently to collect
the money.  So we dismantle the infrastructure because of an
accounting problem.  Usage charges are based on the flawed idea
that one can change behavior based upon how much it costs.  All
it really does is inforce behavior based upon how much money you have.
Can you really say that someones research is more valuable because
they have lots of grant money to pay for communication charges?

dennis

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Apr 88 17:04:29 -0400
From:      tmallory@PARK-STREET.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA
Cc:        tmallory@PARK-STREET.BBN.COM
Subject:   Type of service charging(Re: packet level accounting)

Before we sit back and let the new marketing department build us a tarif, we
might want to look again at the type-of-service issues and how they ought to
be included into the new scheme.  Without belaboring an obvious point, it is
clear that there are different types of network usage that could reasonably be
charged at different rates if they were mapped onto appropriate types of
service.  The network would have to actually provide different services in
order to charge for them, but it ought to cost more for high-reliability(an
internet VC?), or guaranteed low delay, or high-bandwidth schedule to deadline
(perhaps charged by bandwidth*connect-time).  Given the current IP, provide a
low basic rate for traffic with TOS=0 which will leave the existing situation
unchanged: fight for your share of whatever is available.  Then give better
service for more money when someone wants it.  There probably ought to be an
option for even cheaper refusable service that could be used by most
mailers(4th class/bulk rate), and for other time-insensitive file-transfers.
'Nuff said.

Cheers,

Tracy Mallory
BBNCC
-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Apr 88 22:48:34 -0700
From:      kzm@TWG.COM
To:        Valdis Kletnieks <VALDIS@clvm.clarkson.edu>
Cc:        tcp-ip@sri-nic.arpa, kzm@TWG.COM
Subject:   Re: My two cents about charge schemes on the Arpanet

> I know that my users will freak if we suddenly restrict them to 'free
> call' sites only.  Especially if gateways being up/down make day-to-day
> differences.  (Huh?  Why did I get billed for this telnet session to
> BNL?  It always uses Nysernet.  Sorry Charlie, that day a router was
> down at Cornell and it went via MilNet).

You raise an interesting issue : the mixing of free networks and 
charge-back networks.  In practice this is bound to occur when the
first charge-back scheme gets introduced.  Even if all networks became
charge-back after some period of time, it's hardly likely that they will 
all charge the same amount.

This points out (in my view) that charging within an internet (consisting 
of multiple separately-administered networks) cannot be done at the 
application layer (i.e. charging for individual Telnet/FTP sessions), 
but rather must be done at the IP layer.  Since the IP layer is datagram 
oriented, charging will have to be done on the basis of packets sent/received 
(but not necessarily based on packet-counts, e.g. charging could be based 
on time periods during which packets were sent).

There's also the spectre of a central WAN administration charging each of
its neighbouring administrations, which might pass on the charges to its 
users, some of whom might be other adminstrations, and etc. !!!

Given that users need to be able to specify whether (and how much ?) they
are willing to pay, it would appear that the decision to route a packet 
across a charge-back network must be made by IP routers, and therefore 
must be made based on the content of a packet's IP header.  If so, IP's
Type-of-Service could be the right place for the information to be encoded 
(e.g. "cost" to be added to the existing Delay/Throughput/Reliability, 
although one bit is probably not enough information, especially if 
"collect" were encoded here also).

Keith McCloghrie
The Wollongong Group.
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Apr 88 16:53:41 EDT
From:      David R. Conrad <davidc@terminus.UMD.EDU>
To:        jbvb@vax.ftp.com (James Van Bokkelen)
Cc:        tcp-ip@sri-nic.arpa, David R. Conrad <davidc@terminus.UMD.EDU>
Subject:   Re: Telnet Commands in 3270 Data Stream

>You might want to pose this question on the TN3270 mailing list:

>	tn3270@trantor.umd.edu	(I think it is trantor)

Nope, other end... :-)

    tn3270@terminus.umd.edu

-drc
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Apr 88 17:36:52 EDT
From:      Valdis Kletnieks <VALDIS@clvm.clarkson.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   My two cents about charge schemes on the Arpanet
Uh.. OK. I *enjoy* all this theoredical chit-chat about passing moneygrams
and how to place a collect VC call over TCP and all the rest.
     
Now I have an interesting question motivated from self-interest:
     
We here at Clarkson have two links into the Internet - one via Nysernet
and one via Milnet (which we'll ignore for right now).
     
Now - my users just say 'telnet some.bogon.host.domain' and boom they're
there.  Now, that connection might be via Nysernet only - which requires
no billing.  Or it may be nysernet+nsfnet.  Or maybe
nysernet+arpanet+suranet.  The point is that now not only do the bean
counters have to keep track of the usage on the internet core, but the
gateways must also do bill-back for the people behind them.
     
I know that my users will freak if we suddenly restrict them to 'free
call' sites only.  Especially if gateways being up/down make day-to-day
differences.  (Huh?  Why did I get billed for this telnet session to
BNL?  It always uses Nysernet.  Sorry Charlie, that day a router was
down at Cornell and it went via MilNet).
     
I know my finance department is going to freak trying to do the
bill-back.  Sites that ARE on billable nets are going to want to dun us
for our packets.  (Heck, if I was the gate from Clarkson to MIT, *I*
wouldn't swallow the charges for a Clarkson user FTP'ing in X11R2 or GNU
Emacs or.....) Of course, this leaves all the gates billinging all the
nets.  With 400 or so nets reachable, and I don't know HOW many gates,
it's gonna become a zoo really fast...  (Hmm.  We got a bill from 3
gateways at Cornell to 5 users, and another from someplace in
Pittsburgh, and this place in Saskechewan wants its $1.25 for the 15
packets from Bozoville and.....)
     
I guess the bottom line is that it won't fly unless the ENTIRE Internet goes
with the same scheme, even those regional nets that don't otherwise CARE.
     
Well, that's enough rambling on a heavy-duty mailing list.  Hmm. Am I gonna
get a bill for this? :-)
     
                                   Valdis Kletnieks
                                   Systems Programmer
                                   Clarkson University
     
P.S. Standard disclaimers apply.  I'm just rambling on my own time.
As such, the people I answer to don't even know I mailed this yet....
-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 13:45:26 GMT
From:      haverty@CCV.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

It's encouraging to see a discussion like this happening.  I think
it may be useful and/or important to note the distinction between
cost-recovery and "cost"-feedback.  All of a network's costs must be
recovered somehow, and mechanisms must be in place to collect the
data about costs to support collecting the needed funds.  Basing
that scheme on end-user usage is only one scheme, which is in favor
right now - the analogy on the interstates might be if every vehicle's
odometer reading was reported to some accounting system that produced
bills.  Cost feedback is a separable question, though closely related.
The goal is to encourage efficiency and reduce waste usually, but also
may be to encourage certain kinds of use that the benevolent network
owner wants to promote.  Feedback may be in the form of inconvenience
(slow network performance, long gas lines at the pumps), or money, or
availability (a T1 circuit to your campus, an interstate interchange
at your town).

My suspicion is that a mix of such techniques is needed.  As people
have noted, a blanket usage-based scheme might tend to stifle new
ideas or uses; a free-networking approach drives costs out of sight
for the benefactor.  Maybe we need a scheme which promotes new ideas,
but assures that efficiency gets introduced along the way to large
scale usage of any particular idea?

This sounds like a topic which needs wide input and thinking.  Does
it make sense to hold a session of some kind at the upcoming TCP/IP
conference in Santa Clara this summer?   Dan Lynch's shows seem
to be drawing a good mix of academic, industry, government, and
user representation.  Dennis Perry - maybe in addition to pulling
together that paper you mentioned, you could pull together a session
to present results and a large dose of open discussion?

Jack

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Apr 88 20:57 CST
From:      <EBIBISI%UTMEM1.BITNET@CUNYVM.CUNY.EDU> (ED BIBISI)
To:        tcp-ip@sri-nic.arpa
Subject:   Protocol Analyzers
Hi there,

I am in the process of determining which protocol analyzer to invest in
for our LAN.  We have XNS on our LAN as well as DECnet, TCP/IP,
MS-NET, and one ethernet appletalk encapsulation (PNP from Pacer s'ware
connected via Kinetics Bridges).

We have three main VAXen: 8650, 8700 and 8800.  They all support the above
protocols.  We have a small army of microvaxen about our campus that support
only DECnet.

We have had evaluation units of Exelan's Lanalyzer and currently have
Micom - Interlan's product based upon Network General's Sniffer s'ware.
U-B's NetScope does not seem to be as versatile as I would like for our LAN,
as well as DEC's software offerings (EtherNIM, etc.)

I have not seen HP's offering or anyone else's.

I would appreciate input from those that have gone through this process.


Thanks,

Ed Bibisi
Director, Telecommunication Systems
Information Systems and Services
University of Tennessee, Memphis
EBIBISI@UTMEM1.BITNET
(901) 528-5848
-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 15:02:46 GMT
From:      jeremy@swatsun.uucp (Jeremy Brest)
To:        comp.os.vms,comp.protocols.tcp-ip,comp.mail.misc
Subject:   VMS mail question

We're going to be internetworking VAXen using PMDF on a TCP/IP
network.  The question is, can you ask the VAX mailer (or is there
another front end for mail?) to use the internet as its default,
rather than having to address every mail to a non-VAX system
	in%"user@system"?




Thanks,

Jeremy Brest
Swarthmore College

uucp:      ...seismo!bpa!swatsun!jeremy
CSnet:     jeremy@swatsun.swarthmore.edu
Internet:  jeremy%swatsun.swarthmore.edu@relay.cs.net

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 15:50:16 GMT
From:      gore@eecs.nwu.edu (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   New BSD TCP/IP & Mt. Xinu

Has anybody incorporated the new 4.3BSD TCP/IP code into Mt. Xinu's
4.3BSD+NFS?

Jacob Gore				Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept.		{oddjob,gargoyle,ihnp4}!nucsrl!gore

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 16:49:29 GMT
From:      sam@ftp.COM (Shelli Meyers)
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

In article <8804222230.AA09291@bu-cs.bu.edu>, bzs@BU-CS.BU.EDU (Barry Shein)
writes:
> 
> I believe this upcoming election might make this an opportune time to
> start, a new administration might be more receptive to new-sounding
> programs such as computer networking. 

There is an interesting article in the April 18th issue of _Computerworld_
regarding the high tech issues playing a part in this year's election, and
the specific stands of Bush, Dukakis, Gore, and Jackson on things like federal
tax credit for R&D, telecommunications regulations, corporate tax rates, etc.
The article is somewhat brief and pretty general, but worth a look.

Shelli Meyers
FTP Software, Inc.

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 16:50:00 GMT
From:      zweig@uiucdcsp.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Thoughts on why packet accounting w


Here's a paranoid thought: could this whole pay-per-packet thing
simply be a ploy to help drive the last nails in the coffin of the
arpanet? If charging is going to be unfair and unrealistic (i.e. bad
for gateways and archives both of which are very important to the
network) then the arpanet dies right on schedule, making way for
the DRI and some nice OSI based kludgery that will make all this
nonsense with pay-per-packet seem like the Dark Ages.

I, for one, smell a rat.


Johnny Zweig
University of Illinois at Urbana-Champaign
Department of Computer Science
--------------------------------Disclaimer:------------------------------------
My views are my own, at least as far as I know, and should in no way be
construed to represent the official views of this university or the department.
   Rule 1: Don't believe everything you read.
   Rule 2: Don't believe anything you read.
   Rule 3: There is no Rule 3.
-------------------------------------------------------------------------------

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 17:42:18 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet Commands in 3270 Data Stream

I can't say what is right, but I can say what we do:

In the incoming data stream, our client processes IAC regardless of IAC EOR
blocking (this also means we assume that IAC-stuffing applies within EOR
blocks).  The data stream we send to the server won't contain any telnet
command sequences within a 3270 block (after the AID but before the IAC EOR),
but it may contain IAC IAC.

You might want to pose this question on the TN3270 mailing list:

	tn3270@trantor.umd.edu	(I think it is trantor)

James VanBokkelen
FTP Software Inc.

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 21:04:29 GMT
From:      tmallory@PARK-STREET.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Type of service charging(Re: packet level accounting)


Before we sit back and let the new marketing department build us a tarif, we
might want to look again at the type-of-service issues and how they ought to
be included into the new scheme.  Without belaboring an obvious point, it is
clear that there are different types of network usage that could reasonably be
charged at different rates if they were mapped onto appropriate types of
service.  The network would have to actually provide different services in
order to charge for them, but it ought to cost more for high-reliability(an
internet VC?), or guaranteed low delay, or high-bandwidth schedule to deadline
(perhaps charged by bandwidth*connect-time).  Given the current IP, provide a
low basic rate for traffic with TOS=0 which will leave the existing situation
unchanged: fight for your share of whatever is available.  Then give better
service for more money when someone wants it.  There probably ought to be an
option for even cheaper refusable service that could be used by most
mailers(4th class/bulk rate), and for other time-insensitive file-transfers.
'Nuff said.

Cheers,

Tracy Mallory
BBNCC

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 21:36:52 GMT
From:      VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks)
To:        comp.protocols.tcp-ip
Subject:   My two cents about charge schemes on the Arpanet

Uh.. OK. I *enjoy* all this theoredical chit-chat about passing moneygrams
and how to place a collect VC call over TCP and all the rest.
     
Now I have an interesting question motivated from self-interest:
     
We here at Clarkson have two links into the Internet - one via Nysernet
and one via Milnet (which we'll ignore for right now).
     
Now - my users just say 'telnet some.bogon.host.domain' and boom they're
there.  Now, that connection might be via Nysernet only - which requires
no billing.  Or it may be nysernet+nsfnet.  Or maybe
nysernet+arpanet+suranet.  The point is that now not only do the bean
counters have to keep track of the usage on the internet core, but the
gateways must also do bill-back for the people behind them.
     
I know that my users will freak if we suddenly restrict them to 'free
call' sites only.  Especially if gateways being up/down make day-to-day
differences.  (Huh?  Why did I get billed for this telnet session to
BNL?  It always uses Nysernet.  Sorry Charlie, that day a router was
down at Cornell and it went via MilNet).
     
I know my finance department is going to freak trying to do the
bill-back.  Sites that ARE on billable nets are going to want to dun us
for our packets.  (Heck, if I was the gate from Clarkson to MIT, *I*
wouldn't swallow the charges for a Clarkson user FTP'ing in X11R2 or GNU
Emacs or.....) Of course, this leaves all the gates billinging all the
nets.  With 400 or so nets reachable, and I don't know HOW many gates,
it's gonna become a zoo really fast...  (Hmm.  We got a bill from 3
gateways at Cornell to 5 users, and another from someplace in
Pittsburgh, and this place in Saskechewan wants its $1.25 for the 15
packets from Bozoville and.....)
     
I guess the bottom line is that it won't fly unless the ENTIRE Internet goes
with the same scheme, even those regional nets that don't otherwise CARE.
     
Well, that's enough rambling on a heavy-duty mailing list.  Hmm. Am I gonna
get a bill for this? :-)
     
                                   Valdis Kletnieks
                                   Systems Programmer
                                   Clarkson University
     
P.S. Standard disclaimers apply.  I'm just rambling on my own time.
As such, the people I answer to don't even know I mailed this yet....

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 88 21:57:44 GMT
From:      ospwd@emory.uucp (Peter Day {EUCC})
To:        comp.protocols.tcp-ip
Subject:   RIP, gated reply summary

(Since the question was originally posted to both the BIG-LAN BITnet
list and this newsgroup, the summary is being posted both places as
well.  I hope anyone who reads both will forgive me for the
multiple posting.)

Thanks to all who responded to my question:
 
>How can I get more specific information about the Routing Information
>Protocol (RIP) used by Proteon, and gated, a demon which translates
>between RIP and EGP, the External Gateway Protocol?

RFC 827, 888 and 904 describe EGP, the *Exterior* Gateway Protocol. 
RFC 827 is less formal and is easier to read.
RFCs are available from a number of sources, but in particular,
may be obtained by sending a note to
service@sri-nic.arpa with Subject: RFC nnn
where of course nnn is the RFC number.
 
Here is a summary:
 
"From: Charley Kline <KLINE@UIUCVMD>
 
The best functional description of RIP is a paper called IDEA004, soon
to be an RFC, from Chuck Hedrick at Rutgers. Gated an implementation of
RIP and HELLO and EGP, and the best documentation of that I know if is
the gated man page. In a complex networking environment though, you need
to have a deep understanding of what is going on to use gated effectively
 
From: Philip Prindeville [CC]  <philipp@larry.mcrcim.mcgill.edu>
 
Send mail to "service@sri-nic.arpa" with subject as "get idea:idea004.txt".
 
Or, ftp to sri-nic.arpa and login as anonymous.  cd into "idea:".  get the
file idea004.txt.
 
"From:         David Wasley <dlw@violet.berkeley.edu>
 
There is a document available from the sri-nic that describes RIP.
It is currently called IDEA004 but may become an RFC.
 
Here is the blurb on how to get this:
 
        The IDEAS can be found at SRI-NIC.ARPA (10.0.0.51).
        Login as 'anonymous'. The directory is <ietf>. Each
        IDEA is named "IDEAnnn.TXT", where nnn is the IDEA number.
        The indices are IDEA-INDEX.TXT (the short index, no abstracts)
        and IDEA-INDEX-ABS.TXT (the long index, with abstracts).
 
"From:         "Mark S. Fedor" <fedor@nisc.nyser.net>
 
    Peter,
 
    I have written a implementation paper on gated which was
    just accepted for presentation and publication at the summer
    1988 USENIX conference.
 
    There is also a gated document (man) page.  The routed(8) man
    page describes RIP, but the ultimate RIP document was done by
    Charles Hedrick of rutgers.  The document is available via
    anonymous FTP from topaz.rutgers.edu or I`m sure
    hedrick@topaz.rutgers.edu could mail it to you.

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Apr 88 02:29:45 EDT
From:      Valdis Kletnieks <VALDIS@clvm.clarkson.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Another problem with usage charges
(Forgive me - it *is* 2:30AM here, so I may be a TAD off base, but...)
     
Ever have this happen to you?
     
% ftp someplace.faraway.arpa
ftp>get big.manymeg.file
(....)
(....)
(14 meg of the 15 meg file has been transferred)
netinet: net unreachable
ftp>
(Insert typesetting symbol for 'scream of anguish' here)
     
Who pays for the 14 meg of usage? I sure don't want to - I didn't get the
service I asked for.
     
Defining 'got requested service' for each service type is left as an exercise
for the student.  Don't forget the case of homegrown TCP client programs.
     
                                   Valdis Kletnieks
     
P.S. Usual disclaimers apply.  Flame me, not my boss...
I'm not a TCP guru, I just use the stuff - a lot.
-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Apr 88 05:25:09 EDT
From:      Bruce Crabill <BRUCE%UMDD.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TN3270 mailing list address
No, the proper address for the TN3270 mailing list is TN3270@TERMINUS.UMD.EDU.
If anyone wishes to be added to the list, please contact me.

                                       Bruce
-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Apr 88 09:30:10 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        perry@mcl.unisys.com
Cc:        tcp-ip@sri-nic.ARPA
Subject:   refund mechanisms in charging

Dennis,

    I suspect you can't permit a refund mechanism....

    Take the case of the 14 of 15 megabytes transferred.

    If I know that aborting a connection before all the data requested
has been passed then I can happily set up schemes with my friends to
pad all FTPable files with an extra few megabytes of junk.  Then
we transfer our data, abort while the junk is being transferred,
and apply for a refund.  Voila, free networking....

    I think the implication of this is that you'd have to certify
programs as not able to abuse the charging scheme this way before
you permitted a refund mechanism.

Craig
-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 02:57:00 GMT
From:      EBIBISI@UTMEM1.BITNET (ED BIBISI)
To:        comp.protocols.tcp-ip
Subject:   Protocol Analyzers

Hi there,

I am in the process of determining which protocol analyzer to invest in
for our LAN.  We have XNS on our LAN as well as DECnet, TCP/IP,
MS-NET, and one ethernet appletalk encapsulation (PNP from Pacer s'ware
connected via Kinetics Bridges).

We have three main VAXen: 8650, 8700 and 8800.  They all support the above
protocols.  We have a small army of microvaxen about our campus that support
only DECnet.

We have had evaluation units of Exelan's Lanalyzer and currently have
Micom - Interlan's product based upon Network General's Sniffer s'ware.
U-B's NetScope does not seem to be as versatile as I would like for our LAN,
as well as DEC's software offerings (EtherNIM, etc.)

I have not seen HP's offering or anyone else's.

I would appreciate input from those that have gone through this process.


Thanks,

Ed Bibisi
Director, Telecommunication Systems
Information Systems and Services
University of Tennessee, Memphis
EBIBISI@UTMEM1.BITNET
(901) 528-5848

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 03:40:23 GMT
From:      cyrus@hi.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   udp port numbers


I asked something similar to this last week without ANY responses
so here is a rephrase....

What `rules' does "UN*X like" operating systems use when picking udp
port numbers?  

By watching packets fly around on our network it appears that if both
the source and destination ports are less than 1024, then they have
the meaning specified in RFC 1010 and /etc/services.  If one of the
ports is > 1024, then this is a generic network connect where the port
numbers have no special meaning.  This would be fine if it were not
for NFS which appears to use 1023 and 2049 as port numbers.  NFS
total breaks my idea of > 1024 numbers being generic.  Also, what
does 1022 and 2049 for ports mean?  Is this still NFS or just a
coincidence?

I am trying to `parse' packets and am having a difficult time figuring
out RFC's and UN*X source (SUN 3.2 & BSD 4.3).

Any comments would be appreciated.

-- 
    @__________@    W. Tait Cyrus   (505) 277-0806
   /|         /|    University of New Mexico
  / |        / |    Dept of Electrical & Computer Engineering 
 @__|_______@  |       Parallel Processing Research Group (PPRG)
 |  |       |  |       UNM/LANL Hypercube Project
 |  |  hc   |  |    Albuquerque, New Mexico 87131
 |  @.......|..@    
 | /        | /     e-mail:      
 @/_________@/        cyrus@hc.dspo.gov

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 05:21:14 GMT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: 4.3 TCP sockets revisited.

The load sharing option of the Sunlink Internetwork Router allows you
to connect two Suns with some number of parallel serial lines using
the Xerox Point to Point protocol on each line. The load sharing
driver tries to distribute the outgoing IP packets over these lines in
a method which tries to maximize the utiltization of each line;
essentially a round robin when all of the packets are the same
(maximum) size. This allows you to get effective throughput close to
the sum of the baudrate of all lines used, and to continue to send
packets as long as at least one of the lines is operating. Routing is
still done on a per-interface basis; all of the load-shared lines use
the same IP network interface for transmission of packets. In
contrast, if you used an IP interface per line between two nodes, only
one of the lines would be used at any time by routing algorithm
provided in standard 4BSD software. 

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Apr 88  9:30:04 EDT
From:      "Alan R. Hill" <ahill@cc7.bbn.com>
To:        haverty@ccv.bbn.com
Cc:        tcp-ip@sri-nic.arpa, CERF@a.isi.edu, sean@cadre.dsl.pittsburgh.edu
Subject:   Re: Whither chargeback policies?
	Why is it that I have a fear that worthy discussions of issues such as
these will not survive the introduction of the tarrif?

Alan

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 05:48:34 GMT
From:      kzm@TWG.COM
To:        comp.protocols.tcp-ip
Subject:   Re: My two cents about charge schemes on the Arpanet


> I know that my users will freak if we suddenly restrict them to 'free
> call' sites only.  Especially if gateways being up/down make day-to-day
> differences.  (Huh?  Why did I get billed for this telnet session to
> BNL?  It always uses Nysernet.  Sorry Charlie, that day a router was
> down at Cornell and it went via MilNet).

You raise an interesting issue : the mixing of free networks and 
charge-back networks.  In practice this is bound to occur when the
first charge-back scheme gets introduced.  Even if all networks became
charge-back after some period of time, it's hardly likely that they will 
all charge the same amount.

This points out (in my view) that charging within an internet (consisting 
of multiple separately-administered networks) cannot be done at the 
application layer (i.e. charging for individual Telnet/FTP sessions), 
but rather must be done at the IP layer.  Since the IP layer is datagram 
oriented, charging will have to be done on the basis of packets sent/received 
(but not necessarily based on packet-counts, e.g. charging could be based 
on time periods during which packets were sent).

There's also the spectre of a central WAN administration charging each of
its neighbouring administrations, which might pass on the charges to its 
users, some of whom might be other adminstrations, and etc. !!!

Given that users need to be able to specify whether (and how much ?) they
are willing to pay, it would appear that the decision to route a packet 
across a charge-back network must be made by IP routers, and therefore 
must be made based on the content of a packet's IP header.  If so, IP's
Type-of-Service could be the right place for the information to be encoded 
(e.g. "cost" to be added to the existing Delay/Throughput/Reliability, 
although one bit is probably not enough information, especially if 
"collect" were encoded here also).

Keith McCloghrie
The Wollongong Group.

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 06:29:45 GMT
From:      VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks)
To:        comp.protocols.tcp-ip
Subject:   Another problem with usage charges

(Forgive me - it *is* 2:30AM here, so I may be a TAD off base, but...)
     
Ever have this happen to you?
     
% ftp someplace.faraway.arpa
ftp>get big.manymeg.file
(....)
(....)
(14 meg of the 15 meg file has been transferred)
netinet: net unreachable
ftp>
(Insert typesetting symbol for 'scream of anguish' here)
     
Who pays for the 14 meg of usage? I sure don't want to - I didn't get the
service I asked for.
     
Defining 'got requested service' for each service type is left as an exercise
for the student.  Don't forget the case of homegrown TCP client programs.
     
                                   Valdis Kletnieks
     
P.S. Usual disclaimers apply.  Flame me, not my boss...
I'm not a TCP guru, I just use the stuff - a lot.

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Apr 88 15:46:24 PDT
From:      cire@clash.cisco.com
To:        bzs%bu-cs.bu.edu@bu-it.bu.edu (Barry Shein)
Cc:        perry@mcl.unisys.com, VALDIS@clvm.clarkson.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Another problem with usage charges
>> Date: Tue, 26 Apr 88 09:05:34 EDT
>> From: bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein)
>> To: perry@MCL.UNISYS.COM
>> Cc: VALDIS@clvm.clarkson.edu, tcp-ip@sri-nic.ARPA, perry@mcl.unisys.com
>> Subject:  Another problem with usage charges
>> 
>> If nothing else this is becoming an object lesson in why AT&T was
>> granted a monopoly, it certainly did simplify a lot of things. Sure,
>> that's been broken up, perhaps around 2080 Judge Greene will see that
>> the internet can be "deregulated" also.

One of the depressing things about the deregulation of AT&T is that in
many ways it may have been better to not deregulate.  I haven't seen
lower prices or better service.  But then again I live in the hinter
land of the Santa Clara Valley.  There are some things that should
perhaps be left as a monopoly or set up that way because the overhead
of other structures is too costly.

>> 
>> There are other examples, I think people on this list are starting to
>> understand what the word "infrastructure" really means. It has a lot
>> to do with services who's very value is based upon their universality
>> (roads that go to other roads, phones that can call all other phones,
>> railroads that can use other tracks, canals that link to other
>> waterways, consistent rules and tariffs etc.)
>> 

Is the infrastructure of networks universal to an Information Age?
What ever that is.

>> 	-Barry Shein, Boston University
>> 

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 09:25:09 GMT
From:      BRUCE@UMDD.BITNET (Bruce Crabill)
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270 mailing list address

No, the proper address for the TN3270 mailing list is TN3270@TERMINUS.UMD.EDU.
If anyone wishes to be added to the list, please contact me.

                                       Bruce

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 1988 14:39:50 CDT
From:      Link@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        LINK@GUNTER-ADAM.ARPA
Subject:   Network Operating Systems
 
 
     I've reviewed RFCs 1001 and 1002, NETBIOS over TCP/IP, but 
have been unable to resolve a nagging question:  Do I need a 
Network Operating System to provide PC to PC communications on a 
802.3/TCP/IP/NETBIOS LAN?  I've spoken to several vendors, such 
as Novell, Torus, and Bridge/3Com, and received conflicting and 
contradictory answers.   Can anyone out there give me some 
help/point me in the right direction?
 
     I'm also in need of the NETBIOS spec.  IBM has been most 
uncooperative helping me find their technical documentation; " it 
was last marketed in October 1987, and I can't give to you..."
 
     Please reply to me directly and I will summarize for the 
rest of the TCP/IP mailing list.  Thanks.
 

  |====================================================================|
  |  Link Verstegen                Network Solutions, Inc. (NSI)       |
  |  Lead Hardware Engineer        4350 Will Rogers Parkway, Suite 100 |
  |                                Oklahoma City, OK  73064            |
  |  Link@Gunter-Adam.ARPA         (405)942-8884                       |
  |====================================================================|

-------
-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 09:52:49 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  My two cents about charge schemes on the Arpanet

Valdis, you raise an interesting point about multiple routes and
some nets that charge and some that don't.  This gets into some
interesting issues about routing and routing restrictions.  Indeed,
one might develop several PhD thesis about 'routing with restrictions'
or gateways that spend 50% of there time deciding if they can accept
you packet (no money, wrong organization, wrong destination, etc.)

A similar issue apparent arose in the Arpanet connections to Europe
that went over x.25 links thru the PTTs.  The X.25 networks wanted
to charge the Arpanet for traffice originating in the Arpanet destined
to Europe, across the X.25 links.  The Europeans were already paying
for their half.  DARPA refused to pay, making the argument that
it was a 'wash'.  If we charged the Europeans to carry their traffic
and they charged us to carry their traffic, the excercise was one
of exchanging the same amount of money, so why waste the money on
the overhead of breaking even?  The net result was the Europeans
pay for both directions of traffic.

dennis

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 09:56:25 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  Another problem with usage charges

I suspect there should be some mechanism to ask for a refund.  Isn't
this fun?

dennis

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 17:05 EDT
From:      Corrigan @ DDN3.ARPA
To:        tcp-ip @ sri-nic.arpa
Subject:   Network Charges

1.  Members of the list (at least collectively) probably won't make the 
decision, but that's DARPA's call.  
2. Members can influence the decision, not only for the ARPANET, but for the
MILNET as well.  I am batching up the collected comments for delivery to
the keeper of the "Commercial Communications Industrial Fund".  They set the
rate structure for both nets in conjunction with the network manager.  It is
a revolving fund, and as long as expenditures equal receipts over time, there
is some freedom in making the "right things" happen.

Mike Corrigan

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 13:05:34 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Another problem with usage charges


If nothing else this is becoming an object lesson in why AT&T was
granted a monopoly, it certainly did simplify a lot of things. Sure,
that's been broken up, perhaps around 2080 Judge Greene will see that
the internet can be "deregulated" also.

There are other examples, I think people on this list are starting to
understand what the word "infrastructure" really means. It has a lot
to do with services who's very value is based upon their universality
(roads that go to other roads, phones that can call all other phones,
railroads that can use other tracks, canals that link to other
waterways, consistent rules and tariffs etc.)

	-Barry Shein, Boston University

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 13:30:04 GMT
From:      ahill@CC7.BBN.COM ("Alan R. Hill")
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?


	Why is it that I have a fear that worthy discussions of issues such as
these will not survive the introduction of the tarrif?

Alan

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 13:30:10 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   refund mechanisms in charging


Dennis,

    I suspect you can't permit a refund mechanism....

    Take the case of the 14 of 15 megabytes transferred.

    If I know that aborting a connection before all the data requested
has been passed then I can happily set up schemes with my friends to
pad all FTPable files with an extra few megabytes of junk.  Then
we transfer our data, abort while the junk is being transferred,
and apply for a refund.  Voila, free networking....

    I think the implication of this is that you'd have to certify
programs as not able to abuse the charging scheme this way before
you permitted a refund mechanism.

Craig

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Apr 88 19:38
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@relay.MOD.UK>
To:        Dennis Perry <@nss:perry@mcl.unisys.com>
Cc:        tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa>
Subject:   Re:  My two cents about charge schemes on the Arpanet
Dennis,
 
Not so. The issue with X25 connected to Arpanet was that the caller
pays for the whole circuit - not half. When Europe called Arpanet that
was fine, Europe paid. But if for example e-mail was routing from
Arpanet to Europe over X25 and a X25 call had to be opened then
Arpanet would be billed. Bob Kahn then proposed that in such
situations he would raise a matching equal bill from Arpanet to
be paid by Europe. (Remember between Europe and US it is not
possible to do reverse charging on X25 for legal reasons rather than
technical I understand.)
 
 
So as of now if X25 is used between Europe and Arpanet it is only
used in the west direction. Traffic initiated in Arpanet for Europe
takes other paths - and that is another issue.
 
 
I have found this discussion most interesting because it parallels
many of the issues I see in how to route within the future NATO
community of interconnected peer level National/Service networks.
 
John
-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 16:30:15 GMT
From:      don@SRI-LEWIS.ARPA (Donald Holman)
To:        comp.protocols.tcp-ip
Subject:   Network charges. (A snide comment.)

Fellow net-workers,

Because of time I have only read the occasional note regarding network
charges, thus if I am restating old ideas I appologize.

I have a question with regard to the network charge decision process.
Is the decision to be made by members of this list? For if not then
I submit that the time being charged on the timeslips for all of this
rhetoric may be adequate to pay for the 'net' for the next
fiscal year.

ON THE OTHER HAND, if the members of this list can influence the decision
process, I have a more palatable comment. Is it not true that the real cost
of keeping the 'net' up and running can be closely determined. (i.e. I am sure
that someone in the bill paying department can tell us that last year network
connection fees totaled X dollars, thus this year the budget for these fees 
has been allocated as Y dollars.) If this is the case, we can use this value
Y along with (perhaps a swag) the amount of data to be transfered next year last year. 
Thus if Y is 100 dollars and 'swag' is 1kbyte the network charge is $1/kbyte across the
board. As far as re-routing and use of other peoples network services, this amount
is charged locally (i.e. as data leaves the local site and uses PBN or the like)
and placed into a central pot to pay for the network as a whole. 

Just a thought,
(Usual disclaimers apply)
Don

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 16:36:18 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  My two cents about charge schemes on the Arpanet

Dennis,

You may have left out the most interesting fact: Reverse-charging was not
available for international public packet-switching nets. So far as I know,
it still is not available.

Consider how the various carriers collect charges in the case of a call
placed to a ship at sea. The landside originator pays (1) the landline
segment from point of origin to coastal radio station (possibly international),
(2) the radio station usage itself and (3) the ship radio station usage.
Any or all three charges may be payable to operators in different countries.
While payable in different currencies, all charges must be expressable
in Swiss Francs; however, the caller may pay his local carrier in the currency
of origin, so you can see there may be lots of Swiss francs floating around
for each call. Once a year the various countries settle their accounts with
each other (in Swiss francs). If everything works right (your "wash" rule),
very little currency actually has to change hands. If a balance-of-Swiss-
francs is not preserved, some carrier, station or ship may need to invest
some capital to correct the imbalance.

Here's another one: venerable coastal station WLO (Mobile, AL) operates
a high-seas radio bulletin board/mail relay using SITOR (semi-reliable HF
radio link protocol) which, presumably, can relay onward via landline to
domestic destinations. To the above we add volume charges, selection of
domestic carrier and mailbox system charges.

I submit this community may not be the first to squarely face the charging
issue.

Dave

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 16:42:17 GMT
From:      kozel@SPAM.ISTC.SRI.COM (Edward R. Kozel)
To:        comp.protocols.tcp-ip
Subject:   Re: 4.3 TCP sockets revisited.


Bill,
	You implied that routing of packets over load sharing serial
lines occurs once within the 4.3 router and again at the Internetwork
Router interface handler.  Is this true?  Also, does your round robin
handling dynamically pass packets from one queue to another if, for
example, one of the serial links failed?  I guess my question really
is - do you have one outgoing queue from which packets are dynamically
allocated to each interface or is there a N-deep queue for each 
interface (latter scenario raising my earlier question).

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 18:15:11 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Charging and aborted transfers

Someone asked why one should pay "network charges" if 14 of 15
megabytes are transferred and then the FTP connection aborts.

If we are still asking this question when usage-based charges are
common, we deserve what we get.  There is (almost) no reason why this
should be a problem, given some thought to protocol design; in other
words, the problem is in FTP, not in whatever charging scheme.

Consider what happens today when you've just lost an FTP connection
after waiting 3 hours for a large file to ooze across the ARPAnet.  Do
you think "wow, what I really want to do is retransfer all those bytes"
or do you think "darn, all I really want is the last 37 bytes"?  FTP is
a good protocol for efficient transfers over stable networks, but it's
not particularly useful if the probability that the transfer will never
complete approaches 1.

If our bulk-transfer protocol allowed us to ask for a piece of a file,
rather than the whole thing, life today would be a lot easier (and life
in the pay-per-packet future would be a lot cheaper).  A robust FTP
user program might then be able to automatically retry failed transfers
without duplicating data already transferred.  I'm not saying that NFS
is perfect, but at least it makes this kind of thing possible.

The reason why I used the word "almost" in the 2nd paragraph is that
one would have to worry more about locking (in case the file changed)
between two partial transfers, and that opens up a hornets nest ... but
many current systems don't guarantee consistency anyway.

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 19:39:50 GMT
From:      Link@GUNTER-ADAM.ARPA
To:        comp.protocols.tcp-ip
Subject:   Network Operating Systems


 
 
     I've reviewed RFCs 1001 and 1002, NETBIOS over TCP/IP, but 
have been unable to resolve a nagging question:  Do I need a 
Network Operating System to provide PC to PC communications on a 
802.3/TCP/IP/NETBIOS LAN?  I've spoken to several vendors, such 
as Novell, Torus, and Bridge/3Com, and received conflicting and 
contradictory answers.   Can anyone out there give me some 
help/point me in the right direction?
 
     I'm also in need of the NETBIOS spec.  IBM has been most 
uncooperative helping me find their technical documentation; " it 
was last marketed in October 1987, and I can't give to you..."
 
     Please reply to me directly and I will summarize for the 
rest of the TCP/IP mailing list.  Thanks.
 

  |====================================================================|
  |  Link Verstegen                Network Solutions, Inc. (NSI)       |
  |  Lead Hardware Engineer        4350 Will Rogers Parkway, Suite 100 |
  |                                Oklahoma City, OK  73064            |
  |  Link@Gunter-Adam.ARPA         (405)942-8884                       |
  |====================================================================|

-------

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 21:03:18 GMT
From:      hine@comp.vuw.ac.nz (John Hine)
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

This has been an interesting discussion.  Unfortunately it seems to
ignore those of us a long way from the centre of activity.  COnsider
the case for usage charges.

I would have to agree that usage charges don't always create an
immediate increase in efficiency of use, but they might introduce some
fairness.  Down here we pay real money for our X.25 link to UUNET, and
we pay both ways.  Because the Internet has no chargeback mechanism we
pay for you to send us mail.  This makes an e-mail connection
expensive but still worthwhile.  The problem arises when someone
decides they have something you would like and, without thinking, pops
it in the e-mail.  Voila, we have a $60 bill for something that might
not have been solicited.  We've had worse cases than this and it
happens with annoying regularity.

Some form of chageback would at least get these people to think about
their actions -- at least after their first $60 bill.  For a lot of
things air mail is still a cost effective communication medium!

jh
-- 
-----------------------------------------------------------------------
Domain: hine@comp.vuw.ac.nz		 Dept. of Computer Science
UUCP: ...!uunet!vuwcomp!hine		 Victoria University
					 P.O. Box 600, Wellington, NZ

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 21:05:00 GMT
From:      Corrigan@DDN3.ARPA
To:        comp.protocols.tcp-ip
Subject:   Network Charges


1.  Members of the list (at least collectively) probably won't make the 
decision, but that's DARPA's call.  
2. Members can influence the decision, not only for the ARPANET, but for the
MILNET as well.  I am batching up the collected comments for delivery to
the keeper of the "Commercial Communications Industrial Fund".  They set the
rate structure for both nets in conjunction with the network manager.  It is
a revolving fund, and as long as expenditures equal receipts over time, there
is some freedom in making the "right things" happen.

Mike Corrigan

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 21:42:32 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  refund mechanisms in charging

Craig, you are right about the certification of bad transfers.  Messages
from some trusted network component might satisfy such a
requirement.  I know this sounds messy, but even the telephone
system sort of relys upon my work to say the a call was disconnected
during use and I get a full refund, even if I only call back and say 
goodbye and pay only the minimum charge.  Such are the issues
of charging for useage.

dennis

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 21:45:14 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

Alan, certainly if I had to pay for each character I sent I would
try to find a better way of participating in this discussion, or
not participate at all.  After all, this conversation is not related
to very many of our jobs, but is extreamly important in that the network
facilitates the performance of our job.

dennis

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 22:06:44 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  Charging and aborted transfers

Jeffrey, I think you have hit on and important question that is not
asked very offten, namely, how does policy affect the architecture?
Certainly, this was answered when packet switching was chosen over
circuit switching.  Now that we have a network, new policy questions
may force us to reexamine the architecture we use.  This of course
may have some interesting consequences for the DoD.  For example, suppose
we go to pay per packet and the architecture is changed to minimize
costs.  Now we find that we are in conflict with survivability or
security or robustness policy issues.  What does the DoD do?  does
it want to recover cost, or develop technology which will survive
in a stress environment.

Oh well, in this case it may not matter, because if we get involved
in a stressed situation, there may not be anyone around to use the
net anyway.:-)

dennis

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 22:46:24 GMT
From:      cire@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Another problem with usage charges

>> Date: Tue, 26 Apr 88 09:05:34 EDT
>> From: bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein)
>> To: perry@MCL.UNISYS.COM
>> Cc: VALDIS@clvm.clarkson.edu, tcp-ip@sri-nic.ARPA, perry@mcl.unisys.com
>> Subject:  Another problem with usage charges
>> 
>> If nothing else this is becoming an object lesson in why AT&T was
>> granted a monopoly, it certainly did simplify a lot of things. Sure,
>> that's been broken up, perhaps around 2080 Judge Greene will see that
>> the internet can be "deregulated" also.

One of the depressing things about the deregulation of AT&T is that in
many ways it may have been better to not deregulate.  I haven't seen
lower prices or better service.  But then again I live in the hinter
land of the Santa Clara Valley.  There are some things that should
perhaps be left as a monopoly or set up that way because the overhead
of other structures is too costly.

>> 
>> There are other examples, I think people on this list are starting to
>> understand what the word "infrastructure" really means. It has a lot
>> to do with services who's very value is based upon their universality
>> (roads that go to other roads, phones that can call all other phones,
>> railroads that can use other tracks, canals that link to other
>> waterways, consistent rules and tariffs etc.)
>> 

Is the infrastructure of networks universal to an Information Age?
What ever that is.

>> 	-Barry Shein, Boston University
>> 

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 23:05:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re:  Charging and aborted transfers


    Jeffrey, I think you have hit on and important question that is not
    asked very offten, namely, how does policy affect the architecture?

Actually, I was trying to make a slightly different point: that we
are already "paying" for lost packets, even if we aren't actually
mailing in checks.  We should be looking for ways to avoid "wasting"
packets even before we have to pay for them in real money, because
we can't afford the latency/congestion/low bandwidth anyway.  Alas,
charging real money might be the only way to get people to listen.

Thus, if I'm doing a transaction protocol and the network loses a
packet late in the transaction, or I'm running NFS with mobygrams
and the fragmentation demons strike (thanks to JQJ for these examples),
why should I not have to pay for the packets that the network delivered
properly?  Perhaps some sense of "justice" implies that the work
I've lost is the fault of the network, but nowadays when the network
is "free" we still have to deal with those losses, so we might as
well think about making our protocols more robust rather than looking
for someone else to pay.

True, if the phone company gives you a bad connection, you expect them
not to charge when you complain.  If the "network company" doesn't
meet their service guarantees (error rate) then you shouldn't pay them
either.  That doesn't make it any less necessary to make the best
of the situation.

I don't pretend to know how to build a transaction protocol that is
efficient yet responds well to lost packets.  I have, however, trashed
NFS in public before for using fragmentation instead of a real
protocol; there's no excuse for that and I have no sympathy for
people who don't want to pay for the successfully transmitted fragments
if the network drops one.

    For example, suppose we go to pay per packet and the architecture is
    changed to minimize costs.  Now we find that we are in conflict with
    survivability or security or robustness policy issues.  What does the
    DoD do?  does it want to recover cost, or develop technology which will
    survive in a stress environment.
    
    Oh well, in this case it may not matter, because if we get involved in
    a stressed situation, there may not be anyone around to use the net
    anyway.:-)
    
Does too matter, since if the network collapses from stress during
a crisis, we might launch those missiles by accident (or through panic).
I think it's foolish to try to combine both pay-per-packet and serious
real-time constraints; if you want guaranteed service you should pay
for it in advance, where "pay" may mean "assign a high priority" or
"build a VC and reserve the resources".  Datagram networks seems
best if "spreading the pain" is your goal; I'm not sure I would
be a datagram fan if I had to guarantee service through a big hairy
internet.

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 23:12:49 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Charging and aborted transfers


	
	If we are still asking this question when usage-based charges are
	common, we deserve what we get.  There is (almost) no reason why this
	should be a problem, given some thought to protocol design; in other
	words, the problem is in FTP, not in whatever charging scheme.
	
We GAVE that thought to the FTP design, in 1975!  Alex McKenzie came up
with the simple and elegant Restart mechanism which is in the FTP protocol.
All that is needed is for people to implement it.  File access protocols
are very useful, but they are not needed, and probably not particularly
useful, to replace FTP Restart.

Bob Braden

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 88 23:22:16 GMT
From:      cg13+@ANDREW.CMU.EDU ("Curtis C. Galloway")
To:        comp.protocols.tcp-ip
Subject:   Broadcast-induced crash stories wanted

I'm looking for horror stories of network crashes (or dramatic congestion)
caused by broadcast packets.  In particular, I am interested in problems caused
by local broadcast address mismatches.  Any and all replies will be greatly
appreciated.

Thanks --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Curt Galloway
ARPA: cg13+@andrew.cmu.edu
UUCP: ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!cg13+
Drop In Any Mailbox, Return Postage Guaranteed

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 01:04:08 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  My two cents about charge schemes on the Arpanet

Dave, as you may know by now, John Laws, bless his heart, has set me
straight on the way x.25 charges were made or not made as the case
may be.  I am also constantly amazed at the mass of information you
have stored in your permenant memory on type of networks and stories
attached thereto.  I do not doubt that there are many inovative ways
to make money in this world.  I like the one about the DJ who announced
on the air to send him $20 and he now as $240K and doesn't know what
to do with it.  He gave no reason for people to send him money, just that
they do it.  I suspect some of are like that.  When someone says send
money for the datagram I just sent you, we will, no questions asked.

dennis

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 1988 05:29-EDT
From:      CERF@A.ISI.EDU
To:        perry@MCL.UNISYS.COM
Cc:        sean@CADRE.DSL.PITTSBURGH.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Whither chargeback policies?
Dennis,

I don't see much difference between connect time charge and volume
if the data rate is fixed (e.g. at 64 kb/s). Some people would
argue that connect time is regressive if you are charged the same
to send a little as a person who sends a lot. That's one reason
the Telenets and Compuserves charge more for 1200 baud than for 300 
baud access.

Vint
-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 02:38:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re:  My two cents about charge schemes on the Arpanet

Dennis,
 
Not so. The issue with X25 connected to Arpanet was that the caller
pays for the whole circuit - not half. When Europe called Arpanet that
was fine, Europe paid. But if for example e-mail was routing from
Arpanet to Europe over X25 and a X25 call had to be opened then
Arpanet would be billed. Bob Kahn then proposed that in such
situations he would raise a matching equal bill from Arpanet to
be paid by Europe. (Remember between Europe and US it is not
possible to do reverse charging on X25 for legal reasons rather than
technical I understand.)
 
 
So as of now if X25 is used between Europe and Arpanet it is only
used in the west direction. Traffic initiated in Arpanet for Europe
takes other paths - and that is another issue.
 
 
I have found this discussion most interesting because it parallels
many of the issues I see in how to route within the future NATO
community of interconnected peer level National/Service networks.
 
John

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 1988 06:54-EDT
From:      CERF@A.ISI.EDU
To:        perry@MCL.UNISYS.COM
Cc:        craig@NNSC.NSF.NET, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  refund mechanisms in charging
At MCI, we had the policy of refunding charges if users called with
complaints - both for the telephone charges and for MCI Mail. If,
however, a user had a track record of claiming refunds regularly,
we looked a lot more closely and sometimes revoked the user's
subscription to service.

Its generally good business to believe customers but, like the
Russian saying quoted by Reagan: Trust but Verify.

Vint
-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 1988 06:57-EDT
From:      CERF@A.ISI.EDU
To:        EBIBISI%UTMEM1.BITNET@CUNYVM.CUNY.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Protocol Analyzers
Ed,

I suggest you get in touch with Charles Brown at Complete Systems, Inc.
He is in Reston, VA (or close to that) in area code (703). I don't
have his telephone number handy, but you ought to be able to reach it
via information (703) 555-1212. Charles handles a lot of LAN equipment
and is familiar with a number of LAN monitoring tools.

Vint Cerf
-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 1988 07:10-EDT
From:      CERF@A.ISI.EDU
To:        perry@MCL.UNISYS.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  My two cents about charge schemes on the Arpanet
Dennis,

one of the reasons policy based routing is important is to accommodate
charging. Some nets may say "don't send traffic to me if you can't
pay for it" - it happens in the X.25 public data net arena all the time.

Vint
-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 1988 07:26-EDT
From:      CERF@A.ISI.EDU
To:        LAWS%rsre.mod.uk@RELAY.MOD.UK
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  My two cents about charge schemes on the Arpanet
Internatinal reverse charging has not been implemented, in general,
because it was too hard to collect from the calling party (usually, reverse
charges were billed back to the caller along with services rendered at
the destination of the call - as in timesharing service). Some experiments
in international reverse charing have been conducted. Between the U.S. and
Canada, for example, calls are treated as "domestic" for purpose of allowing
reverse charging.

Clarification:

in reverse charging, the network bills the called party, but typically,
the called party bills the costs back to the caller, bundled with other
service charges.

Vint
-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 04:48:19 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  My two cents about charge schemes on the Arpanet

Dennis,

Gotta tell you that I worked my way through undergrad school partly as a
DJ/combo man for every radio station within ten miles of Ann Arbor, MI.\
This was during the Payola years and, lemme tell you, a DJ that collected
$240 that way would instantly be connected from the base of the antenna
to ground with full carrier on. My how times they do change...

Dave

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Apr 88 13:31:40 PDT
From:      braden@venera.isi.edu
To:        craig@nnsc.nsf.net, perry@mcl.unisys.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  refund mechanisms in charging
	
	Craig, you are right about the certification of bad transfers.  Messages
	from some trusted network component might satisfy such a
	requirement.  I know this sounds messy, but even the telephone
	system sort of relys upon my work to say the a call was disconnected
	during use and I get a full refund, even if I only call back and say 
	goodbye and pay only the minimum charge.  Such are the issues
	of charging for useage.
	
	dennis
	
Dennis,

The solution is to implement the FTP protocol, including FTP Restart! The
user DID transfer most of the bytes... why should we return his money?
Why create a hard problem when there is a trivial solution?

Bob Braden
-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Apr 88 13:28:18 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   Why charge for packets

    Perhaps I'm covering ground already mentioned somewhere (if so,
set me straight) but I wonder if charging by packet is the right
mechanism.

    Consider charging people entirely by the capacity of their link
to the Internet.  I.e., if you have a 56Kbit connection you pay a certain
sum, if you have a 9.6Kbit connection you pay much less and if you
have a T1 connection you pay much more.

    These cost are set in such a way to cover the infrastructure costs
(e.g. the cost of the backbone networks).

    The logic behind this scheme is that your line speed tells us roughly
how much traffic you can introduce into the network (as either a sender
or receiver), and if the costing is done right, you have an incentive
to pay for only as much bandwidth as you need.

    Similar schemes are in use in other fields.  Pardon the choice of
example, but in cities where you pay for garbage collection, an oft
used payment scheme is that you (even residential customers) rent
approved garbage dumpsters from the city -- and the city only picks
up trash in approved dumpsters.  The result is that you buy as much
dumpster capacity as you need to get rid of your trash (and you have
some incentive to minimize your trash production).

    Of course this scheme can be rigged slightly so that lucky folks
in high network density areas are paying more than their fair share of
the infrastructure costs so folks in low density areas can get networking
too.

Craig
-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 09:29:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

Dennis,

I don't see much difference between connect time charge and volume
if the data rate is fixed (e.g. at 64 kb/s). Some people would
argue that connect time is regressive if you are charged the same
to send a little as a person who sends a lot. That's one reason
the Telenets and Compuserves charge more for 1200 baud than for 300 
baud access.

Vint

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Apr 1988 15:45:20 EST
From:      Greg Swartwout <R1ECGF%AKRONVM.BITNET@CUNYVM.CUNY.EDU>
To:        COMM-L@OHSTVMA, TCPIP-L@UIUCVMD, IBM-MAIN@AKRONVM, IBM-NETS@BITNIC, TCP-IP@SRI-NIC.ARPA
Subject:   Connecting IBM 3090's to internet
  We have just recently started connecting the different system here to
internet and are innterested in finding out how other sites had handled
IBM mainframes.  We are particularly interested in knowing what hardware
and software has been used, and the advantages and disadvantages of each.
TCP/IP, Ethernet, and DECNET are the main protocol we are interested in.
Please respond directly to me, as I am not on all of these lists.

                                                      Greg
-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 10:54:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  refund mechanisms in charging

At MCI, we had the policy of refunding charges if users called with
complaints - both for the telephone charges and for MCI Mail. If,
however, a user had a track record of claiming refunds regularly,
we looked a lot more closely and sometimes revoked the user's
subscription to service.

Its generally good business to believe customers but, like the
Russian saying quoted by Reagan: Trust but Verify.

Vint

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 10:57:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Protocol Analyzers

Ed,

I suggest you get in touch with Charles Brown at Complete Systems, Inc.
He is in Reston, VA (or close to that) in area code (703). I don't
have his telephone number handy, but you ought to be able to reach it
via information (703) 555-1212. Charles handles a lot of LAN equipment
and is familiar with a number of LAN monitoring tools.

Vint Cerf

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 11:10:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  My two cents about charge schemes on the Arpanet

Dennis,

one of the reasons policy based routing is important is to accommodate
charging. Some nets may say "don't send traffic to me if you can't
pay for it" - it happens in the X.25 public data net arena all the time.

Vint

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 11:16:42 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

Vint, we had different connect time charges at Los Alamos, depending
on the rate, so rate sensitivity is was understood by the users.
The difference between volume and connect charges is of course
rather small, but I think goes the right way to support an infrastructure.
After all, we are not arguing about wheather one should pay, just about
how one goes about collecting the money and how much for what services.
You pay for the resourse you use in keeping others out of the system.
The resourse you use to get to the system, telecommunications, may in
fact be dedicated to you, but there were limited number of users
who could effectively use the ports available to get to the supercomputers.
Now, you could sign on and use the facility at any rate you chose, i.e.
usage rate is not the same as bandwidth.  Typing characters at 20 word
per minute is not the same as transmitting each character at 56 kbit/s.
Those who only type text could get by with 2400 to 4800 b/sec service,
while those who generated lots of graphics to a textronix would much
prefer a 9.6 kbit/s service or higher (we had some that ran substantially
higher, I don't remember now how high).

In the arpanet one does not normally have the option of connection and
disconnecting to the PSN, thus, one has a static connection.  What we
do have is random receipt and sending of packets accros the interface.
Even today, the Arpanet folks have the option of giving you a 9.6 kbit/s
line connection to the PSN or a 56 kbit/s line connection.  I do not
remember for sure, but I believe that the cost to DARPA is the same.
This is one of the flawed aspects of current billing for the Arpanet.  The
only cost to the user is the connection line to the PSN (excpet for early
connection which were still being paid for by DARPA, but were being looked
at to have the user pay the connect charges.)

I am not sure where this conversation is going, but I sense an attitude
by some that usage sensivitive charging is the way to go with out looking
at alternatives and resultant possible reactions by the community or the
purpose of fostering the network in the first place (policy).

My bottom line is that the existing system may not be designed to
support certain types of charges and one should examine that as well.
Do we want to change the protocols, do we have to, how does it affect
the policy if we do, etc.?

I do not claim to know the answeres, nor do I believe a simple solution
is necessarily available outside of the Government to continue to provide
'free' service.  Another solution might be for the Government to find
a way for connectees to pay their port charge instead of DARPA having
to pay it.  That way DARPA could continue to subsidize those whom they
wished, others would pay.  I suspect that solution alone would reduce
the DARPA part of the bill to less than a $1M.  By the way, I am not
convinced that DARPA really wants to reduce its cost that much.  The
DARPA default connection is to the Milnet, which is going to usage
charges.  It used to be the Arpanet, but we switched over when the
Arpanet became so congested and DARPA folks could not get to ISI
to read their mail.  I suggested that they switch back, but that has
not happened (yet?).

dennis

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 11:26:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  My two cents about charge schemes on the Arpanet

Internatinal reverse charging has not been implemented, in general,
because it was too hard to collect from the calling party (usually, reverse
charges were billed back to the caller along with services rendered at
the destination of the call - as in timesharing service). Some experiments
in international reverse charing have been conducted. Between the U.S. and
Canada, for example, calls are treated as "domestic" for purpose of allowing
reverse charging.

Clarification:

in reverse charging, the network bills the called party, but typically,
the called party bills the costs back to the caller, bundled with other
service charges.

Vint

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Apr 1988 18:37:25 EDT
From:      Ittai Hershman <ittai@vx2.GBA.NYU.EDU>
To:        Craig Partridge <craig@nnsc.nsf.net>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Why charge for packets
I have been sitting on the sidelines watching the discussion on
network costing/charging.  I am afraid that some people have missed
the forest for the trees.  Craig Partridge has put us back on the
right track.

The Internet is a tool to increase R&D and productivity.  Because this
increase is a result of sharing among competitors (regardless of
whether these are profit-making or non-profit institutions, sharing of
information results in a loss of competitive edge).  Yet it promotes a
common good and the rules-of-the-game are changed by this sharing:
standards are formed, technology is advanced, and competition is
spurred.

This, in my opinion, is precisely why the Internet is an
"infrastructure issue" as are interstate highways; like interstate
highways, the cost of the network infrastructure -- the PSNs and the
trunks which interconnect them -- should be federally funded from
general revenues.  I suspect that the Internet infrastructure
operating and capital costs can be budgeted with a high degree of
certainty.

Furthermore, the States have gotten involved, and we now have a bunch
of regional networks with State funding as well.  So the model is one
of a federally funded national infrastructure which serves two
subordinate layers: federal institutions, and regional subnets.  The
regional networks, in turn have subordinate institutions.  And
finally, the institutions are responsible for their own internal
networking.

All of this, I think, conforms to the spirit of FCCSET.  

The pragmatic problem, of course, is that it is (unfortunately)
unlikely that the Congress and the State Legislatures will value the
Internet as we (who are biased consumers of it) do.

And so, in this imperfect world, we must find a way to raise some of
the money ourselves.  And since many of the consumers of this resource
are cash poor, we struggle to find an equitable method of cost
distribution which does not negate the raison-d'etre.

I agree with Craig.  Charging by "bandwidth" is both equitable and
reasonable.  Look at the rousing sucess of BITnet -- it permitted
virtually all institutions of higher education an affordable but
minimal level of service.  A lifeline service.  Mail.  
To get more, you pay more. 

To further raise revenues, I think the Internet should allow/encourage
involvement of commercial companies.  Aside from the computer
manufacturers and software houses, there are many commercial companies
involved in (non-defense) research and would benefit from Internet
access.  For example, the financial institutions in the Wall Street
area hire PHDs (and faculty) galore and have more advanced computer
technology than most CS departments.  Many would be interested, and
certainly could be "sold" on joining.  They would be charged higher
fees, since their return to the Internet will be less direct.  The
fees could be used to subsidize the non-profits.  (Note that we would
not be selling communications media, rather the data, so I think this
can be justified legally).

Lastly, I suspect that the most expensive (read: inefficient) part of
the Internet at present is not the traffic per se.  Rather, that the
redundency is at the site level rather than at the infrastructure
level.  NYU, for example, has three Internet connections: MILnet,
JVNCnet, and NYSERnet.  Wouldn't the resources required for all of
this (computers, gateways, leased lines) be better spent on the
PSN/trunk level?!?  Reorganizing the whole mess will probably save
enough money to make some needed capital improvements.

On a final note, as a member of the University-wide network planning
committee at NYU, I see that we are a microcosm of the Internet.  We
are a huge institution, spanning unwieldy amounts of real estate, with
decentralized control.  We have "rich schools" and "poor schools" and
the rich subsidize the poor.  We have not found a good method of
charging for network services, and I suspect we never will.

You can't quantify the loss of an infrastructure service -- only what
it costs a part to run, and what it costs to replace that part if it
fails.  The value of the whole is immeasurable.

Apologies for the length...

-Ittai
-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 17:09:45 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

In article <8804262145.AA13529@LANAI.MCL.UNISYS.COM> 
perry@MCL.UNISYS.COM (Dennis Perry) writes:
>Alan, certainly if I had to pay for each character I sent I would
>try to find a better way of participating in this discussion, or
>not participate at all.

If we mst al py per char, ther my b wys to rduc th no o chars xmitd.
	kwe, BU

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 17:28:18 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Why charge for packets


    Perhaps I'm covering ground already mentioned somewhere (if so,
set me straight) but I wonder if charging by packet is the right
mechanism.

    Consider charging people entirely by the capacity of their link
to the Internet.  I.e., if you have a 56Kbit connection you pay a certain
sum, if you have a 9.6Kbit connection you pay much less and if you
have a T1 connection you pay much more.

    These cost are set in such a way to cover the infrastructure costs
(e.g. the cost of the backbone networks).

    The logic behind this scheme is that your line speed tells us roughly
how much traffic you can introduce into the network (as either a sender
or receiver), and if the costing is done right, you have an incentive
to pay for only as much bandwidth as you need.

    Similar schemes are in use in other fields.  Pardon the choice of
example, but in cities where you pay for garbage collection, an oft
used payment scheme is that you (even residential customers) rent
approved garbage dumpsters from the city -- and the city only picks
up trash in approved dumpsters.  The result is that you buy as much
dumpster capacity as you need to get rid of your trash (and you have
some incentive to minimize your trash production).

    Of course this scheme can be rigged slightly so that lucky folks
in high network density areas are paying more than their fair share of
the infrastructure costs so folks in low density areas can get networking
too.

Craig

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 18:10:00 GMT
From:      Plummer@DOCKMASTER.ARPA
To:        comp.protocols.tcp-ip
Subject:   Net usage charges

Suppose I decide to get rich by implementing a new, world wide net and
get it patched into many of the existing nets using standard gateways.
My net will be a good one but my gateways will advertize infinite
bandwidth, zero delay so my net will soak up all of your traffic.  Since
you probably won't agree to subsidize me, Ihave to be able to send bills
and be able to collect.  But none of you are actually on my net, I'm
just a transport with marketeering gateways.  But you probably won't
like my bills which will be the max I can get away with.  Do you need a
Type Of Service that says "avoid high priced nets"?  What if I'm the
only path available?  Can my profiteering be legislated out?  Should it
be?  --Bill Plummer -at DOCKMASTER

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 20:28:37 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Another problem with usage charges

Valdis,

Scream at the implementors who thought FTP Restart was only for sliderule
nurds.

   Bob Braden
   

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 20:45:20 GMT
From:      R1ECGF@AKRONVM.BITNET (Greg Swartwout)
To:        comp.protocols.tcp-ip
Subject:   Connecting IBM 3090's to internet


  We have just recently started connecting the different system here to
internet and are innterested in finding out how other sites had handled
IBM mainframes.  We are particularly interested in knowing what hardware
and software has been used, and the advantages and disadvantages of each.
TCP/IP, Ethernet, and DECNET are the main protocol we are interested in.
Please respond directly to me, as I am not on all of these lists.

                                                      Greg

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 21:12:06 GMT
From:      ehrlich@blitz.cs.psu.edu (Dan Ehrlich)
To:        comp.protocols.tcp-ip,comp.unix.wizards,comp.unix.questions
Subject:   How do I trace IP packets across the InterNet?

Would someone out there tell me how to "trace" the route an packet
takes on an IP network?  In the IP header there is a "Record Route"
option but I can not find any utilities, etc, that use it.  Any help or
hints would be apprecited.  Thanks in advance.

Dan Ehrlich <ehrlich@blitz.cs.psu.edu>
The Pennsylvania State University, Department of Computer Science
333 Whitmore Laboratory, University Park, PA   16802
+1 814 863 1142 or +1 814 865 9723

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 21:28:02 GMT
From:      AI.CLIVE@MCC.COM (Clive Dawson)
To:        comp.protocols.tcp-ip
Subject:   Re: Why charge for packets

Another scheme which might come in useful, and which is often
used by city utilities, is to pick a period of time where
usage is monitored to obtain a figure for "average" usage.  Then
a charge is based on this figure.  There are no meters on
our sewage lines which can be used to bill for wastewater.
Instead, the city bases its wastewater charges by sampling
potable water usage for a month or two.  (This usually is done
in the winter time to avoid the lawn watering factor, etc.)

In this case, the network administrators might wish to
compute an "average" packet count for each host by
monitoring for some period of time.  (Such times should 
obviously be well-kept secrets so that hosts don't influence
the result by changing their behavior.)  Network charges 
could then be assessed based on these results.

Just figured I had to get MY two cents in...!

Clive Dawson
-------

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 22:37:25 GMT
From:      ittai@VX2.GBA.NYU.EDU (Ittai Hershman)
To:        comp.protocols.tcp-ip
Subject:   Re: Why charge for packets

I have been sitting on the sidelines watching the discussion on
network costing/charging.  I am afraid that some people have missed
the forest for the trees.  Craig Partridge has put us back on the
right track.

The Internet is a tool to increase R&D and productivity.  Because this
increase is a result of sharing among competitors (regardless of
whether these are profit-making or non-profit institutions, sharing of
information results in a loss of competitive edge).  Yet it promotes a
common good and the rules-of-the-game are changed by this sharing:
standards are formed, technology is advanced, and competition is
spurred.

This, in my opinion, is precisely why the Internet is an
"infrastructure issue" as are interstate highways; like interstate
highways, the cost of the network infrastructure -- the PSNs and the
trunks which interconnect them -- should be federally funded from
general revenues.  I suspect that the Internet infrastructure
operating and capital costs can be budgeted with a high degree of
certainty.

Furthermore, the States have gotten involved, and we now have a bunch
of regional networks with State funding as well.  So the model is one
of a federally funded national infrastructure which serves two
subordinate layers: federal institutions, and regional subnets.  The
regional networks, in turn have subordinate institutions.  And
finally, the institutions are responsible for their own internal
networking.

All of this, I think, conforms to the spirit of FCCSET.  

The pragmatic problem, of course, is that it is (unfortunately)
unlikely that the Congress and the State Legislatures will value the
Internet as we (who are biased consumers of it) do.

And so, in this imperfect world, we must find a way to raise some of
the money ourselves.  And since many of the consumers of this resource
are cash poor, we struggle to find an equitable method of cost
distribution which does not negate the raison-d'etre.

I agree with Craig.  Charging by "bandwidth" is both equitable and
reasonable.  Look at the rousing sucess of BITnet -- it permitted
virtually all institutions of higher education an affordable but
minimal level of service.  A lifeline service.  Mail.  
To get more, you pay more. 

To further raise revenues, I think the Internet should allow/encourage
involvement of commercial companies.  Aside from the computer
manufacturers and software houses, there are many commercial companies
involved in (non-defense) research and would benefit from Internet
access.  For example, the financial institutions in the Wall Street
area hire PHDs (and faculty) galore and have more advanced computer
technology than most CS departments.  Many would be interested, and
certainly could be "sold" on joining.  They would be charged higher
fees, since their return to the Internet will be less direct.  The
fees could be used to subsidize the non-profits.  (Note that we would
not be selling communications media, rather the data, so I think this
can be justified legally).

Lastly, I suspect that the most expensive (read: inefficient) part of
the Internet at present is not the traffic per se.  Rather, that the
redundency is at the site level rather than at the infrastructure
level.  NYU, for example, has three Internet connections: MILnet,
JVNCnet, and NYSERnet.  Wouldn't the resources required for all of
this (computers, gateways, leased lines) be better spent on the
PSN/trunk level?!?  Reorganizing the whole mess will probably save
enough money to make some needed capital improvements.

On a final note, as a member of the University-wide network planning
committee at NYU, I see that we are a microcosm of the Internet.  We
are a huge institution, spanning unwieldy amounts of real estate, with
decentralized control.  We have "rich schools" and "poor schools" and
the rich subsidize the poor.  We have not found a good method of
charging for network services, and I suspect we never will.

You can't quantify the loss of an infrastructure service -- only what
it costs a part to run, and what it costs to replace that part if it
fails.  The value of the whole is immeasurable.

Apologies for the length...

-Ittai

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 88 23:41:16 GMT
From:      mckee@corwin.ccs.northeastern.EDU (George McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

Alternative-Subject: "what price broadcasts?"

Dennis Perry <perry@mcl.unisys.com> writes:
>...
>The resourse you use to get to the system, telecommunications, may in
>fact be dedicated to you, but there were limited number of users
>who could effectively use the ports available to get to the supercomputers.
>Now, you could sign on and use the facility at any rate you chose, i.e.
>usage rate is not the same as bandwidth.  Typing characters at 20 word
>per minute is not the same as transmitting each character at 56 kbit/s.
>Those who only type text could get by with 2400 to 4800 b/sec service,
>while those who generated lots of graphics to a textronix would much
>prefer a 9.6 kbit/s service or higher (we had some that ran substantially
>higher, I don't remember now how high).
>...
>dennis

When I think about network service, this statement is more like the mental
model I have than the other one that seems to be implicit in much of this
discussion.  The fact that mail is perhaps the most visible form of
network use leads people think about billing in terms of per-message
(i.e. per-packet) charges, just like the post office or the telephone
company.  An alternative model that I think is just as valid is cable
television, where you pay (in advance, even) for a guarantee of a certain
amount of bandwidth.  Subscribers are offered different levels of service,
and it is provided whether your TV is on or not.  Few people watch HBO
24 hours a day, but that's what you pay for.

I'd guess that there's at least as much internet traffic generated by
"broadcast" lists such as this one, as there is traffic generated by
individual-to-individual messages, though I have no idea how the
relevant data could be collected.  In a research-oriented community,
the free flow of information is widely acknowledged to be essential for
productivity.  It seems to me that bandwidth limits would be much less
painful to run up against than would usage limits.  I wouldn't like to
be in the middle of transferring some important file and suddenly get
hit by a "sorry: packet quota exceeded" message.  Or to be told that
I've exceeded my network budget with a whole month left in the fiscal
year.  Bandwidth limits could avoid this kind of trouble because the
costs are fixed in advance.

Of course, there would have to be ways of limiting bandwith (and other
forms of net access, as well) by software rather than hardware, so that
senior researchers could obtain the bandwith to transfer their
supercomputer output, while undergraduates or other peons who happen to
have signons on the same machine/subnet could be restricted to a
harmless trickle, but this should be preferable to flooding the network
with accounting packets.

If this alternative has already been considered and rejected, I
apologize.  I'd appreciate knowing the reasons, though, if someone could
point to an article where this is discussed.

	- George McKee
	  Software Coordinator
	  College of Computer Science
	  Northeastern University, Boston 02115
CSnet: mckee@Corwin.CCS.Northeastern.EDU
Phone: (617) 437-5204
Usenet: the signal/noise ration here is already too low...

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 88 13:47:31 GMT
From:      gross@GATEWAY.MITRE.ORG (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re:  RIP, gated reply summary

>        The IDEAS can be found at SRI-NIC.ARPA (10.0.0.51).
>        Login as 'anonymous'. The directory is <ietf>. Each
>        IDEA is named "IDEAnnn.TXT", where nnn is the IDEA number.
>        The indices are IDEA-INDEX.TXT (the short index, no abstracts)
>        and IDEA-INDEX-ABS.TXT (the long index, with abstracts).

As luck would have it, Charles Hedrick has just submitted a final version 
of the RIP paper, which has not yet been placed at the NIC.  He just mailed 
it to me yesterday and it is still sitting in my mailbox.  This also comes
at the exact same time that we are changing the IDEA numbering scheme to 
accomodate revisions (rather than issuing new numbers).  So it may be
Monday before the new version gets into place with its new not-quite-
zip-code-sized number IDEA0004-01.

I strongly encourage interested folks to wait for the new version.  It is 
this version that will be submitted as an RFC.  I promise to mail a notice 
to this list as soon as the new RIP document and the new numbering scheme 
are in place.  

As they say, timing is everything.  

Phill Gross

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 88   18:16 EDT
From:      PL233270%TECMTYVM.BITNET@CORNELLC.CCS.CORNELL.EDU
To:        TCP-IP @ SRI-NIC.ARPA
Subject:   BITNET mail follows
Date: 28 April 1988, 18:10:26 EDT
From: Teresa Lucio Nieto        Mexico (83) 58 56 49 PL233270 at TECMTYVM
To:   TCP-IP at SRI-NIC.ARPA

unsubscribe pl233270 at tecmtyvm and
            pp192157 at tecmtyvm
-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 88 15:52:00 GMT
From:      LIVINGSTONE@BERT.DECNet (LIVINGSTONE)
To:        comp.protocols.tcp-ip
Subject:   Re: Whither chargeback policies?

SIGNOFF TCPIP-L
UNSUBSCRIBE TCPIP-L

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 88 17:02:53 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Simple Cost Accounting Policy


	All this talk about problems and issues that would happen if
cost recovery just starts up ad-hoc proves that a straightforward
attempt to implement cost recovery piecemeal will fail.
	I would think that one place to start in coming up with
something reasonable for a campus/regional/backbone hierarchical model
would be to look at the network management data in the Management
Information Base (MIB).  IpPktsIn, IpPktsOut, TcpPktsIn, etc.  I don't
think usage charges should get any more complicated than that for
LAN/internet traffic.  If the jvnc-net people sent me a bill for $xxx
per month line charge for my 56kbps link and $yyy per thousand
IpPktsIn/IpPktsOut I could check that against what my router tells me
went in/out that interface.  I could set up the same kind of billing
per k of IpPkts for my local Ethernets if I wanted.  I really don't
think it should get any more complex than that.
	Even this simple scheme has problems.  What if BITnet and
jvncnet have vastly different charging schemes?  What if jvncnet and
the nsfnet backbone have different schemes?  What if jvncnet wants to
bill me for traffic that goes onto the backbone?  How will they
measure that?  How will I verify or understand charges like that?
There have to be simple rules for collecting traffic information and
collecting charges at limited specific points in the network.  I don't
see how it will work unless the campus nets, the regionals, and the
backbones all have similar models for collecting money.  Services like
the backbone should charge the regionals only and the regionals pass
on charges to the campus LANs without trying to account for individual
packets as they traverse nets.  Trying to differentiate intra-regional
from inter-regional (sound like intraLATA vs interLATA? :-) would be
too complicated to do at first.  Point is, it has to be coordinated
among the various nets or we have games being played where traffic
seeks the least literal cost route and not most effective transport
route.  Keep it simple.

	Kent England, Boston University

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 88 17:37:27 GMT
From:      rminnich@udel.EDU (Ron Minnich)
To:        comp.protocols.tcp-ip
Subject:   Re: Another problem with usage charges

In article <8804260944.AA25473@ucbvax.Berkeley.EDU> VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks) writes:
>% ftp someplace.faraway.arpa
>ftp>get big.manymeg.file
>(14 meg of the 15 meg file has been transferred)
>netinet: net unreachable
>Who pays for the 14 meg of usage? I sure don't want to - I didn't get the
>service I asked for.
Hmm, this is the second comment on this sort of thing. Is this 
an argument AGAINST charging or an argument FOR something better
than ftp- something that lets you move pieces of things
instead of the whole thing, and that would let you pop off that
last megabyte or so. After all, it did move 14/15th of the file for
you :-). 
   What if that 15 mb were 15 seperate files, and you did an mget,
then recovery would be easy. Maybe it is an argument for 
a different way of storing ftp-able things?

-- 
ron (rminnich@udel.edu)

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 88 19:11:28 GMT
From:      karwowska@xyzzy.UUCP (Joanna Karwowska)
To:        comp.protocols.tcp-ip
Subject:   Public Domain Software for Bootp

I would like to get an access to the public domain software
for remote bootstrap protocol - bootp (RFC951).
Can anybody help?

		Joanna Karwowska
		karwowska@dg-rtp.dg.com

-- 
			             Joanna Karwowska
			   Data General, Research Triangle Park, NC
			<the known world>!mcnc!rti-sel!rtp46!karwowska

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 88 22:16:00 GMT
From:      PL233270@TECMTYVM.BITNET
To:        comp.protocols.tcp-ip
Subject:   BITNET mail follows

Date: 28 April 1988, 18:10:26 EDT
From: Teresa Lucio Nieto        Mexico (83) 58 56 49 PL233270 at TECMTYVM
To:   TCP-IP at SRI-NIC.ARPA

unsubscribe pl233270 at tecmtyvm and
            pp192157 at tecmtyvm

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 88 00:33:22 GMT
From:      jbs@fenchurch.MIT.EDU (Jeff Siegal)
To:        comp.protocols.tcp-ip
Subject:   Re: Another problem with usage charges

In article <8804260944.AA25473@ucbvax.Berkeley.EDU> VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks) writes:
>Ever have this happen to you?
>% ftp someplace.faraway.arpa
>ftp>get big.manymeg.file
>(14 meg of the 15 meg file has been transferred)
>netinet: net unreachable
>     
>Who pays for the 14 meg of usage? 

The serial-line file transfer protocol Zmodem supports "crash
recovery."  This allows you to restart an aborted transfer, and the
protocol negotiates the restart point.  Charging for your 14 meg would
likely inspire the prompt creation of a similar internet protocol.

Jeff Siegal

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 88 09:15:11 GMT
From:      steve@NOTE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re: Simple Cost Accounting Policy


The NSFNET backbone will be directly funded by NSF.  -s

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      04/29/88 15:47:32
From:      Keith R. Hacke <M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA>
To:        <TCP-IP@sri-nic.arpa>
Subject:   TCP/IP Books
is something like "Internetworking with TCP/IP". If you know the ISBN, that
would do it for me.

Keith Hacke
McDonnell Douglas - St. Louis

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 88 12:39:24 GMT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Simple Cost Accounting Policy

Kent,

You have made two valid points here that should be differenciated, 
one is how to charge (fix cost versus measured traffic cost), second 
is consistency among all the mid-level networks (i.e. JVNCNet) and 
the backbone networks (i.e. NSFNET).  On the first point you have to 
cover your costs whether you charge for measured traffic or fix cost.  
The problem with measured traffic is that: (1) we have to further agree 
among all the other networks administrations what parameters to use 
in the charging model, (2) the implementation can become "expensive" 
to accomplish from the bandwidth and cpu point of view.  Thus I suggest 
the fix cost depending on line bandwidth (as I recall Craig Partridge 
suggested this before).  These costs have to: (1) cover the operational 
costs of the network, and (2) be consistent among other networks.  
All this can be worked on, with the exception that this assumes one 
type of user (i.e. University), what about if the user of the network 
is a researcher working for a profit making organization?, shall he pay 
the same as a researcher working for a University?.  The networks 
then have to get into an aggreement that is consistent, and take all 
these issues in consideration.  

As a point of information, there is a task force whithin the Federation
of American Research Networks (FARnet), working on this issue right
now.

					-- Sergio

-----------------------------------------------------------------------------
Sergio Heker				tel:	(609) 520-2000
Internet: "heker@jvnca.csc.org"		Bitnet:	"heker@jvnc"
JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager
-----------------------------------------------------------------------------

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 1988 18:15-EDT
From:      CERF@A.ISI.EDU
To:        zweig@P.CS.UIUC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Thoughts on why packet accounting w
Johnny,

Get your nose tested. There isn't a rat. The ARPANET is old technology
now (56 kb/s) and costs a lot to operate. The ARPA guys want to spend their
R&D money on new networking technology operating at much higher raes.

The accounting issue comes up for two reasons: the MILNET operation folks
need to allocate costs among the users of MILNET and the general growth
of the Internet infrastructure can't be supported solely on government
subsidy in today's climate. So we need to find ways for those who can to
pay for services rendered.

Vint
-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 88 14:18:32 GMT
From:      smb@ulysses.homer.nj.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Another problem with usage charges

In article <8804260944.AA25473@ucbvax.Berkeley.EDU> VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks) writes:
>Ever have this happen to you?
>% ftp someplace.faraway.arpa
>ftp>get big.manymeg.file
>(14 meg of the 15 meg file has been transferred)
>netinet: net unreachable
>     
>Who pays for the 14 meg of usage? 

Well -- if you read the spec, FTP itself implements checkpoint/restart.
Better protocols may be desirable, but for now we should make the most
of the ones we already have.

Has anyone implemented checkpoint/restart in FTP?


	--Steve Bellovin
	ulysses!smb
	smb@ulysses.att.com

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 88 15:14:13 GMT
From:      mo@maximo.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   Amazing conversation


I'm sure glad we're having this "How many 
FTP transfers can dance on the head of a
chargeback packet" conversation now,
because when chargebacks happen, it will
surely be too expensive to read these
amazing conversations.

	Smile broadly - it keeps 'em guessing.

	-Mike

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 88 15:18:09 GMT
From:      km@emory.uucp (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   TCP for Dec RT11 or DG RDOS

Does anyone know of a TCP implementation for either
of these environments?
-- 
Ken Mandelberg      |  {decvax,sun!sunatl,gatech}!emory!km  UUCP
Emory University    |  km@emory                             BITNET
Dept of Math and CS |  km@emory.ARPA                        ARPA,CSNET
Atlanta, GA 30322   |  Phone: (404) 727-7963

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 88 19:38:16 GMT
From:      Robin@turbo.RAY.COM (Robin Alston)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Many things on ethernet together???


We have a bunch of SGI workstations currently running XNS over ethernet.
We have just been informed that when we move into a new building at the 
end of May we will have to use a single ethernet cable for the whole
building which includes many vaxen running VMS many many pc's with some kind
of future-net link and many pc's with simple vax links.

My question is can this really work?
Can XNS and TCP-IP share the same coax cable with no possible problems?
Can we have our own domain (we really have no interest at this time in
talking to our vaxes), while decnet has its own on the same cable?

Am I right to be paranoid about some bureaucrats decision to limit internal
cabling this way?

We are intending at some future time to upgrade to TCP-IP so we can run NFS
but we want to do that in our own sweet time and not in a hurry.

Any help or hard facts would be gratefully accepted before I go out and
humanely shoot myself.

-- 
 -------------------------------------------------
# Whats worse than two MA drivers on a freeway?    #      Dr. Robin the REAL
# Answer: One Toronto driver                       #      SuperUser Atilla!
 -------------------------------------------------	  (617)-460-8225
	Robin@turbo.ray.com		.....!rayssd!turbo!Robin

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 88 22:15:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Thoughts on why packet accounting w

Johnny,

Get your nose tested. There isn't a rat. The ARPANET is old technology
now (56 kb/s) and costs a lot to operate. The ARPA guys want to spend their
R&D money on new networking technology operating at much higher raes.

The accounting issue comes up for two reasons: the MILNET operation folks
need to allocate costs among the users of MILNET and the general growth
of the Internet infrastructure can't be supported solely on government
subsidy in today's climate. So we need to find ways for those who can to
pay for services rendered.

Vint

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 88 22:36:21 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Charging and aborted transfers

It seems you are arguing that the charges should be based on
an assessment of usage at the application layer, where earlier
posters, talking about per-packet, are at the transport or lower
layer.

Rex Buddenberg

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 88 22:47:32 GMT
From:      M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA (Keith R. Hacke)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Books

is something like "Internetworking with TCP/IP". If you know the ISBN, that
would do it for me.

Keith Hacke
McDonnell Douglas - St. Louis

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 88 01:32:59 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, VALDIS@CLVM.CLARKSON.EDU
Subject:   Re: Another problem with usage charges


In many cases there are things the local site can do to improve the
reliability of long-distance FTP's.  The problem of getting 95% of a
file and then having the connection break is often due to a bug in
your TCP that causes it to interrupt the connection when it gets a
transient error message.  Newer versions of TCP and gateway code can
also make a dramatic difference.  I'm not sure that I approve of
usage-sensitive charging, at least in the research context.  But if
we're going to do it, paying for broken connections may not be so bad.
At the moment, people don't have much incentive to clean up old,
decrepit TCP's.

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 88 01:48:28 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Books

Keith Hacke:

ISBN 0-13-470154-2 025

--jon.

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 88 04:58:52 GMT
From:      greg@muddy.cs.unlv.edu (Greg Wohletz)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Campus Network Query

I am interested  in hearing any  comments people might  have on campus
wide networks; experiences with particular types  of networks, and the
companies that   provide them.   I'll  post  a  summary  if   there is
sufficient interest.

				--Greg
				greg@jimi.cs.unlv.edu
				<@relay.cs.net:greg@jimi.cs.unlv.edu>
				...!convex!jimi!greg

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 88 05:59:07 GMT
From:      limes@SUN.COM (Greg Limes)
To:        comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???

In article <218@turbo.RAY.COM> Robin@turbo.RAY.COM (Robin Alston) writes:

>Can XNS and TCP-IP share the same coax cable with no possible problems?

No problem. At the bottem layer, all the packets are tagged with source
and destination ethernet addresses, so packets only go where they are
expected -- except for the broadcast packets ...

Also, there is a field in the ethernet packet that determines the
protocol type; this should be checked by your network software.
Hopefully the drivers will not bitch about unknown packet types, as the
XNS packets are a complete mystery to TCP, and TCP is just greek to XNS.
It is even possible (gag) to run both TCP/IP and XNS through the same
physical interface, but the bottom layer does need to know where to send
each packet type. You might consider contacting someone at Communcation
Machinery Corporation in Santa Barbara, California; when I was there we
did some XNS development that shared the building-wide ethernet with
normal TCP used by all the other iron.

>Can we have our own domain (we really have no interest at this time in
>talking to our vaxes), while decnet has its own on the same cable?

You do not need to do anything special to ignore each other; in fact,
quite a bit would need to be done to make them talk. One would have to
understand the other's protocol. Imagine red and blue light in an
optical fiber. The upper level packet layouts just do not jibe.
-- 
   Greg Limes [limes@sun.com]				frames to /dev/fb

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 88 05:59:14 GMT
From:      limes@sun.uucp (Greg Limes)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Many things on ethernet together???

In article <218@turbo.RAY.COM> Robin@turbo.RAY.COM (Robin Alston) writes:

>Can XNS and TCP-IP share the same coax cable with no possible problems?

No problem. At the bottem layer, all the packets are tagged with source
and destination ethernet addresses, so packets only go where they are
expected -- except for the broadcast packets ...

Also, there is a field in the ethernet packet that determines the
protocol type; this should be checked by your network software.
Hopefully the drivers will not bitch about unknown packet types, as the
XNS packets are a complete mystery to TCP, and TCP is just greek to XNS.
It is even possible (gag) to run both TCP/IP and XNS through the same
physical interface, but the bottom layer does need to know where to send
each packet type. You might consider contacting someone at Communcation
Machinery Corporation in Santa Barbara, California; when I was there we
did some XNS development that shared the building-wide ethernet with
normal TCP used by all the other iron.

>Can we have our own domain (we really have no interest at this time in
>talking to our vaxes), while decnet has its own on the same cable?

You do not need to do anything special to ignore each other; in fact,
quite a bit would need to be done to make them talk. One would have to
understand the other's protocol. Imagine red and blue light in an
optical fiber. The upper level packet layouts just do not jibe.
-- 
   Greg Limes [limes@sun.com]				frames to /dev/fb
-- 
   Greg Limes [limes@sun.com]				frames to /dev/fb

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 88 16:35:29 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Books


Doug Comer's new book on TCP/IP is entitled "Internetworking with TCP/IP",
with a subtitle of "Principles, Protocols, and Architecture".  It
is published by Prentice Hall.  The ISBN is 0-13-470154-2.

It is a 375 page book that explains how and why it all works.

Dan
-------

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 88 17:37:33 GMT
From:      dls@mace.cc.purdue.edu (David L Stevens)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Many things on ethernet together???


	We ran two distinct logical TCP/IP networks on one Ethernet cable
for a time with no problems. The only thing you'll have to worry about
are (Ethernet) broadcast packets, since those will go everywhere. IP should
drop them quietly, but I don't know about XNS.

-- 
					+-DLS  (dls@s.cc.purdue.edu)

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 88 17:48:20 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: WHY are those mailbridges dropping so many packets????

Bob,  Your last paragraph suggested a campaign to get everyone running the
"new, improved" version of TCP that Jacobson and Karels have developed.
Van and Mike are putting on a two day seminar on that very subject
in a week and thus far we have more than half of the reelvant vendors
signed up to attend.  Hopefully those will provide enough oomph to
get products in the field soon.  (And goad the others to upgrade their
products or suffer vanishing sales...)

Dan
-------

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 88 19:21:07 GMT
From:      zweig@P.CS.UIUC.EDU (Jonathan Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: Thoughts on why packet accounting w

I agree heartily. ARPANET is old technology and should be phased out.
I was merely speculating because it struck me as rather *too* con-
venient that now that many people want to junk the arpanet, all of
a sudden the arpanet is much less fun to use and harder to hook
into.

Does it matter? ARPANET is doomed anyway. We'll have DRI and OSI and
all that sort of FUN (``eff-you-enn'') before long and the Earth shall
smell again of roses.

-Johnny Zweig

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 88 23:01:17 GMT
From:      "Thomas_D._Herbst.HENR801c"@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   RE:Many things on ethernet together???

At our facility XNS and TCP/IP coexist quite well on the same ethernet and even
the same interfaces.  The Xerox 1186, Xerox 6085 and two Sun 3/60's in my office
and the VMS MicroVax II next door all do both TCP/IP and XNS at the same time.
The Vax also does DECNet/LAT and the two Xerox machine also do PUP.  The Suns
may soon do PUP (somethings just won't die, we still have a working 3 MBit net
connecting working Altos...).

	They exist quite well on a coax that has nearly 1000 devices including limited
DECNet, lots of XNS, lots of PUP and growing amount of TCP/IP with NFS, but no
diskless workstations. 

tom 

tom.henr801c@xerox.com

Disclaimer -
If my opinion was corporate opinion, I wouldn't have time to write electronic
mail.

END OF DOCUMENT