|
|
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 ARPANETIt 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 spec1. 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.25Evidently 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