----MESSAGE-BEGIN---- [880401@kremvax.arpa] <1988040100000100> From: meese@kremvax.arpa Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso Subject: OSI abandoned! Message-ID: <880401@kremvax.arpa> Date: 1 Apr 88 00:00:01 GMT Organization: Soviet Sanctuary for Victims of American Persecution Lines: 32 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804010031.AA07011@Bear-Mountain.nyser.net] <1988040100311700> From: schoff@A.NYSER.NET ("Marty Schoffstall") Newsgroups: comp.protocols.tcp-ip Subject: Re: OSI does not mean X.25 Message-ID: <8804010031.AA07011@Bear-Mountain.nyser.net> Date: 1 Apr 88 00:31:17 GMT References: <76.008873@adam.DG.COM> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1017@thumper.bellcore.com] <1988040100341800> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso Subject: Re: SLIP working group? Message-ID: <1017@thumper.bellcore.com> Date: 1 Apr 88 00:34:18 GMT References: <1966@hou2d.UUCP> <1016@thumper.bellcore.com> <9312@tut.cis.ohio-state.edu> Organization: Bell Communications Research, Inc Lines: 17 Summary: And the user loses... > ... 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804010208.AA03943@uc.msc.umn.edu] <1988040102081200> From: slevy@UC.MSC.UMN.EDU ("Stuart Levy") Newsgroups: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET Message-ID: <8804010208.AA03943@uc.msc.umn.edu> Date: 1 Apr 88 02:08:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 It might not be that bad... the Bell System Tech. J. a few years ago had an article on supplying telephone power directly over the optical fiber, using LEDs and photocells. Efficiency was quite high -- photocells do a good job when they see light of the right wavelength. Stuart Levy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [494@etn-rad.UUCP] <1988040103393000> From: jru@etn-rad.UUCP (John Unekis) Newsgroups: comp.protocols.tcp-ip,comp.sys.ibm.pc Subject: PC to SUN Keywords: PC SUN COMM Message-ID: <494@etn-rad.UUCP> Date: 1 Apr 88 03:39:30 GMT Reply-To: jru@etn-rad.UUCP (John Unekis) Organization: Eaton Inc. IMSD, Westlake Village, CA Lines: 10 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1988.03.31.22.36.16.milazzo.01312@titan.rice.edu] <1988040104361600> From: milazzo@RICE.EDU (Paul Milazzo) Newsgroups: comp.protocols.tcp-ip Subject: The case for SLIP CRCs Message-ID: <1988.03.31.22.36.16.milazzo.01312@titan.rice.edu> Date: 1 Apr 88 04:36:16 GMT References: <8803311518.AA16742@trantor.UMD.EDU> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 42 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 Dept. of Computer Science Rice University, Houston, TX ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8803311603.AA10097@ucbvax.Berkeley.EDU] <1988040104415500> From: droms@BKNLVMS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: NFS across the Internet Message-ID: <8803311603.AA10097@ucbvax.Berkeley.EDU> Date: 1 Apr 88 04:41:55 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 X-Unparsable-Date: Wed, 30 Mar 1988 06:34:23.26 EST 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12386880485.30.LYNCH@A.ISI.EDU] <1988040104464400> From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet ring Message-ID: <12386880485.30.LYNCH@A.ISI.EDU> Date: 1 Apr 88 04:46:44 GMT References: Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8803311607.AA10141@ucbvax.Berkeley.EDU] <1988040105075300> From: droms@BKNLVMS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: Checksums (again) Message-ID: <8803311607.AA10141@ucbvax.Berkeley.EDU> Date: 1 Apr 88 05:07:53 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 X-Unparsable-Date: Wed, 30 Mar 1988 06:44:04.83 EST 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [11942@sri-spam.istc.sri.com] <1988040105175600> From: gds@spam.istc.sri.com (Greg Skinner) Newsgroups: comp.protocols.tcp-ip,comp.mail.misc,comp.bugs.4bsd Subject: sendmail queueing discipline Message-ID: <11942@sri-spam.istc.sri.com> Date: 1 Apr 88 05:17:56 GMT Sender: nobody@sri-spam.istc.sri.com Reply-To: gds@spam.istc.sri.com (Greg Skinner) Organization: SRI International Lines: 19 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [779@kaos.UUCP] <1988040105231600> From: romkey@kaos.UUCP (John Romkey) Newsgroups: comp.protocols.tcp-ip Subject: ignoring UDP checksums Message-ID: <779@kaos.UUCP> Date: 1 Apr 88 05:23:16 GMT References: <8803311257.AA16410@mome.cs.umd.edu> Reply-To: romkey@kaos.UUCP (John Romkey) Organization: Chaos; Somerville, MA Lines: 36 Keywords: UDP NFS 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1018@thumper.bellcore.com] <1988040105260600> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Summary: link vs end-to-end acks Message-ID: <1018@thumper.bellcore.com> Date: 1 Apr 88 05:26:06 GMT References: <8803301117.aa08824@Huey.UDEL.EDU> Organization: Bell Communications Research, Inc Lines: 36 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [351396.880401.JBVB@AI.AI.MIT.EDU] <1988040105265300> From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: draft ulana sw & sec spec Message-ID: <351396.880401.JBVB@AI.AI.MIT.EDU> Date: 1 Apr 88 05:26:53 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 1. Why no mention of RFCs 963 and 964, detailing the ways in which the descriptions of IP and TCP in MIL-STD 1777 and 1778 are wrong? The 1983 dates on the MIL-STDs lead me to believe that they haven't been revised to correct these problems. 2. Why no mention of RFC-950, "Internet Standard Subnetting Procedure"? This brings up another issue that has been on my mind recently: Is anyone working on a "Requirements for Internet Hosts" RFC, in the vein of RFC1009? I have recently encountered a number of very literal readings of the MIL-STDs into government procurement specifications, such that a PC is required to: a. Support 'Page Mode' in its FTP. b. Generate ICMP Time Exceeded messages, even though it has only one interface, and this represents discarding an otherwise perfectly acceptable packet (albeit one which barely got to me). c. Reply to ICMP Information Request messages, which appear to me to be intended for DDN use, and not for a broadcast LAN. I can't guess exactly why they might want this, but BOOTP seems to be much better suited. There is also the issue of whether a workstation should reply to this sort of thing at all (particularly if the request is broadcast). d. Support the IP option "Satnet stream ID", which I am informed is not relevant to any of the standard upper layer protocols (TCP, UDP, etc.). I can ignore it just fine, but I don't know if this is 'support'. I would be interested in working with anyone who is working on a host- oriented equivalent to RFC1009. I might even have time to start one myself. Of course, if I'm entirely wrong in my criticism above, I'm not the right person... James VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU].1-Apr-88.02:22:13.CERF] <1988040107220000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: draft ulana sw & sec spec Message-ID: <[A.ISI.EDU].1-Apr-88.02:22:13.CERF> Date: 1 Apr 88 07:22:00 GMT References: <8803311651.AA12031@mitre-bedford.ARPA> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [780@kaos.UUCP] <1988040107591800> From: romkey@kaos.UUCP (John Romkey) Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso Subject: vendors on committees (was Re: SLIP working group?) Message-ID: <780@kaos.UUCP> Date: 1 Apr 88 07:59:18 GMT References: <1966@hou2d.UUCP> <1016@thumper.bellcore.com> <9312@tut.cis.ohio-state.edu> <1017@thumper.bellcore.com> Reply-To: romkey@kaos.UUCP (John Romkey) Organization: Chaos; Somerville, MA Lines: 47 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [20989@amdcad.AMD.COM] <1988040109050900> From: rpw3@amdcad.AMD.COM (Rob Warnock) Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso Subject: Re: SLIP working group? Message-ID: <20989@amdcad.AMD.COM> Date: 1 Apr 88 09:05:09 GMT References: <1966@hou2d.UUCP> <1016@thumper.bellcore.com> <9312@tut.cis.ohio-state.edu> <1017@thumper.bellcore.com> Reply-To: rpw3@amdcad.UUCP (Rob Warnock) Organization: [Consultant] San Mateo, CA Lines: 52 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040109150000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 1 Apr 88 11:25:52-PST Date: 1 Apr 1988 14:15-EST Sender: CERF@A.ISI.EDU Subject: Re: RFCs by E-Mail From: CERF@A.ISI.EDU To: haverty@CCV.BBN.COM Cc: postel@VENERA.ISI.EDU, tcp-ip@SRI-NIC.ARPA Cc: michel@CCT.BBN.COM Message-ID: <[A.ISI.EDU] 1-Apr-88 14:15:50.CERF> In-Reply-To: The message of Fri, 01 Apr 88 07:34:43 -0500 from haverty@CCV.BBN.COM 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [01.APR.1988.01:19:31.LAWS@RSRE] <1988040109190000> From: LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE) Newsgroups: comp.protocols.tcp-ip Subject: Re: LAN Hardware/Software advice needed Message-ID: <01.APR.1988.01:19:31.LAWS@RSRE> Date: 1 Apr 88 09:19:00 GMT References: <194@mcf.UUCP> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040112200100> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Fri 1 Apr 88 14:22:48-PST Received: from NIHCU.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 1966; Fri, 01 Apr 88 17:19:59 EST To: TCP-IP@SRI-NIC.ARPA From: "Roger Fajman" Date: Fri, 01 Apr 88 17:20:01 EST 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804020256.AA08787@ucbvax.Berkeley.EDU] <1988040112344300> From: haverty@CCV.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: RFCs by E-Mail Message-ID: <8804020256.AA08787@ucbvax.Berkeley.EDU> Date: 1 Apr 88 12:34:43 GMT References: <8803311846.AA02696@bel.isi.edu> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [674@sun.soe.clarkson.edu] <1988040115181000> From: nelson@sun.soe.clarkson.edu (Russ Nelson) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP Fiber Optic Ring Backbone Message-ID: <674@sun.soe.clarkson.edu> Date: 1 Apr 88 15:18:10 GMT References: <8803292224.AA13808@trout.nosc.mil> Reply-To: nelson@sun.soe.clarkson.edu.UUCP (Russ Nelson) Organization: Clarkson University, Potsdam, NY Lines: 25 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8273@sol.ARPA] <1988040115411000> From: bukys@cs.rochester.edu (Liudvikas Bukys) Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso Subject: Re: SLIP working group? Message-ID: <8273@sol.ARPA> Date: 1 Apr 88 15:41:10 GMT References: <1966@hou2d.UUCP> <1016@thumper.bellcore.com> <9312@tut.cis.ohio-state.edu> <1017@thumper.bellcore.com> <20989@amdcad.AMD.COM> Reply-To: bukys@cs.rochester.edu (Liudvikas Bukys) Organization: U of Rochester, CS Dept, Rochester, NY Lines: 7 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! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [675@sun.soe.clarkson.edu] <1988040115433800> From: nelson@sun.soe.clarkson.edu (Russ Nelson) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Message-ID: <675@sun.soe.clarkson.edu> Date: 1 Apr 88 15:43:38 GMT References: <8803302037.AA02493@PHOEBE.CAM.UNISYS.COM> Reply-To: nelson@sun.soe.clarkson.edu.UUCP (Russ Nelson) Organization: Clarkson University, Potsdam, NY Lines: 16 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880401154848.884770@DOCKMASTER.ARPA] <1988040115480000> From: Plummer@DOCKMASTER.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Wang TCP/IP Message-ID: <880401154848.884770@DOCKMASTER.ARPA> Date: 1 Apr 88 15:48:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804010809.1.UUL1.3#948@fernwood.mpk.ca.us] <1988040116091800> From: geoff@fernwood.mpk.ca.us (Geoff Goodfellow) Newsgroups: comp.protocols.tcp-ip Subject: Public RFC retrieval (via Net Mail). Message-ID: <8804010809.1.UUL1.3#948@fernwood.mpk.ca.us> Date: 1 Apr 88 16:09:18 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804011628.AA00382@korppi.tut.fi] <1988040116282700> From: jh@tut.fi (Juha Hein{nen) Newsgroups: comp.protocols.tcp-ip Subject: OSI does not mean X.25 Message-ID: <8804011628.AA00382@korppi.tut.fi> Date: 1 Apr 88 16:28:27 GMT References: <76.008873@adam.DG.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 29 Evidently there are still people who see "OSI" and hear "X.25" and "connections". ** THIS IS NOT A VALID ASSUMPTION! ** You can have OSI with a Transport protocol similar to TCP (ISO 8073) and a connectionless internetwork protocol (ISO 8473) even more similar to IP. You do not have to have X.25. You do not have to have PTTs. You do not have to have network connections. There is NO part of OSI that requires X.25 (although if X.25 is all you have, you can use it to support OSI). OSI loves LANs. The OSI IP likes nothing better than to connect LANs together (or to any other type of subnetwork). ... I fully agree with all you are saying about ISO IP/TP4 supporting LANs. The problem is that according to EC politics, you are NOT allowed to run ISO IP in the European academic OSI network!!!! Instead you have to run CONS and they even force you to run X.25 on your Ethernet. This is THE European OSI. Of course we in Finland and even wider in Scandinavia don't accept this bullshit and are just now in the process to set up an Internet using multiprotocol routers that soon will support ISO IP. Because of this, the leaders of the political OSI migration are saying that we are non European heretics. Hope this clarifies my earlier comment. I have nothing against OSI but European OSI politics. Juha Heinanen ----MESSAGE-END---- ----MESSAGE-BEGIN---- [230@oravax.UUCP] <1988040116401900> From: alex@oravax.UUCP (Alex Feldman) Newsgroups: comp.protocols.tcp-ip Subject: SLIP for beginners (me) Keywords: help Message-ID: <230@oravax.UUCP> Date: 1 Apr 88 16:40:19 GMT Distribution: na Organization: Odyssey Research Ass., Ithaca NY Lines: 12 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804011852.AA07974@uunet.UU.NET] <1988040118250600> From: mo@maximo.UUCP (Mike O'Dell) Newsgroups: comp.protocols.tcp-ip Subject: internet in abstentia Message-ID: <8804011852.AA07974@uunet.UU.NET> Date: 1 Apr 88 18:25:06 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804011908.AA06660@braden.isi.edu] <1988040119082000> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: draft ulana sw & sec spec Message-ID: <8804011908.AA06660@braden.isi.edu> Date: 1 Apr 88 19:08:20 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6200003@hpindda.HP.COM] <1988040119092000> From: dwall@hpindda.HP.COM (Darren Wall) Newsgroups: comp.protocols.tcp-ip Subject: IP/X.25 Call User Data ... Message-ID: <6200003@hpindda.HP.COM> Date: 1 Apr 88 19:09:20 GMT Organization: HP Technical Networks, Cupertino, Calif. Lines: 14 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU].1-Apr-88.14:15:50.CERF] <1988040119150000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: RFCs by E-Mail Message-ID: <[A.ISI.EDU].1-Apr-88.14:15:50.CERF> Date: 1 Apr 88 19:15:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804011925.AA06676@braden.isi.edu] <1988040119253900> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: draft ulana sw & sec spec Message-ID: <8804011925.AA06676@braden.isi.edu> Date: 1 Apr 88 19:25:39 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804011946.AA10697@zaphod.ncsa.uiuc.edu] <1988040119465000> From: timk@NCSA.UIUC.EDU (Tim Krauskopf) Newsgroups: comp.protocols.tcp-ip Subject: Re: LAN Hardware/Software advice & NCSA Telnet Message-ID: <8804011946.AA10697@zaphod.ncsa.uiuc.edu> Date: 1 Apr 88 19:46:50 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 41 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23564@hi.unm.edu] <1988040120290400> From: cyrus@hi.unm.edu (Tait Cyrus) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: computing network loads Keywords: load average Message-ID: <23564@hi.unm.edu> Date: 1 Apr 88 20:29:04 GMT Organization: U. of New Mexico, Albuquerque Lines: 43 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12387062647.46.PERILLO@SRI-NIC.ARPA] <1988040121272200> From: PERILLO@SRI-NIC.ARPA (Francine Perillo) Newsgroups: comp.protocols.tcp-ip Subject: RFCs, IENs and the DDN NIC Message-ID: <12387062647.46.PERILLO@SRI-NIC.ARPA> Date: 1 Apr 88 21:27:22 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804012153.AA04185@uxc.cso.uiuc.edu] <1988040121534400> From: kline@UXC.CSO.UIUC.EDU (Charley Kline) Newsgroups: comp.protocols.tcp-ip Subject: Re: Checksums (again) Message-ID: <8804012153.AA04185@uxc.cso.uiuc.edu> Date: 1 Apr 88 21:53:44 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 61 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." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804020633.AA11433@ucbvax.Berkeley.EDU] <1988040122200100> From: RAF@NIHCU.BITNET ("Roger Fajman") Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP for IBM's MVS Message-ID: <8804020633.AA11433@ucbvax.Berkeley.EDU> Date: 1 Apr 88 22:20:01 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 > 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12387077725.7.MRC@PANDA.PANDA.COM] <1988040122501200> From: Crispin@SUMEX-AIM.STANFORD.EDU (Mark Crispin) Newsgroups: comp.protocols.tcp-ip Subject: Re: RFCs by E-Mail Message-ID: <12387077725.7.MRC@PANDA.PANDA.COM> Date: 1 Apr 88 22:50:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Crispin@SUMEX-AIM.Stanford.EDU Organization: The Internet Lines: 15 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 -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [674@tetra.NOSC.MIL] <1988040123461600> From: budden@tetra.NOSC.MIL (Rex A. Buddenberg) Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso Subject: Re: SLIP working group? Message-ID: <674@tetra.NOSC.MIL> Date: 1 Apr 88 23:46:16 GMT References: <1966@hou2d.UUCP> <1016@thumper.bellcore.com> <9312@tut.cis.ohio-state.edu> Reply-To: budden@tetra.nosc.mil.UUCP (Rex A. Buddenberg) Organization: Naval Ocean Systems Center, San Diego Lines: 10 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804012352.AA06902@braden.isi.edu] <1988040123522900> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP for IBM's MVS Message-ID: <8804012352.AA06902@braden.isi.edu> Date: 1 Apr 88 23:52:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1724@thebes.UUCP] <1988040123541300> From: hirai@swatsun.uucp (Eiji "A.G." Hirai) Newsgroups: comp.protocols.tcp-ip Subject: Stop comp.protocols.tcp-ip.eniac ! Message-ID: <1724@thebes.UUCP> Date: 1 Apr 88 23:54:13 GMT Organization: Sun Lab, Swarthmore College PA Lines: 100 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040200223000> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun 3 Apr 88 09:03:30-PDT Received: by ucbvax.Berkeley.EDU (5.59/1.26) id AA26785; Sat, 2 Apr 88 19:55:51 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Apr 88 00:22:30 GMT From: lupine!klein@uunet.uu.net (Doug Klein) Organization: Network Computing Devices, Palo Alto, CA Subject: Need SLIP information Message-Id: <112@lupine.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1108@infinet.UUCP] <1988040202572100> From: rhorn@infinet.UUCP (Rob Horn) Newsgroups: comp.protocols.tcp-ip Subject: Checksums, CRC's, and NFS Message-ID: <1108@infinet.UUCP> Date: 2 Apr 88 02:57:21 GMT Reply-To: rhorn@infinet.UUCP (Rob Horn) Organization: Infinet, Inc. North Andover, MA Lines: 61 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040206120000> Mail-From: TODD created at 2-Apr-88 17:23:07 Return-Path: Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sat 2 Apr 88 11:13:46-PST Date: 2 Apr 1988 14:12-PST Sender: WREN@A.ISI.EDU Subject: PLEASE POST TO TCP-IP BULLETIN BOARD From: WREN@A.ISI.EDU To: TCP-IP-REQUEST@SRI-NIC.ARPA Cc: WREN@A.ISI.EDU Message-ID: <[A.ISI.EDU] 2-Apr-88 14:12:01.WREN> ReSent-Date: Sat, 2 Apr 88 17:22:20 PST ReSent-From: Todd Koumrian ReSent-To: tcp-ip@SRI-NIC.ARPA ReSent-Message-ID: <12387367565.14.TODD@SRI-NIC.ARPA> 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 --------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804022042.AA27139@vax.ftp.com] <1988040220425200> From: stev@VAX.FTP.COM (Stev Knowles) Newsgroups: comp.protocols.tcp-ip Subject: SLIP Message-ID: <8804022042.AA27139@vax.ftp.com> Date: 2 Apr 88 20:42:52 GMT Sender: uucp@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 29 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU].2-Apr-88.14:12:01.WREN] <1988040222120000> From: WREN@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: PLEASE POST TO TCP-IP BULLETIN BOARD Message-ID: <[A.ISI.EDU].2-Apr-88.14:12:01.WREN> Date: 2 Apr 88 22:12:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 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 --------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804021851.AA03124@wb6rqn.UUCP] <1988040223514900> From: brian@wb6rqn.UUCP (Brian Lloyd) Newsgroups: comp.protocols.tcp-ip Subject: SLIP link error correction Message-ID: <8804021851.AA03124@wb6rqn.UUCP> Date: 2 Apr 88 23:51:49 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 22 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! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040302190000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 3 Apr 88 06:21:47-PDT Date: 3 Apr 1988 09:19-PDT Sender: CERF@A.ISI.EDU Subject: Re: ignoring UDP checksums From: CERF@A.ISI.EDU To: spdcc!kaos!romkey@HUSC6.HARVARD.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 3-Apr-88 09:19:46.CERF> In-Reply-To: <779@kaos.UUCP> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804030943.AA11156@sluggo.sun.com] <1988040309432300> From: melohn@SUN.COM (Bill Melohn) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Message-ID: <8804030943.AA11156@sluggo.sun.com> Date: 3 Apr 88 09:43:23 GMT References: <8803300501.AA14341@beno.CSS.GOV> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: melohn@Sun.COM (Bill Melohn) Organization: Sun Microsystems, Mountain View Lines: 24 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU].3-Apr-88.09:19:46.CERF] <1988040316190000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ignoring UDP checksums Message-ID: <[A.ISI.EDU].3-Apr-88.09:19:46.CERF> Date: 3 Apr 88 16:19:00 GMT References: <779@kaos.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040317270000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Sun 3 Apr 88 20:32:29-PDT Date: 3 Apr 88 22:27:00 EST From: Subject: Is performing the checksum really that bad? To: "melohn" cc: 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804031958.AA05134@Larry.McRCIM.McGill.EDU] <1988040319585900> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) Newsgroups: comp.protocols.tcp-ip Subject: Re: Checksums Message-ID: <8804031958.AA05134@Larry.McRCIM.McGill.EDU> Date: 3 Apr 88 19:58:59 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 [ 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804032049.AA05594@Larry.McRCIM.McGill.EDU] <1988040320495500> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) Newsgroups: comp.protocols.tcp-ip Subject: Re: A network you can trust Message-ID: <8804032049.AA05594@Larry.McRCIM.McGill.EDU> Date: 3 Apr 88 20:49:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [16300002@uxh.cso.uiuc.edu] <1988040403020000> From: german@uxh.cso.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: Wang TCP/IP Message-ID: <16300002@uxh.cso.uiuc.edu> Date: 4 Apr 88 03:02:00 GMT Lines: 10 Nf-ID: #R:<8803290011.AA14344@ACC-SB-UNIX.:-37:uxh.cso.uiuc.edu:16300002:000:537 Nf-From: uxh.cso.uiuc.edu!german Apr 3 21:02:00 1988 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804040418.AA16921@ucbvax.Berkeley.EDU] <1988040403270000> From: enger@BLUTO.SCC.COM Newsgroups: comp.protocols.tcp-ip Subject: Is performing the checksum really that bad? Message-ID: <8804040418.AA16921@ucbvax.Berkeley.EDU> Date: 4 Apr 88 03:27:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040410165200> Received: from po3.ANDREW.CMU.EDU by SRI-NIC.ARPA with TCP; Mon 4 Apr 88 14:01:44-PDT Received: by po3.ANDREW.CMU.EDU (5.54/3.15) id for tcp-ip@sri-nic.arpa; Mon, 4 Apr 88 17:00:28 EDT Received: via switchmail; Mon, 4 Apr 88 17:00:17 -0400 (EDT) Received: from lancaster.andrew.cmu.edu via qmail ID ; Mon, 4 Apr 88 16:57:42 -0400 (EDT) Received: from lancaster.andrew.cmu.edu via qmail ID ; Mon, 4 Apr 88 16:57:20 -0400 (EDT) Received: from Messages.6.09.CUILIB.3.43.SNAP.NOT.LINKED.lancaster.andrew.cmu.edu.rt.r3 via MS.4.6.lancaster.andrew.cmu.edu.rt_r3; Mon, 4 Apr 88 16:56:52 -0400 (EDT) Message-Id: <8WJzWIy00UoJQ1H8o4@andrew.cmu.edu> Date: Mon, 4 Apr 88 16:56:52 -0400 (EDT) From: Drew Daniel Perkins X-Andrew-Message-Size: 356+0 To: Randy Subject: Re: CRC calculation costs (was Re: SLIP working group? ) Cc: tcp-ip@sri-nic.arpa, randy@larry.cs.washington.edu In-Reply-To: <8803302136.AA02360@larry.cs.washington.edu> References: <8803302136.AA02360@larry.cs.washington.edu> > *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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040410325900> Received: from wnyosi4.arpa by SRI-NIC.ARPA with TCP; Mon 4 Apr 88 11:46:15-PDT Date: Mon, 4 Apr 88 14:32:59 EDT From: dvaughan@wnyosi4.arpa To: tcp-ip@sri-nic.arpa Subject: Addition to mailing list Cc: dvaughan 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804041338.AA12433@etn-wlv.EATON.COM] <1988040413382400> From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) Newsgroups: comp.protocols.tcp-ip Subject: Re: Checksums, CRC's, and NFS Message-ID: <8804041338.AA12433@etn-wlv.EATON.COM> Date: 4 Apr 88 13:38:24 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19880404142121.1.HORNIG@WINTER.SCRC.Symbolics.COM] <1988040414210000> From: Hornig@ALDERAAN.SCRC.SYMBOLICS.COM (Charles Hornig) Newsgroups: comp.protocols.tcp-ip Subject: PLEASE POST TO TCP-IP BULLETIN BOARD Message-ID: <19880404142121.1.HORNIG@WINTER.SCRC.Symbolics.COM> Date: 4 Apr 88 14:21:00 GMT References: <[A.ISI.EDU].2-Apr-88.14:12:01.WREN> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 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 --------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [93400001@uiucdcsp] <1988040416550000> From: zweig@uiucdcsp.cs.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: Checksums, CRC's, and NFS Message-ID: <93400001@uiucdcsp> Date: 4 Apr 88 16:55:00 GMT References: <1108@infinet.UUCP> Lines: 19 Nf-ID: #R:infinet.UUCP:1108:uiucdcsp:93400001:000:1072 Nf-From: uiucdcsp.cs.uiuc.edu!zweig Apr 4 10:55:00 1988 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.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2728@cg-atla.UUCP] <1988040417574000> From: bobshaw@cg-atla.UUCP (Steve Robertshaw X5552) Newsgroups: comp.protocols.tcp-ip Subject: Request for TCP/IP source in C. Message-ID: <2728@cg-atla.UUCP> Date: 4 Apr 88 17:57:40 GMT Distribution: comp Organization: Compugraphic Corp., Wilmington, Mass Lines: 20 Keywords: TCP/IP Source 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804050938.AA14404@ucbvax.Berkeley.EDU] <1988040418325900> From: dvaughan@WNYOSI4.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Addition to mailing list Message-ID: <8804050938.AA14404@ucbvax.Berkeley.EDU> Date: 4 Apr 88 18:32:59 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804041958.AA24282@okeeffe.Berkeley.EDU] <1988040419585200> From: karels@OKEEFFE.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: release of updated network sources for 4.3BSD Message-ID: <8804041958.AA24282@okeeffe.Berkeley.EDU> Date: 4 Apr 88 19:58:52 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 117 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [wWJzcjy00UoJ81H9Mb@andrew.cmu.edu] <1988040421034300> From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) Newsgroups: comp.protocols.tcp-ip Subject: Re: link level crap protection Message-ID: Date: 4 Apr 88 21:03:43 GMT References: <8803310739.AA29768@uunet.UU.NET> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 > *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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [IWK0Ity00UoJQ1H9xZ@andrew.cmu.edu] <1988040421504900> From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Message-ID: Date: 4 Apr 88 21:50:49 GMT References: <8803302259.AA28640@beno.CSS.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 39 > *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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [606164879.A0345.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU] <1988040422220700> From: Crispin@SUMEX-AIM.STANFORD.EDU (Mark Crispin) Newsgroups: comp.protocols.tcp-ip Subject: IMAP2 protocol/implementation status Message-ID: <606164879.A0345.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> Date: 4 Apr 88 22:22:07 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 39 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:MAPSER.MAC and SS:IMAPSV.MAC; the other implementations will be offered once policies/procedures/etc are ready. The BNF can be found on PS: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 -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8WK10ty00UoJQ1H-MI@andrew.cmu.edu] <1988040422374500> From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP complexity Message-ID: <8WK10ty00UoJQ1H-MI@andrew.cmu.edu> Date: 4 Apr 88 22:37:45 GMT References: <8803302201.AA00162@wb6rqn.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1306@PT.CS.CMU.EDU] <1988040422572000> From: ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre) Newsgroups: comp.protocols.tcp-ip,news.groups Subject: comp.protocols.tcp-ip.eniac Message-ID: <1306@PT.CS.CMU.EDU> Date: 4 Apr 88 22:57:20 GMT References: <1724@thebes.UUCP> Sender: netnews@PT.CS.CMU.EDU Organization: Carnegie-Mellon University, CS/RI Lines: 36 Summary: NO to comp.protocols.tcp-ip.eniac, go with comp.lang.cobol Keywords:COBOL 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1321@cos.com] <1988040423405000> From: smith@cos.com (Steve Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP Fiber Optic Ring Backbone Message-ID: <1321@cos.com> Date: 4 Apr 88 23:40:50 GMT References: <8803292224.AA13808@trout.nosc.mil> Reply-To: smith@cos.UUCP (Steve Smith) Organization: Corporation for Open Systems, McLean, VA Lines: 40 Summary: Ring? Star? 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." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1307@PT.CS.CMU.EDU] <1988040423431800> From: ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre) Newsgroups: comp.protocols.tcp-ip,comp.protocols.appletalk Subject: Mac TCP/IP (KA9Q vs. NCSA vs. SU-MacIP) Message-ID: <1307@PT.CS.CMU.EDU> Date: 4 Apr 88 23:43:18 GMT References: <8804021615.AA18966@ucbvax.Berkeley.EDU> Sender: netnews@PT.CS.CMU.EDU Organization: Carnegie-Mellon University, CS/RI Lines: 53 Summary: SU-MacIP has nicer interface Followup-to:comp.protocols.appletalk [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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040501130000> Received: from UHRCC2.CRCC.UH.EDU ([129.7.3.3]) by SRI-NIC.ARPA with TCP; Tue 5 Apr 88 07:02:11-PDT Date: Tue, 5 Apr 88 07:13 CST From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA 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 To: 'Howard Jares' X-VMS-To: 'Howard Jares' 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804042119.AA00280@n3dmc.UUCP] <1988040501190400> From: johnl@n3dmc.UUCP (John Limpert) Newsgroups: comp.protocols.tcp-ip Subject: SLIP link error correction Message-ID: <8804042119.AA00280@n3dmc.UUCP> Date: 5 Apr 88 01:19:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 27 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804050208.AA00436@bel.isi.edu] <1988040502082000> From: postel@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: IP/X.25 Call User Data Message-ID: <8804050208.AA00436@bel.isi.edu> Date: 5 Apr 88 02:08:20 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Darren Wall: See RFC-877. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040502380000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 5 Apr 88 03:39:26-PDT Date: 5 Apr 1988 06:38-EDT Sender: CERF@A.ISI.EDU Subject: Re: Checksums From: CERF@A.ISI.EDU To: philipp@LARRY.MCRCIM.MCGILL.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 5-Apr-88 06:38:32.CERF> In-Reply-To: <8804031958.AA05134@Larry.McRCIM.McGill.EDU> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040504040000> Mail-From: STJOHNS created at 5-Apr-88 11:06:09 Date: 5 Apr 1988 11:04-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Net Nums and Gateways From: STJOHNS@SRI-NIC.ARPA To: Link@GUNTER-ADAM.ARPA Cc: tcp-ip@SRI-NIC.ARPA, afddn.beach@GUNTER-ADAM.ARPA Cc: afres.hq-sip@GUNTER-ADAM.ARPA, tmd@MITRE-BEDFORD.ARPA Message-ID: <[SRI-NIC.ARPA]Tue, 5 Apr 88 11:04:23 PDT.STJOHNS> In-Reply-To: The message of 5 Apr 1988 10:16:52 CST from Link@GUNTER-ADAM.ARPA 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040504165200> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Tue 5 Apr 88 08:16:58-PDT Date: 5 Apr 1988 10:16:52 CST Subject: Net Nums and Gateways 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 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 | |====================================================================| ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [792@kaos.UUCP] <1988040507275600> From: romkey@kaos.UUCP (John Romkey) Newsgroups: comp.protocols.tcp-ip,news.groups Subject: INFO-COBOL (was comp.protocols.tcp-ip.eniac) Message-ID: <792@kaos.UUCP> Date: 5 Apr 88 07:27:56 GMT References: <1724@thebes.UUCP> <1306@PT.CS.CMU.EDU> Reply-To: romkey@kaos.UUCP (John Romkey) Organization: Chaos; Somerville, MA Lines: 13 Keywords: COBOL 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804051017.AA14644@devvax.TN.CORNELL.EDU] <1988040510175900> From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Message-ID: <8804051017.AA14644@devvax.TN.CORNELL.EDU> Date: 5 Apr 88 10:17:59 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU].5-Apr-88.06:38:32.CERF] <1988040510380000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Checksums Message-ID: <[A.ISI.EDU].5-Apr-88.06:38:32.CERF> Date: 5 Apr 88 10:38:00 GMT References: <8804031958.AA05134@Larry.McRCIM.McGill.EDU> Sender: uucp@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040512020000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Tue 5 Apr 88 15:08:22-PDT Received: from KSUVM.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 4685; Tue, 05 Apr 88 18:08:05 EDT Received: by KSUVM (Mailer X1.25) id 9400; Tue, 05 Apr 88 17:07:25 CDT Date: Tue, 5 Apr 88 17:02 CDT From: Neil Erdwien Subject: SLIP suggestion To: 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040513083800> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Tue 5 Apr 88 04:56:08-PDT Received: from UKACRL.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 1624; Tue, 05 Apr 88 07:46:54 EDT Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 5611; Tue, 05 Apr 88 12:09:43 BST Via: UK.AC.RL.EARN; Tue, 05 Apr 88 12:09:42 BST Received: Via: UK.AC.UMRCC.CMS; 5 APR 88 12:09:38 BST Message-id: <05 Apr 88 12:08:38 BST ZZAPSJC@UK.AC.UMRCC.CMS> Date: Tue, 05 Apr 88 12:08:38 BST From: "John Heaton (G1YYH@G4BVE) 061-275-6011" To: TCP-IP@SRI-NIC.ARPA Subject: STOP SENDING POSTCARDS PLEASE IGNORE THE MESSAGE REPRODUCED BELOW, THERE HAS BEEN AN APPEAL ON TV IN THE UK FOR THIS TO STOP. THE STORY IS TRUE, BUT DAVID HAS ALREADY ESTABLISHED A WORLD RECORD FOR COLLECTING POSTCARDS, AND AS SCHOOL IS GETTING FED UP WITH THE EXCESSIVE MAIL. > David is a 7 year old boy who is dying from cancer. > Before he does, he has a dream of one day being in the Guiness Book of > Records for the person who has had the most postcards sent to him. > If you would like to help David achieve his dream, all you have to do is send > a postcard to him as soon as possible. > Send to : > David > c/o Miss McWilliams > St. Martin de Porres Infant School > Luton, > Bedfordshire > England **DON'T FORGET TO SIGN YOUR NAME** =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804090520.AA07195@ucbvax.Berkeley.EDU] <1988040516165200> From: Link@GUNTER-ADAM.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Net Nums and Gateways Message-ID: <8804090520.AA07195@ucbvax.Berkeley.EDU> Date: 5 Apr 88 16:16:52 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 47 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 | |====================================================================| ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [93400002@uiucdcsp] <1988040516450000> From: zweig@uiucdcsp.cs.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: Request for TCP/IP source in C. Message-ID: <93400002@uiucdcsp> Date: 5 Apr 88 16:45:00 GMT References: <2728@cg-atla.UUCP> Lines: 16 Nf-ID: #R:cg-atla.UUCP:2728:uiucdcsp:93400002:000:512 Nf-From: uiucdcsp.cs.uiuc.edu!zweig Apr 5 10:45:00 1988 Two nice TCP/IP implementations: KAQ9 NCSA Telnet Both are nice and written in C. I hacked the NCSA code for awhile, trying something rather ickier than just adapting it to a 68020 board. Either should work nicely for your application -- maybe you should grab both. NCSA code is available via anonymous FTP from: ncsa.uiuc.edu. You just cd into the NCSA_Telnet directory and mget what you want. Johnny Zweig Dept. of Computer Science University of Illinois at Urbana-Champaign (standard disclaimer) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804051652.AA01099@braden.isi.edu] <1988040516523100> From: braden@venera.isi.EDU Newsgroups: comp.protocols.tcp-ip Subject: OSI Has Arrived! Message-ID: <8804051652.AA01099@braden.isi.edu> Date: 5 Apr 88 16:52:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 33 There are intermittent bursts of controversy on this list about whether or not the OSI protocols are only paper figments. Attached you will find a piece of hard evidence that some OSI protocols (X.400) are actually alive and functioning. You can tell this are real, not demoware, because it is screwing up! (No, MTA is NOT the Boston subway system). Bob Braden ----- Begin Forwarded Message ----- From @RELAY.CS.NET:mmdf@zix.gmd.dbp.de Mon Apr 4 19:39:05 1988 Date: Mon, 4 Apr 88 19:38:59 PDT Posted-Date: Mon, 4 Apr 88 19:38:59 PDT Received-Date: Mon, 4 Apr 88 19:38:59 PDT Message-Id: <8804050238.AA23604@venera.isi.edu> Received: from RELAY.CS.NET by venera.isi.edu (5.54/5.51) id AA23604; Mon, 4 Apr 88 19:38:59 PDT Received: from relay2.cs.net by RELAY.CS.NET id am10000; 4 Apr 88 22:37 EDT Received: from zix.gmd.dbp.de by RELAY.CS.NET id ce01890; 4 Apr 88 22:25 EDT Received: from zix.gmd.dbp.de by .zix.gmd.dbp.de id a003643; 5 Apr 88 1:10 MET To: braden@VENERA.ISI.EDU From: DFN Gateway Subject: DFN Mail Network -- failed mail Status: R Mail Failure Diagnostics: Rejected-Message-id: <8803301719.AA03945@braden.isi.edu> Message Recipients: nittmann@rusvx1.rus.uni-stuttgart.dbp.de: MTA congestion ----- End Forwarded Message ----- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5204@venera.isi.edu] <1988040517190000> From: cracraft@venera.isi.edu (Stuart Cracraft) Newsgroups: comp.unix.wizards,comp.protocols.tcp-ip Subject: netin: Connection reset by peer Message-ID: <5204@venera.isi.edu> Date: 5 Apr 88 17:19:00 GMT Organization: USC-Information Sciences Institute Lines: 14 The following transaction took place on two subnets (e.g. A.B.C and A.B.C2). I ftp'd from one host to a MicroVax running Ultrix. Then, a 'dir' or 'get' command resulted in: 200 PORT command okay. 150 Opening data connection for /bin/ls (128.149.3.151,1213) (0 bytes). netin: Connection reset by peer 226 Transfer complete. Does anyone know what the mysterious 'netin: Connection reset by peer' is? Stuart ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6200004@hpindda.HP.COM] <1988040517505500> From: dwall@hpindda.HP.COM (Darren Wall) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP/X.25 Call User Data ... Message-ID: <6200004@hpindda.HP.COM> Date: 5 Apr 88 17:50:55 GMT References: <6200003@hpindda.HP.COM> Organization: HP Technical Networks, Cupertino, Calif. Lines: 19 > > Is it an "accepted practice" to use 0xCC in the first byte of > Call User Data in an X.25 CALL REQUEST Packet for routing IP > data over an X.25 Link? I know that for DDN Standard Services > it's required, but I had thought that everyone did it whether > DDN Standard is being requested or not. > Please note the "accepted practice" phrase. The reason I posted the note was to find out if other people knew of implementations that did the same thing. After talking with my Corporate Telecommunications Department, I understand that this is a bug with the particular version of firmware that I had. However, this was the first node of many that I need to set up and I was shocked to find that my assumptions were wrong. The 0xCC flag is important when nodes need simultaneous X.25 and IP access. Darren Wall ----MESSAGE-END---- ----MESSAGE-BEGIN---- [61.009074@adam.DG.COM] <1988040517563800> From: LYMAN_CHAPIN@ICE9.CEO.DG.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: OSI does not mean X.25 Message-ID: <61.009074@adam.DG.COM> Date: 5 Apr 88 17:56:38 GMT Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: Organization: The Internet Lines: 40 >> Not to put too fine a point on it, how many different vendors have >> implementations which are either known to interoperate or have been >> through COS certification? I'm glad to know the specs are finished. >> I will be even more happy to know that there are implementations for >> many operating systems and hardware bases which can work together and >> which you can buy off the shelf. Amen! OSI has a LONG way to go before it even comes close to the level of real-product availability of TCP/IP. It would be very difficult (although not impossible) to go out into the world today & put together a fully OSI network using commercially available hardware & software. And, more to the point, there would be very little reason to go to the trouble of doing so - TCP/IP products are readily available, they do the job, and they are (after years of experience and engineering) both efficient and reliable. I am not suggesting that the moment an OSI product becomes available, it is ipso facto preferable to its TCP/IP counterpart! But sooner or later everyone (well, almost everyone) is going to have to figure out how to make OSI networks work. Unfortunately, while a few people have been working to factor the advantages of TCP/IP internetworking into OSI (via ISO TP/IP) in an effort to make OSI viable (i.e. not just X.25 and PTTs), too many other people have been just bashing it (and OSI, like most network architectures, is highly bashable), on the assumption (presumably) that they would never have to live with it. Which brings us to the current state of affairs: commercial OSI gear is X.25-based (and most of it is in Europe), because the people with a vested interest in TP/IP-based OSI haven't been working on OSI - they've been working on TCP/IP, and taking pot shots at OSI whenever possible. Perhaps OSI will fail worldwide, thereby keeping the world safe for TCP/IP. Or, perhaps OSI (based on X.25) will quickly become the norm in the rest of the world (thanks to various combinations of PTTs), while we play catch-up. I like TCP/IP a whole lot better than X.25-OSI; but I would like an internationally viable TP/IP-OSI even better. ----------------------------------------------------------------------------- Lyman Chapin lyman@ice9.ceo.dg.com Data General Corp. [lyman%ice9.ceo.dg.com@relay.cs.net] (617) 870-6056 ----------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]Tue,.5.Apr.88.11:04:23.PDT.STJOHNS] <1988040518040000> From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: Net Nums and Gateways Message-ID: <[SRI-NIC.ARPA]Tue,.5.Apr.88.11:04:23.PDT.STJOHNS> Date: 5 Apr 88 18:04:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1898@louie.udel.EDU] <1988040518452100> From: rminnich@udel.EDU (Ron Minnich) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Message-ID: <1898@louie.udel.EDU> Date: 5 Apr 88 18:45:21 GMT References: <8803311257.AA16410@mome.cs.umd.edu> Reply-To: rminnich@udel.EDU (Ron Minnich) Organization: University of Delaware Lines: 21 In article <8803311257.AA16410@mome.cs.umd.edu> steve@cs.umd.EDU (Steven D. Miller) writes: >As of the last time I looked (SunOS 3.2), you can't turn UDP checksums on >for NFS packets. A code path that is completely separate from the "normal" >UDP and IP output code paths is being taken. Has this changed since 3.2 >came out? How many NFS licensees are also not using checksums here? I got an interesting perspective on this from Sequent. Udel just got a 10-processor Balance system, with NFS. NFS did not come with it, though, as shipments of NFS had been halted. The reason, according to support people at Sequent, is that undetected errors were making their way through their enet hardware, undetected because checksums were turned off on NFS. The fix was to isolate the patterns and tighten up their enet hardware. The fix was hard because it was something like 10 patterns that occurred VERY infrequently. I am told that NFS is shipping again from Sequent, minus errors. We don't have ours yet, though. Going from Mt. Xinu 4.3 to an Ultrix system we can very easily and very repeatably (100%) get errors just compiling files. We haven't had a chance to track it down, but when we compile one of the X-windows files (a small one) the .o file gets trashed. And yes, no UDP checksums. -- ron (rminnich@udel.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3765@medusa.cs.purdue.edu] <1988040519473900> From: riedl@cs.purdue.EDU (John T Riedl) Newsgroups: comp.protocols.tcp-ip Subject: Re: CRC calculation costs (was Re: SLIP working group? ) Message-ID: <3765@medusa.cs.purdue.edu> Date: 5 Apr 88 19:47:39 GMT Sender: news@cs.purdue.EDU Organization: Department of Computer Science, Purdue University Lines: 26 Tom Mueller and I did some experiments [1] on measuring the costs of various components of UDP on Suns (3/50s), using *very small packets*. We measured UDP round-trips of 7.2ms, with checksuming being 0.12ms of that, and mbuf manipulation about 0.5ms. 1.6ms was spent in the socket layering (just the socket abstraction code), 0.5ms in the context switch on receive, and 0.4ms in copying from kernel to user space. Note that these are the cheap 1s-complement bitsums that have been under discussion recently and that only the headers are being checksumed. Our data compare well with Watson and Mamrak's work on VMS [2]. They report on transmitting 1024 byte packets. The total transmission time (one-way) was 4.2ms, of which 0.5 ms was data checksuming vs. 0.8ms for the context switch and system call overhead. So at least in some environments, checksuming is relatively cheap. [1] Bharat Bhargava, Tom Mueller, and John Riedl, "Experimental Analysis of Layered Ethernet Software". In Proceedings of the ACM-IEEE Computer Society 1987 Fall Joint Computer Conference. [2] Richard Watson and Sandy Mamrak, "Gaining Efficiency in Transport Services by Appropriate Design and Implementation Choices". ACM Transactions on Computer Systems, May 1987. -- John Riedl {ucbvax,decvax,hplabs}!purdue!riedl -or- riedl@mordred.cs.purdue.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804052108.AA11102@beno.CSS.GOV] <1988040521080100> From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: comp.protocols.tcp-ip Subject: Re: Checksums, CRC's, and NFS Message-ID: <8804052108.AA11102@beno.CSS.GOV> Date: 5 Apr 88 21:08:01 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 places (i.e. over noisy asynch lines)?? If important files get bit The point I was trying to make and a lot of people missed is: An async line is not usually noisy. You do not have to automatically put a CRC on it. You probably don't use a CRC between your terminal and the TTY MUX on the host. That's because it's not necessary in 99% of the cases. The same holds true for async lines in general. They don't normally have a noise problem. If you have a serious noise problem, you shouldn't be using a simple async scheme. Buy a paid of decent modems and let them do the work. (E.g. today you can buy a pair of telebit trailblazers for $1345.) If you need a special case for your special environment, fine. However, don't claim that a protocol that doesn't have it is broken. No one seems to feel the need to put a CRC around the TCP/IP packet that is handed to the ethernet. Yet, given a broken ethernet board, you could be just as likely to have a corrupt packet as with SLIP without a CRC --rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804051628.AA01625@wb6rqn.UUCP] <1988040521284100> From: brian@wb6rqn.UUCP (Brian Lloyd) Newsgroups: comp.protocols.tcp-ip Subject: SLIP Message-ID: <8804051628.AA01625@wb6rqn.UUCP> Date: 5 Apr 88 21:28:41 GMT Sender: jkf@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 Drew, Allowing an LLP (SLIP in this case) to "use" information contained in a ULP header violates the concept of layering and it invites disaster should the ULP header change in the future. As the specifier of the LLP you have no control over ULP header content. On the other hand it appears that "new" SLIP will negotiate options. This implies that both ends know how to negotiate. Since there is no way for "old" SLIP to negotiate with "new" SLIP it might be possible to use that information (the lack of negotiation) to flag this as an "old" slip link. When a "new" SLIP driver attempts to elict a response from an "old" SLIP driver, a valid response seems unlikely. A reasonable number of attempts can be made before the "new" SLIP driver decides to speak "old" SLIP. One more thing -- we have been trying to contact you for some time now to no avail. Could you please ACK this messags so that I know that you have received it? Could you also give me another address, i.e. telephone number, where I can reach you? Thanks. Brian Lloyd, President Sirius Systems, Inc. (301) 540-2066 brian@wb6rqn.uucp Share and enjoy! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804051632.AA01636@wb6rqn.UUCP] <1988040521320400> From: brian@wb6rqn.UUCP (Brian Lloyd) Newsgroups: comp.protocols.tcp-ip Subject: Becoming part of the Internet Message-ID: <8804051632.AA01636@wb6rqn.UUCP> Date: 5 Apr 88 21:32:04 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 At Sirius Systems we are actively involved in the development of TCP/IP based products. We would like to become part of the Internet if it is possible. Currently our software supports IEEE 802.3 (not too useful in this case), AX.25 (again not too useful), and SLIP. We plan to have X.25 in place Real Soon Now. We would like to find some way to become a permanent part of the Internet. Any suggestions would be greatly appreciated. Brian Lloyd, President Sirius Systems, Inc. (301) 540-2066 brian@wb6rqn.uucp Share and enjoy! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804072200.AA00203@ucbvax.Berkeley.EDU] <1988040522020000> From: NEIL@KSUVM.BITNET (Neil Erdwien) Newsgroups: comp.protocols.tcp-ip Subject: SLIP suggestion Message-ID: <8804072200.AA00203@ucbvax.Berkeley.EDU> Date: 5 Apr 88 22:02:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [KPETERSEN.12388095326.BABYL@SIMTEL20.ARPA] <1988040600370000> From: YMUM86@PRIME-A.CENTRAL-SERVICES.UMIST.AC.UK (John Heaton) Newsgroups: comp.protocols.tcp-ip Subject: POSTCARDS to DAVID Message-ID: Date: 6 Apr 88 00:37:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 Keith In Info-Hams digest 131 there was a mail message about a boy called David living in Wales who is dying from cancer, the message was repeated from sri-nic.arpa, and was asking people to send David a postcard c/o a Miss MacWilliams at his school. About a month ago there was a report on the BBC TV program 'Thats Life' which said the school had been flooded with postcards from around the world. David has achieved his record attempt, but the postcards keep on flowing in. The school/parents have requested that no more postcards be sent. Could you please recirculate this request around any similar networks /mailing lists etc., John Heaton, UMRCC Network Unit (Room G45) Manchester University Telephone : +44 61 275 6011 Janet : J.Heaton @ UMIST.CN.PA BitNET/Earn : J.Heaton % PA.CN.UMIST.AC.UK @ UKACRL Packet Radio : G1YYH @ G4BVE Tue, 05 Apr 88 13:37:52 BST ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040601570000> Received: from OAC.UCLA.EDU by SRI-NIC.ARPA with TCP; Wed 6 Apr 88 08:57:06-PDT Date: Wed, 06 Apr 88 08:57 PDT To: tcp-ip@SRI-NIC.ARPA From: Michael Stein Subject: Re: SLIP suggestion > >Has anyone considered making SLIP work on an IBM system? In particular, > >most IBM systems will only handle 7-bit ASCII. When I last looked at > >SLIP it assumed an 8-bit channel. IBM reads must be terminated by a > >carriage return also. There might also be full/half duplex > >compatibility problems. Likely the "near future" best way to do this is to run SLIP to a PC which sits on a local LAN. (Who's using your PC when your not there?) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040602011400> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Wed 6 Apr 88 05:41:26-PDT To: Link@GUNTER-ADAM.ARPA cc: tcp-ip@SRI-NIC.ARPA, afddn.beach@GUNTER-ADAM.ARPA, afres.hq-sip@GUNTER-ADAM.ARPA, tmd@MITRE-BEDFORD.ARPA, brescia@PARK-STREET.BBN.COM Subject: Re: Net Nums and Gateways Date: Wed, 06 Apr 88 08:41:14 -0400 From: Mike Brescia You are doing exactly the right thing... 42 class B addresses. Since the idea of subnetting is to hide the distinction among the subnets from the rest of the routers, you can use a single net which you subnet. The penalty you pay is to have the other routers send to an arbitrary one of your 42 gateways in order to reach a particular subnet. This means you must be prepared to take a packet addressed to subnet #27 in on the gateway for subnet #33 and forward it to the proper your other gateway for subnet #33. You may have better (faster) connections inside your domain than on the DDN, so it may not be too painful in user delay or DDN overload. If the source of the packet is a host on the DDN, rather than a gateway, then your gateway can send an ICMP redirect-host to get further packets to the proper gateway [flames about hosts which do not listen to redirect-host go to those hosts]. This example has come up often in the past, but usually the number of sites has been around 2 rather than 42. For the cases where the sites have no separate connection, they used separate nets. For the cases where the sites had backdoor trunks, or a bridged ethernet, they used a single net, and paid the extra penalty of sending traffic over their internal trunk that came in on the 'wrong' gateway. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2@stanton.TCC.COM] <1988040602421300> From: donegan@stanton.TCC.COM (Steven P. Donegan) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: computing network loads Message-ID: <2@stanton.TCC.COM> Date: 6 Apr 88 02:42:13 GMT References: <23564@hi.unm.edu> Organization: Stanton Public Domain Systems, Stanton, Ca. Lines: 26 Keywords: load average Summary: Determinate vs Non-Determinate LANS In article <23564@hi.unm.edu>, cyrus@hi.unm.edu (Tait Cyrus) writes: > > I am looking for an equation that roughly computes the theoretical > load on a network given only the following information: > 1) time over which the load is to be computed, > 2) the number of packets seen in that time, > 3) the number of bytes seen in that time. > > Currently I am using something like: > num_bytes / (MBYTES_PER_SEC * time) There is a fundamental question which must be asked before any answer to this question can be considered - what type of LAN are you trying to get bandwidth utilization numbers for? An Ethernet type LAN is extremely variable based on the number of 'stations' or 'nodes', differences in nodal load and collision detection timing, traffic rate per node etc. A token ring on the other hand can be very predictable in it's performance. Steve Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3736@dasys1.UUCP] <1988040603174300> From: jeffreyb@dasys1.UUCP (Jeffrey L Bromberger) Newsgroups: comp.protocols.tcp-ip Subject: Ethernet Overload Problem Message-ID: <3736@dasys1.UUCP> Date: 6 Apr 88 03:17:43 GMT Reply-To: jeffreyb@dasys1.UUCP (Jeffrey L Bromberger) Organization: City College/Big Electric Cat Public Access Unix Lines: 66 Keywords: Ethernet, packet overload, Unix Summary: Why does our Ethernet bog down??? This posting is for a friend on a machine with no outgoing newsfeed. He/I/we have no idea why this happens (no outgoing, yet incoming news), but that goes in a different group :-) Here is his article =========== cut here ============== I am new to the problems of TCP/IP on an ethernet and am slowly learning my way around. We have a problem which I can "fix" but which I don't understand. The observable problem is that the ethernet becomes so filled with packets that none of the computers connected to it can get any work done because they are busy servicing interrupts. Since I don't know what the packets contain, I hesitate to label it a broadcast storm. Let me describe our setup more completely. We have a Vax/780, a Vax/750, a Celerity 1260, and a Bridge Communications CS/100 connected together by a DELNI. We run 4.3BSD Unix on the 3 computers and use TCP/IP. The problem first occured when we connected an Evans&Sutherland PS350 to the DELNI. Booting up the PS350 would send the interrupt rate on the 780 to a level where it wasn't even an adequate single user machine. I eventually persuaded myself that it was related to trailers and the way to get rid of the problem was to use arp -s to define the name and ethernet address for the PS350 (leaving off the trailer attribute). None of the other hosts on the "ethernet" had arp entries in the boot startup file (/etc/rc.local). I did not add them. I think now that the above analysis of the problem was incorrect. The reason that I changed my mind is that the problem came back after being gone for about 9 months. The occasion of the reappearance was a rebuilding of the system disk for the CS/100. The CS/100 had been a bit flakey recently and so it seemed like a good idea to start with a fresh system diskette. It was rebuilt with all the same parameters as the original. Booting up the CS/100 caused the problem. Rebooting seems to have eliminated the problem for the time being. Both the Vaxen have been down since the change and the problem has not come back. (It has been 2 weeks now.) Now, the questions. What tools do I have in BSD Unix to diagnose this problem? Should I use arp -s to define all of the hosts on the ethernet? Why? Any ideas what is causing the problem? I would like to have a better understanding of what is giong on here because in a short while we will be running a real ethernet with at least another Bridge hung off it. Thanks for your help. If these questions are too elementary to have answers of general interest then mail to me instead of posting. Dan Schlitt UUCP: backbone!cmcl2!{phri,cucard}!ccnysci!dan BITNET: dan@ccnysci.BITNET ========= cut here ================ There it is. Can you help us please, as this bogging down of the ethernet is making life/work here abominable. Thanks in advance!! -- *---Jeffrey Bromberger -- 2847 West 22nd Street Brooklyn, NY 11224---* | Compu$erve: 71171,730 /dasys1!jeffreyb | | UUCP: cmcl2!{cucard,phri}!ccnysci!jeffrey | *---Disclaimer: "My school disavows any knowledge of my actions!" ---* ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804052345.aa13062@Huey.UDEL.EDU] <1988040603451000> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP suggestion Message-ID: <8804052345.aa13062@Huey.UDEL.EDU> Date: 6 Apr 88 03:45:10 GMT Sender: uucp@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Neil, Ouch. I can't believe "most" IBM systems are that bad. Twenty years ago (really) I designed this fool thing called the Data Concentrator, which used a PDP8 (!) and interfaced directly to a System/360-67 Multiplexor Channel. We had a lot of fun at U Michigan hooking the thing up to a wonderful brew of hokey terminals, which were the smallest thing just larger than a Turing Machine that was potentially useful. While the PDP8 system was retired only a few years ago, its successors are yet clanking away at Michigan, where that crew has gotten rather good at making the things. My point is that maybe you should be looking beyond IBM and, furthermore, lots of other good souls have beaten the dumb-ASCII curse with that approach. It was once worse. You had to end the line with . Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804060436.AA12483@trwrb] <1988040604361900> From: mdm@TRWRB.DSD.TRW.COM (Michael D. Marcinkevicz) Newsgroups: comp.protocols.tcp-ip Subject: Ethernet Consulting help Message-ID: <8804060436.AA12483@trwrb> Date: 6 Apr 88 04:36:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Folks: We've a wide-area network here at TRW that could really use some consulting for DECnet and TCP/IP Ethernet. Does anyone know of L.A. area consulting services available? Some vendors are quite expensive. What price ranges you've seen? Please mail directly to mdm@trwrb.dsd.trw.com. I'll post responses to the net. Thanks, --Mike Michael Marcinkevicz (213) 812-2154 TRW Space and Defense Sector, Communications services trwrb!mdm@trwind.TRW.COM (ARPA) ...{decvax,ihnp4,ucbvax}!trwrb!mdm (UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040607480000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed 6 Apr 88 09:01:16-PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 8346; Wed, 06 Apr 88 12:00:39 EDT Date: Wed, 6 Apr 1988 11:48:00.68 EDT From: Subject: NFS across the Internet To: Thanks to all who responded to my recent request for references to experiences with NFS across the Internet. I received about 5 replies, all of which confirm Barry Shein's observation that "the concept is not nearly so wild as [has been suggested]". A summary of the replies is available on request. - Ralph Droms Computer Science Department Bucknell University droms@bknlvms.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804061326.AA07773@ucbvax.Berkeley.EDU] <1988040612411400> From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: Net Nums and Gateways Message-ID: <8804061326.AA07773@ucbvax.Berkeley.EDU> Date: 6 Apr 88 12:41:14 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 You are doing exactly the right thing... 42 class B addresses. Since the idea of subnetting is to hide the distinction among the subnets from the rest of the routers, you can use a single net which you subnet. The penalty you pay is to have the other routers send to an arbitrary one of your 42 gateways in order to reach a particular subnet. This means you must be prepared to take a packet addressed to subnet #27 in on the gateway for subnet #33 and forward it to the proper your other gateway for subnet #33. You may have better (faster) connections inside your domain than on the DDN, so it may not be too painful in user delay or DDN overload. If the source of the packet is a host on the DDN, rather than a gateway, then your gateway can send an ICMP redirect-host to get further packets to the proper gateway [flames about hosts which do not listen to redirect-host go to those hosts]. This example has come up often in the past, but usually the number of sites has been around 2 rather than 42. For the cases where the sites have no separate connection, they used separate nets. For the cases where the sites had backdoor trunks, or a bridged ethernet, they used a single net, and paid the extra penalty of sending traffic over their internal trunk that came in on the 'wrong' gateway. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040612535300> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed 6 Apr 88 14:09:18-PDT Received: from NIHCU.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 0488; Wed, 06 Apr 88 16:58:19 EDT To: TCP-IP@SRI-NIC.ARPA From: "Roger Fajman" Date: Wed, 06 Apr 88 16:53:53 EDT Subject: Re: SLIP suggestion > > >Has anyone considered making SLIP work on an IBM system? In particular, > > >most IBM systems will only handle 7-bit ASCII. When I last looked at > > >SLIP it assumed an 8-bit channel. IBM reads must be terminated by a > > >carriage return also. There might also be full/half duplex > > >compatibility problems. > > Likely the "near future" best way to do this is to run SLIP to a > PC which sits on a local LAN. (Who's using your PC when your not > there?) > I have an IBM mainframe. If I were going to provide SLIP access to it, I think I would get something like the Cisco communications server that supports SLIP and put it on the same Ethernet as the mainframe. I haven't actually done this, however. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804061437.AA14141@bu-cs.bu.edu] <1988040614375100> From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: SLIP suggestion Message-ID: <8804061437.AA14141@bu-cs.bu.edu> Date: 6 Apr 88 14:37:51 GMT References: <8804060515.AA14072@bu-cs.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 44 >Has anyone considered making SLIP work on an IBM system? In particular, >most IBM systems will only handle 7-bit ASCII. When I last looked at >SLIP it assumed an 8-bit channel. IBM reads must be terminated by a >carriage return also. There might also be full/half duplex >compatibility problems. > >Neil Erdwien >Kansas State University Gee, took a minute to figure out if this was referring to a PC or what. My guess is you're referring to a 370 architecture mainframe running a line to a 3705 or equivalent. I've never done SLIP but I did write a serial link of my own design once a few years ago between a 4.2 Unix (probably 4.1 back then) system here and a 3705 which transferred jobs for printing or batch execution. Basically I found the only way to deal with the 3705 was to write a layer which passed the packets as discrete ascii lines of text (I just translated to hex ascii, prepending each line with a checksum and byte count) and lock-stepped out the packets (send/ack/send/ack etc., just like a card reader.) The half-duplex nature of the interface presents some interesting problems. Actually, it's more like quarter-duplex, it won't even listen unless it wants to (you have to lock-step on a prompt from it, usually a dot in column one.) If you talk before it's expecting you to it throws away the characters and then demands a carraige return to assure it you won't do that again (at which point you are free to start the error cycle all over again.) It's not ideal (hah!) but it can be done, once I got it working it worked pretty much unnoticed, but there were a lot of heuristics in there (did we just get a "!:" oops, it's angry! send a and back off for a bit waiting for a "."). You also might want to see if there's a mode buried in there that was used for downloading from a KSR33 paper tape which did flow control (used ^S/^Q to express it's distaste for your data.) Or get a network interface... -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804061505.AA18177@windsor.cray.com] <1988040615052800> From: hrp@windsor.CRAY.COM (Hal Peterson) Newsgroups: comp.protocols.tcp-ip Subject: SLIP link error correction Message-ID: <8804061505.AA18177@windsor.cray.com> Date: 6 Apr 88 15:05:28 GMT References: <8804042119.AA00280@n3dmc.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 There was a paper in IEEE Transactions on Communications some time in 1980 (plus or minus a year) about an error detection scheme that was almost as easy to calculate as a checksum, but at the same time was almost as effective as CRC-16 at detecting link errors. Sorry about the vague citation, but the Cray library wasn't subscribing to ToC back then, so I can't look it up. -- Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-3145 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804071726.AA03814@ucbvax.Berkeley.EDU] <1988040615570000> From: CSYSMAS@OAC.UCLA.EDU (Michael Stein) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP suggestion Message-ID: <8804071726.AA03814@ucbvax.Berkeley.EDU> Date: 6 Apr 88 15:57:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 > >Has anyone considered making SLIP work on an IBM system? In particular, > >most IBM systems will only handle 7-bit ASCII. When I last looked at > >SLIP it assumed an 8-bit channel. IBM reads must be terminated by a > >carriage return also. There might also be full/half duplex > >compatibility problems. Likely the "near future" best way to do this is to run SLIP to a PC which sits on a local LAN. (Who's using your PC when your not there?) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2690@saturn.ucsc.edu] <1988040616463200> From: eshop@saturn.ucsc.edu (Jim Warner) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Overload Problem Message-ID: <2690@saturn.ucsc.edu> Date: 6 Apr 88 16:46:32 GMT References: <3736@dasys1.UUCP> Reply-To: eshop@saturn.ucsc.edu (Jim Warner) Organization: University of California, Santa Cruz Lines: 23 Keywords: Ethernet, packet overload, Unix You problem was described in a message from Tom Ferrin at UCSF: +The ARP code for negotiating the use of trailers with another host +is broken. If the remote host cannot understand trailers, the +algorithm can get stuck in a loop continually exchanging ARP_REPLY +packets with the remote host. This floods the ethernet with LOTS +of packets for several minutes until the algorithm gives up trying. +The scenario is as follows: 1) the local host tries to resolve a +ethernet address that is not in it's arp table by sending out a +ARPOP_REQUEST packet; 2) the remote host sends a ARPOP_REPLY with +the ETHERTYPE_IP protocol field set indicating that it does +not wish to receive trailers; 3) local host sends a ARPOP_REPLY +announcing that it does wish to receive trailers; 4) remote host +sends another ETHERTYPE_IP reply indicating it does not wish to +send trailers either. This reply is indistinguishable from #2 +above and the whole cycle repeats. Tom goes on to describe mods to VAX unix to break the cycle. Revised code is now available, however, from E&S that fixes the problem on the PS3xx end. That is probably the preferable solution. Contact E&S for an upgrade. jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2735@pdn.UUCP] <1988040620171300> From: larry@pdn.UUCP (Larry Swift) Newsgroups: comp.protocols.tcp-ip Subject: Re: The case for SLIP CRCs Message-ID: <2735@pdn.UUCP> Date: 6 Apr 88 20:17:13 GMT References: <8803311518.AA16742@trantor.UMD.EDU> <1988.03.31.22.36.16.milazzo.01312@titan.rice.edu> Reply-To: larry@pdn.UUCP (0000-Larry Swift) Organization: Paradyne Corporation, Largo, Florida Lines: 7 Are you talking about checksums or CRC's (cyclic redundancy checks)? They're not the same. Larry Swift UUCP: {codas,usfvax2}!pdn!larry Paradyne Corp., LF-207 Phone: (813) 530-8605 P. O. Box 2826 Largo, FL, 34649-9981 She's old and she's creaky, but she holds! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804062110.AA03916@milk10] <1988040621100700> From: robert@SPAM.ISTC.SRI.COM (Robert Allen) Newsgroups: comp.protocols.tcp-ip Subject: TCP socket question under SunOS 3.4. Message-ID: <8804062110.AA03916@milk10> Date: 6 Apr 88 21:10:07 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 208 Recently I was experimenting with client and server processes under SunOS 3.4, using the 4.2 BSD networking kernel, which used TCP sockets to carry out Inter Process Communication (IPC). I dis- covered several points which I think have some relevance to this list so I thought I'd mention them and open the topic for discussion. Note: I discuss the issues below. I've included dumps from netstat below the discussion to show exactly what I saw; they are labled appropriately. Background ---------- - 1 Server process listening at a port number for connections from processes attemping connections at that port. The backlog to the UNIX listen() call is 5. - 30 client processes attempting, somewhat sequentially, to connect to the server at the agreed upon port number. Issues ------ - Due to UNIX implementation issues, the Server can accept upto 26 client connections. After that point the limit on the max. number of open file descriptors per-process will be exceeded. - If the Server attempts to support a 27th client connection then two things happen simultaneously: 1. The Server hears the connection request, and attempts an accept(). The accept() fails due to the UNIX restriction on the max. number of open file descriptors per process. Thus, the Server cannot accept the 27th connection. 2. The Client makes a connect() call, and the call succeeds! A netstat -a shows the TCP connection for that socket as being "ESTABLISHED". The connections in the listen() backlog are all ESTABLISHED as well. These connections can be picked up by the Server routine if the Server closes some of its' open file descriptors (previously accepted connections) and does some more accept()s. - The 'netstat -a' shows that the "Recv-Q" is getting filled, but since the Server process cannot accept the socket/connection, it cannot read from it, and hence the system cannot free the data buffered up. Questions --------- Some people will probably point out that what I've discovered is an excellent reason to implement a session-layer protocol on top of the sockets between the Client and Server here. This is the same conclusion I've arrived at. However, up until now I supposed that the UNIX socket implementation *provided* a session layer protocol. While I was obviously wrong in this instance, I'm curious to know whether I was assigning the socket interface more significance than it merited (ie. it *isn't* a session layer protocol), or if this is a (pardon the word) 'bug' of the implementation. I'm not trying to cast aspersions regarding implementation with this question! Although this test was done on a Sun 3, I will soon be doing this test on a Hewlett-Packard 9000 series computer, and I don't know what results I'll get there. If this is a bug, is it a 4.2 bug? A 4.3 bug? A Sun bug? On a more direct note, what do the entries mean in the "Recv-Q"? Does each element therein correspond to a TCP message, or an mbuf, or what? How high can the Q go (To the TCP high-water mark?)? What happens when it reaches that point (does the system crash, or do the Clients' write() calls block?)? Comments/Explanations will be much appreciated, Robert Allen, robert@spam.istc.sri.com 415-859-2143 (work phone, days) /****************************************************************************/ /* In all the output below only sockets used for the Client or Server are */ /* listed. The listen socket at port 3030 is the Server listen socket. */ /* The command used in all cases is "netstat -a" */ /****************************************************************************/ /* The following netstat was taken as the 30 Client processes were * attempting to connect to the server process. Some are established * and some are still getting established. */ Active connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 milk10.3030 milk10.1643 ESTABLISHED tcp 0 0 milk10.1643 milk10.3030 ESTABLISHED tcp 0 0 localhost.1642 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1641 ESTABLISHED tcp 0 0 milk10.1641 milk10.3030 ESTABLISHED tcp 0 0 localhost.1640 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1639 ESTABLISHED tcp 0 0 milk10.1639 milk10.3030 ESTABLISHED tcp 0 0 localhost.1638 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1637 ESTABLISHED tcp 0 0 milk10.1637 milk10.3030 ESTABLISHED tcp 0 0 localhost.1636 localhost.sunrpc TIME_WAIT tcp 0 0 localhost.1635 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1634 ESTABLISHED tcp 0 0 milk10.1634 milk10.3030 ESTABLISHED tcp 0 0 localhost.1633 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1632 ESTABLISHED tcp 0 0 milk10.1632 milk10.3030 ESTABLISHED tcp 0 0 localhost.1631 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1630 ESTABLISHED tcp 0 0 milk10.1630 milk10.3030 ESTABLISHED tcp 0 0 localhost.1629 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1628 ESTABLISHED tcp 0 0 milk10.1628 milk10.3030 ESTABLISHED tcp 0 0 localhost.1627 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1626 ESTABLISHED tcp 0 0 milk10.1626 milk10.3030 ESTABLISHED tcp 0 0 localhost.1625 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1624 ESTABLISHED tcp 0 0 milk10.1624 milk10.3030 ESTABLISHED tcp 0 0 localhost.1623 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1622 ESTABLISHED tcp 0 0 milk10.1622 milk10.3030 ESTABLISHED tcp 0 0 localhost.1621 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1620 ESTABLISHED tcp 0 0 milk10.1620 milk10.3030 ESTABLISHED tcp 0 0 localhost.1619 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1618 ESTABLISHED tcp 0 0 milk10.1618 milk10.3030 ESTABLISHED tcp 0 0 localhost.1617 localhost.sunrpc TIME_WAIT tcp 0 0 milk10.3030 milk10.1616 ESTABLISHED tcp 0 0 milk10.1616 milk10.3030 ESTABLISHED tcp 0 0 localhost.1615 localhost.sunrpc TIME_WAIT tcp 0 0 localhost.1614 localhost.sunrpc TIME_WAIT tcp 0 0 *.3030 *.* LISTEN /* A few seconds later. All sockets which the Server can accept on are * full. All clients' connect() calls have returned 0, which indicates * that they have connected. Note that 4 connections which show "ESTABLISHED" * have "Recv-Q"'s of 11. These are the Clients which think they are * connected to the Server based on the connect() call return of 0, but * which in actuality are still in the listen backlog of the Server. Left * alone, the Clients will be able to send data through the socket, and will * get no UNIX error indications, because they are connected to the peer TCP * entity. */ Active connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 localhost.1677 localhost.sunrpc TIME_WAIT tcp 11 0 milk10.3030 milk10.1675 ESTABLISHED tcp 0 0 milk10.1675 milk10.3030 ESTABLISHED tcp 11 0 milk10.3030 milk10.1673 ESTABLISHED tcp 0 0 milk10.1673 milk10.3030 ESTABLISHED tcp 11 0 milk10.3030 milk10.1671 ESTABLISHED tcp 0 0 milk10.1671 milk10.3030 ESTABLISHED tcp 11 0 milk10.3030 milk10.1669 ESTABLISHED tcp 0 0 milk10.1669 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1667 ESTABLISHED tcp 0 0 milk10.1667 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1665 ESTABLISHED tcp 0 0 milk10.1665 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1663 ESTABLISHED tcp 0 0 milk10.1663 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1661 ESTABLISHED tcp 0 0 milk10.1661 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1659 ESTABLISHED tcp 0 0 milk10.1659 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1657 ESTABLISHED tcp 0 0 milk10.1657 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1655 ESTABLISHED tcp 0 0 milk10.1655 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1653 ESTABLISHED tcp 0 0 milk10.1653 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1651 ESTABLISHED tcp 0 0 milk10.1651 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1649 ESTABLISHED tcp 0 0 milk10.1649 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1647 ESTABLISHED tcp 0 0 milk10.1647 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1645 ESTABLISHED tcp 0 0 milk10.1645 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1643 ESTABLISHED tcp 0 0 milk10.1643 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1641 ESTABLISHED tcp 0 0 milk10.1641 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1639 ESTABLISHED tcp 0 0 milk10.1639 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1637 ESTABLISHED tcp 0 0 milk10.1637 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1634 ESTABLISHED tcp 0 0 milk10.1634 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1632 ESTABLISHED tcp 0 0 milk10.1632 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1630 ESTABLISHED tcp 0 0 milk10.1630 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1628 ESTABLISHED tcp 0 0 milk10.1628 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1626 ESTABLISHED tcp 0 0 milk10.1626 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1624 ESTABLISHED tcp 0 0 milk10.1624 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1622 ESTABLISHED tcp 0 0 milk10.1622 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1620 ESTABLISHED tcp 0 0 milk10.1620 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1618 ESTABLISHED tcp 0 0 milk10.1618 milk10.3030 ESTABLISHED tcp 0 0 milk10.3030 milk10.1616 ESTABLISHED tcp 0 0 milk10.1616 milk10.3030 ESTABLISHED tcp 0 0 *.3030 *.* LISTEN ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804062316.AA11364@ACC-SB-UNIX.ARPA] <1988040623164400> From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) Newsgroups: comp.protocols.tcp-ip Subject: TCP-IP GATEWAY for DECNET Message-ID: <8804062316.AA11364@ACC-SB-UNIX.ARPA> Date: 6 Apr 88 23:16:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Evening all... About a week ago someone sent an extensive description of somethings they had seen relating to the DECNET - TCP/IP gateway. I don't remember the facts but now find myself in need of this info. AS usual, this was one of those "scan and delete" sessions that we all go through after leaving the mailbox unchecked for 2 or 3 days. Can anyone help me overcome my lack of foresight and send me any info you may have on this product. I do remember something something about a module called PORTAL. Ring any bells??? Many thanks in advance, Chris VandenBerg ACC chris@acc-sb-unix.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [204@csvaxa.UUCP] <1988040623584100> From: edward@csvaxa.UUCP (Edward Wilkinson) Newsgroups: comp.protocols.tcp-ip Subject: a few questions about a NFS based network over ethernet Message-ID: <204@csvaxa.UUCP> Date: 6 Apr 88 23:58:41 GMT Reply-To: G.Eustace@massey.ac.nz Organization: Computer Centre, Massey University, Palmerston North, New Zealand Lines: 30 Keywords: NFS, ethernet, 802.3 The following article is being posted for our Software Manager. Sorry about repeating this article - last time it went to comp.dcom.lans but *nobody* replied :-( We're about to make a sizeable decision about our LAN & we'd like to hear from people who have made similar decisions in the past so that we can avoid any obvious problems. A t D h V a A n N k C s E ----------cut-here-------------cut-here-------------cut-here---------- What is an acceptable load on an 802.3 network? We are intending putting approx. 300 PCs running Sun's PC-NFS on a single net, with the intention of expanding to 1200 within 5 years. Will a single trunk be capable of supporting that number of work stations or should we be looking at putting in several parallel cables? If so how many? How much horse power would be reasonable to support the number of PCs being proposed? i.e. what size machine should we have for a NFS server? ----------cut-here-------------cut-here-------------cut-here---------- All replies to him please, or to this newsgroup if the info is generally useful. -- Ed Wilkinson @ Computer Centre, Massey University, Palmerston North, NZ uucp: {uunet,watmath!cantuar}!vuwcomp!csvaxa!edward DTE: 530163000005 Janet/Greybook: E.Wilkinson@nz.ac.massey Phone: +64 63 69099 x8587 CSnet/ACSnet/Internet: E.Wilkinson@massey.ac.nz New Zealand = GMT+12 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040703050000> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Thu 7 Apr 88 15:10:02-PDT Received: from relay2.cs.net by RELAY.CS.NET id ak01217; 7 Apr 88 17:41 EDT Received: from northeastern.edu by RELAY.CS.NET id em24299; 7 Apr 88 17:02 EDT Date: Thu, 7 Apr 88 08:05 5 From: "I am only and egg." Subject: subnet probems fixed To: tcp-ip@SRI-NIC.ARPA X-VMS-To: TCP-IP Hello. Back in late December and early January I asked for help with our network at Northeastern University. Many replies were received all of which helped. Thank you all. I'm sorry it took so long to get back to say that. The help was much appreciated. A good deal of our problem seems to have been Sun OS 3.4. The 3.5 release works a LOT better with subnets than 3.4 did. I only recently discovered that there were a number a patches for 3.4 dealing with subnets. The most successful of these were put into 3.5 as I understand it. When we finally received 3.5 and went to it, things started working much better. It was mostly a less than ideal TCP/IP implementation that seems to have done us in. Again, thank you all. Chris Johnson Northeastern University. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804070313.AA18321@gyre.umd.edu] <1988040703134500> From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP socket question under SunOS 3.4. Message-ID: <8804070313.AA18321@gyre.umd.edu> Date: 7 Apr 88 03:13:45 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 If the server attempts an accept() call which returns with an EMFILE (`too many open files') error, the pending connection should NOT be established. I.e., that it is is a bug. 4.3BSD does not have this bug (see /sys/sys/uipc_syscalls.c$accept(), around line 137). Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1115@maccs.UUCP] <1988040704365500> From: Ariel@en-c06.Prime.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Checksums (was Re: Ping, checksum algorithm?) Summary: more C code for doing TCP/IP checksums Keywords: checksums Message-ID: <1115@maccs.UUCP> Date: 7 Apr 88 04:36:55 GMT Article-I.D.: maccs.1115 Posted: Thu Apr 7 00:36:55 1988 References: <8803301719.AA03945@braden.isi.edu> Sender: gordan@maccs.UUCP Reply-To: Ariel@en-c06.Prime.COM Lines: 51 Forwarded article follows: ---------------------------------------------------------------- Hi, I noted your article about the TCP and IP checksum algorithm on Usenet. Feel free to post this if you feel it is of interest; I only have CSnet/ARPAnet access. The algorithm used by Prime's TCP/IP/X.25 software is very similar to your "psuedo-code". Note that it is not necessary to add the carries back in until the end. (Prime 50-series machines have network byte order) ---------------------------------------------------------------- int checksumIP(ip) IP_header *ip; { uns16 *word; uns32 sum; int count; ip->IP_checksum = 0; count = ip->IP_IHL * 2; sum = 0; word = (uns16 *)ip; /* magic occurs ... */ while (count--) sum += *word++; while (sum > 0xFFFF) sum = (sum & 0xFFFF) + (sum >> 16L); sum = (~sum & 0xFFFF); ip->IP_checksum = sum; return; } ---------------------------------------------------------------- Note that most of the work is in the single instruction while loop, with a non-complex termination test. The second while loop is executed at most twice. A 9955 or 6350 running this in CIX mode blows the doors off of any poor controller micro-processor. Robert Ullmann Prime.COM zone/domain adminitrator Ariel@en-c06.Prime.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040707440000> Mail-From: STJOHNS created at 7-Apr-88 14:49:54 Date: 7 Apr 1988 14:44-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: MIL-STD vs. RFC From: STJOHNS@SRI-NIC.ARPA To: jbvb@VAX.FTP.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]Thu, 7 Apr 88 14:44:53 PDT.STJOHNS> In-Reply-To: <8804072055.AA18356@vax.ftp.com> I tell you three times: "where the MIL-STDS and RFC's disagree, the RFCs are correct". The point of contact for standards matters is Kevin Ebel, Ebel@DCA-EMS.ARPA, tell him I sent you *grin*. Seriously though - officially, the MIL-STDs superceded the RFCs, however we (DCA and DCEC) are aware that the MIL-STDs have some problems. (Like IP not being able to deliver data to its ULP, or was it TCP? *grin*). Our guidance has been to take the average of the RFCs and the MIL-STDs... sort of... Mike (Umm, if you get guidance that is different than the above, I would appreciate hearing details on who said it so I can either get them or me straightened out. ) I guess I ought to make it official: Mike StJohns, Capt, USAF, DDN Program, Defense Communication Agency ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040707523500> Received: from CORNELLC.CCS.CORNELL.EDU by SRI-NIC.ARPA with TCP; Thu 7 Apr 88 09:13:10-PDT Received: from CORNELLC.BITNET by CORNELLC.CCS.CORNELL.EDU ; Thu, 07 Apr 88 11:53:41 EDT Received: by CORNELLC (Mailer X1.25) id 7846; Thu, 07 Apr 88 11:53:39 EDT Date: Thu, 07 Apr 88 11:52:35 EDT From: Dick Cogger Subject: Cornell Mac/PC IP University Release To: TCP/IP List All Interested Parties: (Please forgive posting to multiple lists, due to overlapping subject matter) Cornell University MacIP and PC/IP are now available to colleges and Universities, essentially free. Cornell's versions of Mac and PC programs implement telnet, tn3270, and serial port terminal emulators compatible with the TCP/IP applicaitons. A ping application is also available. These programs are derived from the MIT PC/IP, and the Mac's Appletalk drivers were developed at Stanford. Major features are as follows: 1. Both tn and tn3270 are quite fast. With tn3270, full screens are displayed in less than a second, counting host time to generate the screen. Times approximately as follows: PC/XT 1 sec, MacPlus, .6 SEC, PC/AT OR MACII .45 SEC. 2. User key-mapping is supported. On the Mac, a simple macro facility provides the mapping. (The PC will have the equivalent soon.) 3. A very easy-to-use file transfer is built into the tn3270. A simple host command (e.g. "download foo memo") effects the transfer. Speed is about 3Kbytes/sec. 4. Serial port versions of the terminal programs present a near- identical user interface, including the same key mapping, same visual appearance. If calling an IBM host via 7171, the file transfer works trasparently with error checking, albeit more slowly. In fact, the same CMS module is used whether operating on TCP/IP or by async connection-- therefore, upload/download commands may be imbedded in exec's to operate either way. 5. The Mac versions support Appletalk and Omninet (Ethertalk soon), the PC versions support Appletalk (TOPS Flashtalk card), Omninet, Ethernet (3C501), Pronet-10, and a Netbios 5C interface. This latter is IP over Netbios, not to be confused with the reverse, and permits the use of various networks for telnet while running local file- service, such as Novell. 6. With Appletalk, the Mac and PC can be used with the Kinetics fastpath. The PC will operate normally on an ethernet or Pronet. Omninet and the Netbios interface require a matching router which we have at Cornell but is not generally available (see below). We've been running the Omninet versions for over 18 months at Cornell, and the Appletalk versions for several months. I'd estimate that over 100 people use them daily and the number is growing. However, they havn't been tested much outside Cornell, and most of the use at Cornell is over low-latency local nets. At least for now, we will be licensing these programs to colleges and universities only, with a simple license that basically has the licensee agreeing not to redistribute or hold Cornell responsible for any problems. For now, we won't be sending out source, but eventually we will on some basis. For non-university folks, we hope to find a commercial vendor who will release (sell) and support the programs, but we havn't been able to conclude such an arrangement. If we don't soon, we'll probably put it all in the public domain. If you want to license these programs, send me electronic mail and I'll send you a copy of the agreement to sign and return. SPECIAL: The first 25 requests I get, we'll provide the disks and postage to send it to you. (You'll know if you're in the 25 when you get the license form.) After that, there will be a distribution fee of $25.00. Regarding the IP Router (Gateway): We use a PC/AT clone, configured with one backbone interface and up to four local net interfaces. Usually, the backbone is Pronet, but it could be ethernet. The local nets are Omninet or Appletalk, or some of both. We have about 10 gateways in service in this configuration, and expect several more soon. With these Omninet/Appletalk units, we locate the router in a locked room at one of eight locations served by our backbone Pronet. From there, we run a telephone type twisted pair (part of our System 85 wireplant) to the building of interest where we install a star hub at the BDF (Building Distribution Frame). Additional telephone pairs go from the hub to outlets in offices. Also for local nets we can support ethernet or pronet or the Netbios interface. We've tested the Netbios interface with Starlan and IBM TokenRing, so far; it should work with lots of other nets. For this type of local net, we're thinking of using an Omninet (1 Mbit) to connect a port on a backbone gateway to a "satelite gateway" connected on the local ethernet or Netbios net. The gateways are assembled without disks, keyboards, or monitors. They boot over the backbone and download configuration. The boot server is a PC running a simple net monitor that pings listed IP addresses and displays responding status while answering boot requests in the background. Even stuffed full of cards, the gateway boxes usually cost under $2000 for the hardware. Performance seems to be excellent, although we have not done extensive testing. In one test we did do, an appletalk wire was saturated at 75 packets/sec (plus another 150/sec on the wire for ALAP RTS/CTS packets), about 180 Kbits/sec, all of the packets coming/going to a Pronet using 23% of the AT's CPU. Right now, we're adding Appletalk protocol-forwarding with IP tunnel-routing (like the KIP code for the Kinetics box). We're working on arranging for the AT-based gateway to be made available, but because of licensing issues, it seems to be taking a long time. Let me know if you would be interested. -Dick Cogger, Cornell University Internet: RHX@CornellC.ccs.cornell.edu Bitnet: RHX@CornellC 607-255-7566 U.S.Mail: Richard Cogger, Cornell University, 192 Caldwell Hall, Ithaca, NY 14853 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040707551700> Received: from CORNELLC.CCS.CORNELL.EDU by SRI-NIC.ARPA with TCP; Thu 7 Apr 88 09:14:03-PDT Received: from CORNELLC.BITNET by CORNELLC.CCS.CORNELL.EDU ; Thu, 07 Apr 88 11:55:50 EDT Received: by CORNELLC (Mailer X1.25) id 7967; Thu, 07 Apr 88 11:55:48 EDT Date: Thu, 07 Apr 88 11:55:17 EDT From: Dick Cogger Subject: Checksum in FEP To: TCP/IP List Probably, the following suggestion has been discussed in the past, but I haven't seen a reference: Why not offload JUST the IP and TCP checksumming to a Front End Processor (or controller board)? Doing so would require code operating at a lower layer to "peek" at fields deeper in the packet, and protocol layer-bigots may object, but it should work. For incoming packets, if the lap-type is IP (or the SNAP, etc.) then checksum the header-- if bad drop the packet. If the IP-type is TCP, checksum the packet; if bad drop it. In general, this is what the higher layer in the host is going to do anyway. If you trust the channel or dualported memory used to get the packet from the controller board, you could then rely on getting only good (in terms of checksums) packets. For outgoing packets, the controller could make the same sort of tests and calculate and fill in checksums only if the host had left them as zero. In both cases, the host code could (re)do the checksumming if it wanted to. In any case, the programming interface to the host would not be complicated (tcp, udp socket clients; multiple boards, etc.), but a major source of host overhead would be offloaded. Of course, the fast host processor might still be able to execute the checksum faster than a slow controller board. Dick Cogger RHX@CornellC.ccs.cornell.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040709424700> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Thu 7 Apr 88 11:24:47-PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 4416; Thu, 07 Apr 88 14:24:25 EDT Date: Thu, 7 Apr 1988 13:42:47.85 EDT From: Subject: Summary of responses to "NFS over the Internet" To: I received enough requests for a summary of repsonses to my earlier posting to warrant posting the summary to the net. As Barry Shein suggests, "the concept is not nearly as wild as [it might seem]". - Ralph Droms Computer Science Department Bucknell University droms@bknlvms.bitnet ----- From: edu%"bhoward@sol.engin.umich.edu" 31-MAR-1988 13:46 at one point, i mounted hoser.berkeley.edu:/usr/src or /usr/src/X (not certain anymore which) from sol.engin.umich.edu this was last summer and throughput was low, but it worked. i don't recall doing anything special, simply did a mount hoser:directory /n/hoser/directory bruce ----- From: EDU%"bzs%bu-cs.bu.edu@buita.BU.EDU" 1-APR-1988 04:48 As far as NFS over a serial line I tried it one evening over our 9.6Kb Cypress line between BU and UCB. It really wasn't bad, NFS is not a particularly high overhead protocol, the info being exchanged is fairly similar to what gets exchanged in an FTP session (DIR,GET,PUT etc.) Of course this disregards transmission problems which I didn't seem to have that evening, the question was thruput. It's probably an intuitive confusion that because NFS is so useful and neat that it must therefore demand massive bandwidth (or perhaps people are mixing the thought with ND, the diskless protocol?) Doubtless you'd want your binaries local but as a very easy to use "ftp" (eg. snooping around directories, copying stuff, file management) it's really not bad on a relatively slow line in my experience, perhaps a little slower than FTP but being able to use the native OS interface to the remote file system can make it worthwhile. Note that there are various timeout parameters etc that would need to be tuned (can be set on a per mount basis) for smooth performance, but the concept is not nearly as wild as seems to be presented here. -Barry Shein, Boston University ----- From: EDU%"pdb@SEI.CMU.EDU" 1-APR-1988 12:29 I've done it. (I only lose on one qualification - I had it running between two LANs, and the traffic had to cross the ARPANET to get between them. But I administer both those LANs.) --Pat. ----- From: edu%"hedrick@aramis.rutgers.edu" 1-APR-1988 17:19 We run NFS between departments all the time. In different buildings through 2 gateways. We also know people who have mounted our disks across the Arpanet, but this was done just as a hack, for a few minutes. Note that when we do it between our departments, we require that all the departments involved coordinate their uid allocation, since otherwise there are security problems. ----- From: NET%"roy%phri@uunet.UU.NET" 2-APR-1988 11:56 I remember reading a while ago that Rob Liebschutz (liebschutz@ig.com and/or liebschutz@bionet-20.arpa) and Mel Pleasant (pleasant@rutgers.edu) had tried remote mounting an NFS file system at Intelligenetics in California from Rutgers in New Jersey over the Internet. Supposedly they had no problems. You might try asking Rob or Mel for more details. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 ----- From: EDU%"sy.Ken@CU20B.COLUMBIA.EDU" 30-MAR-1988 11:38 We use NFS disk mounts between here and another machine (the exact whereabouts I can't tell you, but it's not on this campus), separated by a T1 circuit. Seems to work quite well, although is, of course, a bit slower than you would get off the direct ether. As for disjoint administrations, we are Columbia University, and the disks we mount belong to the NYSER Network Information machine. /Ken ------- From: EDU%"sy.Ken@CU20B.COLUMBIA.EDU" 30-MAR-1988 16:32 OK, well, that's not us, I guess... however, the technical (mechanical) aspects of such a hookup work well. The NYSER disks look like real local disks to us, and even with the distance separating us, we get pretty decent response time. Can't say anything about administrative aspects concerning common roots and all that, though... /Ken ------- From: GOV%"cpw%sneezy@LANL.GOV" 30-MAR-1988 19:57 As a lark, I mounted an NFS filesystem in La Jolla, CA. The linkage was: [Client]-ethernet (Los Alamos, NM) | IP router -- ethernet | IP router -- 19.2 serial line -- IP router | ethernet - [File Server] (La Jolla, CA) By the way, one could consider this a security breach. In fact one did, after I told them about it. This is a pet gripe of mine: Sun ships their systems WIDE OPEN, and its up to the user to shut them down. I think it should be the other way around. wood, cornett philip (cpw@lanl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23117@bbn.COM] <1988040714210400> From: mfidelma@bbn.com (Miles Fidelman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Becoming part of the Internet Message-ID: <23117@bbn.COM> Date: 7 Apr 88 14:21:04 GMT References: <8804051632.AA01636@wb6rqn.UUCP> Sender: news@bbn.COM Reply-To: mfidelma@cc5.bbn.com.BBN.COM (Miles Fidelman) Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 3 You could always join CSNet. Try contacting the CSNet information center at BBN Labs in Cambridge, MA. Their phone number is 617-873-2777 and their email address is cic@sh.cs.net I'll send you a little more info by mail. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804071508.AA15433@sneezy] <1988040715083500> From: cpw%sneezy@LANL.GOV (C. Philip Wood) Newsgroups: comp.protocols.tcp-ip Subject: Re: release of updated network sources for 4.3BSD Message-ID: <8804071508.AA15433@sneezy> Date: 7 Apr 88 15:08:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 59 For those of you with VAX's that are planning on incorporating the Berkeley fixes, the following patch should be applied to ip_output.c. It's the old byte order problem coming back to haunt us... Index: /sys/netinet/ip_output.c 4.3 (with new inet code) Submitted by: C. Philip Wood Description: Ip_output, when called upon to fragment, sends the incorrect length and fragment flag in the first packet. Repeat-By: Use minor internet discard protocol with udp and a packet length > the mtu of the network you are netting on, and monitor the network with a suitable tool. % discard -t datagram -l 1700 -p 1 doc Or, ship it through a vanilla IP gateway that keeps track of data length and header header length errors for IP. Take a snap before and after you send the fragmented packet and watch the count of bad packets. % netstat -s | grep "with data length" 265 with data length < header length % netstat -s | grep "with data length" 266 with data length < header length Fix: *** ip_output.c Wed Apr 6 11:52:50 1988 --- ip_output.c.orig Tue Mar 15 22:12:40 1988 *************** *** 10,14 **** * is provided ``as is'' without express or implied warranty. * ! * @(#)ip_output.c 7.9 (LANL) 3/15/88 */ --- 10,14 ---- * is provided ``as is'' without express or implied warranty. * ! * @(#)ip_output.c 7.9 (Berkeley) 3/15/88 */ *************** *** 233,238 **** */ m_adj(m0, hlen + firstlen - ip->ip_len); ! ip->ip_len = htons((u_short)(hlen + firstlen)); ! ip->ip_off = htons((u_short)(ip->ip_off | IP_MF)); ip->ip_sum = 0; ip->ip_sum = in_cksum(m0, hlen); --- 233,238 ---- */ m_adj(m0, hlen + firstlen - ip->ip_len); ! ip->ip_len = hlen + firstlen; ! ip->ip_off |= IP_MF; ip->ip_sum = 0; ip->ip_sum = in_cksum(m0, hlen); ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804071036.AA00073@wb6rqn.UUCP] <1988040715364200> From: brian@wb6rqn.UUCP (Brian Lloyd) Newsgroups: comp.protocols.tcp-ip Subject: KA9Q TCP/IP commercially available Message-ID: <8804071036.AA00073@wb6rqn.UUCP> Date: 7 Apr 88 15:36:42 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Sirius Systems has the KA9Q "Net" code available for commercial and government purposes. We include our enhancements, bug fixes, and additional drivers (our Ethernet driver is much faster and supports additional interface cards). We do track Phil's work and add his improvements but ours is a more robust product when we are through with it. In addition to the product we provide support and training. We can help someone who is interested in porting the code to other processors. If anyone is interested please contact us for further information. Brian Lloyd, President Sirius Systems, Inc. 19200 Tilford Way, Germantown, MD 20874 (301) 540-2066 brian@wb6rqn.uucp Share and enjoy! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804072118.AA09982@ucbvax.Berkeley.EDU] <1988040715523500> From: RHX@CORNELLC.CCS.CORNELL.EDU (Dick Cogger) Newsgroups: comp.protocols.tcp-ip Subject: Cornell Mac/PC IP University Release Message-ID: <8804072118.AA09982@ucbvax.Berkeley.EDU> Date: 7 Apr 88 15:52:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 110 All Interested Parties: (Please forgive posting to multiple lists, due to overlapping subject matter) Cornell University MacIP and PC/IP are now available to colleges and Universities, essentially free. Cornell's versions of Mac and PC programs implement telnet, tn3270, and serial port terminal emulators compatible with the TCP/IP applicaitons. A ping application is also available. These programs are derived from the MIT PC/IP, and the Mac's Appletalk drivers were developed at Stanford. Major features are as follows: 1. Both tn and tn3270 are quite fast. With tn3270, full screens are displayed in less than a second, counting host time to generate the screen. Times approximately as follows: PC/XT 1 sec, MacPlus, .6 SEC, PC/AT OR MACII .45 SEC. 2. User key-mapping is supported. On the Mac, a simple macro facility provides the mapping. (The PC will have the equivalent soon.) 3. A very easy-to-use file transfer is built into the tn3270. A simple host command (e.g. "download foo memo") effects the transfer. Speed is about 3Kbytes/sec. 4. Serial port versions of the terminal programs present a near- identical user interface, including the same key mapping, same visual appearance. If calling an IBM host via 7171, the file transfer works trasparently with error checking, albeit more slowly. In fact, the same CMS module is used whether operating on TCP/IP or by async connection-- therefore, upload/download commands may be imbedded in exec's to operate either way. 5. The Mac versions support Appletalk and Omninet (Ethertalk soon), the PC versions support Appletalk (TOPS Flashtalk card), Omninet, Ethernet (3C501), Pronet-10, and a Netbios 5C interface. This latter is IP over Netbios, not to be confused with the reverse, and permits the use of various networks for telnet while running local file- service, such as Novell. 6. With Appletalk, the Mac and PC can be used with the Kinetics fastpath. The PC will operate normally on an ethernet or Pronet. Omninet and the Netbios interface require a matching router which we have at Cornell but is not generally available (see below). We've been running the Omninet versions for over 18 months at Cornell, and the Appletalk versions for several months. I'd estimate that over 100 people use them daily and the number is growing. However, they havn't been tested much outside Cornell, and most of the use at Cornell is over low-latency local nets. At least for now, we will be licensing these programs to colleges and universities only, with a simple license that basically has the licensee agreeing not to redistribute or hold Cornell responsible for any problems. For now, we won't be sending out source, but eventually we will on some basis. For non-university folks, we hope to find a commercial vendor who will release (sell) and support the programs, but we havn't been able to conclude such an arrangement. If we don't soon, we'll probably put it all in the public domain. If you want to license these programs, send me electronic mail and I'll send you a copy of the agreement to sign and return. SPECIAL: The first 25 requests I get, we'll provide the disks and postage to send it to you. (You'll know if you're in the 25 when you get the license form.) After that, there will be a distribution fee of $25.00. Regarding the IP Router (Gateway): We use a PC/AT clone, configured with one backbone interface and up to four local net interfaces. Usually, the backbone is Pronet, but it could be ethernet. The local nets are Omninet or Appletalk, or some of both. We have about 10 gateways in service in this configuration, and expect several more soon. With these Omninet/Appletalk units, we locate the router in a locked room at one of eight locations served by our backbone Pronet. From there, we run a telephone type twisted pair (part of our System 85 wireplant) to the building of interest where we install a star hub at the BDF (Building Distribution Frame). Additional telephone pairs go from the hub to outlets in offices. Also for local nets we can support ethernet or pronet or the Netbios interface. We've tested the Netbios interface with Starlan and IBM TokenRing, so far; it should work with lots of other nets. For this type of local net, we're thinking of using an Omninet (1 Mbit) to connect a port on a backbone gateway to a "satelite gateway" connected on the local ethernet or Netbios net. The gateways are assembled without disks, keyboards, or monitors. They boot over the backbone and download configuration. The boot server is a PC running a simple net monitor that pings listed IP addresses and displays responding status while answering boot requests in the background. Even stuffed full of cards, the gateway boxes usually cost under $2000 for the hardware. Performance seems to be excellent, although we have not done extensive testing. In one test we did do, an appletalk wire was saturated at 75 packets/sec (plus another 150/sec on the wire for ALAP RTS/CTS packets), about 180 Kbits/sec, all of the packets coming/going to a Pronet using 23% of the AT's CPU. Right now, we're adding Appletalk protocol-forwarding with IP tunnel-routing (like the KIP code for the Kinetics box). We're working on arranging for the AT-based gateway to be made available, but because of licensing issues, it seems to be taking a long time. Let me know if you would be interested. -Dick Cogger, Cornell University Internet: RHX@CornellC.ccs.cornell.edu Bitnet: RHX@CornellC 607-255-7566 U.S.Mail: Richard Cogger, Cornell University, 192 Caldwell Hall, Ithaca, NY 14853 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804090542.AA07624@ucbvax.Berkeley.EDU] <1988040715551700> From: RHX@CORNELLC.CCS.CORNELL.EDU (Dick Cogger) Newsgroups: comp.protocols.tcp-ip Subject: Checksum in FEP Message-ID: <8804090542.AA07624@ucbvax.Berkeley.EDU> Date: 7 Apr 88 15:55:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 Probably, the following suggestion has been discussed in the past, but I haven't seen a reference: Why not offload JUST the IP and TCP checksumming to a Front End Processor (or controller board)? Doing so would require code operating at a lower layer to "peek" at fields deeper in the packet, and protocol layer-bigots may object, but it should work. For incoming packets, if the lap-type is IP (or the SNAP, etc.) then checksum the header-- if bad drop the packet. If the IP-type is TCP, checksum the packet; if bad drop it. In general, this is what the higher layer in the host is going to do anyway. If you trust the channel or dualported memory used to get the packet from the controller board, you could then rely on getting only good (in terms of checksums) packets. For outgoing packets, the controller could make the same sort of tests and calculate and fill in checksums only if the host had left them as zero. In both cases, the host code could (re)do the checksumming if it wanted to. In any case, the programming interface to the host would not be complicated (tcp, udp socket clients; multiple boards, etc.), but a major source of host overhead would be offloaded. Of course, the fast host processor might still be able to execute the checksum faster than a slow controller board. Dick Cogger RHX@CornellC.ccs.cornell.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804071734.AA04025@ucbvax.Berkeley.EDU] <1988040717352900> From: droms@BKNLVMS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: NFS across the Internet Message-ID: <8804071734.AA04025@ucbvax.Berkeley.EDU> Date: 7 Apr 88 17:35:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 X-Unparsable-Date: Wed, 6 Apr 1988 11:48:00.68 EDT Thanks to all who responded to my recent request for references to experiences with NFS across the Internet. I received about 5 replies, all of which confirm Barry Shein's observation that "the concept is not nearly so wild as [has been suggested]". A summary of the replies is available on request. - Ralph Droms Computer Science Department Bucknell University droms@bknlvms.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [93400003@uiucdcsp] <1988040719310000> From: zweig@uiucdcsp.cs.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: NCSA Telnet source Message-ID: <93400003@uiucdcsp> Date: 7 Apr 88 19:31:00 GMT Lines: 12 Nf-ID: #N:uiucdcsp:93400003:000:278 Nf-From: uiucdcsp.cs.uiuc.edu!zweig Apr 7 13:31:00 1988 Oops! Sorry folks. The NCSA Telnet code is available via anonymous FTP from: ftp.ncsa.uiuc.edu not from ncsa.uiuc.edu which (as any fool can see) is something else. My apologies for the inconvenience. Johnny Z Univ. of Ill. at Urbana Champaign Dept. of Computer Science ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1972@hou2d.UUCP] <1988040719372600> From: n2dsy@hou2d.UUCP (G.BEATTIE) Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip,rec.ham-radio.packet Subject: Asynchronous Framing Technique Document File: AFT.DOC Message-ID: <1972@hou2d.UUCP> Date: 7 Apr 88 19:37:26 GMT Organization: AT&T Bell Laboratories, Holmdel Lines: 357 Keywords: AFT, a SLIP alternative Here is the document file that I promised last week describing the Asynchonous Framing Technique (AFT). This is only a framing protocol. It contains NO state machine, transparency and error control. Four files will follow this message(but only in comp.protocols.tcp-ip): 1. AFT.C - a machine independent implementation of the AFT software. 2. ASYNC.ASM - an MS-DOS device driver to use with AFT. 3. TEST1.C - a test and demo programme for the AFT software. 4. Test2.C - another test and demo programme for the AFT software. The file contained in this message is AFT.DOC. If you like what you see here in the document file, go to the newsgroup "comp.protocols.tcp-ip" and pull the other four files. Machine Independent Asynchronous Framing Technique (AFT) Version 1.0, by John Howell (N2FVN), August 7, 1987 This software is in the public domain. It is provided on an 'as is' basis without warranty. This is a portable implementation of the Asynchronous Framing Technique for X.25 (X.25/AFT) Revision 2 coded in the C language. AFT is a protocol which allows X.25 style framing to be done over an asynchronous communication channel. It allows for detection of the start and end of frames, detection of corrupted transmission, and sending of frames containing eight bit characters over communication links which cannot accept all possible characters. AFT is intended to be used as a replacement for the X.25 level two framing technique in cases where synchronous communication is not practical. For more information on X.25/AFT contact: Research Department Hayes Microcomputer Products, Inc. 705 Westech Drive Norcross, Georgia 30092 This implementation of AFT supports all features of revision two of the protocol. A method is provided to select which of the possible options are to be used. The implementation has three components: 1) Option Selection 2) Frame Transmission 3) Frame Reception The interface to the user of AFT was chosen to allow use of the software in many different environments. As provided this software requires additional machine dependant software to provide a full AFT implementation. The transmit and receive routines have been implemented in such a way that they may be called either within interrupt service routines as characters are sent and received or they may be called from non-interrupt routines which fill or empty queues used by the software doing the hardware dependant portion of the I/O. This implementation provides no actual routines to do I/O since this is highly machine dependant. In this program the terms bytes and characters are used as synonyms for eight bit groups of data which are known as octets in X.25. This program assumes that the implementation of type 'char' is an eight bit value. Also the type 'int' is assumed to be at least 16 bits in size. An attempt has been made to only use those features of C which are common to nearly all implementations. This code was actually tested using Microsoft C version 4.0. Some abbreviations used in this program are: FCS Frame Check Sequence LEN Length OPT Option RX Receive SUB Substituted TX Transmit Interface to External Routines The following routines make up the interface to the AFT implementation. It is assumed that the user is familiar with the C language. aft_options(ebdt, transparency_level, suffix_len, suffix, max_rx_len) This routine selects the options to be used for AFT communication. It must be called at least once before any other AFT routines are used. It may be called again later to change the previously selected options. This should only be done at a time when no frames are being sent or received. 'ebdt' is a flag (0=false, non-zero=true) which determines whether the eight-bit data transparency option is to be used on transmit and receive. The EBDT option should only be used in cases where the communication path does not transfer the high order bit of characters transparently. This option must be selected identically on both the sending and receiving sides of the link. Use of this feature adds an extra 14% overhead to the communications. 'transparency_level' takes on one of three values. Zero indicates that basic transparency is to be used. This should be selected when the communication path allows transparent transmission of all 256 possible characters. One indicates that flow control transparency is to be used. This should be selected when the transmission of X-on and X- off characters would cause the receiver to perform flow control which would prevent them from appearing within frames. Two indicates that control-character transparency is to be used. This should be selected when the transmission path does not allow transparent transmission of some control characters. Each higher numbered option adds more overhead to transmitted frames. 'suffix_len' is the length of a string which will be appended to each frame when it is sent. This feature is used to provide any extra characters which the receiving system may require to recognize the end of an input. Zero should be used when no frame suffix is to be added which is the most common case. The maximum suffix allowed is three characters. 'suffix' is a pointer to the actual character string in which the suffix is stored. This is only examined if the suffix length is non-zero. This string may contain up to three characters which may each be any value. 'max_rx_len' is the size of the buffer which will be used for receiving frames. This length is used by the receive frame routines to prevent storing data past the end of the buffer. Received frames which are too long will be discarded. The receive buffer provided must be at least two characters larger than the maximum expected frame size. This is required since buffer is used for temporary storage of the two character frame check sequence. int aft_tx_start(length, buffer) This is the routine used to do the setup for transmitting a frame. This routine returns a value of zero if a new frame cannot be started because a frame is already being sent, or a value of one if the request is accepted. In either case this routine returns immediately. The actual sending of the frame is done by aft_tx_char. 'length' is the length of the frame to be sent. The minimum valid frame length is two characters. The maximum is limited only by the restrictions of the C compiler used. 'buffer' is a pointer to the buffer holding the frame to be sent. This buffer should contain only the address, control, and information fields for the frame. The AFT routines will generate starting and closing flags, frame check sequence, and other characters required for transparency when the frame is sent. AFT will not modify the contents of the buffer. The buffer contents should not be modified by any other routines until transmission of the frame is completed or an incorrect frame may be sent. int aft_tx_char() This routine is used to obtain the next character to be sent in order to transmit a frame. It returns characters to be sent as a value from zero to 255 in the low order byte of the returned integer and zero in the high order byte of the integer. Once the final character of the frame has been sent the return value will be one in the high order byte and a flag character in the low order byte. This routine is designed to be either used as a non- interrupt routine to which is called in a loop to fill an outgoing buffer which will be sent by other software or called within an interrupt routine when a transmitter buffer empty condition occurs to provide the next character to be sent. When used in an interrupt routine the caller may ignore the upper byte of the return value. If this is done then the result will be to send continuous flags between frames. aft_tx_abort() This routine may be called to cause aft_send_char to abort the frame it is currently sending. A lead-in character is sent followed by a flag to indicate that the receiver should ignore the frame. It a frame is not being sent then no action is taken. int aft_tx_complete() This routine is intended to be used in cases where aft_tx_char is being called during interrupt service. It provides a way for non-interrupt routines to poll for frame sending completion. It returns zero if a frame is currently being sent or one if no frame is being sent. A frame is considered to be sent once aft_tx_char is about to return the frame complete code (0x017E) to its caller. Instead of using this routine aft_tx_char may be easily modified to take any desired action when sending of a frame is completed. int aft_rx_start(buffer) This routine provides a buffer for the AFT software to use to receive a frame into. This routine returns a value of zero if the buffer is not accepted because a receive operation is already in progress or a value of one if the buffer is accepted. In either case this routine returns immediately to its caller. 'buffer' is a pointer to the buffer into which the frame will be received. This buffer will be filled one character at a time by aft_rx_char as characters for the frame are received. Once the receive operation is completed this buffer will hold the received frame address, control, and information fields. All flags, FCS, and extra transparency characters will have been removed. int aft_rx_char(c) This routine accepts a received character and adds it to the frame being received. If aft_rx_start has not been called to provide a buffer for receive then the first few characters of the frame will be saved in a temporary buffer. This will prevent loss of data in cases where aft_rx_char is being called directly by the receive interrupt service routine. This routine can also be called by a non-interrupt routine which obtains the characters from a received character queue. A value of zero is returned if this character does not complete a frame. A non-zero return value indicates that the character provided completed the received frame. In this case the value returned is the length of the frame which is contained in the receive buffer. If an invalid FCS is received at the end of the frame then the frame will be discarded. A frame of less than two bytes will also be discarded. 'c' is the next character received from the communication port. aft_rx_error() This routine is called to indicate the occurrence of an error condition on the communication line. Possible conditions may be framing error, break received, parity error (if in EBDT mode), time out (which is not required for AFT), or overrun. When this routine is called AFT discards the frame currently being received and begins searching for the start of the next frame. int aft_rx_complete() This routine is used in cases where aft_rx_char is being called during interrupt service. It provides a way for non- interrupt routines to poll for completion of a receive operation. It returns zero if the receive operation has not completed and the received frame length if it has. After this routine returns that a frame has completed then aft_rx_start should be called as quickly as possible to provide a new receive buffer. If this is not done in time then the next incoming frame may be lost. Instead of using this routine aft_rx_char may be easily modified to take any desired action when sending of a frame is completed. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1973@hou2d.UUCP] <1988040719394100> From: n2dsy@hou2d.UUCP (G.BEATTIE) Newsgroups: comp.protocols.tcp-ip Subject: Asynchronous Framing Technique Software: AFT.C Message-ID: <1973@hou2d.UUCP> Date: 7 Apr 88 19:39:41 GMT Organization: AT&T Bell Laboratories, Holmdel Lines: 159 Keywords: AFT, a SLIP Alternative /* Machine Independent Asynchronous Framing Technique (AFT) Version 1.0, by John Howell (N2FVN), Copyright August 7, 1987 This software is free for non-commercial use. All commercial rights are retained by the author or his designees. Commercial use without the explicit written permission of the author is prohibited. This package is provided on an 'as is' basis without warranty. */ /* Macros */ #define FLAG 0x007E /* This is the flag character which is used to start and end frames. The send generates separate starting and ending flag characters, but the receiver can accept a single flag to end one frame and start another. */ #define LEAD_IN 0x007D /* This is the lead in character which is used when transparency is required. When the receiver detects this character it takes the following character and exclusive ors it with 0x20 to produce the proper character. This is used to allow the transmission of characters which would not otherwise be received properly. */ #define TRANSPARENT(c) (c ^ 0x20) /* This is the function to be performed to convert a character into one which may be transmitted transparently. This is also used to return a character to its original value since the function is its own inverse. */ #define IDLE_CODE (0x0100 + FLAG) /* This is the idle code with is returned by aft_tx_char when it has no frame to send. The high order byte indicates completion and the low order byte is a flag which might be sent if flags are to be used between frames as filler. */ #define GENERATOR 0x8408 /* This is the generator polynomial for the frame check sequence. The polynomial is the standard CCITT polynomial. It is in reverse bit order for faster calculation. The polynomial is X**16 + X**12 + X**5 + 1. */ #define EXPECT_FCS 0xF0B8 /* This is the expected final FCS for a correctly received frame. */ #define OK 1 /* This is the return code used by some routines to indicate successful completion. */ #define NO_GOOD 0 /* This is the return code used by some routines to indicate unsuccessful completion. */ /* Global declarations */ static char opt_ebdt; /* This is a flag controlling the use of eight-bit data transparency on transmitted and receive frames. */ static char opt_transparency_level; /* This is the transparency level to be used when transmitting frames (0-2). Each increasing level causes more characters to be avoided when sending frames which allows them to be sent in situations where certain characters are not allowed. */ static char opt_suffix_len; static unsigned char opt_suffix[3]; /* This is the suffix string to be added to the end of each frame sent. Any character including a null is allowed. */ static unsigned int opt_max_rx_len; /* This is the maximum size of a receive buffer. It is used when receiving to make sure that a received frame does not go past the end of the buffer. A received frame which is too long will be discarded. */ static unsigned char transparency_level [256] = { 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 2, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 0, 0, 2, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9}; /* For each possible character this is the transparency level at which it should be encoded for transparency. A value of nine is used for character which should never be encoded. */ /* Variables and macros used by aft_tx_char */ static char tx_char_state; /* This is the state of the transmission routine which handles transparency, delimiting of frames, and frame abort. It is used to determine the next action to be performed by aft_tx_char when it is called. State names are given by the 'TCS_' macros. */ #define TCS_IDLE 0 /* This state ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1974@hou2d.UUCP] <1988040719421200> From: n2dsy@hou2d.UUCP (G.BEATTIE) Newsgroups: comp.protocols.tcp-ip Subject: Asynchronous Framing Technique Software: ASYNC.ASM Message-ID: <1974@hou2d.UUCP> Date: 7 Apr 88 19:42:12 GMT Organization: AT&T Bell Laboratories, Holmdel Lines: 1225 Keywords: AFT, a SLIP Alternative - MS-DOS Device Driver page 58,132 ; file: ASYNC.ASM TITLE ASYNC DRIVER FOR MSDOS SUBTTL DESCRIPTION ; ; Loadable asyncrounous device driver for msdos. ; Written by: Mike Higgins ; Copyright (c) April 1984 by The Computer Entomologist. ; ; Permission is hearby granted to use or distribute this software ;without any restrictions. You may make copies for yourself or your ;friends. You may include it in any hardware or software product that you ;sell for profit. ; ; This software is distributed as is, and is not guaranteed to work ;on any particular hardware/software configuration. Furthermore, no ;liability is granted with this software: the user takes responcibility for ;any damage this software may do to his system. ; ; Nasy notices aside, if you have any questions about this software, you ;can reach me at the address below. If you impliment any new features or ;find (and fix!) any bugs, I would be happy to hear from you. ; ; Mike Higgins ; The Computer Entomologist ; P.O. Box 197 ; Duncans Mills, CA 95430 ; ; -Impliments FULL RS232 support for IBM PC and compatable async cards. ; -Includes 128-byte buffers on input and output. ; -Supports Xon/Xoff or hardware handshake. Hardware handshake uses ; DSR or CTS (to throttle output data) All handshake modes are ; treated separately, an can be used in combinations. ; -The 8th bit (parity) can optionally be stripped off on input ; and/or output. ; -The IOCTRL read and write function is used to query or change ; baud rates, bits/byte, parity, as well as enabling/disabling all ; the optional features mentioned above. This eliminates the ; necesity of a program that has special knowledge of the system. ; A program to change these features need not know the location of ; the driver or special words in low memory, or even the port ; address of the UART. Instead, all that is needed is the name of ; the device, and the format of an IOCTL write to this driver. ; ; ASSEMBLY INSTRUCTIONS: ; MASM ASYNC,ASYNC,ASYNC,NUL ; LINK ASYNC,ASYNC,ASYNC,NUL ; EXE2BIN ASYNC ; COPY ASYNC.BIN A: (IF NOT THERE ALREADY) ; ADD THE FOLLOWING LINE TO A:CONFIG.SYS: ; DRIVER=ASYNC.BIN ; RE-BOOT YOUR SYSTEM AND IT'S THERE! NOTE: THIS DRIVER ; DOES NOT GET ALONG AT ALL WITH BASICA OR MODE, AND POSSIBLY ; MANY OTHER PCDOS PROGRAMS THAT DO NOT CONFORM TO THE MSDOS ; STANDARDS. BASICA IN PARTICULAR MUCKS UP ALL THE ASYNC CARD ; INTERNAL REGESTERS, REDIRECTS THE HARDWARE VECTOR, AND IT ; NEVER PUTS THEM BACK THE WAY THEY WERE. IF YOU TRY TO USE ; THIS DRIVER AFTER BASICA HAS BEEN IN MEMORY, THE DRIVER WILL ; PROBABLY HANG YOUR SYSTEM. ; ; ***BUGS*** ; ; If your RS232 device continually sends data to the driver, the driver ; will hang when your system boots. (The EPSON RX80 serial card sends ; ^Q's constantly and causes this). The current solution is to leave ; your device turned off until the system boots completely. Then turn ; the RS232 device on after the driver is ready for it, and everything ; works as expected. ; SUBTTL DEFINITIONS PAGE ; ; DEVICE TYPE CODES DEVCHR EQU 08000h ;THIS IS A CHARACTER DEVICE DEVBLK EQU 0H ;THIS IS A BLOCK (DISK) DEVICE DEVIOC EQU 04000H ;THIS DEVICE ACCEPTS IOCTRL REQUESTS DEVNON EQU 02000H ;NON IBM DISK DRIVER DEVSPC EQU 010H ;CONSOLE ACCEPTS SPECIAL INTERUPT 29 DEVCLK EQU 08H ;THIS IS THE CLOCK DEVICE DEVNUL EQU 04H ;THIS IS THE NUL DEVICE DEVSTO EQU 02H ;THIS IS THE CURRENT STANDARD OUTPUT DEVICE DEVSTI EQU 01H ;THIS IS THE STANDARD INPUT DEVICE ; ; ERROR STATUS BITS STSERR EQU 08000H ;GENERAL ERROR, SEE LOWER ORDER BITS FOR REASON STSBSY EQU 0200H ;DEVICE IS BUISY STSDNE EQU 0100H ;REQUEST IS COMPLETED ; ERROR REASON VALUES FOR LOWER ORDER BITS. ERRWP EQU 0 ;WRITE PROTECT ERROR ERRUU EQU 1 ;UNKNOWN UNIT ERRDNR EQU 2 ;DRIVE NOT READY ERRUC EQU 3 ;UNKNOWN COMMAND ERRCRC EQU 4 ;CYCLIC REDUNDANCY CHECK ERROR ERRBSL EQU 5 ;BAD DRIVE REQUEST STRUCTURE LENGTH ERRSL EQU 6 ;SEEK ERROR ERRUM EQU 7 ;UNKNOWN MEDIA ERRSNF EQU 8 ;SECTOR NOT FOUND ERRPOP EQU 9 ;PRINTER OUT OF PAPER ERRWF EQU 10 ;WRITE FAULT ERRRF EQU 11 ;READ FAULT ERRGF EQU 12 ;GENERAL FAILURE ; ; DEFINE THE BIT MEANINGS OF THE OUTPUT STATUS BYTE ; LINIDL EQU 0FFH ;IF ALL BITS OFF, XMITTER IS IDLE. LINXOF EQU 1 ;OUTPUT IS SUSPENDED BY XOFF LINEXP EQU 2 ;XMITTER IS BUISY, INTERUPT EXPECTED. LINDSR EQU 10H ;OUTPUT IS SUSPENDED UNTIL DSR COMES ON AGAIN LINCTS EQU 20H ;OUTPUT IS SUSPENDED UNTIL CTS COMES ON AGAIN ; ; BIT DEFINITIONS OF THE INPUT STATUS BYTE ; MODIDL EQU 0FFH ;MASK TO CHECK BLOCKING BITS MODERR EQU 1 ;INPUT LINE ERRORS HAVE BEEN DETECTED. MODOFF EQU 2 ;DEVICE IS OFFLINE NOW. MODOVR EQU 4 ;RECEIVER BUFFER OVERFLOWED, DATA LOST. MODXON EQU 8 ;RX IS BLOCKED SINCE WE SENT XOFF (^S). MODDTR EQU 10H ;RX IS BLOCKED SINCE DTR IS LOW. MODRTS EQU 20H ;RX IS BLOCKED SINCE RTS IS LOW. ; ; DEFINE THE BIT MEANINGS IN THE SPECIAL CHARACTERISTICS WORDS ; ; THE FIRST SPECIAL WORD CONTROLS HOW THE INPUT FROM THE UART IS TREATED ; INDTR EQU 2 ;DTR IS DATA-THROTTLE SIGNAL. INRTS EQU 4 ;RTS IS DATA-THROTTLE SIGNAL. INXON EQU 8 ;XON/XOFF IS USED TO THROTTLE INPUT DATA. INHDP EQU 020H ;HALF DUPLEX: INPUT CHARS ARE ECHOED. INEST EQU 0400H ;ERRORS CAUSE STATUS RETURNS. INEPC EQU 0800H ;ERRORS TRANSLATE TO CODES WITH PARITY BIT ON. INSTP EQU 01000H ;STRIP PARITY BIT OFF ON INPUT ; ; THE SECOND SPECIAL WORD CONTROLS HOW THE OUTPUT TO THE UART IS TREATED ; OUTDSR EQU 2 ;DSR IS USED TO THROTTLE OUTPUT DATA. OUTCTS EQU 4 ;CTS IS USED TO THROTTLE OUTPUT DATA. OUTXON EQU 8 ;XON/XOFF IS USED TO THROTTLE OUTPUT DATA. OUTCSF EQU 010H ;CTS IS OFFLINE SIGNAL. OUTCDF EQU 020H ;CARRIER DETECT IS OFFLINE SIGNAL OUTDRF EQU 040H ;DSR IS OFFLINE SIGNAL. OUTSTP EQU 01000H ;STRIP PARITY OFF ON OUTPUT. ; ; DEFINE THE PORT OFFSETS AND IMPORTANT ASYNC BOARD CONSTANTS ; LINE CONTROL REG DEFINITIONS ; BITS5 EQU 0 BITS6 EQU 1 BITS7 EQU 2 BITS8 EQU 3 ONESTOP EQU 0 ;DEFAULT TWOSTOP EQU 4 nopar equ 0 PARON EQU 8 ODDPAR EQU 0+paron ;DEFAULT EVENPAR EQU 10H+PARON STICKPAR EQU 20H ;(THIS IS STRANGE) BREAKON EQU 40H DLAB EQU 080H ;DIVISOR LATCH ACCESS BIT ; ; MODEM CONTROL REG DEFINITIONS DTR EQU 1 RTS EQU 2 OUT1 EQU 4 OUT2 EQU 8 LOOPBACK EQU 10H ; ALLINT EQU 01111B ;ENABLE ALL INTERUPTS IN INTEN REGESTER. TXBUF EQU 0 ;OFFSET TO TRANSMITTER BUFFER REGESTER RXBUF EQU 0 ;DITO FOR RECEIVER (DIRECTION DIFERENTIATES FUNCS) BAUD0 EQU 0 ;BAUD DIVISOR REG (DLAB IN LCTRL DIFFERENCIATES) BAUD1 EQU 1 ;BAUD DIVISOR HIGH BYTE INTEN EQU 1 ;INTERUPT ENABLE REGESTER INTID EQU 2 ;INTERUPT IDENTIFICATION REGESTER. LCTRL EQU 3 ;LINE CONTROL REGESTER MCTRL EQU 4 ;MODEM CONTROL REGESTER LSTAT EQU 5 ;LINE STATUS REGESTER MSTAT EQU 6 ;MODEM STATUS REGESTER ; BAUD RATE CONVERSION TABLE ; BD50 EQU 2304 BD75 EQU 1536 BD110 EQU 1047 BD134 EQU 857 BD150 EQU 786 BD300 EQU 384 BD600 EQU 192 BD1200 EQU 96 BD1800 EQU 64 BD2000 EQU 58 BD2400 EQU 48 BD3600 EQU 32 BD4800 EQU 24 BD7200 EQU 16 BD9600 EQU 12 ; SUBTTL DRIVER LIST HEAD PAGE ;************************************************************************* ; ; BEGENING OF DRIVER CODE. ; DRIVER SEGMENT ASSUME CS:DRIVER,DS:DRIVER,ES:DRIVER ; ORG 0 ;DRIVERS START AT 0 ASYNC2: DW ASYNC1,-1 ;POINTER TO NEXT DEVICE: DOS FILLS THIS IN. DW DEVCHR OR DEVIOC ;CHARACTER DEVICE DW STRATEGY ;OFFSET TO STRATEGY ROUTINE. DW REQUEST2 ;OFFSET TO "INTERUPT" ENTRYPOINT. DB "ASYNC2 " ;DEVICE NAME. ASYNC1: DW -1,-1 ;POINTER TO NEXT DEVICE: END OF LINKED LIST. DW DEVCHR OR DEVIOC ;THIS DEVICE IS CHARACTER IOCTL DW STRATEGY ;STRATEGY ROUTINE DW REQUEST1 ;I/O REQUEST ROUTINT DB "ASYNC1 " ; SUBTTL DRIVER INTERNAL DATA STRUCTURES PAGE ; ASY_UNITS EQU 2 ;NUMBER OF UNITS THIS DRIVER IS BUILT FOR UNIT STRUC ;EACH UNIT HAS A STRUCTURE DEFINING IT'S STATE: PORT DW ? ;I/O PORT ADDRESS VECT DW ? ;INTERUPT VECTOR OFFSET (NOT INTERUPT NUMBER!) ISRADR DW ? ;OFFSET TO INTERUPT SERVICE ROUTINE LINE DB ? ;DEFAULT LINE CONTROL BIT SETTINGS DURING INIT, ;OUTPUT STATUS BITS AFTERWORDS. MODEM DB ? ;MODEM CONTROL BIT SETTINGS DURING INIT, ;INPUT STATUS BITS AFTERWARDS. INSPEC DW ? ;SPECIAL CHAR INPUT TREATMENT, HANDSHAKING MODE. OUTSPEC DW ? ;SPECIAL MODE BITS FOR OUTPUT BAUD DW ? ;CURRENT BAUD RATE DIVISOR VALUE IFIRST DW ? ;OFFSET TO FIRST CHARACTER IN INPUT BUFFER. IAVAIL DW ? ;OFFSET TO NEXT AVAILABLE BYTE. IBUF DW ? ;POINTER TO 128 BYTE INPUT BUFFER. OFIRST DW ? ;OFFSET INTO FIRST CHARACTER IN OUTPUT BUFFER OAVAIL DW ? ;OFFSET INTO NEXT AVAIL BYTE IN OUTPUT BUFFER OBUF DW ? ;POINTER TO 128 BYTE OUTPUT BUFFER UNIT ENDS ;TABLE OF STRUCTURES FOR EACH ASYNCROUNOUS UNIT ;ASYNC1 DEFAULTS TO THE COM1 PORT AND VECTOR, b81n equ bits8 or onestop or nopar dtrrts equ dtr or rts or out2 ;seems to need out2 all the time!!!!!!!! ASY_TAB1: UNIT <3F8H,30H,ASY1ISR,B81N,DTRRTS,INDTR+INEST,OUTCTS,BD1200,0,0,IN1BUF,0,0,OUT1BUF> ;ASYNC2 DEFAULTS TO THE COM2 PORT AND VECTOR, ;NO PARITY, 8 DATA BITS, 1 STOP BIT, ;AND 9600 BAUD. ASY_TAB2: UNIT <2F8H,2CH,ASY2ISR,B81N,DTRRTS,INDTR+INEST,OUTCTS,BD1200,0,0,IN2BUF,0,0,OUT2BUF> ;IF THE BUFFER SIZE IS A POWER OF TWO, THE PROCESS OF KEEPING ;THE OFSETTS WITHIN THE BOUNDS OF THE BUFFER IS GREATLY ;SIMPLIFIED. IF YOU MODIFY THE BUFFER SIZE, KEEP IT A ;POWER OF 2, AND MODIFY THE MASK ACCORDINGLY. BUFSIZ EQU 128 ;INPUT BUFFER SIZE BUFMSK EQU 127 ;MASK FOR CALCULATING OFFSETS MODULO BUFSIZ ISTOP EQU 120 ;TRY TO STOP RX WHEN IBUF IS THIS FULL ISTART EQU 100 ;LET THE GUY SEND AGAIN WHEN THIS FULL IN1BUF DB BUFSIZ DUP (?) IN2BUF DB BUFSIZ DUP (?) OUT1BUF DB BUFSIZ DUP (?) OUT2BUF DB BUFSIZ DUP (?) ; ASY_BAUDT DW 50,BD50 ;FIRST VALUE IS DESIRED BAUD RATE, DW 75,BD75 ;SECOND IS DIVISOR REGISTER VALUE. DW 110,BD110 DW 134,BD134 DW 150,BD150 DW 300,BD300 DW 600,BD600 DW 1200,BD1200 DW 1800,BD1800 DW 2000,BD2000 DW 2400,BD2400 DW 3600,BD3600 DW 4800,BD4800 DW 7200,BD7200 DW 9600,BD9600 ; ; STRUCTURE OF AN I/O REQUEST PACKET STATIC HEADER ; PACK STRUC LEN DB ? ;LENGTH OF RECORD PRTNO DB ? ;UNIT CODE CODE DB ? ;COMMAND CODE STAT DW ? ;RETURN STATUS DOSQ DD ? ;UNUSED DOS QUE LINK POINTER DEVQ DD ? ;UNUSED DRIVER QUE LINK POINTER MEDIA DB ? ;MEDIA CODE ON READ/WRITE XFER DW ? ;XFER ADDRESS OFFSET XSEG DW ? ;XFER ADDRESS SEGMENT COUNT DW ? ;TRANSFER BYTE COUNT. PACK ENDS ; ; THE FOLLOWING TWO WORDS IS THE STORAGE AREA FOR THE REQUEST PACKET ; ADDRESS, SENT TO ME BY A STRATEGY ROUTINE CALL. ; AS REQUESTED BY THE MSDOS DRIVER MANUAL, I AM "THINKING ; ABOUT" THE FUTURE, SO I`M DESIGNATING THIS POINTER AS THE QUEUE ; LIST HEAD FOR REQUESTS TO THIS DRIVER. ; PACKHEAD DD 0 ; ; THE STRATEGY ROUTINE ITSELF. STRATEGY PROC FAR ;SQUIRREL AWAY THE POINTER FOR LATER. MOV WORD PTR CS:PACKHEAD,BX ;STORE THE OFFSET, MOV WORD PTR CS:PACKHEAD+2,ES ;AND THE SEGMENT. RET STRATEGY ENDP SUBTTL REQUEST ROUTINES PAGE ; PHYLOSOPHICAL RUMINATIONS: ; Why does MicroSoft INSIST on choosing names for things that ; already have firmly defined meanings for OTHER things? Take for ; example, the MASM definition of a SEGMENT: It bears little relation ; to the deffinition of a segment in the intel 8088 processor handbook. ; This leads to a GREAT DEAL of confusion. Many other assemblers on ; other systems have constructs that are equivalent to MASM's SEGMENT, ; they are often called PSECTS for Program SECTionS. Perhaps the ; people at Microsoft wanted a word that made more sence in English, ; but I wish they had chosen SECTION instead of SEGMENT. ; The example that it bringing all this to mind now is the ; MicroSoft device driver documentation, which insists on calling ; the following routine an "interupt routine". Go read the intel ; manual, you will find that an interupt routine is defined THERE as ; a bunch of code that is jumped to by a special kind of event in ; the hardware. That is NOT what the people at MicroSquishy mean ; this time either. Depending on weather you describe these routines ; in terms of what they do now, or in the "future", the following ; routine should be called the "I/O request routine" or the "I/O ; completion routine". But NO, they had to deside to call this ; the "interupt routine", and create another layer of confusion for ; those of us who already know the traditional deffinition of this ; relatively well known phrase. ; ; I am herby refering to the "interupt routine" as the ; "request routine", and nameing all my labels accordingly. ; ; I/O REQUEST ROUTINES REQUEST1: ;ASYNC1 HAS BEEN REQUESTED PUSH SI ;SAVE SI SO YOU CAN MOV SI,OFFSET ASY_TAB1 ;GET THE DEVICE UNIT TABLE ADDRESS. JMP GEN_REQUEST ;THE GENERIC DRIVER DOES THE REST. REQUEST2: ;ASYNC2 HAS BEEN REQUESTED TO DO SOMETHING PUSH SI ;SAVE SI MOV SI,OFFSET ASY_TAB2 ;GET UNIT TABLE TWO`S ADDRESS GEN_REQUEST: PUSHF ;I REQUIRE DIRECTION FLAG CLEARED, SO I SAVE CLD ;THE FLAGS AND CLEAR THEM HERE. PUSH AX ;SAVE ALL THE REGESTERS, YOU MAY NOT PUSH BX ;NEED THEM ALL, BUT YOU WILL REGRET IT PUSH CX ;IF YOU FORGET TO SAVE JUST ONE OF THEM. PUSH DX PUSH DI PUSH BP PUSH DS PUSH ES PUSH CS ;COPY THE CS REGESTER POP DS ;INTO THE DS TO ACCESS MY DATA LES BX,PACKHEAD ;RECOVER THE POINTER TO THE PACKET. MOV DI,OFFSET ASY_FUNCS ;GET THE POINTER TO THE DISPATCH TABLE MOV AL,ES:CODE[BX] ;GET THE FUNCTION REQUEST CODE, MOV AH,0 ;MAKE IT INTO A WORD, SAL AX,1 ;CONVERT TO A WORD OFFSET, ADD DI,AX ;AND ADD TO THE TABLE START ADDRESS JMP [DI] ;JUMP TO THE APPROPRIATE ROUTINE ; ; TABLE OF OFFSETS TO ALL THE DRIVER FUNCTIONS ASY_FUNCS: DW ASYNC_INIT ;INITIALIZE DRIVER DW EXIT ;MEDIA CHECK (BLOCK DEVICES ONLY) DW EXIT ;BUILD BPB (BLOCK DEVICES ONLY) DW IOCTLIN ;IOCTL INPUT DW READ ;READ DW NDREAD ;NON-DESTRUCTIVE READ DW RXSTAT ;INPUT STATUS DW INFLUSH ;FLUSH INPUT BUFFER DW WRITE ;WRITE DW WRITE ;WRITE WITH VERIFY DW TXSTAT ;OUTPUT STATUS DW TXFLUSH ;FLUSH OUTPUT BUFFER DW IOCTLOUT ;IOCTL OUTPUT ; ; EXIT FROM DRIVER REQUEST ; CALL WITH AX= RETURN STATUS VALUE EXITP PROC FAR EXIT: LES BX,PACKHEAD ;RETREIVE POINTER TO PACKET OR AX,STSDNE ;SET THE DONE BIT IN IT. MOV ES:STAT[BX],AX ;STORE THE STATUS BACK IN THE PACKET. POP ES ;RESTORE ALL THE REGESTERS POP DS POP BP POP DI POP DX POP CX POP BX POP AX POPF POP SI RET EXITP ENDP SUBTTL READ DATA REQUEST ROUTINE PAGE ; ; ALL THE FOLLOWING ROUTINES ARE CALLED WITH THE SAME CONTEXT ; FROM THE REQUEST ROUTINE: ; - ES:BX POINTS TO THE I/O PACKET. ; ROUTINES CAN MUCK UP THESE TWO REGESTERS IF THEY WANT, AS EXIT ; WILL RESTORE THEM BEFORE IT TRIES TO SEND THE STATUS WORD BACK. ; - CS: AND DS: POINT TO THE BEGENING OF THE DRIVER SEGMENT. ; - DS:SI POINTS TO THE DEVICE UNIT TABLE DESCRIBING THE PARTICULAR ; PORT BEING ACCESSED. ; - ALL OTHER REGESTERS ARE AVAILABLE FOR USE, THE EXIT ROUTINE ; RESTORES THEM ALL BEFORE RETURNING TO MSDOS. ; ALL THE FOLLOWING ROUTINES SHOULD EXIT BY DOING A JMP ; TO THE EXIT ROUTINE. EXIT ASSUMES THAT AX ; CONTAINS EITHER ZERO, OR THE ERROR BIT SET AND A VALID ERROR ; RETURN VALUE IN THE LOW ORDER BITS. EXIT SETS THE DONE BIT IN ; THIS VALUE FOR YOU BEFORE IT RETURNS TO MSDOS. ; SUBTTL READ REQUEST ROUTINE ; READ DATA FROM DEVICE ; READ: MOV CX,ES:COUNT[BX] ;GET THE REQUESTED NUMBER OF BYTES MOV DI,ES:XFER[BX] ;DI IS OFFSET TO USER BUFFER MOV DX,ES:XSEG[BX] ;SEGMENT IS LAST I NEED FROM PACKET, MOV ES,DX ;NOW ES:DI POINTS TO USER BUFFER. CALL START_IN ;TRY TO RESTART RX, ALL REGS PRESERVED TEST MODEM[SI],MODERR OR MODOVR ;HAVE ANY LINE ERRORS OCCURED? JE NO_LERR ;NOT LATELY. AND MODEM[SI],NOT ( MODERR OR MODOVR ) ;YES, CLEAR THE BITS, MOV AX,ERRRF ;AND RETURN ERROR INDICATION TO DOS JMP EXIT NO_LERR: RLUP: CALL GET_IN ;GET NEXT CHAR FROM INPUT BUFFER CMP AH,0 ;WAS THERE ONE? JE TEST_READ ;YES, TEST FOR SPECIAL BITS JMP RLUP ;NO, WAIT FOR A CHAR TO ARRIVE. TEST_READ: ;BEFORE RETURNING A CHARACTER TO MSDOS, I CHECK FOR ANY ;SPECIAL PROCESSING I AM REQUIRED TO DO. I DO AS MANY ;OF THESE FUNCTIONS HERE AS POSSIBLE, TO SAVE THE ;RECEIVER INTERUPT ROUTINE FROM HAVING TO DO THEM, AND ;TO ALLOW INTELIGENT USE OF THE RING BUFFER. FOR EXAMPLE, ;CHARACTERS TO NOT ECHO-HALF-DUPLEX UNTIL THEY ARE READ ;FROM THE BUFFER HERE, SO A PROGRAM THAT DISABLES ECHO ;WHILE READING A PASSWORD WILL WORK EVEN IF THE USER TYPED ;THE PASWORD IN BEFORE BEING PROMPTED FOR IT. ;************************************ ;TEST FOR STRIPPING PARITY BIT TEST INSPEC[SI],INSTP ;SHOULD I STRIP PARITY? JE NO_STRIP ;NOPE. AND AL,NOT 080H ;YES. NO_STRIP: ;**********************************8 ;TEST FOR HALF-DUPLEX MODE STOS BYTE PTR [DI] ;BUT FIRST STORE CHAR IN USER BUFFER. TEST INSPEC[SI],INHDP ;AM I IN HALF DUPLEX MODE? JE NO_HALF ;NO. HALF_WAIT: CALL PUT_OUT ;YES, PUT THE CHARACTER IN OUTBUF. CMP AH,0 ;WAS THERE ROOM? JNE HALF_WAIT ;NO, WAIT FOR IT. CALL START_OUTPUT ;AND MAKE SURE THE XMITTER STARTS NO_HALF: ;ALTHOUGH MSDOS NEVER, TO MY KNOWLEDGE, ASKS FOR MORE THAN ;ONE STUPID CHARACTER AT A TIME, I LOOP ON THE REQUEST SIZE ;SO THAT THIS DRIVER WILL STILL WORK ON THAT GLORIOUS DAY ;WHEN SOMEBODY ASKS FOR MORE THAN ONE. LOOP RLUP ;KEEP GOING IF YOU WERE REQUESTED. MOV AL,0 ;RETURN NO ERRORS IN AX IF DONE. JMP EXIT SUBTTL NON-DESTRUCTIVE READ REQUEST ROUTINE PAGE ; NON-DESTRUCTIVE READ FROM DEVICE ; NDREAD: MOV DI,IFIRST[SI] ;GET POINTER TO FIRST CHAR CMP DI,IAVAIL[SI] ;IS THE BUFFER EMPTY? JNE NDGET ;NO, GET ONE NON DESTRUCTIVELY. MOV AX,STSBSY ;YES, RETURN DEVICE BUISY JMP EXIT NDGET: PUSH BX ;SAVE AN EXTRA COPY OF BX. MOV BX,IBUF[SI] ;GET BUFFER ADDRESS MOV AL,[BX+DI] ;GET THE CHARACTER, POP BX ;RECOVER BX AGAIN. MOV ES:MEDIA[BX],AL ;RETURN IT IN THE REQUEST PACKET. MOV AX,0 ;RETURN NO ERRORS IN AX. JMP EXIT SUBTTL INPUT STATUS REQUEST ROUTINE PAGE ; INPUT STATUS REQUEST ; RXSTAT: MOV DI,IFIRST[SI] ;GET POINTER TO FIRST CHAR CMP DI,IAVAIL[SI] ;IS THE BUFFER EMPTY? JNE RXFUL MOV AX,STSBSY ;NO, RETURN STATUS BUISY. JMP EXIT RXFUL: MOV AX,0 ;YES, RETURN STATUS ZERO. JMP EXIT SUBTTL INPUT FLUSH REQUEST ROUTINE ; INPUT FLUSH REQUEST ; INFLUSH: MOV AX,IAVAIL[SI] ;GET THE POINTER TO THE NEXT EMPTY MOV IFIRST[SI],AX ;CHAR AND POINT THE FIRST AT IT. MOV AX,0 ;AND RETURN DONE. JMP EXIT SUBTTL WRITE REQUEST ROUTINE PAGE ; OUTPUT DATA TO DEVICE ; WRITE: MOV CX,ES:COUNT[BX] ;GET BYTE COUNT, MOV DI,ES:XFER[BX] ;GET XFER ADDRESS OFFSET, MOV AX,ES:XSEG[BX] ;GET XFER SEGMENT. MOV ES,AX ;STORE IN ES NOW. WLUP: MOV AL,ES:[DI] ;GET THE NEXT CHAR, INC DI ;AND INC DI PAST IT. ; ; CHECK FOR STRIP PARITY ON OUTPUT. ; TEST OUTSPEC[SI],OUTSTP ;IS THIS ENABLED? JE NOOSTP ;NOPE AND AL,NOT 080H ;YES, WACK OFF BIT SEVEN! NOOSTP: ; ; AFTER ALL THE SPECIAL OUTPUT PROCESSING, I DO A HARD WAIT ; FOR A SLOT IN THE OUTPUT BUFFER. WWAIT: CALL PUT_OUT ;ATTEMPT TO PUT IN IN OUTPUT BUFFER CMP AH,0 ;DID IT WORK? JNE WWAIT ;NO, KEEP TRYING. LOOP WLUP ;YES, GO GET NEXT CHAR. CALL START_OUTPUT ;START THE XMITTER IF NECC. MOV AX,0 ;RETURN SUCCESS JMP EXIT SUBTTL OUTPUT STATUS REQUEST ROUTINE ; OUTPUT STATUS REQUEST ; TXSTAT: MOV AX,OFIRST[SI] ;GET POINTER TO NEXT CHAR OUT DEC AX ;SUBTRACT ONE FROM IT, AND AX,BUFMSK ;MODULO 128. CMP AX,OAVAIL[SI] ;IF THAT EQUALS THE INPUT PNTR, JNE TXROOM MOV AX,STSBSY ;THEN THE DEVICE IS BUISY. JMP EXIT TXROOM: MOV AX,0 ;OTHERWIZE THE DEVICE IS OK. JMP EXIT SUBTTL I/O CONTROL READ REQUEST PAGE ; ; IOCONTROL READ REQUEST, RETURN LINE PARAMETERS ; IOCTLIN: MOV CX,ES:COUNT[BX] ;GET THE REQUESTED NUMBER OF BYTES MOV DI,ES:XFER[BX] ;DI IS OFFSET TO USER BUFFER MOV DX,ES:XSEG[BX] ;SEGMENT IS LAST I NEED FROM PACKET, MOV ES,DX ;NOW ES:DI POINTS TO USER BUFFER. CMP CX,14 ;ONLY WORKS WHEN YOU GIVE ME AN JE DOIOCIN ;14 BYTE BUFFER TO STOMP ON. MOV AX,ERRBSL ;RETURN AN ERROR IF NOT 14 BYTES. JMP EXIT DOIOCIN: MOV DX,PORT[SI] ;GET PORT NUMBER ADD DX,LCTRL ;SLIDE UP TO LINE CONTROL MOV CX,4 ;SET UP FOR PORT LOOP. GETPORT: IN AL,DX ;GET NEXT BYTE FROM DEVICE STOS BYTE PTR [DI] ;STORE THEM IN USER BUFFER INC DX ;SKIP TO NEXT BYTE LOOP GETPORT ;READ AND STORE 4 BYTES OF INFO MOV AX,INSPEC[SI] ;GET THE SPECIAL INPUT BITS STOS WORD PTR [DI] ;SEND BACK TO USER BUFFER MOV AX,OUTSPEC[SI] ;GET THE SPECIAL OUTPUT BITS STOS WORD PTR [DI] ;SEND BACK TO USER BUFFER MOV AX,BAUD[SI] ;GET BAUD RATE DIVISOR MOV BX,DI ;SAVE DI FOR A WHILE. MOV DI,OFFSET ASY_BAUDT+2 ;POINT AT BAUD RATE CONVERSION. MOV CX,15 ;JUST IN CASE, STOP AT 15 BAUDS BAUDCIN: CMP [DI],AX ;IS THIS THE BAUD I AM USING? JE YESINB ;YES, RETURN THAT ADD DI,4 ;NO, SKIP TO NEXT ONE LOOP BAUDCIN ;KEEP LOOKING. YESINB: ;SEARCH SHOULD ALWAYS TERMINATE ON COMPARE MOV AX,-2[DI] ;GET THE ASSOCIATED BAUD RATE MOV DI,BX ;GET DI'S OLD VALUE BACK STOS WORD PTR [DI] ;STORE THE BAUD RATE BACK. mov ah,0 mov al,line[si] stos byte ptr [di] mov ah,0 mov al,modem[si] stos byte ptr [di] MOV AX,0 ;RETURN NO ERRORS stos word ptr [di] ;zero the extra word JMP EXIT ; ; FLUSH OUTPUT BUFFER REQUEST ; TXFLUSH: MOV AX,OAVAIL[SI] ;GET NEXT FREE BYTE OFFSET, MOV OFIRST[SI],AX ;POINT THE FIRST BYTE OFFSET AT IT. MOV AX,0 JMP EXIT SUBTTL I/O CONTROL WRITE REQUEST ROUTINE PAGE ; IOCONTROL REQUEST: CHANGE LINE PARAMETERS FOR THIS DRIVER ; IOCTLOUT: MOV CX,ES:COUNT[BX] ;GET THE REQUESTED NUMBER OF BYTES MOV DI,ES:XFER[BX] ;DI IS OFFSET TO USER BUFFER MOV DX,ES:XSEG[BX] ;SEGMENT IS LAST I NEED FROM PACKET, MOV ES,DX ;NOW ES:DI POINTS TO USER BUFFER. CMP CX,10 ;ONLY WORKS WHEN YOU GIVE ME A JNL DOIOCOUT ;atleast 10 BYTE BUFFER TO READ MOV AX,ERRBSL ;RETURN AN ERROR IF NOT =>10 BYTES. JMP EXIT DOIOCOUT: MOV DX,PORT[SI] ;GET PORT NUMBER ADD DX,LCTRL ;SLIDE UP TO LINE CONTROL MOV AL,ES:[DI] ;GET LINE CONTROL FROM USER BUF. INC DI OR AL,080H ;SET DLAB BIT FOR BAUD RATE OUT DX,AL ;OUTPUT TO DEVICE INC DX ;SKIP TO NEXT BYTE MOV AL,ES:[DI] ;GET MODEM CONTROL FROM USER BUF. INC DI OR AL,08H ;MAKE SURE INTERUPTS ARE ENABLED. OUT DX,AL ;SEND IT TO DEVICE. ADD DI,2 ;SKIP OVER THE STATUS BYTES MOV AX,ES:[DI] ;GET THE SPECIAL INPUT BITS ADD DI,2 MOV INSPEC[SI],AX ;STORE THE NEW BITS IN UNIT MOV AX,ES:[DI] ;GET THE OUTPUT SPECIAL BITS ADD DI,2 MOV OUTSPEC[SI],AX ;STORE THEM ALSO. MOV AX,ES:[DI] ;GET THE REQUESTED BAUD RATE MOV BX,DI ;SAVE DI FOR A WHILE. MOV DI,OFFSET ASY_BAUDT ;POINT AT BAUD RATE CONVERSION MOV CX,15 ;JUST IN CASE, STOP AT 15 BAUDS BAUDCOUT: CMP [DI],AX ;IS THIS THE BAUD I AM USING? JE YESOUTB ;YES, RETURN THAT ADD DI,4 ;NO, SKIP TO NEXT ONE LOOP BAUDCOUT ;KEEP LOOKING. IN AL,DX ;GET LINE CONTROL REGESTER AGAIN, AND AL,NOT 080H ;CLEAR DLAB BIT. DEC DX OUT DX,AL ;AND WRITE IT BACK OUT. MOV AX,ERRUM ;RETURN AN ERROR NUMBER IF JMP EXIT ;BAUD RATE IS NOT IN TABLE. YESOUTB: MOV AX,2[DI] ;GET THE ASSOCIATED BAUD RATE MOV BAUD[SI],AX ;STORE IT IN UNIT TABLE MOV DX,PORT[SI] ;GET PORT ADDRESS AGAIN, OUT DX,AL ;WRITE THE LOW BYTE, INC DX ;SKIP TO NEXT ONE, MOV AL,AH ;GET HIGH BYTE INTO AL OUT DX,AL ;OUTPUT IT AS WELL. ADD DX,LCTRL-BAUD1 ;POINT AT THE LINE CONTROL REG. IN AL,DX ;READ IT IN, AND AL,NOT 080H ;CLEAR THE DLAB BIT. OUT DX,AL ;OUTPUT IT BACK. MOV AX,0 ;RETURN NO ERROR JMP EXIT SUBTTL RING BUFFER ROUTINES PAGE ; LOCAL ROUTINES FOR MANAGING THE RING BUFFERS ON INPUT ; AND OUTPUT. THE FOLLOWING FOUR ROUTINES ARE ALL CALLED WITH THE ; SAME CONTEXT: ; ; DS:SI POINTS TO THE UNIT STRUCTURE FOR THIS UNIT ; AL IS THE CHARACTER TO BE PLACED IN OR REMOVED FROM A BUFFER ; AH IS THE RETURN STATUS FLAG: 0=SUCESS, -1=FAILURE ; ; ALL OTHER REGESTERS ARE PRESERVED. ; PUT_OUT PROC NEAR ;PUTS AL INTO THE OUTPUT RING BUFFER PUSHF CLI ;DISABLE INTERUPTS WHILE I HAVE OAVAIL PUSH CX PUSH DI MOV CX,OAVAIL[SI] ;GET POINTER TO NEXT AVAILABLE BYTE IN MOV DI,CX ;OUTPUT BUFFER. INC CX ;INCRIMENT A COPY OF IT TO SEE IF THE AND CX,BUFMSK ;BUFFER IS FULL. CMP CX,OFIRST[SI] ;IS IT? JE POERR ;YES, RETURN AN ERROR ADD DI,OBUF[SI] ;NO, CALCULATE ACTUAL OFFSET OF CHAR MOV [DI],AL ;AND STUFF THE CHARACTER INTO BUFFER MOV OAVAIL[SI],CX ;UPDATE THE POINTER MOV AH,0 ;INDICATE SUCCESS JMP PORET ;AND RETURN POERR: MOV AH,-1 ;INDICATE FAILURE. PORET: POP DI POP CX POPF ;RE-ENABLE INTERUPTS RET PUT_OUT ENDP GET_OUT PROC NEAR ;GETS THE NEXT CHARACTER FROM OUTPUT RING BUFFER PUSHF ;JUST IN CASE, DISABLE INTERUPTS CLI ;WHILE IN THIS ROUTINE. ;SURE YOU DISABLE INTERUPTS FIRST. PUSH CX PUSH DI MOV DI,OFIRST[SI] ;GET POINTER TO FIRST CHARACTER TO OUTPUT CMP DI,OAVAIL[SI] ;IS THE BUFFER EMPTY? JNE NGOERR ;NO. MOV AH,-1 ;YES, INDICATE FAILURE JMP GORET ;AND RETURN NGOERR: MOV CX,DI ;SAVE A COPY OF THE POINTER ADD DI,OBUF[SI] ;CALCULATE ACTUAL ADDRESS MOV AL,[DI] ;GET THE CHAR INTO AL MOV AH,0 ;INDICATE SUCCESS. INC CX ;INCRIMENT THE OFFSET AND CX,BUFMSK ;MODULO 128 MOV OFIRST[SI],CX ;STORE BACK IN UNIT TABLE. GORET: POP DI POP CX POPF RET GET_OUT ENDP PUT_IN PROC NEAR ;PUT THE CHAR FROM AL INTO INPUT RING BUFFER PUSHF ;DISABLE INTS WHILE IN THIS ROUTINE CLI PUSH CX PUSH DI MOV DI,IAVAIL[SI] ;GET POINTER TO NEXT AVAILABLE SLOT IN BUFFER MOV CX,DI ;SAVE A COPY OF IT, INC CX ;AND INCRIMENT THAT COPY (MODULO AND CX,BUFMSK ;128) TO SEE IF THE BUFFER IS FULL. CMP CX,IFIRST[SI] ;WELL, IS IT? JNE NPIERR ;NO, THERE`S ROOM. MOV AH,-1 ;YES, INDICATE FAILURE JMP PIRET ;AND RETURN NPIERR: ADD DI,IBUF[SI] ;CALCULATE ACTUAL ADDRES, MOV [DI],AL ;STORE THE CHARACTER THERE MOV IAVAIL[SI],CX ;UPDATE THE POINTER. MOV AH,0 ;AND INDICATE SUCCESS. PIRET: POP DI POP CX POPF RET PUT_IN ENDP GET_IN PROC NEAR ;GETS ONE CARACTER FROM INPUT RING BUFFER INTO AL PUSHF CLI ;DISABLE INTERUPTS WHILE I LOOK AT IFIRST. PUSH CX PUSH DI MOV DI,IFIRST[SI] ;GET POINTER TO FIRST CHAR TO READ CMP DI,IAVAIL[SI] ;IS THE BUFFER EMPTY? JE GIERR ;THEN YOU CAN`T VERY WELL SQUEEZE WATER OUT OF IT MOV CX,DI ;MAKE A COPY OF POINTER, ADD DI,IBUF[SI] ;CALCULATE ACTUAL ADDRESS OF CHAR MOV AL,[DI] ;GET THE CHAR INTO AL MOV AH,0 ;INDICATE SUCCESS INC CX ;INCRIMENT THAT COPY OF YOUR POINTER, AND CX,BUFMSK ;MODULO THE BUFFER SIZE, MOV IFIRST[SI],CX ;SO YOU CAN UPDATE THE POINTER. JMP GIRET GIERR: MOV AH,-1 ;RETURN FAILURE INDICATOR GIRET: POP DI POP CX POPF ;RE-ENABLE INTERUPTS BEFORE YOU RETURN RET GET_IN ENDP SUBTTL INPUT FLOW CONTROL CHECKING ROUTINES STOP_IN PROC NEAR ;STOP INPUT IF BUFFER IS GETTING FULL PUSHF CLI PUSH AX PUSH DX MOV AX,IAVAIL[SI] ADD AX,BUFSIZ SUB AX,IFIRST[SI] ;AX IS NOW THE # BYTES USED AND AX,BUFMSK ;PUT IT IN THE RIGHT RANGE CMP AX,ISTOP ;SHOULD WE STOP THE TURKEY? JL S_IN_OK ;AXRESTART POINT DO IT LATER TEST INSPEC[SI],INXON ;IS XON/XOFF ENABLED? JE Q_IN_DTR ;NOPE, TRY DTR MOV DX,PORT[SI] ;GET PORT ADDRESS ADD DX,LSTAT ;POINT TO LSTAT Q_IN_LOP: IN AL,DX ;GET STATUS TEST AL,20H ;HOLDING REG EMPTY? JE Q_IN_LOP ;NOPE, WAIT FOR IT MOV DX,PORT[SI] MOV AL,'Q' AND 1FH OUT DX,AL AND MODEM[SI],NOT MODXON OR LINE[SI],LINEXP Q_IN_DTR: MOV DX,PORT[SI] ADD DX,MCTRL ;POINT TO MODEM CONTROL REG TEST INSPEC[SI],INDTR ;DTR FLOW CONTROL ENABLED? JE Q_IN_RTS ;NOPE, TRY RTS IN AL,DX OR AL,1 ;TURN DTR ON OUT DX,AL Q_IN_RTS: TEST INSPEC[SI],INRTS ;RTS FLOW CONTROL ENABLED? JE Q_IN_OK ;NOPE, WE ARE DONE IN AL,DX OR AL,2 ;TURN RTS ON OUT DX,AL Q_IN_OK: POP AX POP DX POPF RET START_IN ENDP SUBTTL INTERUPT SERVICE ROUTINES PAGE ; THE FOLLOWING ROUTINES ARE WHAT I REALLY CALL AN INTERUPT ; ROUTINE! THESE ROUTINES ARE ONLY CALLED WHEN AN INTERUPT IS GENERATED ; BY THE 8088, NOT BY A SOFWARE CALL THROUGH A LINKED LIST! ONE EASY ; WAY TO TELL A REAL INTERUPT ROUTINE WHEN YOU SEE IT IS TO LOOK AT THE ; LAST INSTRUCTION, WHICH IS AN "INTERUPT RETURN", NOT A FAR RETURN ; LIKE THE SO-CALLED MSDOS "INTERUPT ROUTINE" DOES. ; THESE INTERUPT ROUTINES ARE ENVOKED WHENEVER A CHAR ARRIVES IN THE ; UART, THE UART FINISHES SENDING A CHARACTER OUT, AN ERROR OCCURS ; WHILE READING A CHARACTER INTO THE UART, OR THE MODEM STATUS LINES ; CHANGE. ASY1ISR: CLI PUSH SI LEA SI,ASY_TAB1 ;POINT AT THE CORRECT TABLE FOR THIS UART, JMP INT_SERVE ;JUMP INTO THE COMMON INTERUPT SERVER CODE. ASY2ISR: CLI PUSH SI LEA SI,ASY_TAB2 ;GET UNIT TABLE ; ; IF YOU ADD MORE UNITS, YOU CAN ADD THEM HERE, ; BUT DON'T FORGET TO ADD A JUMP INT_SERVE AFTER ; ASY2ISR'S LEA INSTRUCTION! ; ; THE FOLLOWING CODE IS THE COMMON SHARED CODE THAT ALL THE ; ASYNC PORTS SHARE. IT "KNOWS" WHICH ONE TO TALK TO BY REFERENCING ; THE STRUCTURE POINTED TO BY CS:SI. INT_SERVE: PUSH AX ;PUSH ALL THE GP REGESTERS PUSH BX PUSH CX PUSH DX PUSH DI PUSH DS ;SAVE THE DATA SEGMENT PUSH CS ;SO YOU CAN LOAD CS POP DS ;INTO DS AND FIND YOUR OWN STRUCTURES. INT_EXIT: MOV DX,PORT[SI] ;GET THE PORT ADDRESS OF THIS DEVICE ADD DX,INTID ;SLIDE UP TO THE INTERUPT ID REGISTER IN AL,DX ;GET THE INTERUPT REASON TEST AL,1 ;MAKE SURE IT IS VALID JNE INT_DONE ;IT IS NOT. MOV AH,0 ;CONVERT IT TO A 16 BIT NUMBER ADD AX,OFFSET INT_REASON ;ADD IT TO THE JUMP TABLE ADDRESS MOV DI,AX ;PUT IT IN AN INDEX REGESTER, JMP [DI] ;AND GO PROCESS THAT TYPE OF INTERUPT INT_DONE: ADD DX,LSTAT-INTID ;BECAUSE IT SEEMS TO BE NECESSARY, IN Al,DX ;READ THE STATUS PORT BEFORE YOU EXIT. MOV AL,020H ;OUTPUT A 20H TO THE UNDOCUMENTED INTERUPT OUT 020H,AL ;COMMAND PORT TO ENABLE FURTHER INTERUPTS? POP DS ;RECOVER ALL THE REGESTERS POP DI POP DX POP CX POP BX POP AX POP SI IRET ; ; JUMP TABLE OF INTERUPT REASONS. INTERUPT ID REGISTER ; IS USED AS INDEX TO THIS TABLE. INT_REASON: DW INT_MODEM ;INT WAS CAUSED BY A MODEM LINE TRANSITION DW INT_TXMIT ;INT WAS CAUSED BY A TX REGISTER EMPTY DW INT_RECEIVE ;NEW CHARACTER AVAILABLE IN UART DW INT_RXSTAT ;CHANGE IN RECEIVER STATUS REGESTER SUBTTL RECEIVER INTERUPT SERVICE ROUTINE PAGE ; ; THE INTERUPT SERVICE ROUTINES BELOW ALL HAVE THE ; FOLLOWING CONTEXT: ; -CS AND DS POINT TO THE DRIVER SEGMENT. ; -DS:[SI] POINTS TO THE UNIT STRUCTURE FOR THE ASYNC LINE THAT ; FIRED THE INTERUPT. ; -AX BX CX DX AND DI ARE AVAILABLE FOR SCRATCH. ALL OTHERS ; MUST BE LEFT ALONE OR SAVED AND RECOVERED. ; TO EXIT FROM AN INTERUPT SERVICE ROUTINE, THESE SERVERS MUST ; JUMP TO INT_EXIT. ; SUBTTL RECEIVER INTERUPT SERVICE ROUTINE INT_RECEIVE: ;THE UART HAS RECEIVED A NEW CHARACTER, I MUST COPY IT ;INTO THE INPUT TYPEAHEAD BUFFER. MOV DX,PORT[SI] ;POINT DX BACK AT THE RXBUF REGESTER IN AL,DX ;GET THE CHARACTER ; ; BEFORE I STORE THE CHARACTER BACK IN THE RING ; BUFFER, I CHECK TO SEE IF ANY OF THE SPECIAL ; INPUT SEQUENCES ARE ENABLED, AND IF THEY ; HAVE BEEN FOUND IN THE INPUT. ; ; ; CHECK FOR XON/XOFF ; TEST OUTSPEC[SI],OUTXON ;IS XON/XOFF ENABLED? JE NOXON ;NO, SKIP THIS WHOLE SECTION CMP AL,'S' AND 01FH ;IS THIS A CONTROL-S? JNE ISQ ;NO, CHECK FOR CONTROL-Q OR LINE[SI],LINXOF ;DISABLE OUTPUT. JMP INT_EXIT ;DON'T STORE THIS CHAR. ISQ: CMP AL,'Q' AND 01FH ;IS THIS A CONTROL-Q? JNE NOXON ;NO, SKIP TO THE NEXT TEST. TEST LINE[SI],LINXOF ;AM I WAITING FOR THIS ^Q? JE INT_EXIT ;NO, DON'T STIR UP DRIVER. AND LINE[SI],NOT LINXOF ;CLEAR THE XOFF BIT, CALL START_OUTPUT JMP INT_EXIT ;DON'T BUFFER ^Q'S NOXON: STUFF_IN: CALL PUT_IN ;PUT THE CHARACTER IN THE RING BUFFER CMP AH,0 ;WAS THERE ROOM? JE INT_RX_CHK OR MODEM[SI],MODOVR ;NO, SET THE OVERFLOW BIT INT_RX_CHK: CALL STOP_IN ;STOP RX IF GETTING FULL JMP INT_EXIT SUBTTL RECEIVER LINE STATUS INTERUPT ROUTINE PAGE ; THE LSTAT REGISTER DETECTED A RECEIVER ERROR CONDITION INT_RXSTAT: ADD DX,LSTAT-INTID ;READ THE REGESTER AND FIND OUT WHY IN AL,DX TEST INSPEC[SI],INEPC ;DO I RETURN THEM AS CODES? JE NOCODE ;NO, WHAT ELSE? AND AL,01EH ;YES, MASK OFF ALL BUT ERROR BITS, OR AL,080H ;SET THE PARITY BIT TO MAKE IT ;AN ILLEGAL CHARACTER, JMP STUFF_IN ;AND PUT IT IN THE INPUT BUFFER. NOCODE: OR MODEM[SI],MODERR ;SET A STATUS BIT THAT WILL ;NOTIFY MSDOS ON THE NEXT REQUEST JMP INT_EXIT PAGE SUBTTL MODEM STATUS INTERUPT SERVICE ROUTINE ; THE MODEM STATUS REGESTER DETECTED A CHANGE IN ONE OF THE ; MODEM LINES. I COULD CHECK THE "DELTA BITS" TO SEE EXACTLY WHICH ; LINE TRIGGERED THIS INTERUPT, BUT I JUST CHECK ALL OF THEM WHEN ; I GET ANY MODEM STATUS INTERUPT. INT_MODEM: ADD DX,MSTAT-INTID ;READ THE MODEM STATUS REGESTER IN AL,DX ;********************************* ;CHECK THE CARIER-DETECT BIT (CD) TEST AL,080H ;IS CARRIER DETECT OFF? JNE MSDSR ;NO, CHECK DSR NEXT TEST OUTSPEC[SI],OUTCDF ;IS CD THE OFF-LINE SIGNAL? JE MSDSR ;NO, IGNORE CD THEN. OR MODEM[SI],MODOFF ;YES,SET OFLINE FOR NEXT READ REQUEST ;************************************** ;CHECK THE DATA-SET-READY BIT (DSR) MSDSR: TEST AL,020H ;IS DSR OFF? JNE DSRON ;NO, GO CHECK TO SEE IF I WAS WAITING ON IT. TEST OUTSPEC[SI],OUTDSR ;IS DSR THE OUTPUT DATA THROTTLE FLG? JE DSROFF ;NO, MABY IT'S OFFLINE SIGNAL OR LINE[SI],LINDSR ;YES, SUSPEND OUTPUT WAITING ON DSR DSROFF: TEST OUTSPEC[SI],OUTDRF ;IS DSR THE OFFLINE SIGNAL? JE MSCTS ;NOPE. OR MODEM[SI],MODOFF ;YES, SET FLAG FOR NEXT READ. JMP MSCTS DSRON: TEST LINE[SI],LINDSR ;WAS I WAITING FOR DSR TO COME ON? JE MSCTS ;NO, IGNORE IT. AND LINE[SI],NOT LINDSR ;YES, CLEAR THE BIT, AND CALL START_OUTPUT ;START OUTPUT BACK UP AGAIN. ;**************************************** ;CHECK THE CLEAR-TO-SEND BIT (CTS) MSCTS: TEST AL,010H ;IS CTS OFF? JNE CTSON ;NO, GO CHECK TO SEE IF ITS EXPECTED TEST OUTSPEC[SI],OUTCTS ;IS CSR THE OUTPUT DATA THROTTLER? JE CTSOFF ;NO, MABY IT'S OFFLINE SIGNAL OR LINE[SI],LINCTS ;YES, SUSPEND OUTPUT. CTSOFF: TEST OUTSPEC[SI],OUTCTS ;IS CTS THE OFF-LINE SIGNAL? JE INT_EXIT4 ;NOPE. OR MODEM[SI],MODOFF ;YES, SET FLAG FOR NEXT READ. JMP INT_EXIT CTSON: TEST LINE[SI],LINCTS ;WAS I WAITING FOR THIS CTS? JE INT_EXIT4 ;NO, THERE'S NOTHING LEFT TO CHECK. AND LINE[SI],NOT LINCTS ;YES, CLEAR THE BIT, AND CALL START_OUTPUT ;START OUTPUT UP AGAIN. INT_EXIT4: JMP INT_EXIT SUBTTL TRANSMITTER INTERUPT SERVICE ROUTINE PAGE ; THE TRANSMITTER HOLDING REGESTER IS EMPTY, LOOK TO SEE IF INT_TXMIT: ;THERE ARE MORE CHARS TO PRINT NOW. AND LINE[SI],NOT LINEXP ;CLEAR INTERUPT EXPECTED BIT. CALL START_OUTPUT ;START THE NEXT CHARACTER JMP INT_EXIT ;ROUTINE TO START THE NEXT CHARACTER PRINTING ON THE UART, IF OUTPUT ;IS NOT BEING SUSPENDED FOR ONE REASON OR ANOTHER. ;THIS ROUTINE MAY BE CALLED FROM REQUEST ROUTINES, OR FROM INTERUPT ;SEVICE ROUTINES. ; THIS ROUTINE DESTROYS AX AND DX. ; SX MUST POINT AT THE UNIT STRUCTURE. START_OUTPUT PROC NEAR PUSHF ;SAVE THE FLAGS SO I CAN CLI ;DISABLE INTERUPTS TEST LINE[SI],LINIDL ;AM I IN HOLD OUTPUT MODE? JNE DONT_START ;YES, DON'T SEND ANY MORE CHARS. ; MOV DX,PORT[SI] ;CHECK HOLDING REG STATUS ; ADD DX,LSTAT ; IN AL,DX ; TEST AL,20H ;IS IT EMPTY? ; JE DONT_START ;NOPE, TRY NEXT TIME CALL GET_OUT ;CHECK TO SEE IF THERE IS A CHAR IN THE BUF CMP AH,0 ;WELL, WAS THERE? JNE DONT_START ;NO, BUFFER IS EMPTY MOV DX,PORT[SI] ;YES, POINT DX AT THE TX OUT REGISTER OUT DX,AL ;SEND HIM THE CHARACTER OR LINE[SI],LINEXP ;WARN EVERYBODY THAT I'M BUSY. DONT_START: POPF RET START_OUTPUT ENDP ; THE FOLLOWING LABEL DEFINES THE END OF THE DRIVER, SO I ; CAN TELL DOS HOW BIG I AM. ASYNC_END: SUBTTL INITIALIZATION REQUEST ROUTINE PAGE ; ; THE INITIALIZE DRIVER ROUTINE IS STORED AFTER THE "END" ; OF THE DRIVER HERE SO THAT THIS CODE CAN BE THROWN AWAY AFTER ; THE DEVICE HAS BEEN INITIALIZED. THIS CODE IS ONLY CALLED TWICE: ; ONCE TO INITIALIZE EACH OF THE ASYNC UNITS THAT THIS DRIVER ; CONTAINS. (HOPEFULLY, MSDOS DOESN'T WRITE ANYTHING ON TOP OF ; THIS CODE UNIT BOTH UNITS ARE INITIALIZED. ; THE CONTEXT OF THE INITIALIZE CODE BELOW IS THE SAME AS ; ALL THE OTHER REQUEST ROUTINES EARLIER IN THE DRIVER. ; ; INITIALIZE THE DRIVER AND DEVICE ; ASYNC_INIT: MOV AX,OFFSET ASYNC_END ;GET THE SIZE OF THE DRIVER MOV ES:XFER[BX],AX ;SEND THAT BACK IN PACKET MOV ES:XSEG[BX],CS ;SEND THE CODE SEGMENT ALSO. ;I HAVE SATISFIED ALL THE REQIREMENTS OF THE ;INIT FUNCTION TO RETURN IN THE I/O PACKET, SO ;I CAN DESTROY THE CONTENTS OF ES:BX AND USE ;THEM FOR OTHER THINGS. MOV AX,0 ;POINT ES AT THE VECTOR SEGMENT MOV ES,AX ;SO CAN INITIALIZE THE VECTORS MOV AX,ISRADR[SI] ;GET ADRS OF INTERUPT SERVICE ROUTINE ;THE FOLLOWING CODE IS SPECIFIC TO THE IBM: ;BASIC USES LOCATIONS 400 AND 402 TO FIND ;THE PORT ADDRESSES OF COM1 AND COM2. IF I ;ZERO THESE, THEN BASIC CANNOT MUCK UP THE ;REGESTERS ON ME ANY MORE! (IT STILL ;DISABLES INTERUPTS, THOUGH. BUMMER!) MOV DI,400 ;POINT AT THE ASYNC ADDRESS LIST CLD STOS WORD PTR [DI] ;CLOBBER THE FIRST ONE, STOS WORD PTR [DI] ;AND THE SECOND ONE. ;NOW WE'RE BACK ON THE GENERIC MSDOS TRACK. MOV DI,VECT[SI] ;GET ADRS OF VECOTR, STOS WORD PTR [DI] ;STORE THE OFFSET THERE, THEN MOV ES:[DI],CS ;THE SEGMENT IN THE FOLLOWING WORD. MOV CX,DI ;GET THE VECTOR NUMBER, SUB CL,022H ;SUBTRACT BIAS TO HARDWARE INTS, SAR CL,1 ;DIVIDE BY 4 TO CONVERT TO SAR CL,1 ;HARDWARE INTERUPT NUMBER. MOV AH,1 ;SHIFT A MASK BY THAT MUCH TO SAL AH,CL ;CREATE INTERUPT ENABLE MASK BIT, NOT AH ;WHICH IS ACTIVE LOW... IN AL,021H ;GET SYSTEM HARDWARE INTERUPT MASK AND AL,AH ;AND MY BIT OUT OF IT, OUT 021H,AL ;WRITE IT BACK OUT AGAIN. MOV DX,PORT[SI] ;GET THE PORT ADDRESS OF THIS LINE ADD DX,INTID INT_CAN: IN AL,DX ;GET INTERUPT ID REGESTER TEST AL,1 ;IF HE HAS ANYTHING TO COMPLAINE JNZ INT_NONE ;ABOUT, READ THEM ALL AND IGNORE. ADD DX,LSTAT-INTID ;JUST TO MAKE UART HAPPY, READ THE IN AL,DX ;LINE STATUS AND ADD DX,MSTAT-LSTAT ;THE MODEM STATUS TO IN AL,DX ;"RESET INTERUPT CONTROL" ADD DX,RXBUF-MSTAT ;READING THE RECEIVER MIGHT IN AL,DX ;HELP ALSO. ADD DX,INTID-RXBUF ;POINT BACK AT INTERUPT ID, JMP INT_CAN ;AND DO THIS AGAIN. INT_NONE: ADD DX,LSTAT-INTID ;CALC ADDRESS OF LINE STATUS, IN AL,DX ;INPUT IT OR SOMETIMES IT DOESN'T WORK ADD DX,LCTRL-LSTAT ;CALC ADDRESS OF LINE CONTROL REG MOV AL,LINE[SI] ;GET THE DEFAULT LINE OR AL,DLAB ;SET THE DIVISOR LATCH BIT OUT DX,AL ;SET UP DEFAULT LINE CHARS SUB DX,LCTRL ;POINT BACK AT FIRST PORT MOV AX,BAUD[SI] ;GET DIVISOR VALUE FOR BAUD RATE OUT DX,AL ;SEND LOW BYTE INC DX ;INC TO HIGH BYTE PORT MOV AL,AH ;GET HIGH BYTE, OUT DX,AL ;AND SEND TO BOARD. ADD DX,LCTRL-1 ;POINT AT LINE CONTROL AGAIN, MOV AL,LINE[SI] ;GET DEFAULT LINE CONTROL BITS AGAIN OUT DX,AL ;SET THEM WITHOUT DLAB ON. MOV LINE[SI],0 ;RE-USE LINE OFFSET AS STATUS SUB DX,LCTRL-INTEN ;POINT DX AT INTERUPT ENABLE PORT MOV AL,ALLINT ;SET UP TO GET ALL POSSIBLE INTS OUT DX,AL ;IN THE INTEN REGESTER. ADD DX,MCTRL-INTEN ;POINT AT MODEM STATUS REGESTER MOV AL,MODEM[SI] ;GET THE DEFAULT MODEM STATUS BITS, OUT DX,AL ;AND SET THEM IN MCTRL. MOV MODEM[SI],0 ;RE-USE THIS BYTE FOR INPUT STATUS. TEST INSPEC[SI],INXON ;IS INPUT THROTTLED WITH XON? JE DONE_INIT ;NO, LEAVE HIM BE. MOV AL,'Q' AND 01FH ;YES, SEND A CONTROL-Q MOV DX,PORT[SI] ;TO THE DEVICE AT INIT TIME, OUT DX,AL ;TO MAKE SURE IT WAKES UP. DONE_INIT: MOV AX,0 ;RETURN NO ERRORS. JMP EXIT DRIVER ENDS END ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040719441400> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sat 9 Apr 88 13:01:37-PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA18978; Sat, 9 Apr 88 10:12:03 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Apr 88 19:44:14 GMT From: mtunx!whuts!homxb!hou2d!n2dsy@rutgers.edu (G.BEATTIE) Organization: AT&T Bell Laboratories, Holmdel Subject: Asynchronous Framing Technique Software: TEST1.C Message-Id: <1975@hou2d.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa /* This is a test program for the AFT system. Version 1.0, by John Howell (N2FVN), Copyright August 7, 1987 This software is free for non-commercial use. All commercial rights are retained by the author or his designees. Commercial use without the explicit written permission of the author is prohibited. This package is provided on an 'as is' basis without warranty. */ #include "stdio.h" main() { char ebdt, c, level, suff_str[10], suff_len; char in_str[256], out_str[256]; int rx_max, in_len, out_len, i, match, tc; printf("AFT Test Program 1\n\n"); printf("Eight-bit data transparency?"); scanf("%1s",&c); ebdt = c == 'y' || c == 'Y'; printf("Transparency level?"); scanf("%d",&level); printf("Suffix?"); get_array(suff_str, &suff_len); printf("Maximum receive length?"); scanf("%d",&rx_max); aft_options(ebdt, level, suff_len, suff_str, rx_max); while (1) { printf("Frame to send?"); get_array(out_str, &out_len); if (out_len == 0) exit(0); aft_tx_start(out_len, out_str); aft_rx_start(in_str); tc = aft_tx_complete(); if (tc) { printf("ERR: Tx CMPL 1\n"); } if (aft_rx_complete()) { printf("ERR: Rx CMPL 1\n"); } do { i = aft_tx_char(); if (tc != (i == 0x017e)) { printf("ERR: Tx CMPL 2\n"); } tc = aft_tx_complete(); if (i != 0x017e) { printf("%4x ",i); in_len = aft_rx_char(i & 0x00ff); if (in_len != aft_rx_complete()) printf("ERR: Rx CMPL 2\n"); if (in_len != 0) printf("RX "); } } while ((i & 0xff00) == 0); printf("TX\n"); if (!aft_tx_complete()) { printf("ERR: Tx CMPL 3\n"); } aft_rx_error(); match = 1; if (in_len != out_len) { printf(" ERR: in_len=%d out_len=%d\n", in_len, out_len); match = 0; } for (i = 0; i < out_len; i++) if (in_str[i] != out_str[i]) match = 0; if (!match) { printf(" ERR: RX mismatch\n"); for (i = 0; i < in_len; i++) printf("%2x ",in_str[i]); printf("\n"); } } } get_array(buffer, len) char *buffer; int *len; { char c; c = getc(stdin); *len = 0; while (1) { c = getc(stdin); ungetc(c, stdin); if (c == '\n') return; if (!scanf("%2x", buffer++)) return; (*len)++; } } ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1976@hou2d.UUCP] <1988040719460700> From: n2dsy@hou2d.UUCP (G.BEATTIE) Newsgroups: comp.protocols.tcp-ip Subject: Asynchronous Framing Technique Software: TEST2.C Message-ID: <1976@hou2d.UUCP> Date: 7 Apr 88 19:46:07 GMT Organization: AT&T Bell Laboratories, Holmdel Lines: 190 Keywords: AFT, a SLIP Alternative - Test and Demo Programme /* This is a test program for the AFT system. Version 1.0, by John Howell (N2FVN), Copyright August 7, 1987 This software is free for non-commercial use. All commercial rights are retained by the author or his designees. Commercial use without the explicit written permission of the author is prohibited. This package is provided on an 'as is' basis without warranty. Send and receive frames. Machine dependant for the PC with async driver installed. Requires Microsoft C 4.0. */ #include "stdio.h" #include "conio.h" #include "dos.h" #include "fcntl.h" #include #include #include "io.h" #include "stdlib.h" int async_handle; main() { char ebdt, c, level, suff_str[10], suff_len; char in_str[256], out_str[256]; int out_busy; int rx_max, in_len, out_len, i, match, tc; printf("AFT Test Program 2\n"); printf("Send and receive frames over COM1: using ASYNC driver.\n"); async_handle = open("ASYNC1", O_RDWR | O_BINARY); if (async_handle == -1) { printf("Open of async driver failed. errno=%d\n", errno); printf("Make sure ASYNC.BIN is included in CONFIG.SYS.\n"); exit(1); } printf("Eight-bit data transparency (y/n)?"); scanf("%1s",&c); ebdt = c == 'y' || c == 'Y'; printf("Transparency level (0-2)?"); scanf("%d",&level); printf("Suffix string (HEX)?"); get_array(suff_str, &suff_len); rx_max = sizeof(in_str) - 2; aft_options(ebdt, level, suff_len, suff_str, rx_max); aft_rx_start(in_str); out_len = 0; out_busy = 0; printf("Enter characters to fill transmit buffer. Return to send.\n"); printf("Enter empty line to exit.\n\n"); while (1) { if (async_char_waiting()) { if (aft_rx_char(async_get_char())) { in_len = aft_rx_complete(); printf("Frame received. Length=%d data:", in_len); for (i=0; i From: karn@THUMPER.BELLCORE.COM (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: alternate source for new 4.3 files Message-ID: <8804071950.AA26872@thumper.bellcore.com> Date: 7 Apr 88 19:50:27 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 I have placed copies of the new 4.3 networking files announced by Mike Karels on flash.bellcore.com (128.96.32.20). They are available by anonymous FTP under /pub/4.3. The latest version of bind (4.8) is also available under /pub as /pub/bind.4.8.tar.Z. Flash also has a complete set of RFCs, IENs and IETF working papers under /pub/rfc, /pub/ien and /pub/ietf. All files are compressed with the unix "compress" program. This will hopefully be of interest to those on the east coast who would like to help unload the cross-country ARPANET links. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1977@hou2d.UUCP] <1988040719504800> From: n2dsy@hou2d.UUCP (G.BEATTIE) Newsgroups: comp.protocols.tcp-ip Subject: Asynchronous Framing Technique Software Message-ID: <1977@hou2d.UUCP> Date: 7 Apr 88 19:50:48 GMT Organization: AT&T Bell Laboratories, Holmdel Lines: 12 Keywords: AFT, a SLIP Alternative The preceeding was brought to you by: The Radio Amateur Telecommunications Society 206 North Vivyen Street Bergenfield, New Jersey 07621 Thanks, J. Gordon Beattie, Jr. E-mail: ihnp4!hou2d!n2dsy (Unix) n2dsy@kd6th.a3100201.ampr Telephone: 201-615-4168 (Office) 201-615-4669 (Office FAX) Telephone: 201-387-8896 (Home) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804072055.AA18356@vax.ftp.com] <1988040720550000> From: jbvb@VAX.FTP.COM (James Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: MIL-STD vs. RFC Message-ID: <8804072055.AA18356@vax.ftp.com> Date: 7 Apr 88 20:55:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 Recently, various people concerned with government RFPs have been asking if my product conformed to the MIL-STDs. I know the original 1983 MIL-STDs for IP and TCP, at least (1777 and 1778) were wrong (as outlined in RFC 963 & 964). I have no information which even hints that they have been, or will be, corrected. I have also been told by authorities whose word I accept "where the RFCs and the MIL-STDs differ, the RFCs are correct". Accordingly, I have been telling these people "We conform to the RFCs, and to the MIL-STDs to the extent that they are correct." However, a case has recently arisen where someone wanted more than just my word on it. I gave them some people's names, and an organization or two. At one of the places they called, the person they spoke to (not someone closely involved in Internet development) told them that they thought the MIL-STDs superceded the RFCs. Is there a document where the primacy of the RFCs is explicitly stated (other than being implied in RFC 1011, "Official Internet Protocols")? Is there an organization which I should direct these questions to? A person at that organization who considers it their business to answer such, and is vested in some sort of formal authority that should be accepted by the questioning parties? I promise to only use it as a last resort... James VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4438@bloom-beacon.MIT.EDU] <1988040721004800> From: steiner@athena.mit.edu (Jennifer Steiner) Newsgroups: comp.unix.wizards,comp.dcom.lans,comp.protocols.tcp-ip Subject: Kerberos documentation Message-ID: <4438@bloom-beacon.MIT.EDU> Date: 7 Apr 88 21:00:48 GMT Sender: daemon@bloom-beacon.MIT.EDU Reply-To: info-kerberos@athena.mit.edu Followup-To: comp.misc Organization: MIT Project Athena, Cambridge MA Lines: 41 Keywords: network security, authentication Documentation on MIT Project Athena's authentication service, Kerberos, is available for anonymous ftp on "athena-dist.mit.edu", in ~ftp/pub/kerberos. Documents include the paper given at the Winter 1988 Usenix Conference (text or postscript), a detailed design document (text or postscript), and manual pages. If you can't ftp, and would like a hardcopy, send your request (and US/PTT mail address) to info-kerberos@athena.mit.edu. We are currently running a beta test of the software. When the beta test has been completed, we plan to put the code in the public domain (except for the encryption library, which probably can't be exported out of the U.S.). I'll post a pointer when the code is available. Please post any followup messages to comp.misc. Jennifer Steiner Project Leader, Kerberos Development MIT Project Athena -------- Below is the abstract from the Usenix paper: In an open network computing environment, a workstation cannot be trusted to identify its users correctly to network services. Kerberos provides an alternative approach whereby a trusted third-party authentication service is used to verify users' identities. This paper gives an overview of the Kerberos authentication model as implemented for MIT's Project Athena. It describes the protocols used by clients, servers, and Kerberos to achieve authentication. It also describes the management and replication of the database required. The views of Kerberos as seen by the user, programmer, and administrator are described. Finally, the role of Kerberos in the larger Athena picture is given, along with a list of applications that presently use Kerberos for user authentication. We describe the addition of Kerberos authentication to the Sun Network File System as a case study for integrating Kerberos with an existing application. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804072110.AA01067@alcuin.mitre.org] <1988040721105300> From: mankin@GATEWAY.MITRE.ORG Newsgroups: comp.protocols.tcp-ip Subject: TCP socket question Message-ID: <8804072110.AA01067@alcuin.mitre.org> Date: 7 Apr 88 21:10:53 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 Hi, Sockets are not really the provider of session service, though they are the interface to the service. And they don't provide a protocol. For sockets to provide a session _protocol_ there would have to be a session protocol data unit to be sent over TCP when establishing and tearing down the TCP connection. But such a protocol is not defined separately in the DoD stack. In some ways, TCP contains its own session protocol, in the SYN and FIN handshakes. It is a bug that 4.2 TCP connections can become ESTABLISHED and receive data when the upper layer process is incapable of receiving the data. However, TCP has a good mechanism for dealing with the situation where its ULP does not consume the incoming data: it indicates a zero window to its TCP peer, which then must cease to send, though it may send a periodic probe to see if the window has opened. A TCP which has been given this zero window needs some way to throttle the process sending over it. In UNIX, once the send queue gets filled with the data that can't be sent, the system blocks further writes. There is no crash. In your case, it looks like the Client sends an 11 byte message that needs a reply from the Server, so the Client waits without being blocked. The Recv-Q and Send-Q entries are in bytes. The high-water mark is an amount queued that determines when to indicate a zero window (receiving) or block the write (sending). The high-water mark is some multiple of 1024, often 4096, depending on your version. In 4.3 it is user-settable. The file descriptor limit which caused your situation is an implementation matter, nothing to do with the protocol definitions. In 4.3, the fd limit went up to 100. Even in 4.2-based systems, one server can establish more than 26 simultaneous connections by handing off the active sockets to children, then closing its own copies of the file descriptors. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]Thu,.7.Apr.88.14:44:53.PDT.STJOHNS] <1988040721440000> From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: MIL-STD vs. RFC Message-ID: <[SRI-NIC.ARPA]Thu,.7.Apr.88.14:44:53.PDT.STJOHNS> Date: 7 Apr 88 21:44:00 GMT References: <8804072055.AA18356@vax.ftp.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 22 I tell you three times: "where the MIL-STDS and RFC's disagree, the RFCs are correct". The point of contact for standards matters is Kevin Ebel, Ebel@DCA-EMS.ARPA, tell him I sent you *grin*. Seriously though - officially, the MIL-STDs superceded the RFCs, however we (DCA and DCEC) are aware that the MIL-STDs have some problems. (Like IP not being able to deliver data to its ULP, or was it TCP? *grin*). Our guidance has been to take the average of the RFCs and the MIL-STDs... sort of... Mike (Umm, if you get guidance that is different than the above, I would appreciate hearing details on who said it so I can either get them or me straightened out. ) I guess I ought to make it official: Mike StJohns, Capt, USAF, DDN Program, Defense Communication Agency ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804072159.AA25933@tsunami.West.Sun.COM] <1988040721593100> From: efb@nswed5.UUCP Newsgroups: comp.protocols.tcp-ip Subject: BSD PING kills Mot/CMC card or code (Sys V.2) Message-ID: <8804072159.AA25933@tsunami.West.Sun.COM> Date: 7 Apr 88 21:59:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 We are using Motorola SYS-1131 (VME Bus) MC68020 host running Mot/AT&T V68 / SysV 5.2.2 ( not going 5.3 for 30-90 days, problem may still be there ). We use the tcp-ip suite from CMC (2.1.5) telnet, ftp, rlogin, rsh on the CMC enp-10 card ( believe onboard IP ) which DIES with the daemon's still running, IMMEDIATELY, upon sending the PING packets from my BSD Sun OS 3.3 (4.2). I have muted ping and hasten to think what will jump up next to hurt me. Any tips / fixes will be well received. [ To the '*you* should be running version xx of ' set, we are tax funded operation and take anything we can get in whatever year Congress allows us ( if ever ) to buy it.] We have inbound ARPA Mail - ONLY. Everett F. Batey II } {UUCP: sun!tsunami!nswed5!efb USNSWSES - Code 4V33 } {ARPA: efbatey@NOBBS.UCSB.EDU Blg 1214 } { efbatey@[26.17.0.46] After HOSTS.TXT.726 efbatey@NSWSES.ARPA Port Hueneme,CA 93043-5007 } {DDD: 805/982-5881 983-1220(ans) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804072314.AA18069@Larry.McRCIM.McGill.EDU] <1988040723140200> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) Newsgroups: comp.protocols.tcp-ip Subject: Fibre local loops (was: Rumors about the... ) Message-ID: <8804072314.AA18069@Larry.McRCIM.McGill.EDU> Date: 7 Apr 88 23:14:02 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 Who do you know who has a 56k trunk in his home now? I was talking about backbone connectivity (where the fiber is already laid), not local loop. Actually, BOCs are starting to offer it for about $200/mo, plus mileage or message unit charges. If you know some tricks (like how to take out an echo-supressor over a digital loop), you can get local digital service fairly inexpensively. By the way, at least some local phone companies are providing local loop fiber now. They figure it is more cost effective, considering growth and weather resistance. I assume we are talking about business and not residential here. A lot of universities that have their own digital switches (MIT has a 5ESS and McGill has a SL-1) have fibre loops at DS-1 or DS-3 rates. -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804080401.AA28931@okeeffe.Berkeley.EDU] <1988040804010200> From: karels@OKEEFFE.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: release of updated network sources for 4.3BSD Message-ID: <8804080401.AA28931@okeeffe.Berkeley.EDU> Date: 8 Apr 88 04:01:02 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 How embarassing! You're quite right about the byte-order problem in ip_output when fragmenting, and your fix is exactly right. Curiously, I tested that between machines with two byte orders, but my home machine now uses network byte order. I guess I should go back to vaxen. The inet.tar files on ucbarpa have been updated with the fix this evening. (And yes, I tested it *both* ways this time.) Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040805300000> Received: from CORNELLC.CCS.CORNELL.EDU by SRI-NIC.ARPA with TCP; Fri 8 Apr 88 10:31:56-PDT Received: from ANLVM.BITNET by CORNELLC.CCS.CORNELL.EDU ; Fri, 08 Apr 88 13:32:35 EDT Date: 8 Apr 88 10:30 CDT From: B32357%ANLVM.BITNET@CORNELLC.CCS.CORNELL.EDU To: TCP-IP @ SRI-NIC.ARPA Subject: BITNET mail follows Date: 8 April 1988, 10:30:27 CDT From: Linda Winkler 312-972-7236 B32357 at ANLVM Argonne National Laboratory Building 221 B-236 9700 S. Cass Ave. Argonne, IL 60439 To: TCP-IP at SRI-NIC.ARPA How does one disable IP forwarding? I have a complex network where a lot of hosts are sending UDP packets which other hosts (non-gateways) relay to their default gateways. Does anyone know where I can good write-up on routed? LINDA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804080748.AA03157@hop.toad.com] <1988040807485400> From: gnu@hoptoad.UUCP (John Gilmore) Newsgroups: comp.protocols.tcp-ip Subject: Shortest domain address in the world? Message-ID: <8804080748.AA03157@hop.toad.com> Date: 8 Apr 88 07:48:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 It seems to me that you (Johan Vromans) may have the shortest fully qualified domain address in the world -- 8 characters: jv@mh.nl Do you know of anyone with a shorter address? John Gilmore ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040810044800> Received: from cc7.bbn.com by SRI-NIC.ARPA with TCP; Fri 8 Apr 88 11:24:52-PDT Date: Fri, 8 Apr 88 14:04:48 EDT From: "Alan R. Hill" Subject: Re: IP/X.25 Call User Data ... In-Reply-To: Your message of 5 Apr 88 17:50:55 GMT To: hpda!hpcupt1!hpcuhb!hpindda!dwall@ucbvax.berkeley.edu Cc: tcp-ip@sri-nic.arpa The field you are discussing is the protocol ID field and should be set to the appropriate value for the protocol you intend to utilize. The BBN PSNs currently support 0xCC for DDN Standard Service (Interoperable) and 0xCD for ISO. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1988.04.08.09.30.50.milazzo.23799@titan.rice.edu] <1988040814305000> From: milazzo@RICE.EDU (Paul Milazzo) Newsgroups: comp.protocols.tcp-ip Subject: Re: The case for SLIP CRCs Message-ID: <1988.04.08.09.30.50.milazzo.23799@titan.rice.edu> Date: 8 Apr 88 14:30:50 GMT References: <2735@pdn.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 Larry Swift asks: "Are you talking about checksums or CRC's? They're not the same." I'm not sure to which mention you refer, but I'll try to clear up any ambiguities. My original message discussed four distinct data integrity tests, in the following order: 1) I used the phrase "link-level checking" to mean any data integrity test applied at the Data Link layer. 2) I used the phrase "UDP checksumming" to mean the IP header checksum algorithm as applied to UDP datagrams, with 0 meaning "no checksum". 3) I used the phrase "IP checksum algorithm" to mean the checksum algorithm described on p. 14 of RFC 791, applied to IP headers and TCP segments. 4) Finally, I used the phrase "link-level CRC" to mean any of the class of polynomial error-detecting codes known as Cyclic Redundancy Codes, applied at the Data Link layer. Previous messages dismissed the need for Data Link layer integrity tests with the argument that the existing TCP and UDP checksums provide an end-to-end integrity test, and that with such a test, hop-by-hop tests are unnecessary. The point of my message was to question RFC 791's description of the effectiveness of the IP header checksum algorithm: "experimental evidence indicates it is adequate". MY experimental evidence indicates otherwise. I hope these clarifications answer your question. Paul G. Milazzo Dept. of Computer Science Rice University, Houston, TX ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1157@ttds.UUCP] <1988040814441100> From: rajaei@ttds.UUCP (Hassan Rajaei) Newsgroups: comp.protocols.tcp-ip Subject: Re: OSI does not mean X.25 Message-ID: <1157@ttds.UUCP> Date: 8 Apr 88 14:44:11 GMT References: <76.008873@adam.DG.COM> Reply-To: rajaei@ttds.UUCP (Hassan Rajaei) Organization: The Royal Inst. of Techn., Stockholm Lines: 36 In article <76.008873@adam.DG.COM> writes: > >Evidently there are still people who see "OSI" and hear "X.25" and >"connections". ** THIS IS NOT A VALID ASSUMPTION! ** > >You can have OSI with a Transport protocol similar to TCP (ISO 8073) >and a connectionless internetwork protocol (ISO 8473) even more similar >to IP. You do not have to have X.25. You do not have to have PTTs. >You do not have to have network connections. There is NO part of OSI I am really glad you mentioned this. There has been a confusion between OSI model and X.25 protocol for a long time just because X.25 was the only available implementation of OSI. The OSI model is so general that you may do any thing with it (except the overhead!). If there is not an standard protocol available for your need within the model, that doesn't mean the model itself is incapabel of doing that. In spite of many standard protocols available for OSI at present time, I believe we need many new ones in future even for the low layers like physical, link and network. The existing standars for low layers are incapable of handling the ultra super speed networks of the future (FDDI can handle just 150 Mbps). The same is true with X.25 and its IP X.75 which are not only limited by speed but rather make the network very vulnerable because of their connection- oriented behaviour throughout the network (internetworks). As Lyman Chapin said the limitation is not in the model but in the protocols. There is much to be done for OSI model to be accepted (or rejected!) world wide, both with new standard protocols and implementations. Hassan Rajaei The Royal Inst. of Technology Stockholm Sweden rajaei@tds.kth.se ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804090447.AA06537@ucbvax.Berkeley.EDU] <1988040815300000> From: B32357@ANLVM.BITNET Newsgroups: comp.protocols.tcp-ip Subject: BITNET mail follows Message-ID: <8804090447.AA06537@ucbvax.Berkeley.EDU> Date: 8 Apr 88 15:30:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 Date: 8 April 1988, 10:30:27 CDT From: Linda Winkler 312-972-7236 B32357 at ANLVM Argonne National Laboratory Building 221 B-236 9700 S. Cass Ave. Argonne, IL 60439 To: TCP-IP at SRI-NIC.ARPA How does one disable IP forwarding? I have a complex network where a lot of hosts are sending UDP packets which other hosts (non-gateways) relay to their default gateways. Does anyone know where I can good write-up on routed? LINDA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [171500011@uxc.cso.uiuc.edu] <1988040817580000> From: sandrock@uxc.cso.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: Checksums, CRC's, and NFS Message-ID: <171500011@uxc.cso.uiuc.edu> Date: 8 Apr 88 17:58:00 GMT References: <1108@infinet.UUCP> Lines: 10 Nf-ID: #R:infinet.UUCP:1108:uxc.cso.uiuc.edu:171500011:000:539 Nf-From: uxc.cso.uiuc.edu!sandrock Apr 8 11:58:00 1988 RMS (Record Management Services) on VMS does a CRC on the entire file both before and after it is transfered. We found this out the hard way when we had a flakey UNIBUS adapter in our VAX/780 which caused most large DECnet file transfers out our DEUNA to fail with the message that the DAP level CRC check had failed. (DAP = Data Access Protocol). Would have had a lot of bad data around without this check, since the network itself was operating correctly and no other errors were ever reported. Mark Sandrock, (sandrock@b.scs.uiuc.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804090505.AA06908@ucbvax.Berkeley.EDU] <1988040818044800> From: ahill@CC7.BBN.COM ("Alan R. Hill") Newsgroups: comp.protocols.tcp-ip Subject: Re: IP/X.25 Call User Data ... Message-ID: <8804090505.AA06908@ucbvax.Berkeley.EDU> Date: 8 Apr 88 18:04:48 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 The field you are discussing is the protocol ID field and should be set to the appropriate value for the protocol you intend to utilize. The BBN PSNs currently support 0xCC for DDN Standard Service (Interoperable) and 0xCD for ISO. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804090658.AA08980@ucbvax.Berkeley.EDU] <1988040818110600> From: murayama@CS.UCL.AC.UK (Yuko Murayama, 387-7050 ext.3695) Newsgroups: comp.protocols.tcp-ip Subject: a question on the IEEE802.1 Part B Message-ID: <8804090658.AA08980@ucbvax.Berkeley.EDU> Date: 8 Apr 88 18:11:06 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 I have looked at Draft M of the IEEE Systems Management standard (Jan.87) and wonder if there is any standard scheme for coding the ManufacturerID which is described as "a string of not more than 3 octets that identifies the manufacturer". Yuko Murayama ----MESSAGE-END---- ----MESSAGE-BEGIN---- [351@tandem.UUCP] <1988040820333700> From: narayan@tandem.UUCP (Narayan Mohanram) Newsgroups: comp.protocols.tcp-ip Subject: Out of Band data in 4.3 Message-ID: <351@tandem.UUCP> Date: 8 Apr 88 20:33:37 GMT Organization: Tandem Computers, Cupertino,CA-development Lines: 13 In tcpinput, I noticed that there was support for SO_OOBINLINE. But it has not been carried through to tcp_usrreq (). The case PRU_RCVOOB, needs to create mbufs, and chain them on to the original mbuf chain (m_copy) up to so_oobmark. This will cause soreceive to do the right thing when it is doing an soreceive MSG_OOB. This fix does not seem to exist even in the new 4.3 updates recently posted THE SUPREME DALEK from SCAROS ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988040820510600> Received: from Cs.Ucl.AC.UK ([128.41.9.6]) by SRI-NIC.ARPA with TCP; Fri 8 Apr 88 11:16:04-PDT Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK via Ethernet with SMTP id aa02932; 8 Apr 88 19:09 BST To: tcp-ip@sri-nic.arpa cc: murayama@Cs.Ucl.AC.UK Subject: a question on the IEEE802.1 Part B Date: Fri, 08 Apr 88 19:11:06 +0100 From: Yuko Murayama (387-7050 ext.3695) I have looked at Draft M of the IEEE Systems Management standard (Jan.87) and wonder if there is any standard scheme for coding the ManufacturerID which is described as "a string of not more than 3 octets that identifies the manufacturer". Yuko Murayama ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804090154.AA02724@ucbvax.Berkeley.EDU] <1988040902085600> From: droms@BKNLVMS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: Summary of responses to "NFS over the Internet" Message-ID: <8804090154.AA02724@ucbvax.Berkeley.EDU> Date: 9 Apr 88 02:08:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 113 X-Unparsable-Date: Thu, 7 Apr 1988 13:42:47.85 EDT I received enough requests for a summary of repsonses to my earlier posting to warrant posting the summary to the net. As Barry Shein suggests, "the concept is not nearly as wild as [it might seem]". - Ralph Droms Computer Science Department Bucknell University droms@bknlvms.bitnet ----- From: edu%"bhoward@sol.engin.umich.edu" 31-MAR-1988 13:46 at one point, i mounted hoser.berkeley.edu:/usr/src or /usr/src/X (not certain anymore which) from sol.engin.umich.edu this was last summer and throughput was low, but it worked. i don't recall doing anything special, simply did a mount hoser:directory /n/hoser/directory bruce ----- From: EDU%"bzs%bu-cs.bu.edu@buita.BU.EDU" 1-APR-1988 04:48 As far as NFS over a serial line I tried it one evening over our 9.6Kb Cypress line between BU and UCB. It really wasn't bad, NFS is not a particularly high overhead protocol, the info being exchanged is fairly similar to what gets exchanged in an FTP session (DIR,GET,PUT etc.) Of course this disregards transmission problems which I didn't seem to have that evening, the question was thruput. It's probably an intuitive confusion that because NFS is so useful and neat that it must therefore demand massive bandwidth (or perhaps people are mixing the thought with ND, the diskless protocol?) Doubtless you'd want your binaries local but as a very easy to use "ftp" (eg. snooping around directories, copying stuff, file management) it's really not bad on a relatively slow line in my experience, perhaps a little slower than FTP but being able to use the native OS interface to the remote file system can make it worthwhile. Note that there are various timeout parameters etc that would need to be tuned (can be set on a per mount basis) for smooth performance, but the concept is not nearly as wild as seems to be presented here. -Barry Shein, Boston University ----- From: EDU%"pdb@SEI.CMU.EDU" 1-APR-1988 12:29 I've done it. (I only lose on one qualification - I had it running between two LANs, and the traffic had to cross the ARPANET to get between them. But I administer both those LANs.) --Pat. ----- From: edu%"hedrick@aramis.rutgers.edu" 1-APR-1988 17:19 We run NFS between departments all the time. In different buildings through 2 gateways. We also know people who have mounted our disks across the Arpanet, but this was done just as a hack, for a few minutes. Note that when we do it between our departments, we require that all the departments involved coordinate their uid allocation, since otherwise there are security problems. ----- From: NET%"roy%phri@uunet.UU.NET" 2-APR-1988 11:56 I remember reading a while ago that Rob Liebschutz (liebschutz@ig.com and/or liebschutz@bionet-20.arpa) and Mel Pleasant (pleasant@rutgers.edu) had tried remote mounting an NFS file system at Intelligenetics in California from Rutgers in New Jersey over the Internet. Supposedly they had no problems. You might try asking Rob or Mel for more details. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 ----- From: EDU%"sy.Ken@CU20B.COLUMBIA.EDU" 30-MAR-1988 11:38 We use NFS disk mounts between here and another machine (the exact whereabouts I can't tell you, but it's not on this campus), separated by a T1 circuit. Seems to work quite well, although is, of course, a bit slower than you would get off the direct ether. As for disjoint administrations, we are Columbia University, and the disks we mount belong to the NYSER Network Information machine. /Ken ------- From: EDU%"sy.Ken@CU20B.COLUMBIA.EDU" 30-MAR-1988 16:32 OK, well, that's not us, I guess... however, the technical (mechanical) aspects of such a hookup work well. The NYSER disks look like real local disks to us, and even with the distance separating us, we get pretty decent response time. Can't say anything about administrative aspects concerning common roots and all that, though... /Ken ------- From: GOV%"cpw%sneezy@LANL.GOV" 30-MAR-1988 19:57 As a lark, I mounted an NFS filesystem in La Jolla, CA. The linkage was: [Client]-ethernet (Los Alamos, NM) | IP router -- ethernet | IP router -- 19.2 serial line -- IP router | ethernet - [File Server] (La Jolla, CA) By the way, one could consider this a security breach. In fact one did, after I told them about it. This is a pet gripe of mine: Sun ships their systems WIDE OPEN, and its up to the user to shut them down. I think it should be the other way around. wood, cornett philip (cpw@lanl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804091710.AA11972@Larry.McRCIM.McGill.EDU] <1988040917103100> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP/X.25 Call User Data ... Message-ID: <8804091710.AA11972@Larry.McRCIM.McGill.EDU> Date: 9 Apr 88 17:10:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 I'm sure that Jon Postel already mentioned this but someone seems to have missed it: The 0xCC in the Call User Data is required in RFC-877, and mentioned in [I think] CSNET report DN-5. -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804091827.AA13381@Larry.McRCIM.McGill.EDU] <1988040918272100> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) Newsgroups: comp.protocols.tcp-ip Subject: Re: Checksums, CRC's, and NFS Message-ID: <8804091827.AA13381@Larry.McRCIM.McGill.EDU> Date: 9 Apr 88 18:27:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 44 >>places (i.e. over noisy asynch lines)?? If important files get bit > >The point I was trying to make and a lot of people missed is: >>An async line is not usually noisy. You do not have to >>automatically put a CRC on it. You probably don't use a >>CRC between your terminal and the TTY MUX on the host. That's >>because it's not necessary in 99% of the cases. Of course the DCE/DTE wire does not need line error detection. It doesn't have 50 volt ring signals in adjacent copper pairs or have to travel through many relays, frequency boosters, or CODECs. And it is only a few meters long, not several kilometers. >>The same holds true for async lines in general. They don't >>normally have a noise problem. If you have a serious noise >>problem, you shouldn't be using a simple async scheme. Buy a >>paid of decent modems and let them do the work. (E.g. >>today you can buy a pair of telebit trailblazers for $1345.) When I was living in a dorm years ago, I had line noise every time the compressor is someones refrigerator started. Dial-up lines do indeed have noise. And I certainly didn't have $1300 to drop on a modem either (the one I had was an AJ rep's demo model). >If you need a special case for your special environment, fine. >However, don't claim that a protocol that doesn't have it is >broken. What the hell is wrong with a little robustness? I think we can all recount stories where a little builtin robustness has saved our butts at unexpected times. It might seem excessive now, but prove invaluable later. >No one seems to feel the need to put a CRC around the TCP/IP packet >that is handed to the ethernet. Yet, given a broken ethernet board, you >could be just as likely to have a corrupt packet as with SLIP without a >CRC > >--rick A computer's buss is hardly as hostile as a telephone line. A mile of copper pair is a great inductor in a thunderstorm... -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1988Apr10.011715.22979@utzoo.uucp] <1988041001171500> Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans From: henry@utzoo.uucp (Henry Spencer) Subject: Re: computing network loads Message-ID: <1988Apr10.011715.22979@utzoo.uucp> Organization: U of Toronto Zoology References: <23564@hi.unm.edu>, <2@stanton.TCC.COM> Date: Sun, 10 Apr 88 01:17:15 GMT > ... A token ring on the > other hand can be very predictable in it's performance. Until the token gets lost or corrupted, of course. -- "Noalias must go. This is | Henry Spencer @ U of Toronto Zoology non-negotiable." --DMR | {allegra,ihnp4,decvax,utai}!utzoo!henry ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041001310000> Received: from nswses.arpa by SRI-NIC.ARPA with TCP; Sun 10 Apr 88 09:44:55-PDT Date: 10 Apr 88 09:31:00 PST From: "TERVAX::EFBATEY" Subject: Guide me to UU-PC To: "tcp-ip" cc: efbatey Reply-To: "TERVAX::EFBATEY" Thanks .. yes I know this it the TCP-IP list for real communications .. what list or center of wisdom might know where to find PC - UU_DOS (for DEC RB-100+ Everett F. Batey II } {UUCP: sun!tsunami!nswed5!efb USNSWSES - Code 4V33 } {ARPA: efbatey@NOBBS.UCSB.EDU Blg 1214 } { efbatey@26.17.0.46 After HOSTS.TXT.726 } { efbatey@NSWSES.ARPA Port Hueneme,CA 93043-5007 } {DDD: 805/982-5881 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804101718.AA11383@ucbvax.Berkeley.EDU] <1988041017310000> From: efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY") Newsgroups: comp.protocols.tcp-ip Subject: Guide me to UU-PC Message-ID: <8804101718.AA11383@ucbvax.Berkeley.EDU> Date: 10 Apr 88 17:31:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "TERVAX::EFBATEY" Organization: The Internet Lines: 10 Thanks .. yes I know this it the TCP-IP list for real communications .. what list or center of wisdom might know where to find PC - UU_DOS (for DEC RB-100+ Everett F. Batey II } {UUCP: sun!tsunami!nswed5!efb USNSWSES - Code 4V33 } {ARPA: efbatey@NOBBS.UCSB.EDU Blg 1214 } { efbatey@26.17.0.46 After HOSTS.TXT.726 } { efbatey@NSWSES.ARPA Port Hueneme,CA 93043-5007 } {DDD: 805/982-5881 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804110058.AA16148@okeeffe.Berkeley.EDU] <1988041100584700> From: karels@OKEEFFE.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: Out of Band data in 4.3 Message-ID: <8804110058.AA16148@okeeffe.Berkeley.EDU> Date: 11 Apr 88 00:58:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 You're wrong. The case PRU_RCVOOB no longer has anything to do with out-of-band data if SO_OOBINLINE is set. As out-of-band data is never removed from incoming packets, it is not stored in the protocol and is not retrieved from there. Calling recv with MSG_OOB with the SO_OOBINLINE option set is wrong. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [242@mahendo.Jpl.Nasa.Gov] <1988041109493000> From: earle@mahendo.Jpl.Nasa.Gov (Greg Earle) Newsgroups: comp.protocols.tcp-ip Subject: Domain name, domain name, what shalt thou be, domain name? Message-ID: <242@mahendo.Jpl.Nasa.Gov> Date: 11 Apr 88 09:49:30 GMT Reply-To: earle@mahendo.JPL.NASA.GOV (Greg Earle) Followup-To: poster Distribution: na Organization: Gainfully Unemployed Ltd., Lakeview Terrace CA Lines: 41 Summary: SLIP links (point-to-point links in general) muddy the picture ... [ This is probably not the best place for this. I couldn't come up with a better one, though, other than `Namedroppers'. Apologies in advance ... ] I have an interesting possible scenario, and would like to solicit suggestions regarding choosing a domain to reside under. To wit: Currently, I access the known Universe and my beloved Internet connection via an account on this machine [mahendo.JPL.NASA.GOV]. Let's say I am about to begin work for the `Moon' company. The Moon company has a registered domain, Moon.COM. There are several sub-domains under Moon.COM, for simplicity's sake let's choose geographically based ones - West.Moon.COM, East.Moon.COM, &c. I will be provided with a machine in order to perform my job duties. Under ordinary circumstances, I could expect to name this machine `gregsbox', and nestle comfortably under the name `gregsbox.West.Moon.COM' with an MX record handled by Moon.COM. On the other hand, say the loss of my Internet connection proves too great to handle (*sniff*). I then cajole the good folks at JPL who administer the JPL.NASA.GOV domain into letting me set up a SLIP link with them. Now, this becomes easy, since JPL.NASA.GOV is neatly subdivided into Class B subnets. Merely by choosing a machine on the backbone net without an existing subnet farm, a TrailBlazer SLIP link between the my machine and somebackbonebox.JPL.NASA.GOV gets me onto a new JPL-Net subnet. Thus, just by running `routed' I become known to the rest of the world (by proxy) because of their current subnet set-up. So, if I chose, I could also easily nestle into `gregsbox.JPL.NASA.GOV' with some Internet address containing 128.149.s.h. In other words, from a *connectivity* and *network* standpoint, such a circumstance would point to being a member of the JPL domain. But from an *organizational* standpoint (i.e., who I *work* for), it would point to staying inside the Moon.COM domain. Given this scenario, how does one choose which domain to reside in? N.B.: I realize that with some point-to-point links such as this, that there are plenty that retain the organizational-oriented domain name. But given that the network address would be one that is under JPL's network domain (i.e., `128.149' is JPL-Net's and JPL-Net's alone), I don't know how this would affect this decision. Any help?!? -- Greg Earle earle@mahendo.JPL.NASA.GOV Indep. Sun consultant earle%mahendo@jpl-elroy.ARPA [aka:] (Gainfully Unemployed) earle%mahendo@elroy.JPL.NASA.GOV Lake View Terrace, CA ...!{cit-vax,ames}!elroy!jplgodo!mahendo!earle ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041109580000> Mail-From: STJOHNS created at 11-Apr-88 16:59:30 Date: 11 Apr 1988 16:58-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: NFS Implementations From: STJOHNS@SRI-NIC.ARPA To: martinea@SKL-CRC.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]Mon, 11 Apr 88 16:58:03 PDT.STJOHNS> In-Reply-To: <8804112224.AA10352@skl-crc.arpa> According to the documentation I got with the uVax, ULTRIX 2.0 has NFS in it. I'll admit I haven't tried it yet though. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041112230000> Received: from MITVMA.MIT.EDU by SRI-NIC.ARPA with TCP; Mon 11 Apr 88 13:53:55-PDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Mon, 11 Apr 88 16:32:54 EDT Received: by MITVMA (Mailer X1.25) id 1774; Mon, 11 Apr 88 16:25:45 EDT Date: Mon, 11 Apr 88 16:23:00 EDT From: Ed Kodinsky Subject: TN3270 Source Code To: TCP-IP@SRI-NIC.ARPA I apologize for disturbing the whole net, but I would like to know from where I might be able to a@obtain the public domain source code for TN3270. May I FTP it from si@ri or berkeley? Thank you in advance for your help! Ed ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041112300000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Mon 11 Apr 88 16:55:16-PDT Received: from AUDUCVAX.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 4459; Mon, 11 Apr 88 19:44:39 EDT Date: Mon, 11 Apr 88 18:30 CST From: (Larry Owen) Subject: mac-level bridges and internet addresses To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, OWEN Here's a real rookie question: I know (or at least am laboring under the assumption) that all hosts (connections) on a given physical network must (should?) use the same network number in their internet address. What about MAC-level bridges (Lan Bridge 100's, Vitalink Translans, and the like)? Are all ethernet segments connected by these devices on a single net (for purposes of internet addressing), or can each segment use a different network (or subnet) number? Thanks in advance, Larry Owen Academic Computing Services Auburn University OWEN@AUDUCVAX.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4410@hoptoad.uucp] <1988041114000900> From: gnu@hoptoad.uucp (John Gilmore) Newsgroups: comp.protocols.tcp-ip Subject: Re: Checksums, CRC's, and NFS Message-ID: <4410@hoptoad.uucp> Date: 11 Apr 88 14:00:09 GMT References: <8804041338.AA12433@etn-wlv.EATON.COM> Organization: Grasshopper Group in San Francisco Lines: 26 mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) wrote: > A gut feel is that a VRC/LRC combination for error detection is just as reliable > as a CRC for detection of errors *and* saves 5 instructions per byte assuming > the use of a CRC table. That would be nice for sending 8-bit data in 9-bit bytes, but we don't have the vertical check bit except on tapes and other 9-bit media (or when sending 7-bit data). If people are serious about fixing the checksums (sounds like a good idea), howabout adding an IP option for full-packet 32 bit CRC? Any site could ignore the option, but at least all the ones that used it would interoperate and check each others' checksums. The first site, gateway, or whatever that implemented the option would throw away a packet whose CRC was bad. That would not work when passed through gateways which modify the IP options (e.g. source routing) but don't implement the CRC option. Another option would be a CRC that protected only the user-data field, relying on the IP header checksum for the header. Not as good, but easier to retrofit. -- {pyramid,pacbell,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com I forsee a day when there are two kinds of C compilers: standard ones and useful ones ... just like Pascal and Fortran. Are we making progress yet? -- ASC:GUTHERY%slb-test.csnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1980@hou2d.UUCP] <1988041116003400> From: n2dsy@hou2d.UUCP (G.BEATTIE) Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip,rec.ham-radio.packet Subject: Asynchronous Framing Technique Message-ID: <1980@hou2d.UUCP> Date: 11 Apr 88 16:00:34 GMT Organization: AT&T Bell Laboratories, Holmdel Lines: 38 Keywords: AFT, a SLIP alternative Distribution Techniques OK Folks ! I have received several notes and messages about the distribution of our software and documents via the net. Let's understand a few basic points here: ISSUE: I don'thave access to ftp to outside systems from hou2d. If someone has such a package with source for a 3B1 and sends me a DISK, I will get it going. I think I can get a network connection at NJIT, but I will entertain other offers. ISSUE: Hate mail for using the net for distribution. The response has been as follows: 2 mailer generated messages signalling error. 2 human generated messages saying No Good. 6 human generated messages saying Thanks. I wished every comment I make on the net could fair this well! One interesting note: one of the messages that said "Don't do it" came from an individual who doesn't like AFT and is PUSHING SLIP... I will re-examine the distribution mechanism and see what makes sense. I will probably forward out the code through "comp.protocols.iso" in the future. I will continue to send out documents and announcements via several groups. Comments? Thanks, J. Gordon Beattie, Jr. E-mail: ihnp4!hou2d!n2dsy (Unix) n2dsy@kd6th.a3100201.ampr Telephone: 201-615-4168 (Office) 201-615-4669 (Office FAX) Telephone: 201-387-8896 (Home) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041116310000> Received: from nswses.arpa by SRI-NIC.ARPA with TCP; Tue 12 Apr 88 00:41:49-PDT Date: 12 Apr 88 00:31:00 PST From: "TERVAX::EFBATEY" Subject: Re 1200 PCs on PCNFS - NZ To: "tcp-ip" cc: efbatey Reply-To: "TERVAX::EFBATEY" Recently, I added some HP Vectras (semi-AT-Clones) with DEC 802.3 cards and a previously very quiet ( even with RWHODs running ) ethernet, visiting Sun_3, 2 Decnet MV_IIs, 3 DECSERVER-200s and a DELNI and I WAS DISAPPOINTED by the traffic() reports. The PC_802.3 cards, it is my surmise, being of low iq, need several extra howdoyoudos to swap stories with the host than I would find reasonable from a more costly host .. I am sure from the last few days traffic here that someone has done some good calculations. All conventional wisdom I read / heard urges no more than 20-40 Suns (vv PCs) on a leg (then a dual enet gateway). While low end pc's ask far fewer favors of their server .. generally .. smarter 386 type PCs and others based on type of load may be very burdensome. Expect as many PCs could be served per leg BUT I'd do some serious data gathering before trying over 30 PCs on one leg .. speculate that is do- able based on connections allowed. You might pass your question on to our SoCal SUN List la-slug@{ elroy | jpl-mil }.JPL.NASA.GOV and to keves@ ucsd.edu. Those are quite a few Sun people with some serious experience. Sorry can't remember if la-slug is on elroy or jpl-mil. /Ev/ Everett F. Batey II } {UUCP: sun!tsunami!nswed5!efb USNSWSES - Code 4V33 } {ARPA: efbatey@NOBBS.UCSB.EDU Blg 1214 } { efbatey@26.17.0.46 After HOSTS.TXT.726 } { efbatey@NSWSES.ARPA Port Hueneme,CA 93043-5007 } {DDD: 805/982-5881 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804111640.AA00180@bel.isi.edu] <1988041116403900> From: postel@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: re: Domain name, domain name, what shalt thou be, domain name? Message-ID: <8804111640.AA00180@bel.isi.edu> Date: 11 Apr 88 16:40:39 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Greg Earle: Domain names are totally independent of networks. If the JPL network manager was agreeable there is no reason you couldn't have "gregsbox.West.Moon.COM" connected to 128.149.s.h. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804111731.AA20611@Larry.McRCIM.McGill.EDU] <1988041117313700> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) Newsgroups: comp.protocols.tcp-ip Subject: Re: Domain name, domain name, what shalt thou be, domain name? Message-ID: <8804111731.AA20611@Larry.McRCIM.McGill.EDU> Date: 11 Apr 88 17:31:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 (I think you were right about namedroppers being more appropriate...) Anyway, you are mixing apples and oranges. A name (even a domain name) can be arbitrarily bound to an address. The fact that you are on JPL's subnet has no bearing on what domain you put your host into... -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2718@cognos.UUCP] <1988041119105000> From: bruce@cognos.uucp (Dwayne Bruce) Newsgroups: comp.protocols.tcp-ip Subject: cmu-tcp Message-ID: <2718@cognos.UUCP> Date: 11 Apr 88 19:10:50 GMT Reply-To: bruce@cognos.UUCP () Organization: Cognos Incorporated, Ottawa, Canada Lines: 42 From nrcaer!gandalf!ml Wed Mar 30 22:36:11 1988 To: cognos!bruce Subject: CMU-TEK TCP/IP and SLIP Status: RO Hi Dwayne, could you forward this to the appropriate newsgroup? I have some comments and question about CMU-TEK TCP/IP for VMS. I've been trying to get it connected to Amateur Packet radio using a PC as a gateway. It works, but the CMU-TEK TCP/IP seems to have a very short (5sec) TCP segment timer. This causes A LOT of unnecessary retransmit traffic on the packet radio link, and leads to even longer packet delays than would occur otherwise. Can anybody think of a fix for this that doesn't involve modifying the source (we don't have a BLISS compiler!!). The CMU-TEK TCP sets the high-reliability flag in the IP datagrams, which causes the gateway to use AX.25 connected mode rather than datagram mode, thus increasing packet delays. Again, I'd like to be able to tell it (VMS) the TOS. Has anybody written a SLIP driver for the CMU-TEK TCP/IP that I could have? The ethernet card that I'm using on the PC is borrowed, and is overkill for our local packet radio network anyway!! In case you haven't already guessed, the PC is running the KA9Q code, version 871225.12. Thanx in advance Marcus Leech VE3MDL ...utzoo!dciem!nrcaer!gandalf!ml VE3MDL@VE3JF > Please reply to above, Marcus Does not have Usenet access.-- Dwayne Bruce P.O. Box 9707 Cognos Incorporated 3755 Riverside Dr. VOICE: (613) 738-1440 FAX: (613) 738-0002 Ottawa, Ontario UUCP: decvax!utzoo!dciem!nrcaer!cognos!bruce CANADA K1G 3Z4 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804111947.AA12194@hogg.cc.uoregon.edu] <1988041119474400> From: jqj@HOGG.CC.UOREGON.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Domain name, domain name, what shalt thou be, domain name? Message-ID: <8804111947.AA12194@hogg.cc.uoregon.edu> Date: 11 Apr 88 19:47:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 >A name (even a domain name) can be arbitrarily bound to an address. It is worth recalling one respect in which this is not quite accurate. A typical site needs a simple way to generate an INADDR-ARPA database from its name->address database. A many-many map from SOA zones to networks makes it hard to automate this generation. I think it very undesirable to have lots of hosts with one authority for their name->address translation and a different one for address->name translation. In some cases it's necessary, I suppose, but the number of such hosts should be minimized so as to maximize the modularity of the database. A much cleaner scheme is to have a host's real domain name directly depend upon its network number, and instead have a pointer record in the other domain allowing an alias. The domain system as presently defined is sufficiently general to allow both schemes; which one gets used becomes a question of taste and pragmatics. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804112219.AA05137@ucbvax.Berkeley.EDU] <1988041120230000> From: KODINSK@MITVMA.MIT.EDU (Ed Kodinsky) Newsgroups: comp.protocols.tcp-ip Subject: TN3270 Source Code Message-ID: <8804112219.AA05137@ucbvax.Berkeley.EDU> Date: 11 Apr 88 20:23:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 I apologize for disturbing the whole net, but I would like to know from where I might be able to a@obtain the public domain source code for TN3270. May I FTP it from si@ri or berkeley? Thank you in advance for your help! Ed ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804112224.AA10352@skl-crc.arpa] <1988041122243200> From: martinea@SKL-CRC.ARPA (Mike Martineau) Newsgroups: comp.protocols.tcp-ip Subject: NFS Implementations Message-ID: <8804112224.AA10352@skl-crc.arpa> Date: 11 Apr 88 22:24:32 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 I am looking for NFS implementations (client, server, or both) which run on the following computing architectures: 1. VAX/VMS 2. VAX/UTLRIX 3. IBM PC (or clones)/MS-DOS 4. IBM PC (or clones)/XENIX 5. MacIntosh If anybody is aware of any such implementations (either commercial or public domain) could you please send me a mail message. If there is a sufficient number of replies I will summarize to the net. Thanks, Michael Martineau Project Engineer Software Kinetics Ltd. Stittsville, Ontario, Canada ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804112232.AA00474@akamai.isi.edu] <1988041122324300> From: jkrey@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: re: a question on the IEEE802.1 Part B Message-ID: <8804112232.AA00474@akamai.isi.edu> Date: 11 Apr 88 22:32:43 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Yuko, These are the same as the high order bits assigned to manufacturers or other organizations by the IEEE when one acquires a block of Ethernet addresses. See RFC-1010, pages 12-15. Joyce and --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804112243.AA11803@gyre.umd.edu] <1988041122434300> From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: comp.protocols.tcp-ip Subject: Re: Domain name, domain name, what shalt thou be, domain name? Message-ID: <8804112243.AA11803@gyre.umd.edu> Date: 11 Apr 88 22:43:43 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Note, though, that if your host name is `home.MegaCorp.COM' but is really attached to `res.ear.ch.EDU', but the ch.EDU server does not also serve for MegaCorp.COM, when MegaCorp.COM (or COM in general) is unreachable, ch.EDU sites will not be able to figure out who you are. Having experienced a miniature version of this situation (the official UMD.EDU servers are one broadband-hop away from the Computer Science Department cable, and the local construction folks like nothing better than to cut through broadband cables while pretending to dig up parking lots :-) ), where none of our `cs.umd.edu' machines could call any `umd.edu' machines---which includes all our multi-user hosts---by name. (Fortunately, we still had call by address, if not by value :-) ) Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804112252.AA11816@gyre.umd.edu] <1988041122523300> From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: comp.protocols.tcp-ip Subject: Re: Domain name, domain name, what shalt thou be, domain name? Message-ID: <8804112252.AA11816@gyre.umd.edu> Date: 11 Apr 88 22:52:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Oh dear, I just mailed a sentence fragment. What I had meant to say is that not being able to address your machines by name tends to be an unhappy situation. (Just look what happens when you allow yourself to be distracted by grammatical arguments occurring in your office. Bam, you send off a letter chock full o' grammatical errors.) Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]Mon,.11.Apr.88.16:58:03.PDT.STJOHNS] <1988041123580000> From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: NFS Implementations Message-ID: <[SRI-NIC.ARPA]Mon,.11.Apr.88.16:58:03.PDT.STJOHNS> Date: 11 Apr 88 23:58:00 GMT References: <8804112224.AA10352@skl-crc.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 1 According to the documentation I got with the uVax, ULTRIX 2.0 has NFS in it. I'll admit I haven't tried it yet though. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804120427.AA11751@ucbvax.Berkeley.EDU] <1988041200300000> From: OWEN@AUDUCVAX.BITNET (Larry Owen) Newsgroups: comp.protocols.tcp-ip Subject: mac-level bridges and internet addresses Message-ID: <8804120427.AA11751@ucbvax.Berkeley.EDU> Date: 12 Apr 88 00:30:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Here's a real rookie question: I know (or at least am laboring under the assumption) that all hosts (connections) on a given physical network must (should?) use the same network number in their internet address. What about MAC-level bridges (Lan Bridge 100's, Vitalink Translans, and the like)? Are all ethernet segments connected by these devices on a single net (for purposes of internet addressing), or can each segment use a different network (or subnet) number? Thanks in advance, Larry Owen Academic Computing Services Auburn University OWEN@AUDUCVAX.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804120254.AA25398@Larry.McRCIM.McGill.EDU] <1988041202542600> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) Newsgroups: comp.protocols.tcp-ip Subject: Re: Domain name, domain name, what shalt thou be, domain name? Message-ID: <8804120254.AA25398@Larry.McRCIM.McGill.EDU> Date: 12 Apr 88 02:54:26 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 46 (I will be happy to move this discussion to a more appropriate list, if you wish to continue this "in public".) A typical site needs a simple way to generate an INADDR-ARPA database from its name->address database. A many-many map from SOA zones to networks makes it hard to automate this generation. IN-ADDR.ARPA records are undeniable a kludge and an afterthought. It seemed that the inverse query was implausible computationally for doing address to name mappings. There is no clean solution. A mapping that is optimized in one direction can be very hard to compute inversely (such as hashing). I think it very undesirable to have lots of hosts with one authority for their name->address translation and a different one for address->name translation. In some cases it's necessary, I suppose, but the number of such hosts should be minimized so as to maximize the modularity of the database. A much cleaner scheme is to have a host's real domain name directly depend upon its network number, and instead have a pointer record in the other domain allowing an alias. The domain system as presently defined is sufficiently general to allow both schemes; which one gets used becomes a question of taste and pragmatics. If JPL is willing to give him a subnet number, then handling address to name translation as well shouldn't be putting them out. What is "desirable" and "clean" is not always convergent with what is necessary. Creating "fake" names to facilitate solutions is hardly a "clean" approach. Having a host's name depend on its address is an intolerable restriction. It completely negates the distributed capability of the domain name system. In the example, you should be able to have: $ORIGIN s.49.128.in-addr.arpa. 1 IN PTR (some name for 1) 2 IN PTR (some other name for 2) ... IN PTR (...) h IN NS Some-Server.Sun.Com. ... IN PTR (...) in JPL's nameserver for s.49.128.in-addr.arpa and have it point to one of Sun's nameservers and make it authorative for that particular host. This would allow the "proper" administration of the name. But as I said, you could just as easily have JPL administer the mapping locally. -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [330@retix.retix.COM] <1988041207251200> From: erik@retix.retix.COM (Erik Forsberg) Newsgroups: comp.protocols.tcp-ip Subject: Re: OSI does not mean X.25 Message-ID: <330@retix.retix.COM> Date: 12 Apr 88 07:25:12 GMT References: <76.008873@adam.DG.COM> <1157@ttds.UUCP> Reply-To: erik@retix.UUCP (Erik Forsberg) Organization: Retix, Santa Monica CA Lines: 68 In article <1157@ttds.UUCP> rajaei@ttds.UUCP (Hassan Rajaei) writes: >I am really glad you mentioned this. There has been a confusion between >OSI model and X.25 protocol for a long time just because X.25 was the only >available implementation of OSI. > >The OSI model is so general that you may do any thing with it (except the >overhead!). If there is not an standard protocol available for your need >within the model, that doesn't mean the model itself is incapabel of doing >that. In spite of many standard protocols available for OSI at present >time, I believe we need many new ones in future even for the low layers >like physical, link and network. > >The existing standars for low layers are incapable of handling the ultra >super speed networks of the future (FDDI can handle just 150 Mbps). The >same is true with X.25 and its IP X.75 which are not only limited by speed >but rather make the network very vulnerable because of their connection- >oriented behaviour throughout the network (internetworks). As Lyman Chapin >said the limitation is not in the model but in the protocols. > >There is much to be done for OSI model to be accepted (or rejected!) world >wide, both with new standard protocols and implementations. > Please make a distinction between the OSI MODEL and the protocols specified by ISO that implements services defined by the ISO model. I don't think you can do anything with the OSI model. Just because you invent your own protocol, which happens to provide some service defined by the OSI model, doesn't really make this new protocol an OSI protocol. There will be just confusion and interoperability problems if every new protocol claims to be an "OSI protocol". Before it could be considered as a protocol to be used to implement a service as defined by OSI, it should become an ISO standard. Otherwise, it's not too useful for the majority of the worlds data communications users. Anyway, there certainly is a place for new protocols for new, higher performing LAN technologies. But, even the existing ISO 8073/8473 protocol combinations are quite performing. (This is the ISO Class 4 Transport protocol operating over a connection-less network service, almost identical with DoD IP). For example, by eliminating overhead imposed by non-perfect hardware, this protocol combination has proven able to have a substained transport layer user data throughput of more than 2000 packets per second (each packet 1024 bytes) which is approximately 16 Megabits/second (this is measured on a VAX 8650). Now, if you add some well-known, supposedly reasonable Ethernet controllers on an otherwise idle Ethernet network, performance drops to a measly 60-180 packets per second, it is my opinion that controller hardware technology, computer buses and software used to interface with the host operating system needs some large improvements. I do not understand why so many believes that X.25 is the only way to implement OSI. It is certainly true that the european continent started work in ISO, specifying the Connection-oriented network service as examplified by X.25, but I think the US has been as successfull in providing equally good protocols when Local Area Networks are the primary technology of interest. Now, there are very reasonable standards in how to inter-connect multiple Local Area Networks using these venerable and perfectly working X.25's as provided by any Public Data Network service provider (in most any country of the world). One of the major problems is that there is no natural way to interoperate between networks using ISO 8473 (IP) or ISO 8208 (X.25) as the network layer. There will always be limitations when such attempts are made (there are several proposals discussed as of this time). -- ---------------------------------------------------------------------------- Erik Forsberg, Retix, 2644 30th Street, Santa Monica CA 90405 (213) 399-2200 UUCP: {cepu,ttidca,rutgers,oliveb}!retix!erik, erik@retix.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804120832.AA16084@ucbvax.Berkeley.EDU] <1988041208310000> From: efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY") Newsgroups: comp.protocols.tcp-ip Subject: Re 1200 PCs on PCNFS - NZ Message-ID: <8804120832.AA16084@ucbvax.Berkeley.EDU> Date: 12 Apr 88 08:31:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "TERVAX::EFBATEY" Organization: The Internet Lines: 26 Recently, I added some HP Vectras (semi-AT-Clones) with DEC 802.3 cards and a previously very quiet ( even with RWHODs running ) ethernet, visiting Sun_3, 2 Decnet MV_IIs, 3 DECSERVER-200s and a DELNI and I WAS DISAPPOINTED by the traffic() reports. The PC_802.3 cards, it is my surmise, being of low iq, need several extra howdoyoudos to swap stories with the host than I would find reasonable from a more costly host .. I am sure from the last few days traffic here that someone has done some good calculations. All conventional wisdom I read / heard urges no more than 20-40 Suns (vv PCs) on a leg (then a dual enet gateway). While low end pc's ask far fewer favors of their server .. generally .. smarter 386 type PCs and others based on type of load may be very burdensome. Expect as many PCs could be served per leg BUT I'd do some serious data gathering before trying over 30 PCs on one leg .. speculate that is do- able based on connections allowed. You might pass your question on to our SoCal SUN List la-slug@{ elroy | jpl-mil }.JPL.NASA.GOV and to keves@ ucsd.edu. Those are quite a few Sun people with some serious experience. Sorry can't remember if la-slug is on elroy or jpl-mil. /Ev/ Everett F. Batey II } {UUCP: sun!tsunami!nswed5!efb USNSWSES - Code 4V33 } {ARPA: efbatey@NOBBS.UCSB.EDU Blg 1214 } { efbatey@26.17.0.46 After HOSTS.TXT.726 } { efbatey@NSWSES.ARPA Port Hueneme,CA 93043-5007 } {DDD: 805/982-5881 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MDC-WWB-DH962@OFFICE-1] <1988041215010000> From: WWB.MDC@OFFICE-1.ARPA (Bill Barns) Newsgroups: comp.protocols.tcp-ip Subject: Packet level accounting in IP routers? Message-ID: Date: 12 Apr 88 15:01:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 70 This is a multifaceted question, and I am asking "What do vendors have", "what do vendors think of doing this", "what is going on with protocol standards in this area, if anything", and "what philosophy of approach, design, policy, etc., should apply", with regard to the following issue: In the not too distant future, there will be a direct cost associated with usage of MILNET, charged on a per-packet basis. There is some perception that the same will be true of the operational Defense Research Internet, though I know of no official statements to this effect. Whatever the case, the relevant point is that there will apparently be a specific charge which will become part of the cost base for contract pricing on certain common types of contracts. Those of you who are familiar with the arcana of government contracting will appreciate that these figures are auditable by various authorities, a fact which has a large number of serious implications. Some people here see it as a problem that the use of a LAN and gateway to MILNET (or any net with similar charging algorithm) would result in a cost to the sponsor which, from the government side, cannot be allocated to specific projects, because the charging information will be generated on a per-port basis. This is bad because a significant number of projects nowadays, and especially in the pipeline, are generating connectivity and data communication requirements of this type. Thus there is a concern that if the traditional management approach (more or less dictated by audit considerations) is employed, it might be necessary to have one physical interconnection for each contract. I trust it is not necessary to explain in complete detail why this is bad. A large defense contractor (like this one) might end up having to have tens or hundreds or thousands of interconnections. Remember that there is also to be a per-port charge, not to mention all the RFS, TSR, NCR, NCD, etc., paperwork that would have to be done. On the other hand, shared gateways are much cheaper. But at present it is not evident that there is a way of allocating cost for shared gateways which would be satisfactory to the government auditors. The port used by the gateway would have to be paid for by one service component, including charges attributable to other programs which might be contracted with other components, or may be subject to different allowable pricing and cost recovery rules. The perceived bottom line here is that there is an implicit requirement for packet-level accounting of IP traffic, and ultimately ISO IP traffic likewise, through such a multiple-use interface. It isn't obvious to me how this can be solved completely right without protocol alterations, probably at the IP level - an accounting code IP option. But I think that is politically infeasible. The existing protocols can be left intact if the accounting is done on the basis of source and destination IP addresses, and I think this may be an adequate solution. However, this still requires some protocol development, as well as implementation work. I imagine such an accounting scheme working in the following manner. The IP router servicing the government network interconnection would extract source/destination (depending on direction) IP addresses and keep packet counts and perhaps other counts tabulated on this basis. At some interval it transmits these values to some configuration determined place or places where a long-term accounting database is maintained. This transmission would be formatted according to some protocol yet to be specified. The target host of the transmission runs some server software which receives these transmissions and stores them in an accounting database, from which reports are developed as needed. So, many questions suggest themselves: Is anyone already doing this? Is any vendor already selling IP gateways that provide such functionality, using this or any other design? Is any vendor willing to volunteer to implement some simple scheme of this sort? Is my design concept valid? Does anyone have a better one? Has anyone ever developed or published suitable protocols in the TCP/IP framework for communicating the accounting data? ISO CLNS/GOSIP? Has anyone gone through this issue with DCAA, local DCAS people, or other such authorities, and what did they say? (etc.) All sorts of relevant comments are solicited. Thanks, Bill Barns / McDonnell Douglas / Internet: WWB.MDC@OFFICE-1.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804121506.AA13088@skl-crc.arpa] <1988041215064000> From: martinea@SKL-CRC.ARPA (Mike Martineau) Newsgroups: comp.protocols.tcp-ip Subject: Executable image of PC-IP Message-ID: <8804121506.AA13088@skl-crc.arpa> Date: 12 Apr 88 15:06:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 I am looking for an executable image of PC-IP for a 3-COM board so that I can run the netwatch program. I am short of disk space and time to compile the PC-IP sources that I have. Any help would be greatly appreciated. Please mail responses directly to me. Thanks. Michael P. Martineau Project Engineer Software Kinetics Ltd. Stittsville, Ontario, Canada ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804121617.AA01275@GAAK.LCS.MIT.EDU] <1988041216172100> From: map@GAAK.LCS.MIT.EDU (Michael A. Patton) Newsgroups: comp.protocols.tcp-ip Subject: mac-level bridges and internet addresses Message-ID: <8804121617.AA01275@GAAK.LCS.MIT.EDU> Date: 12 Apr 88 16:17:21 GMT References: <8804120726.AA00523@GAAK.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 Date: Mon, 11 Apr 88 18:30 CST From: (Larry Owen) X-Original-To: tcp-ip@sri-nic.arpa, OWEN ... I know (or at least am laboring under the assumption) that all hosts (connections) on a given physical network must (should?) use the same network number in their internet address. ... This is not true. We have an Ethernet here with hosts on both 18.0.0.0 and 128.30.0.0 without (many) problems. However, the two groups of hosts do not talk to one another. This could be arranged in several ways, but we don't have any need. There is no conceptual reason why one physical network cannot be several logical (sub-)nets. Mike Patton Network Hacker MIT LCS ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2941836@um.cc.umich.edu] <1988041219221200> From: Doug_Nelson@UM.CC.UMICH.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: mac-level bridges and internet addresses Message-ID: <2941836@um.cc.umich.edu> Date: 12 Apr 88 19:22:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Larry, to answer your question, a set of ethernet segments connected by MAC level bridges is indeed one logical network for the purposes of internet addressing. We are running a large class B+ network with 20 or so MAC bridges, spanning our entire campus. Running the network this way certainly simplifies our local routing problem. It has its own headaches, but there are other benefits, such as being able to run Decnet, etc., over the same wire. Doug Nelson den@serv1.cl.msu.edu Computer Laboratory 08071den@msu.bitnet Michigan State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804122257.AA13640@hogg.cc.uoregon.edu] <1988041222571100> From: jqj@HOGG.CC.UOREGON.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: mac-level bridges and internet addresses Message-ID: <8804122257.AA13640@hogg.cc.uoregon.edu> Date: 12 Apr 88 22:57:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 >We have an Ethernet here with hosts on both >18.0.0.0 and 128.30.0.0 without (many) problems. One must be very careful when running multiple IP networks on the same cable. For example, it makes it much more likely that a misbehaving gateway will cause a broadcast storm aka "meltdown." Typical example: suppose that 128.30.0.0 is 8-8 subnetted, and that subnet 128.30.3.0 is on the shared cable. Suppose also that both IP networks have gateways to the arpanet or something. Suppose some host on 128.30.3.0 sends an IP broadcast (as an Ethernet broadcast) to its subnet broadcast address, say to 128.30.3.255. A gateway between 18.0.0.0 and the arpanet, say 18.0.0.1 (but NOT also configured to be on 128.30.3.0), receives the packet, notes "this is a packet for host 3.255 on net 128.30.0.0" (please observe that since this gateway does not itself have any interfaces on 128.30.0.0, it doesn't know what the subnet mask of that network is and hence can't recognize this as a subnet broadcast), sends it to a gateway on 128.30.3.0, who explodes it onto the cable. The first gateway gets another copy, forwards that packet, etc. As Chuck Hedrick noted in a recent message to tcp-ip, it is essential that gateways pay attention to whether the packet arrived as a media broadcast; unfortunately, many gateways (e.g. 4.3BSD) do not. A fortiori, unless you're willing to also have gateways drop ALL packets sent as Ethernet broadcasts (which I am not), or are willing to insist that any gateway on a physical network know about all the nets on that cable (which I don't see how you can do), you must also forbid topologies such as the one above. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3950002@wdl1.UUCP] <1988041301513300> From: jcw@wdl1.UUCP (John C Williams) Newsgroups: comp.protocols.tcp-ip Subject: Re: Out of Band data in 4.3 Message-ID: <3950002@wdl1.UUCP> Date: 13 Apr 88 01:51:33 GMT References: <351@tandem.UUCP> Lines: 14 Mike Karels, Adding a response unrelated to your response to someone else's article, with the net listening in, I believe qualifies as indirect communication --assuming this note comes to your attention. I can ping your hosts to death, but my mail comes bouncing back. (This ought to be a song!) Question (of possible interest to others): When is the book on UNIX BSD 4.3 Internals coming out? Title, publisher, etc.? Regards (and thanks for the net's indulgence), John jcw@ford-wdl1.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1981@hou2d.UUCP] <1988041302253600> From: n2dsy@hou2d.UUCP (G.BEATTIE) Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso,rec.ham-radio.packet Subject: Asynchronous Framing Technique Message-ID: <1981@hou2d.UUCP> Date: 13 Apr 88 02:25:36 GMT Organization: AT&T Bell Laboratories, Holmdel Lines: 992 Keywords: AFT, a SLIP alternative retransmission of AFT.C /* Machine Independent Asynchronous Framing Technique (AFT) Version 1.0, by John Howell (N2FVN), Copyright August 7, 1987 This software is free for non-commercial use. All commercial rights are retained by the author or his designees. Commercial use without the explicit written permission of the author is prohibited. This package is provided on an 'as is' basis without warranty. */ /* Macros */ #define FLAG 0x007E /* This is the flag character which is used to start and end frames. The send generates separate starting and ending flag characters, but the receiver can accept a single flag to end one frame and start another. */ #define LEAD_IN 0x007D /* This is the lead in character which is used when transparency is required. When the receiver detects this character it takes the following character and exclusive ors it with 0x20 to produce the proper character. This is used to allow the transmission of characters which would not otherwise be received properly. */ #define TRANSPARENT(c) (c ^ 0x20) /* This is the function to be performed to convert a character into one which may be transmitted transparently. This is also used to return a character to its original value since the function is its own inverse. */ #define IDLE_CODE (0x0100 + FLAG) /* This is the idle code with is returned by aft_tx_char when it has no frame to send. The high order byte indicates completion and the low order byte is a flag which might be sent if flags are to be used between frames as filler. */ #define GENERATOR 0x8408 /* This is the generator polynomial for the frame check sequence. The polynomial is the standard CCITT polynomial. It is in reverse bit order for faster calculation. The polynomial is X**16 + X**12 + X**5 + 1. */ #define EXPECT_FCS 0xF0B8 /* This is the expected final FCS for a correctly received frame. */ #define OK 1 /* This is the return code used by some routines to indicate successful completion. */ #define NO_GOOD 0 /* This is the return code used by some routines to indicate unsuccessful completion. */ /* Global declarations */ static char opt_ebdt; /* This is a flag controlling the use of eight-bit data transparency on transmitted and receive frames. */ static char opt_transparency_level; /* This is the transparency level to be used when transmitting frames (0-2). Each increasing level causes more characters to be avoided when sending frames which allows them to be sent in situations where certain characters are not allowed. */ static char opt_suffix_len; static unsigned char opt_suffix[3]; /* This is the suffix string to be added to the end of each frame sent. Any character including a null is allowed. */ static unsigned int opt_max_rx_len; /* This is the maximum size of a receive buffer. It is used when receiving to make sure that a received frame does not go past the end of the buffer. A received frame which is too long will be discarded. */ static unsigned char transparency_level [256] = { 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 2, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 0, 0, 2, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9}; /* For each possible character this is the transparency level at which it should be encoded for transparency. A value of nine is used for character which should never be encoded. */ /* Variables and macros used by aft_tx_char */ static char tx_char_state; /* This is the state of the transmission routine which handles transparency, delimiting of frames, and frame abort. It is used to determine the next action to be performed by aft_tx_char when it is called. State names are given by the 'TCS_' macros. */ #define TCS_IDLE 0 /* This state indicates that no frame is being sent. Calls to aft_tx_char while in this state return the idle code and calls to aft_tx_complete return one. This is the only state in which a call to aft_tx_start is valid. */ #define TCS_START_FLAG 1 /* This state indicates that the starting flag for a frame should be sent when aft_tx_char is next called. This state is entered when aft_tx_start accepts a frame to be sent. */ #define TCS_GET_NEXT_CHAR 2 /* This state indicates that the next character to be sent should be gotten by calling tx_ebdt. Before being sent the character will be checked against a table to see if a substitution is required. If so then the current character is saved and a lead-in character is sent. */ #define TCS_SUBSTITUTE_CHAR 3 /* This state indicates that the next character to be sent is the encoded value of the current character. This is used for transparency purposes. */ #define TCS_SUFFIX 4 /* This state is used when the closing flag has been sent to indicate the need to send any additional defined suffix characters at the end of the frame. Once all suffix characters have been sent the transmitter returns to the TCS_IDLE state. */ #define TCS_ABORT_LEAD_IN 5 /* This state indicates that the caller has decided to abort the frame before it has been completely sent. A lead in character followed by a flag will be sent to indicate that the receiver should discard the frame. */ #define TCS_ABORT_FLAG 6 /* The lead-in character has been sent to abort the current frame. A flag will be now sent to complete the abort sequence. */ static unsigned char tx_encode_char; /* This is the character to be sent after it is encoded for transparency. The value is saved here while waiting for aft_tx_char to be sent after it has returned the transparency lead-in character. */ static char tx_suffix_count; /* This is a count of the number of suffix characters which have been sent so far at the end of the frame. */ /* Variables and macros used by tx_ebdt */ static char tx_ebdt_state; /* This is the state of the eight bit data transparency routines. The value is actually a count of the number of characters which have each contributed their high order bit to the tx_ebdt_char. It is reset back to zero when the ebdt character is sent. */ static unsigned char tx_ebdt_char; /* This is the character being built up from the high order bits of other characters during transmission when eight-bit data transparency is enabled. This will be sent once either seven bits have been collected or the frame ends. */ /* Variables and macros used by tx_data */ static char tx_data_state; /* This is the state of the routines which get data from the transmit buffer, calculate the frame check sequence, and send the frame check sequence. State names are given by the 'TDS_' macros. */ #define TDS_GET_FROM_BUFFER 0 /* This state indicates that the next character to be sent should be gotten from the transmit buffer. The FCS is updated based on the character gotten. Once all characters from the buffer have been sent the FCS will be sent. */ #define TDS_FCS_ONE 1 /* This state indicates that sending of characters from the buffer has completed and that the next character to be sent is the first half of the frame check sequence. */ #define TDS_FCS_TWO 2 /* This state indicates that the first half of the FCS has been sent and so the second half should be sent next. */ #define TDS_COMPLETE 3 /* This state indicates that sending of the FCS is complete. */ static unsigned char *tx_buffer; static unsigned int tx_len_remaining; /* tx_buffer is a pointer to the next character to be sent from the transmit buffer provided by the caller of aft_tx_start. It is incremented as each character is used from the buffer. The length remaining field is decremented as each character is used. When it reaches zero all characters from the supplied buffer have been sent and FCS transmission may begin. */ static unsigned int tx_fcs; /* This is the two bytes of the frame check sequence (FCS) to be sent at the end of the frame being transmitted stored in reverse bit order for easier transmission. The FCS is initialized to all ones before the frame is transmitted. As the frame is sent the FCS is calculated using the algorithm specified in CCITT X.25 using each character as it is obtained from the transmit buffer. */ /* Variables and macros for aft_rx_char */ static unsigned char rx_char_state; /* This is the state of the main reception routine. It is used to determine the next action performed by aft_rx_char when it is called. State names are given by the 'RCS_' macros. */ #define RCS_IDLE 0 /* This state indicates that no buffer has been provided for reception. Received characters are ignored while in this state. */ #define RCS_START_FLAG 1 /* This state indicates that a buffer has been provided to the receive routines and we are waiting to receive the opening flag for a frame. Non-flag characters will be ignored in this state. */ #define RCS_AWAIT_NEXT_CHAR 2 /* This state indicates that the opening flag has been received and characters are being received into the frame buffer. If the character received is the ending flag then the frame size and FCS are verified otherwise the chracter is passed to the eight-bit data transparency routine for processing. */ #define RCS_AWAIT_SUBSTITUTE_CHAR 3 /* This state indicates that we have received a lead in character and are now expecting another character which will decoded and sent to the EBDT routines. If the character received is a flag then this indicates that the sender is aborting the frame so it should be discarded. */ static int rx_ebdt_state; /* This is the number of characters received since the last eight bit data transparency character. This will reach eight when the next EBDT character is received. If the frame ends with this count non-zero then the character just received is the EBDT character for a group of less than seven bytes. */ static unsigned char rx_ebdt_save[7]; /* This array is used to buffer a maximum of seven characters when eight bit data transparency is being used. When the EBDT character is received then each saved character is modified to have the correct eighth bit and transferred to the receive buffer. */ static unsigned char *rx_buffer; /* rx_buffer holds the pointer to the start of the receive buffer. */ static int rx_len, rx_final_len; /* rx_len is the number of characters received so far in the current frame. rx_final_len is initialized to zero and set to the final frame length once the frame has been completely received. */ static unsigned int rx_fcs; /* This is the two bytes of the receive frame check sequence stored in reverse bit order. It is calculated as characters are received using the same method as that used for tx_fcs. At the end of the frame this must match the expected value or the frame is invalid. */ aft_options( o_ebdt, o_transparency_level, o_suffix_len, o_suffix, o_max_rx_len) char o_ebdt; /* Eight-bit data xparency (nonzero) */ char o_transparency_level; /* zero to two */ char o_suffix_len; /* zero to three */ char o_suffix[3]; /* suffix string to be sent */ int o_max_rx_len; /* size of rx buffers */ { int count; /* Suffix character count */ /* Initialize internal state variables */ tx_char_state = TCS_IDLE; rx_char_state = RCS_IDLE; rx_final_len = 0; /* Save selected options */ opt_ebdt = o_ebdt; opt_transparency_level = o_transparency_level; opt_suffix_len = o_suffix_len; for (count = 0; count < sizeof(opt_suffix); count++) opt_suffix[count] = o_suffix[count]; opt_max_rx_len = o_max_rx_len; } int aft_tx_start(length, buffer) unsigned int length; /* length of the buffer */ unsigned char *buffer; /* buffer pointer */ { /* Only allow if transmitter is idle and frame is valid */ if ((tx_char_state != TCS_IDLE) || (length < 2)) return NO_GOOD; /* Set internal state variables for transmission */ tx_data_state = TDS_GET_FROM_BUFFER; tx_buffer = buffer; /* Save pointer to next char */ tx_len_remaining = length; tx_fcs = 0xFFFF; /* Set all FCS bits to one. */ tx_ebdt_state = /* No EBDT char being built */ tx_ebdt_char = tx_suffix_count = 0; /* No suffix characters sent yet. */ /* Now that all is ready the state can be changed. This could not be done before since aft_tx_char might have been called before setup was complete. It is assumed that since the state is a 'char' it can be assigned while interrupts are enabled since it will be changed with a single write to memory. The state is set so that the starting flag will be the next character sent. */ tx_char_state = TCS_START_FLAG; return OK; /* successful return */ } int aft_tx_char() { int c; /* The character to be sent */ /* This routine is responsible for returning each character to be sent over the communication line. It handles generation of starting and ending flags, data transparency, suffix character generation, and frame abort generation. tx_ebdt is called to determine data characters to be sent. */ switch (tx_char_state) { case TCS_IDLE: c = IDLE_CODE; break; case TCS_START_FLAG: /* We are starting to send out a new frame. Send out the starting flag before any data. */ c = FLAG; tx_char_state = TCS_GET_NEXT_CHAR; break; case TCS_GET_NEXT_CHAR: c = tx_ebdt(); /* Get next character */ if (c == IDLE_CODE) { /* The entire frame has been sent. Delimit with a flag. */ c = FLAG; if (opt_suffix_len > 0) tx_char_state = TCS_SUFFIX; else tx_char_state = TCS_IDLE; } else { if (transparency_level[c] <= opt_transparency_level) { /* This character cannot be sent. Use transparency. */ tx_encode_char = c; c = LEAD_IN; tx_char_state = TCS_SUBSTITUTE_CHAR; } } break; case TCS_SUBSTITUTE_CHAR: c = TRANSPARENT(tx_encode_char); tx_char_state = TCS_GET_NEXT_CHAR; break; case TCS_SUFFIX: c = opt_suffix[tx_suffix_count++]; if (tx_suffix_count >= opt_suffix_len) tx_char_state = TCS_IDLE; break; case TCS_ABORT_LEAD_IN: c = LEAD_IN; tx_char_state = TCS_ABORT_FLAG; break; case TCS_ABORT_FLAG: c = FLAG; tx_char_state = TCS_IDLE; } return c; } static int tx_ebdt() { int c; /* Character to be returned */ /* This routine handles eight-bit data transparency. If enabled the high order bit of each character returned by tx_data is removed and added to an eight-bit data transparency character. Once this character has collected seven bits or the frame ends this character is sent. Doing this allows the receiver to recover the high order bits from the previous characters sent. */ if (!opt_ebdt) { /* If eight bit data transparency is not being used then this is just a pass through. If this option is never used then this routine may be completely eliminated for efficiency. */ c = tx_data(); } else { if (tx_ebdt_state == 7) { /* There is a full collection of seven high order bits ready to be sent. */ c = tx_ebdt_char; tx_ebdt_char = tx_ebdt_state = 0; } else { c = tx_data(); if (c != IDLE_CODE) { /* Append the high order bit from the character to be sent to the EBDT character. */ tx_ebdt_char = (tx_ebdt_char << 1) + ((c & 0x80) != 0); c = c & 0x7F; tx_ebdt_state++; } else { /* The end of the frame has been reached. If there have been any high order bits collected then send one last EBDT character. */ if (tx_ebdt_state != 0) { c = tx_ebdt_char << (7 - tx_ebdt_state); tx_ebdt_char = tx_ebdt_state = 0; } else { c = IDLE_CODE; } } } } return c; } static int tx_data() { int c; /* Character to be returned */ char tx_bits, bit_count; /* For FCS calculation */ /* The next character is obtained from the transmit buffer and the FCS calculated. Once all character from the buffer have been sent, the FCS is also sent. */ switch (tx_data_state) { case TDS_GET_FROM_BUFFER: c = *(tx_buffer++); /* FCS calculation */ tx_bits = c; for (bit_count = 0; bit_count < 8; bit_count++) { if ((tx_fcs ^ tx_bits) & 1) tx_fcs = (tx_fcs >> 1) ^ GENERATOR; else tx_fcs = tx_fcs >> 1; tx_bits = tx_bits >> 1; } if (--tx_len_remaining == 0) tx_data_state = TDS_FCS_ONE; break; case TDS_FCS_ONE: /* Send the first character of the frame check sequence. The bits are inverted before sending. */ c = (~tx_fcs) & 0x00ff;; tx_data_state = TDS_FCS_TWO; break; case TDS_FCS_TWO: /* Send the second character of the frame check sequence. The bits are inverted before sending. */ c = (~tx_fcs) >> 8; tx_data_state = TDS_COMPLETE; break; case TDS_COMPLETE: c = IDLE_CODE; break; } return c; } aft_tx_abort() { /* If aft_send_char is being called from within an interrupt service routine and this routine is intended to be used then interrupts must be disabled when this routine is called. The current state is changed to cause an abort sequence to be sent to receiver. */ switch (tx_char_state) { case TCS_START_FLAG: tx_char_state = TCS_IDLE; break; case TCS_GET_NEXT_CHAR: tx_char_state = TCS_ABORT_LEAD_IN; break; case TCS_SUBSTITUTE_CHAR: tx_char_state = TCS_ABORT_FLAG; break; default: break; } } int aft_tx_complete() { return (tx_char_state == TCS_IDLE); } int aft_rx_start(buffer) unsigned char *buffer; { /* Provide a buffer to start receiving the next frame into. If we are already receiving then the request is rejected. */ if (rx_char_state != RCS_IDLE) return NO_GOOD; /* Save the pointer to the buffer and set up for receive. */ rx_buffer = buffer; aft_rx_error(); /* Reset the receive routines */ rx_char_state = RCS_START_FLAG; return OK; } aft_rx_error() { /* Return to the condition of waiting for the starting flag. */ rx_len = rx_final_len = rx_ebdt_state = 0; rx_fcs = 0xffff; if (rx_char_state != RCS_IDLE) rx_char_state = RCS_START_FLAG; } int aft_rx_complete() { return rx_final_len; } int aft_rx_char(c) unsigned char c; { /* Add the next character to the receive buffer depending on the current state. */ if (opt_ebdt) { /* Ignore the high order bit of the character if it cannot be received transparently. */ c = c & 0x7f; } switch (rx_char_state) { case RCS_IDLE: /* If no buffer has been provided then ignore characters. */ break; case RCS_START_FLAG: /* In this state we are hunting for a flag. If this is a flag then the receive operation may begin. */ if (c == FLAG) rx_char_state = RCS_AWAIT_NEXT_CHAR; break; case RCS_AWAIT_NEXT_CHAR: if (c == LEAD_IN) { rx_char_state = RCS_AWAIT_SUBSTITUTE_CHAR; } else { if (c == FLAG) { rx_finish_ebdt(); /* If the frame is too short or the FCS is not correct then the frame is discarded. */ /* For FCS */ rx_final_len = rx_len - 2; if (rx_final_len >= 2 && rx_fcs == EXPECT_FCS) rx_char_state = RCS_IDLE; else aft_rx_error(); } else { rx_ebdt(c); } } break; case RCS_AWAIT_SUBSTITUTE_CHAR: /* Handle the character which follows a lead-in character. If it is a flag then this is a frame abort and so the frame is ignored. Otherwise translate the character and add it to the buffer. */ if (c != FLAG) { rx_ebdt(TRANSPARENT(c)); rx_char_state = RCS_AWAIT_NEXT_CHAR; } else { aft_rx_error(); } break; } return rx_final_len; } rx_ebdt(c) unsigned char c; { int bit_count; /* This routine handles received characters which have passed the normal substitution process. It handles the eight-bit data transparency by saving characters until the transparency character is detected and then adding the correct high order bit to each of the characters. */ if (!opt_ebdt) { rx_data(c); } else { if (rx_ebdt_state >= 7) { for (bit_count = 0; (bit_count < 7) && (rx_ebdt_state != 0); bit_count ++) { c = c << 1; rx_data(rx_ebdt_save[bit_count] | (c & 0x80)); } rx_ebdt_state = 0; } else { rx_ebdt_save[rx_ebdt_state++] = c; } } } rx_finish_ebdt() { unsigned char c; int bit_count; /* This routine finishes any pending EBDT conversion when the end of the frame is detected. */ if (opt_ebdt && rx_ebdt_state > 0) { c = rx_ebdt_save[--rx_ebdt_state]; for (bit_count = 0; (bit_count < rx_ebdt_state) && (rx_ebdt_state != 0); bit_count ++) { c = c << 1; rx_data(rx_ebdt_save[bit_count] | (c & 0x80)); } rx_ebdt_state = 0; } } rx_data(c) unsigned char c; { int bit_count; unsigned char rx_bits; /* FCS calculation */ rx_bits = c; for (bit_count = 0; bit_count < 8; bit_count++) { if ((rx_fcs ^ rx_bits) & 1) rx_fcs = (rx_fcs >> 1) ^ GENERATOR; else rx_fcs = rx_fcs >> 1; rx_bits = rx_bits >> 1; } if (rx_len == opt_max_rx_len) { aft_rx_error(); } else { *(rx_buffer + (rx_len++)) = c; } } ----MESSAGE-END---- ----MESSAGE-BEGIN---- [868@gvgpsa.GVG.TEK.COM] <1988041302312400> From: davew@gvgpsa.GVG.TEK.COM (David C. White) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Looking for users of David Systems equipment Message-ID: <868@gvgpsa.GVG.TEK.COM> Date: 13 Apr 88 02:31:24 GMT Reply-To: davew@gvgpsa.gvg.tek.com (David C. White) Organization: Grass Valley Group, Grass Valley, CA Lines: 34 The following is posted on behalf of the systems manager in our corporate MIS group. I also have concerns about this equipment because their system is being proposed for the T1 link to the new building we are moving into late this summer and the MIS telecommunications person is pushing it real hard even though it only does 1.2Mbit/sec over twisted pair. I've never heard of the company, so if anyone has any direct experience with this equipment of knows anything about it, I certainly would appreciate hearing from you. ------------------------------------------------------------------ The company is: David Systems, Inc. 701 East Evelyn Avenue Sunnyvale, California 94086 The product is David Information Manager. The main unit is called a David Manager, and you connect David-Sets (telephones with the ethernet, and RS232 connections on them) to it via, are you ready for this, the David-Link (a twisted pair of wires). The questions I have are: o Is anybody using all three, telephone, RS232, and ethernet modes at one station? Especially any type of high traffic station like a VAX/VMS or UNIX workstation? o Then there is the question about the T1 bridge part. Is anybody using it? And especially is anybody using use the multiple T1 bridge capability? The David Manager can handle multiple T1 circuits. The question is if you use three T1 circuits do you get 9 MBits/second throughput? -- Dave White Grass Valley Group, Inc. PHONE: +1 916.478.3052 P.O. Box 1114 Grass Valley, CA 95945 davew@gvgpsa.gvg.tek.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041304330000> Received: from ccq.bbn.com by SRI-NIC.ARPA with TCP; Wed 13 Apr 88 06:35:18-PDT Date: Wed, 13 Apr 88 08:33:00 EDT From: Ken Pogran Subject: Re: Packet level accounting in IP routers? In-Reply-To: Your message of 12 Apr 88 11:01 EDT To: Bill Barns Cc: tcp-ip@sri-nic.arpa Bill, Regarding packet-level accounting, and the auditability of shared gateway connections, etc.: There's an alternative approach, that I heard suggested by a (technically-oriented, not contract or financial) Government official. That is to consider the cost of the network attachment to be part of the corporation's infrastructure or overhead -- an indirect cost -- like any utility. That actually seems like a pretty good idea. After all, an indirect cost is one that you incur that benefits a number of contracts, and is such that you can't reasonably allocate it directly among those contracts. Electricity typically fits that bill; some companies allocate phone service to contracts, while some consider it an indirect cost; ditto with postage. So it's probably not unreasonable to consider the cost of being attached to the Internet an indirect cost that you bear in order to be "in the business". (I'm sure all of our contracts and legal people would have opinions on this; I'll bet they mostly don't read TCP-IP though!) Ken Pogran ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804140322.AA28126@ucbvax.Berkeley.EDU] <1988041312330000> From: pogran@CCQ.BBN.COM (Ken Pogran) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <8804140322.AA28126@ucbvax.Berkeley.EDU> Date: 13 Apr 88 12:33:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 Bill, Regarding packet-level accounting, and the auditability of shared gateway connections, etc.: There's an alternative approach, that I heard suggested by a (technically-oriented, not contract or financial) Government official. That is to consider the cost of the network attachment to be part of the corporation's infrastructure or overhead -- an indirect cost -- like any utility. That actually seems like a pretty good idea. After all, an indirect cost is one that you incur that benefits a number of contracts, and is such that you can't reasonably allocate it directly among those contracts. Electricity typically fits that bill; some companies allocate phone service to contracts, while some consider it an indirect cost; ditto with postage. So it's probably not unreasonable to consider the cost of being attached to the Internet an indirect cost that you bear in order to be "in the business". (I'm sure all of our contracts and legal people would have opinions on this; I'll bet they mostly don't read TCP-IP though!) Ken Pogran ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2045@louie.udel.EDU] <1988041314474700> From: garrett@udel.EDU (Joel Garrett) Newsgroups: comp.protocols.tcp-ip Subject: tn3270 for WIN/TCP 3.x... Message-ID: <2045@louie.udel.EDU> Date: 13 Apr 88 14:47:47 GMT Reply-To: garrett@udel.EDU (Joel Garrett) Organization: University of Delaware Lines: 12 Summary: Is there one? Is there some implementation of tn3270 available for VMS systems running WIN/TCP? I guess if there is some source available for a BSD 4.3 tn3270 it might run under Eunice 4.3 BSD, but is there som ething available that will compile under VAX C using only the stuff that comes with stand-alone WIN/TCP? Thanks in advance, Joel Garrett Research Associate CCM University of Delaware Newark, DE 19716 garrett@udel.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804131518.AA11956@XN.LL.MIT.EDU] <1988041315183600> From: glenn@XN.LL.MIT.EDU (Glenn Adams) Newsgroups: comp.protocols.tcp-ip Subject: SLIP working group? Message-ID: <8804131518.AA11956@XN.LL.MIT.EDU> Date: 13 Apr 88 15:18:36 GMT References: <8803301649.AA24991@bu-cs.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 > It's straightforward to turn on UDP checksumming > on a Sun, at worst you can fault them for not making it easier: > % adb -w -k /vmunix /dev/mem > udpcksum?W 1 > $q Perhaps someone has pointed it out already, but Sun's NFS doesn't use the standard udp_output() routine which allows enabling checksums via the udpcksum variable. Instead, they chose to bypass udp_output(), building UDP packets in ku_fastsend() (/sys/rpc/kudp_fastsend.c). This routine has no provision for enabling checksums such as does udp_output(). I rewrote ku_fastsend() for Sun 3.2, but haven't done so for recent Sun releases, primarily because I don't have the more recent sources. I think we should make a lot of noise to Sun to at least code in checksumming similar to udp_output(), giving the system manager the decision to enable or disable checksums. By the way, performance tests which I performed on my modified ku_fastsend(), indicated that the addition of checksumming only resulted in a 2% decrease in performance. I don't believe they (SUN) have actually tried it as they won't provide any data to back up their claim that checksumming is a big performance loss. Personally, I think Sun's decision to exclude checksums is quite unconscionable. Glenn Adams ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21618@bu-cs.BU.EDU] <1988041316544800> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <21618@bu-cs.BU.EDU> Date: 13 Apr 88 16:54:48 GMT References: Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.protocols.tcp-ip Organization: Boston Univ. Information Tech. Dept. Lines: 58 In article WWB.MDC@OFFICE-1.ARPA (Bill Barns) writes: >requirements of this type. Thus there is a concern that if the traditional >management approach (more or less dictated by audit considerations) is >employed, it might be necessary to have one physical interconnection for each >contract. > [...] >On the other hand, shared gateways are much cheaper. But at present it is not >evident that there is a way of allocating cost for shared gateways which would >be satisfactory to the government auditors. The port used by the gateway would >have to be paid for by one service component, including charges attributable to >other programs which might be contracted with other components, or may be >subject to different allowable pricing and cost recovery rules. > >The perceived bottom line here is that there is an implicit requirement for >packet-level accounting of IP traffic, and ultimately ISO IP traffic likewise, >through such a multiple-use interface. I don't agree with the premise that government accounting requires separate physical connections per contract. I assume that we are speaking of separate departments within your company, each of which has one or more separate contracts with separate charging, either fixed price or cost plus. You say that the auditors require per-packet charging to fairly allocate costs. Do they require each dept to pay a separate rent or to install separate phone systems or to buy their own furniture and pencils? They do not. Network costs could be set up as an overhead charge. Links to outside networks like the internet are flat rate and this cost could be allocated to each dept based on a formula. The only trick if there is one is the formula, but every organization has a formula for allocating basic telephone service with cost-per-message added on as needed [long distance billing, for example]. So long as your formula approximately distributes actual costs to all departments and only recovers actual costs and a share of other overhead, it should be acceptable to auditors. If MILnet goes to packet charging, and I don't see how they can do it, those costs could still be approximately redistributed according to a formula based on number of nodes, type of nodes, etc. [flame on] There is absolutely no reason that network access charges should be packet based. It makes no sense on a local area network like Ethernet and no sense in a packet internet. Users will not understand the charges (as well as contract auditors) and you won't be able to justify them. "Well, let's see your diskless workstation used 45k NFS packets last month." "What do you mean, all I did was read netnews!" Local area networks do not cost you on a per-packet basis and you don't need to recover on a per-packet basis. Per packet only works on (virtual) terminal networks, networks of the past. [flame off] Kent England, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8921@e.ms.uky.edu] <1988041320292700> From: david@ms.uky.edu (David Herron -- One of the vertebrae) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <8921@e.ms.uky.edu> Date: 13 Apr 88 20:29:27 GMT References: <21618@bu-cs.BU.EDU> Reply-To: david@ms.uky.edu (David Herron -- One of the vertebrae) Organization: U of Kentucky, Mathematical Sciences Lines: 36 In article <21618@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: > [flame on] There is absolutely no reason that network access >charges should be packet based. It makes no sense on a local area >network like Ethernet and no sense in a packet internet. Users will >not understand the charges (as well as contract auditors) and you >won't be able to justify them. "Well, let's see your diskless >workstation used 45k NFS packets last month." "What do you mean, all >I did was read netnews!" > > Local area networks do not cost you on a per-packet basis and >you don't need to recover on a per-packet basis. Per packet only >works on (virtual) terminal networks, networks of the past. [flame >off] I can't believe I'm about to argue for the grey suits, but here it is. It costs a certain amount of money to install/maintain an ethernet. Ethernet's have a certain maximum number of packets they can pass over a period of time. That ratio gives you a first guess at the cost per packet. The same holds true for some phone line which is being rented from the phone company which gives you 9600bps or 56k or t1 or whatever. That phone line costs x, you can do at most y through the line, so x/y gives you a cost per packet. The place where it's more obvious is a net that DOES charge per packet, like I understand X.25 nets do. As was pointed out rather eloquently from a gentleman in Australia, a charge per packet gives a different style of protocol than not having the charge. -- <---- David Herron -- The E-Mail guy <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- I don't have a Blue bone in my body! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804132104.AA19916@sneezy] <1988041321044400> From: cpw%sneezy@LANL.GOV (C. Philip Wood) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Message-ID: <8804132104.AA19916@sneezy> Date: 13 Apr 88 21:04:44 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 Hey, we all know that SUN is just a hardware company. We gotta figure where we can get the source and fix it ourselves. phil wood (cpw@lanl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [15@stanton.TCC.COM] <1988041401244400> From: donegan@stanton.TCC.COM (Steven P. Donegan) Newsgroups: comp.protocols.tcp-ip Subject: Re: mac-level bridges and internet arg Message-ID: <15@stanton.TCC.COM> Date: 14 Apr 88 01:24:44 GMT References: <8804120427.AA11751@ucbvax.Berkeley.EDU> Organization: Stanton Public Domain Systems, Stanton, Ca. Lines: 31 Summary: MAC Level Bridges - Effectively Transparent In article <8804120427.AA11751@ucbvax.Berkeley.EDU>, OWEN@AUDUCVAX.BITNET (Larry Owen) writes: > I know (or at least am laboring under the assumption) that all hosts > (connections) on a given physical network must (should?) use the same > network number in their internet address. What about MAC-level bridges > (Lan Bridge 100's, Vitalink Translans, and the like)? Are all ethernet > segments connected by these devices on a single net (for purposes of > internet addressing), or can each segment use a different network > (or subnet) number? > In our network (at the physical cable level) there are many different network protocols, internet addresses etc. I don't see any reason to force any one protocol or internet address (anyone with any horror stories?). We have a continuously growing number of sites connected via MAC level bridges and have had no problems getting any ethernet device from any vendor to cross the 'boundaries'. So my experience shows that: A) You do not HAVE to use the same internet address (or protocol) on a single physical media. B) You do not HAVE to use different internet addresses for different segments connected via a MAC level bridge. C) For management purposes you may WANT to implement different internet prefixes -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [16@stanton.TCC.COM] <1988041401264400> From: donegan@stanton.TCC.COM (Steven P. Donegan) Newsgroups: comp.protocols.tcp-ip Subject: Re: Executable image of PC-IP Message-ID: <16@stanton.TCC.COM> Date: 14 Apr 88 01:26:44 GMT References: <8804121506.AA13088@skl-crc.arpa> Organization: Stanton Public Domain Systems, Stanton, Ca. Lines: 8 Summary: 3-COM PC/IP Binaries Michael, I have a copy of the PC/IP binaries for the 3-COM 3c501 board. If that is what you need drop me a line and let me know. -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041404471000> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Thu 14 Apr 88 08:29:11-PDT To: Mike Muuss cc: tcp-ip@SRI-NIC.ARPA Subject: "... and statistics" (Re: [Phil Dykstra: more interesting numbers] ) In-reply-to: Your message of Thu, 14 Apr 88 03:45:05 -0400. <8804140345.aa14435@SEM.BRL.ARPA> Date: Thu, 14 Apr 88 11:27:10 -0400 From: Mike Brescia I think the Internet community would be better served if you could compare these gateways in some way. I want to point out that the LSI11 gateways on the arpanet/milnet border will drop packets and count them for reasons other than congestion, such as '1822 host dead' or 'net unreachable'. Also the "average" throughput is a measure of packets actually offered over the course of the day or week reporting period, so that 10 packets per second really means 864,000 packets in one day, not that the machine is somehow limited to 10 packets per second. While I can cite higher numbers over the 15 minute periods the statistics are sampled, both for arpanet-milnet gateways, and more so for ethernet-ethernet gateways, that still is a measure of handling offered load rather than limitation. There is also no indication whether the packets are long and saturate the communication lines, or short and saturate the gateway processor. Specifically on the msg from phil@brl... Some recently obtained per node averages for gateways: The seven BBN ARPA/MILNET Core gateways: 10.04 packets/sec 5.78 % drop rate (These gateways connect 2 wide area packet switch nets which have 56 kb and 9.6 kb lines.) (As a comparison, here are 2 lsi11 gateways' statistics from yesterday) ( tot sent avr/sec(day) peak/sec(15min) drop(day) ) (MILBBN 1.5e6 19.61 34.30 2.01% ) (CORPE(lan-lan) 1.4e6 18.16 50.01 0 ) The NSFNET Backbone "Fuzzball" gateways: 15.55 packets/sec 0.18 % drop rate (These 5(?) gateways connect to each other with 56 kb lines.) The Bld 394 BRL gateway: ~20 packets/sec ~0.8 % drop rate I would also look for more pleasing statistics from the arpa/mil gateways now that the processors have all been upgraded from dec lsi 11/23 to 11/73. Mike Brescia BBNCC Gateway Development Group ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041405194400> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Thu 14 Apr 88 09:27:19-PDT To: tcp-ip@SRI-NIC.ARPA cc: satlas@PARK-STREET.BBN.COM Subject: Processor Upgrade of LSI-11 Mailbridges Complete Date: Thu, 14 Apr 88 11:59:44 -0400 From: satlas@PARK-STREET.BBN.COM On Tues (4/12/88) MILSRI gateway was upgraded to an 11/73 processor. This completes the upgrade of all Mailbridges and EGP servers to 11/73s. Many thanks to Bob Enger for finding hardware donors and for coordinating the installation effort. Also thanks to the following people for the donation of processors and memory. Phil Karn Bellcore 7 processors Paul Pomes U of Illinios 1 processor 3 memory boards Bob Enger Contel 1 processor 3 memory boards Dan Tappan BBN 1 processor 1 memory board Bill Nesheim Thinking Machines 1 processor 1 memory board Mike Petry U of Maryland 2 processors The upgrade has made a dramatic change in the performance of these gateways and should help all of us who use the INTERNET. Dates of Upgrade GATEWAY DAY ------------------ BBN2 11/09/87 PURDUE 11/18/87 ISI 11/23/87 MILDCEC 11/23/87 YUMA 01/12/88 AERO 01/13/88 MINET 03/22/88 MILBBN 03/22/88 MILSAC 03/29/88 MILISI 03/30/88 MILARPA 03/31/88 MILLBL 04/06/88 MILSRI 04/12/88 Stephen Atlas BBNCC ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804140345.aa14435@SEM.BRL.ARPA] <1988041407450500> From: mike@BRL.ARPA (Mike Muuss) Newsgroups: comp.protocols.tcp-ip Subject: [Phil Dykstra: more interesting numbers] Message-ID: <8804140345.aa14435@SEM.BRL.ARPA> Date: 14 Apr 88 07:45:05 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 ----- Forwarded message # 1: Received: from brl-smoke.arpa by SEM.BRL.ARPA id aa10255; 31 Mar 88 21:59 EST Received: from brl-spark.arpa by SMOKE.brl.ARPA id aa16517; 31 Mar 88 21:55 EST Date: Thu, 31 Mar 88 21:45:08 EST From: Phil Dykstra To: datacom@BRL.ARPA Subject: more interesting numbers Message-ID: <8803312145.aa04086@SPARK.BRL.ARPA> Some recently obtained per node averages for gateways: The seven BBN ARPA/MILNET Core gateways: 10.04 packets/sec 5.78 % drop rate The NSFNET Backbone "Fuzzball" gateways: 15.55 packets/sec 0.18 % drop rate The Bld 394 BRL gateway: ~20 packets/sec ~0.8 % drop rate The vast majority of our dropped packets are comming from the currently sick Proteon Ring, so this value would normally be much lower. The 394 gateway is currently handling over 1.5 Million packets/day. The 328 gateway is probably similar. [I will have better data for BRL in a few weeks.] That's a lot of packets! - Phil ----- End of forwarded messages ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880414091722.4.dp@towntalk.nwyrkr.COM] <1988041409172200> From: dp@nwyrkr.UUCP Newsgroups: comp.protocols.tcp-ip Subject: A poem Message-ID: <880414091722.4.dp@towntalk.nwyrkr.COM> Date: 14 Apr 88 09:17:22 GMT Sender: news@nwyrkr.UUCP Organization: The New Yorker Magazine, NYC Lines: 32 THOUGHTS ON THE DEMISE OF THE ARPANET The Arpanet is going away, Hey, nonny, hey, hey, hey, We'll miss you, boys, But that's OK. You need your dollars, Your hardware too, To build the network That's right for you. So take your IMPS, Your TACS and spares, Your long-haul lines, Your other wares, Go back to the Pentagon, Close your doors, Come up with something That costs us more. And when you're finished Sit back and smile. Yes, our defenses Are right in style. Truly, colonels, It's good to know That soc.singles Has room to grow. -- dorothy parker ----MESSAGE-END---- ----MESSAGE-BEGIN---- [601@tuvie] <1988041411380800> From: rath@tuvie (Rath Martin) Newsgroups: comp.sys.mac,comp.protocols.tcp-ip Subject: Need TCP/IP for MacII, HELP !!! Message-ID: <601@tuvie> Date: 14 Apr 88 11:38:08 GMT Organization: TU Vienna EDP-Center, Vienna, AUSTRIA Lines: 10 Keywords: TCP/IP,MacII,TELNET,FTP,NCSA We URGENTLY need TCP/IP software for a Mac II with an EtherTalk Card. The most probfable candidate would be NCSA Telnet V2.1e. Maybe some kind soul could send it to us (binhexed). Thanks a lot !!! Martin Rathmayer, TU Vienna, EDP-Center MAIL: rath@tuvie.uucp ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804141331.AA26637@gateway.mitre.org] <1988041413314900> From: gross@GATEWAY.MITRE.ORG (Phill Gross) Newsgroups: comp.protocols.tcp-ip Subject: Re: [Phil Dykstra: more interesting numbers] Message-ID: <8804141331.AA26637@gateway.mitre.org> Date: 14 Apr 88 13:31:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Mike, Phil, Fascinating numbers. Do we understand why the mailbridges have such a higher drop rate? Until recently, of course, the 7 mailbridges were still clunky old LSI 11/23's. That would account for some performance difference since I believe the NSFnet Fuzzies are 73's. However, the IETF Adopt-A-Core-Gateway program finally caught up to the mailbridges a couple weeks ago, so they should all be 73's now too. What is the date for your numbers? Or is it that the mailbridges (indeed all core gateways) simply spend too much time processing routing updates and not enough time forwarding packets. Almost half the core traffic seems to be routing updates. That means for every other packet, the gateway has to go off and spend cycles thinking about something besides packet forwarding. (Oh where are those Butterflies?) Phill Gross ----MESSAGE-END---- ----MESSAGE-BEGIN---- [93400004@uiucdcsp] <1988041414510000> From: zweig@uiucdcsp.cs.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP route Message-ID: <93400004@uiucdcsp> Date: 14 Apr 88 14:51:00 GMT References: Lines: 12 Nf-ID: #R::-24:uiucdcsp:93400004:000:449 Nf-From: uiucdcsp.cs.uiuc.edu!zweig Apr 14 08:51:00 1988 Who pays for the packets containing the accounting information? (Seriously. I see lots of ovrhead with this scheme, and even gov't auditors should know that everyone would rather pay according to a possibly unfair approximate formula than pay (fairly) for the overhead of a weird scheme with per-packet charges all over the place.) Johnny Zweig Univ. of Ill. at Urbana-Champaign Dept. of Computer Science (generic standard vanilla disclaimer...) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2064@louie.udel.EDU] <1988041415192700> From: garrett@udel.EDU (Joel Garrett) Newsgroups: comp.protocols.tcp-ip Subject: Re: tn3270 for WIN/TCP 3.x... Message-ID: <2064@louie.udel.EDU> Date: 14 Apr 88 15:19:27 GMT References: <2045@louie.udel.EDU> Reply-To: garrett@udel.EDU (Joel Garrett) Organization: University of Delaware Lines: 20 I've received quite a few requests for any response I get on TWG's support for tn3270. I've tried sending mail to the people who asked, but our local mailer has bounced most of the attempts, so I'll just post my findings here. I talked with several people at TWG yesterday afternoon and came up with the following information: Yes, the current release of Eunice does have tn3270, but I don't think it is the version that supports VM/XA. They said that there probably wasn't a way to get the Eunice executable to run with the runtime executive that comes with WIN/TCP (REX) either. However, they did say that they would be including tn3270 with WIN/TCP v3.3 which should be out sometime this summer. (I know, 3.2 isn't even out yet, but they said that should be out in May) In the meantime I guess we'll all just have to go through some intermediate machine which does support tn3270. Hope this info helps, Joel ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804160621.AA08624@ucbvax.Berkeley.EDU] <1988041415271000> From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: "... and statistics" (Re: [Phil Dykstra: more interesting numbers] ) Message-ID: <8804160621.AA08624@ucbvax.Berkeley.EDU> Date: 14 Apr 88 15:27:10 GMT References: <8804140345.aa14435@SEM.BRL.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 44 I think the Internet community would be better served if you could compare these gateways in some way. I want to point out that the LSI11 gateways on the arpanet/milnet border will drop packets and count them for reasons other than congestion, such as '1822 host dead' or 'net unreachable'. Also the "average" throughput is a measure of packets actually offered over the course of the day or week reporting period, so that 10 packets per second really means 864,000 packets in one day, not that the machine is somehow limited to 10 packets per second. While I can cite higher numbers over the 15 minute periods the statistics are sampled, both for arpanet-milnet gateways, and more so for ethernet-ethernet gateways, that still is a measure of handling offered load rather than limitation. There is also no indication whether the packets are long and saturate the communication lines, or short and saturate the gateway processor. Specifically on the msg from phil@brl... Some recently obtained per node averages for gateways: The seven BBN ARPA/MILNET Core gateways: 10.04 packets/sec 5.78 % drop rate (These gateways connect 2 wide area packet switch nets which have 56 kb and 9.6 kb lines.) (As a comparison, here are 2 lsi11 gateways' statistics from yesterday) ( tot sent avr/sec(day) peak/sec(15min) drop(day) ) (MILBBN 1.5e6 19.61 34.30 2.01% ) (CORPE(lan-lan) 1.4e6 18.16 50.01 0 ) The NSFNET Backbone "Fuzzball" gateways: 15.55 packets/sec 0.18 % drop rate (These 5(?) gateways connect to each other with 56 kb lines.) The Bld 394 BRL gateway: ~20 packets/sec ~0.8 % drop rate I would also look for more pleasing statistics from the arpa/mil gateways now that the processors have all been upgraded from dec lsi 11/23 to 11/73. Mike Brescia BBNCC Gateway Development Group ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804160628.AA08741@ucbvax.Berkeley.EDU] <1988041415594400> From: satlas@PARK-STREET.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Processor Upgrade of LSI-11 Mailbridges Complete Message-ID: <8804160628.AA08741@ucbvax.Berkeley.EDU> Date: 14 Apr 88 15:59:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 38 On Tues (4/12/88) MILSRI gateway was upgraded to an 11/73 processor. This completes the upgrade of all Mailbridges and EGP servers to 11/73s. Many thanks to Bob Enger for finding hardware donors and for coordinating the installation effort. Also thanks to the following people for the donation of processors and memory. Phil Karn Bellcore 7 processors Paul Pomes U of Illinios 1 processor 3 memory boards Bob Enger Contel 1 processor 3 memory boards Dan Tappan BBN 1 processor 1 memory board Bill Nesheim Thinking Machines 1 processor 1 memory board Mike Petry U of Maryland 2 processors The upgrade has made a dramatic change in the performance of these gateways and should help all of us who use the INTERNET. Dates of Upgrade GATEWAY DAY ------------------ BBN2 11/09/87 PURDUE 11/18/87 ISI 11/23/87 MILDCEC 11/23/87 YUMA 01/12/88 AERO 01/13/88 MINET 03/22/88 MILBBN 03/22/88 MILSAC 03/29/88 MILISI 03/30/88 MILARPA 03/31/88 MILLBL 04/06/88 MILSRI 04/12/88 Stephen Atlas BBNCC ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804141303.aa05226@Huey.UDEL.EDU] <1988041417032700> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: [Phil Dykstra: more interesting numbers] Message-ID: <8804141303.aa05226@Huey.UDEL.EDU> Date: 14 Apr 88 17:03:27 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Phil, et al, From Mike Minnich's data presented at a recent IAB meting and other sources such as the LSI-11 reports issued by BBN, I suspect Phil's numbers are total aggregate and include ICMP and routing overheads. As you point out, between 40 and 60 percent of all mailbridge traffic is overhead, while the NSFNET backbone overhead is much lower. While the NSFNET backbone fuzzballs do use the 11/73, they are memory limited, not CPU limited. I would be surprised if this were not the case for the mailbridges, at least those using the 11/73. As reported in the SIGCOM 87 paper and in another submitted to SIGCOM 88, I would like to believe the difference in drop rates is due to the design of the NSFNET backfuzz selective-preemption and source-quench schemes. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10229@ulysses.homer.nj.att.com] <1988041418082800> From: smb@ulysses.homer.nj.att.com (Steven Bellovin) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Message-ID: <10229@ulysses.homer.nj.att.com> Date: 14 Apr 88 18:08:28 GMT References: <8803301649.AA24991@bu-cs.bu.edu> <8804131518.AA11956@XN.LL.MIT.EDU> Organization: AT&T Bell Laboratories, Murray Hill Lines: 10 Has anyone modified the SLIP driver to do ``fair queueuing''? SLIP links are sufficiently slow that a file transfer operation can make remote logins exceedingly unpleasant. A queuer that favored short packets, or perhaps one that did per-hostport queueing, would be helpful. (I know -- what I'm really asking for is type-of-service support, but then I'd have to change all of my applications, and perhaps my TCP/IPs, to request it.) --Steve Bellovin ulysses!smb smb@ulysses.att.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804141655.aa09734@Huey.UDEL.EDU] <1988041420551600> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: "... and statistics" (Re: [Phil Dykstra: more interesting numbers] ) Message-ID: <8804141655.aa09734@Huey.UDEL.EDU> Date: 14 Apr 88 20:55:16 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 Folks, Further to Mike Brescia's comments, the mailbridges are connected to virtual-circuit networks that may have some pretty stiff ideas on flow control, while the NSFNET backfuzz are connected only to each other via DDCMP serial lines and to Ethernets at each site. While the mailbridges can get beat up rather badly if some j-random host or gateway keels, the backfuzz can get blown up by a co-Ether Cray. My point is that the (seven) NSFNET critters face a quite different environment than the mailbridges and each may have predominantly different drop mechanisms. Nevertheless, I continue to think that engineered selective-preemption, source-quench and priority queueing disciplines could help improve mailbridge service in significant ways and (you saw this coming) consideration for these issues should be incorporated into their successors, both of the LSI-11 mailbridges and the NSFNET backfuzz. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804142040.aa20571@SEM.BRL.ARPA] <1988041500403100> From: mike@BRL.ARPA (Mike Muuss) Newsgroups: comp.protocols.tcp-ip Subject: Re: "... and statistics" (Re: [Phil Dykstra: more interesting numbers] ) Message-ID: <8804142040.aa20571@SEM.BRL.ARPA> Date: 15 Apr 88 00:40:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 37 The BRL Gateway mentioned in Phil's message is a DEC PDP-11/70 running the BRL-GATEWAY software under the LOS operating system. It has 3 InterLan Ethernet interfaces, one ProNet-10 ring interface, one ProNet-80 ring interface, and two ACC LH/DH-11 1822 interfaces, one running to MILNET IMP 29 via a 480,000 bps ECU link, and the other directly to BRLNET IMP #1. This is BRL-GATEWAY #1; gateway #2 is similar, with a substitution of a Hyperchannel for the ProNet-80, and only 1 Ethernet. The remaining 6-7 gateways on our campus are much simpler (typically a ProNet-10, an LH/DH, and an ethernet), and are built on smaller processors (11/24, 11/34, 11/44). The rates mentioned were average rates, intended merely to give folks some impression of the levels of inter-building traffic on our campus. We have measured 200 packets/sec as the maximum switching rate of our gateways, when link-limiting is not a factor (ie, using Ethernet or ProNet on both sides of the gateway when testing). This is a round-trip measure, ie, each packet traverses an interface in the gateway 4 times (we use FLOODPING for this statistic). Many would prefer to claim this as a peak rate of 400 packets/sec (2 interface traversals per "packet", counting the ping responses as a second packet) -- we would say "400 monodes/sec" in this case. This is not an attempt to put down the work of others, merely to report on behavior of older gateways at BRL. Clearly, the new commercial gateways have performance several times higher than this, and clearly, it is not a sensible idea to consider the purchase of PDP-11/70 systems for use as gateways. However, it makes a nice retirement job for our old friends, the 11/70s. Also, note that our campus is "traffic rich", with two Cray computers (a Cray X-M/P48 and a Cray-2) that talk TCP/IP, and with 6 Alliant FX/8 super-minis, along with over 100 other machines, many of which exchange high resolution 24-bit-deep color graphics images over the network on a regular basis. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804150231.AA06505@percival.cs.purdue.edu] <1988041502314000> From: narten@PURDUE.EDU (Thomas Narten) Newsgroups: comp.protocols.tcp-ip Subject: Re: [Phil Dykstra: more interesting numbers] Message-ID: <8804150231.AA06505@percival.cs.purdue.edu> Date: 15 Apr 88 02:31:40 GMT References: <8804141331.AA26637@gateway.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 > Almost half the core traffic seems to be routing updates. How true is that statement? The stats I have seen come from core gateways. Hardly a representative sample. Ignoring mailbridge traffic, one expects "real" traffic to go to and from "hosts", where hosts are non-core gateways to LANs, NSFnet, etc. An interesting statistic is last week's traffic stats for the purdue LSI-11 EGP core server: GWY RCVD RCVD IP % IP DEST % DST NAME DGRAMS BYTES ERRORS ERRORS UNRCH UNRCH PURDUE 7,184,830 1,097,986,642 101 0.00% 27,954 0.39% GWY SENT SENT DROPPED % DROPPED NAME DGRAMS BYTES DGRAMS DGRAMS PURDUE 7,557,696 1,424,771,755 24,090 0.32% That's an average of 11.9 and 12.5 pps respectively. The funny thing is, Purdue directs all its traffic out through its Butterfly gateway; the only Purdue traffic traveling through the LSI-11 would be misrouted packets. If we assume that an EGP connection exchanges one hello/I-H-U packet every 60 seconds, and one fragmented and one unfragmented NR update in place of a hello/I-H-U every 180 seconds, one expects 9 EGP packets every 180 seconds, 4 to the LSI, 5 from it. In addition, if we (over) estimate the number of EGP peers the 11 maintains at 260, egp traffic accounts for 260*(4/180) = 5.8 pps RCVD, 260*(5/180) = 7.2 pps SENT. Certainly GGP doesn't consume the remaining 5 pps. Who is responsible for the remaining traffic? Thomas Narten ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1112@infinet.UUCP] <1988041503075400> From: rhorn@infinet.UUCP (Rob Horn) Newsgroups: comp.protocols.tcp-ip Subject: SLIP CRC's and other reliability Message-ID: <1112@infinet.UUCP> Date: 15 Apr 88 03:07:54 GMT References: <8803300417.AA14103@beno.CSS.GOV> Reply-To: rhorn@infinet.UUCP (Rob Horn) Organization: Infinet, Inc. North Andover, MA Lines: 69 The practical engineering decision that CRC's are needed is based upon: assumptions about how SLIP will be used, assumptions about the environment that it will be used in, and cost (time, money, etc.) assumptions. To restate the often discovered and forgotten: IP checksums are mostly a network performance optimization. Transmission errors that escape IP checksums usually escape TCP and vice versa. (Note: I am already assuming that those concerned with reliability use TCP. This is only 95% correct.) So adding checksums to SLIP must be justified on network performance, not error detection. My concern is error detection. I think Rick Adams major mistake is in assuming that SLIP will only be used over voice channels, hence using modems. The errors characteristic of voice channel + modem are dropouts and random error bursts. A checksum is almost as good as a CRC at detecting these, so TCP works well. My assumption is that SLIP will be used over not only voice channels, but also muxes of many kinds, data PBX's, etc. The errors characteristic of these are dropouts, random error bursts, duplications, and transpositions. Checksums are very vulnerable to transpositions. Any even stride byte transposition will escape detection. Much more serious, TCP will probably also fail to detect it. I have experienced such errors with checksummed links through failing multiplexors. I think that a failure which escapes TCP is very serious and an option to detect it is very important. CRC's will catch transpositions. I only ask that CRC be available as a checking option. I see no need to burden a simple system with LAPB or whatever. If the CRC fails, just trash the packet. The cost of this is minor: a few days programming and a few instructions per byte. If you look at costs further, a more cost effective way to enhance reliability is forward error correction (FEC). Instead of retrying, spend cycles to fix damaged packets without retry. This is worthwhile whenever the incremental cost of FEC is less than the cost of retransmission. For a small system, time is what counts. Ten thousand instructions is nothing when compared to a retransmission. For a multi-user host, the tradeoff is not obvious. I have been contemplating a two-way interleaved (255,253) Reed-Solomon FEC with assumed nulls for message length matching. This code would fix: a) any single erroneous byte b) any two erroneous bytes with odd stride (including transposition) Other errors would result in either incorrect fixes or error detection. The incorrect fixes will trigger TCP checksum error detection, including transposition cases. My first complexity estimate is that this FEC would take about twice as much CPU as a 16-bit CRC (for undamaged packets) and would add 32 bits of FEC per 506 bytes of message instead of 16 bits of CRC. More robust FEC's exist if someone has good data on what errors need correction. This FEC alone will make a very big difference to a marginal voice or asynch digital channel. It can be cheaper than the cost difference between an error correcting modem and a normal modem to let the CPU spin a dozen extra instructions per byte. I have implemented LAPB on asynch and I think that FEC+IP+TCP would be faster, more reliable, and less software. -- Rob Horn UUCP: ...harvard!adelie!infinet!rhorn ...ulowell!infinet!rhorn, ..decvax!infinet!rhorn Snail: Infinet, 40 High St., North Andover, MA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13503@comp.vuw.ac.nz] <1988041503281700> From: jonathan@comp.vuw.ac.nz (Jonathan) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans,comp.os.minix Subject: advice wanted: Ethernet cards for IP/TCP + Minix Message-ID: <13503@comp.vuw.ac.nz> Date: 15 Apr 88 03:28:17 GMT Organization: Comp Sci, Victoria Univ., Wellington, New Zealand Lines: 42 Keywords: TCP, Ethernet, Minix, IBM-PC I need some advice on Ethernet boards and free (cheap?) TCP/IP implementations for IBM PC/AT clones. Source for the TCP is a must. The background is as follows: Some graduate students here are starting projects to implement IP/TCP over Ethernet on Minix. We currently have a couple of XT clones with 3C501 (3Com Etherlink) Ethernet boards, and source for PC/IP. We are sure that these will work together, though we have not yet installed PC/IP. We are about to get some more hardware for this project: AT clones (commodore PC-40s) and some kind of Ethernet boards. We have found local suppliers for two boards: 3c505 (3Com Etherlink+), and a Western Digital board. PC/IP does not have drivers for these cards. We also know KA9Q (sp?) exists, but don't know what cards it has drivers for. Does anyone know of drivers for these TCP implementations for either board? Also, could anyone comment on which boards (or software) would be least troublesome for Minix? One specific thing that concerns me is DMA. The WD board doesn't do DMA; I don't know about the 3Com board. Would moving data to and from the ethernet board via programmed I/O loops cause serious problems for Minix? Eg: do we have to disable interrupts? Could we lose asynch TTY interrupts? Will it kill response time? I know DMA is slower on ATs, but with a multi-tasking OS, there are considerations other than raw throughput. (I shouldn't have to say this, but mail any replies to me. If there is sufficient interest, I will summarise to the net.) Thanks in advance, Jonathan Stone Programmer/Student Comp Sci Dept Victoria University -- |`Toto, I have a feeling we're sane mailers: jonathan@comp.vuw.ac.nz | not in Kansas anymore ...'' UUCP path: ...!uunet!vuwcomp!jonathan | - Dorothy,arriving in Oz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804150036.aa13833@Huey.UDEL.EDU] <1988041504362700> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Message-ID: <8804150036.aa13833@Huey.UDEL.EDU> Date: 15 Apr 88 04:36:27 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 Steve, Yes, if what you mean by "fair queueing" (a term I find mesleading at best) is multiple priority queues in the conventional sense, the fuzzball gateways used on the NSFNET Backbone and at several other spots scattered over the US and Europe do that for all network links, including SLIP. The scheme is based on the Precedence field of the IP header, plus a few naughty tricks based on port number (when the precedence field is zero). Having used the scheme a lot on slow (9600 bps) serial links with SLIP and other link protocols, I can't say you should all go rush out and implement it. As implemented in the fuzzballs, priority scheduling ruthlessly shoves interactive traffic to the head of the queue, even if bulk-transfer (FTP, mail) traffic ends up waiting indefinitely at the end, then timing out. Then, little things like miscellaneous UDP and ICMP (ping) services sometimes stop working. Obviously, fancier service disciplines can be designed which would be more "fair," but the fuzzies have not yet learned those tricks. My point is not to discourage innovation in this area or even to conclude the fuzzball scheme does not work right; on the contrary, most of the time it works like a bandit. However, I do want to point out that the fairness issue is much more complex than you might suspect and deserves careful study in its own right. One of the most fertile experimental breeding swamps may well be hoked-up SLIP drivers for exactly the service you describe. After all, there are hundreds of times more Unix systems out there than fuzzballs. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041505490000> Received: from twg.com by SRI-NIC.ARPA with TCP; Mon 18 Apr 88 08:48:06-PDT Received: from TWG.COM by twg.com with SMTP ; Mon, 18 Apr 88 06:59:07 PST Received: from vax2.twg.com by Gonzo.TWG.COM id bp23982; 18 Apr 88 7:54 PDT Date: 15 Apr 88 12:49:00 PDT From: eva@TWG.COM MMDF-Warning: Parse error in original version of preceding line at TWG.COM Subject: Wollongong's TN3270 To: garrett cc: tcp-ip@sri-nic.arpa, dcrocker@TWG.COM MMDF-Warning: Parse error in original version of preceding line at TWG.COM Your message of yesterday concerning Wollongong's EUNICE and TCP products for VMS, contained some information that I would like to correct. We are currently investigeting how this incorrect information was relayed to you and we apologize for the confusion. However... Here are the true facts: 1/ TN3270 is available with EUNICE release 4.3.1 (from September 1987). As released, it has two known minor bugs, which we picked up from the Berkeley sources. They will be fixed in new EUNICE mainten ance release coming up in June. 2/ TN3270 is currently available only with EUNICE, not WIN/TCP. It requires "libcurses" library which is not supported under WIN/TCP, due to the requirement for a UNIX license. 3/ There is no WIN/TCP release 3.3 scheduled for this summer. The release following after 3.2 will be 4.0, which will be compatable with VMS 5.0. We do not yet have an announced release date for WIN/TCP 4.0. Eva Mitter EUNICE Project Leader Software Engineering The Wollongong Group eva@twg.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041506130000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Fri 15 Apr 88 09:37:00-PDT Date: 15 Apr 88 11:13:00 EST From: Subject: F I B R O N I C S Experiences Wanted To: "big-lan" cc: ,, , F I B R O N I C S We are considering the use of Fibronics FINET to link multiple ethernet segments within the same building. We will be running DECnet, XNS, TCP/IP, Appletalk/Ethertalk, and perhaps LAT. If anyone has experience using the FINET product (or can suggest an alternate) we would greatly appreciate your comments. Please respond directly to us, we will summarize to the net if there is interest, or to individual requesters. Thanks. Bob Enger CONTEL Federal Systems enger@bluto.scc.com 301-840-4040 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804150721.AA14117@bu-cs.bu.edu] <1988041507213500> From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Packet level accounting in IP routers? Message-ID: <8804150721.AA14117@bu-cs.bu.edu> Date: 15 Apr 88 07:21:35 GMT References: <8921@e.ms.uky.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Yes, but the problem is that those network elements cost the same amount if you don't use them. I dunno, there's something wrong with these cost accounting arguments, but I can't quite put my finger on it. Maybe that's it, you can't ever reclaim the unused capacity of a network, all idle time is lost forever, so why charge someone simply for making it not idle? Something like that. Back to the 1040... -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804150808.aa00849@CAD.USNA.MIL] <1988041513084200> From: tsmith@USNA.MIL ("Tim G. Smith", Mechanical) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <8804150808.aa00849@CAD.USNA.MIL> Date: 15 Apr 88 13:08:42 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 93 Kent England, Boston University writes < You say that the auditors require per-packet charging to < fairly allocate costs. Do they require each dept to pay a separate < rent or to install separate phone systems or to buy their own < furniture and pencils? They do not. That depends who you work for. < If MILnet goes to packet charging, and I don't see how they < can do it, those costs could still be approximately redistributed < according to a formula based on number of nodes, type of nodes, etc. Talk to the bean counters- it is not a case of IF, it is a case of WHEN. I also think it will be an administrative nightmare to handle the billing but that is not my problem. < [flame on] There is absolutely no reason that network access < charges should be packet based. It makes no sense on a local area < network like Ethernet and no sense in a packet internet. I tend to disagree- the gateways and the point to point links are running at higher and higher capacity. Some folks only use the MILnet to get and send small amounts of mail. Others use to FTP humongous files around and get news. Everyone bitches when the response times spiral and everyone gets hurt by it. I think everyone would like to see increased network bandwith. What should be done to raise the money to expand the network? Should the folks who use the network only sparingly have to bear the cost of the people who use the net heavily? < Users will not understand the charges (as well as contract < auditors) and you won't be able to justify them. "Well, let's see < your diskless workstation used 45k NFS packets last month." "What < do you mean, all I did was read netnews!" Well I guess we will have to do some educating. < Network costs could be set up as an overhead charge. Links to < outside networks like the internet are flat rate and this cost could < be allocated to each dept based on a formula. The only trick if there < is one is the formula, but every organization has a formula for < allocating basic telephone service with cost-per-message added on as < needed [long distance billing, for example]. So long as your formula < approximately distributes actual costs to all departments and only < recovers actual costs and a share of other overhead, it should be < acceptable to auditors. Yes there will be problems but that is life- chock full of problems. I would rather see a flat rate for internal (ie localy owned) network traffic. An analogy is trucks on toll roads. Do trucks pay more than motorcycles to use the road? Yes- because the maintenance the road will require for each truck that uses it is significantly greater than the maintenance required by a motorcycle using the road. (Tell me is your long distance bill on your telephone flat rate?) < Local area networks do not cost you on a per-packet basis and < you don't need to recover on a per-packet basis. Per packet only < works on (virtual) terminal networks, networks of the past. [flame < off] Sure they do. If you want to know the cost per packet of the network you take the cost of the network (hardware, phone lines, maintenance) divided by the total number of packets using it. That gives the cost per packet. I think we all need to remember that the Internet is a research project (a successful one it appears)- that is why its cost has been subsidized so heavily. We all have to face the fact that we are using the Internet just like we use telephones, mail, and other tools essential to our work. If we want to keep the service we are going to have to pay for it. If we don't want to pay for it then I suppose that we can all go back to using whatever we used before there was an Internet. Before I get flamed to death just let me say... I am not looking forward to the impending switch to per packet charges. I would rather see the flat rate continued. But if per packet charging will result in better service than so be it. I also can understand the reasoning that went into the decision to make the change. I think we all are going to have to simply learn to live with it. Tim Smith E-Mail : US mail:Tim Smith CADIG mailstop: 11G US Naval Academy Annapolis, MD 21402 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804151337.AA22421@XN.LL.MIT.EDU] <1988041513373900> From: glenn@XN.LL.MIT.EDU (Glenn Adams) Newsgroups: comp.protocols.tcp-ip Subject: Sun NFS UDP Checksum Fix Message-ID: <8804151337.AA22421@XN.LL.MIT.EDU> Date: 15 Apr 88 13:37:39 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 As many of you know, Sun NFS's use of UDP excludes checksumming the UDP packet. For lossy link layers such as SLIP, or for problem Ethernet controllers, this can result in getting garbage data when using remote mounted file systems. A modified version of kudp_fastsend.o is now available via anonymous FTP from XN.LL.MIT.EDU that employs UDP checksumming. Place this file in /sys/OBJ, saving your old object file, prior to building the kernel. The UDP checksumming is controlled by a global variable, kudpcksum, which is enabled by default. Note well that this only controls the GENERATION of checksums on transmitted NFS packets, it DOES NOT control the detection of checksum errors on received packets or non-NFS packets. To enable the latter, use adb to set the udpcksum variable to non-zero. By default, this latter variable is set to zero by Sun, thus disabling tests for checksum errors on incoming packets. It should be enabled to allow symmetrical checksumming on NFS. This fix will work on SUN OS versions 3.2 through 3.5. Glenn Adams MIT Lincoln Laboratory Internet: Glenn@XN.LL.MIT.EDU UUCP: {ames,cmcl2,decvax,harvard,mit-eddie}!ll-xn!glenn ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804160211.AA03631@ucbvax.Berkeley.EDU] <1988041516130000> From: enger@BLUTO.SCC.COM Newsgroups: comp.protocols.tcp-ip Subject: F I B R O N I C S Experiences Wanted Message-ID: <8804160211.AA03631@ucbvax.Berkeley.EDU> Date: 15 Apr 88 16:13:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 F I B R O N I C S We are considering the use of Fibronics FINET to link multiple ethernet segments within the same building. We will be running DECnet, XNS, TCP/IP, Appletalk/Ethertalk, and perhaps LAT. If anyone has experience using the FINET product (or can suggest an alternate) we would greatly appreciate your comments. Please respond directly to us, we will summarize to the net if there is interest, or to individual requesters. Thanks. Bob Enger CONTEL Federal Systems enger@bluto.scc.com 301-840-4040 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804151628.AA05954@cod.nosc.mil] <1988041516283700> From: neerma@COD.NOSC.MIL (Merle A. Neer) Newsgroups: comp.protocols.tcp-ip Subject: public domain tcp/ip Message-ID: <8804151628.AA05954@cod.nosc.mil> Date: 15 Apr 88 16:28:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 I am looking for a public domain tcp/ip package for PC DOS with a driver for 3COM 3C505. Please reply to : neerma at nosc.mil Thanks in advance, Merle ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804151649.AA02663@Larry.McRCIM.McGill.EDU] <1988041516494200> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <8804151649.AA02663@Larry.McRCIM.McGill.EDU> Date: 15 Apr 88 16:49:42 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 I remember being told once by a telco person that 80% of the toll collected on long lines was just to pay for the accounting process itself (this was in the days when they sent the armoured truck to pick up the AMA tapes). I don't know how much this has changed. I can easily see a significant amount of gateway resources (bandwidth, memory, CPU) being eaten up just by accounting, which would mean getting a more expensive box... so you would pay more to get what you get now. For this reason, I think the flat-rate charge is a good idea (but then I also favour rate-of-return over price-capping). -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23572@hi.unm.edu] <1988041517153300> From: cyrus@hi.unm.edu (Tait Cyrus) Newsgroups: comp.protocols.tcp-ip Subject: packet lengths Message-ID: <23572@hi.unm.edu> Date: 15 Apr 88 17:15:33 GMT Organization: U. of New Mexico, Albuquerque Lines: 28 Keywords: packet lengths vs IP lengths I have been comparing the lengths of packets specified in IP headers against actual packet lengths. What I am seeing, ignoring IP packets smaller than the minimum packet size, is that a fair number of machines send out packets that are 1-3 bytes longer than is specified by the IP length. Although this does not hurt anything, I am wondering why this is. Is it because some machines short/long/quad align the end of the packet before sending? Also, this phenomenon appears to be protocol dependent. For example, I saw several 4.3 machines doing this when sending out timed packets and routed packet, but not with other packets. I've seen our IP/TCP Imagen sending out UDP packets doing this. Although this does not hurt anything, I am just curious as to the reason why. -- @__________@ W. Tait Cyrus (505) 277-0806 /| /| University of New Mexico / | / | Dept of Electrical & Computer Engineering @__|_______@ | Parallel Processing Research Group (PPRG) | | | | UNM/LANL Hypercube Project | | hc | | Albuquerque, New Mexico 87131 | @.......|..@ | / | / e-mail: @/_________@/ cyrus@hc.dspo.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804182349.AA29557@ucbvax.Berkeley.EDU] <1988041519490000> From: eva@TWG.COM Newsgroups: comp.protocols.tcp-ip Subject: Wollongong's TN3270 Message-ID: <8804182349.AA29557@ucbvax.Berkeley.EDU> Date: 15 Apr 88 19:49:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 35 Your message of yesterday concerning Wollongong's EUNICE and TCP products for VMS, contained some information that I would like to correct. We are currently investigeting how this incorrect information was relayed to you and we apologize for the confusion. However... Here are the true facts: 1/ TN3270 is available with EUNICE release 4.3.1 (from September 1987). As released, it has two known minor bugs, which we picked up from the Berkeley sources. They will be fixed in new EUNICE mainten ance release coming up in June. 2/ TN3270 is currently available only with EUNICE, not WIN/TCP. It requires "libcurses" library which is not supported under WIN/TCP, due to the requirement for a UNIX license. 3/ There is no WIN/TCP release 3.3 scheduled for this summer. The release following after 3.2 will be 4.0, which will be compatable with VMS 5.0. We do not yet have an announced release date for WIN/TCP 4.0. Eva Mitter EUNICE Project Leader Software Engineering The Wollongong Group eva@twg.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [285@intek01.UUCP] <1988041522041200> From: mark@intek01.UUCP (Mark McWiggins) Newsgroups: comp.unix.xenix,comp.dcom.lans,comp.protocols.tcp-ip Subject: Bell Technologies 386 RFS "Cheap Ethernet" Message-ID: <285@intek01.UUCP> Date: 15 Apr 88 22:04:12 GMT Organization: Intek, Inc., Bellevue WA Lines: 23 Just got a mailing from Bell Technologies advertising their 386 Unix ($495 complete with manuals and an unlimited-user license). I've been reading about the price for months, but what caught my eye this time was this: "UNIX from Bell Technologies ships Ethernet ready with a complete RFS distributed file system -- just plug in a low-cost Ethernet card and go!" That's exactly what we'd like to do, preferably booting diskless nodes across the network, and running DOS Merge 386 underneath. Are you doing anything like this? Does it work? What kind of Ethernet card are you using and how much did it cost? (I haven't found out yet what Bell considers "low-cost".) Please E-mail (I don't have read access to comp.dcom.lans) and I'll summarize for the net. Thanks in advance. -- Mark McWiggins UUCP: uunet!intek01!mark DISCLAIMER: I could be wrong. INTERNET: mark@intek01.UUCP (206) 641-5014 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804152155.aa29614@SEM.BRL.ARPA] <1988041601555300> From: reschly@BRL.ARPA ("Robert J. Reschly Jr.") Newsgroups: comp.protocols.tcp-ip Subject: Re: "... and statistics" (Re: [Phil Dykstra: more interesting numbers] ) Message-ID: <8804152155.aa29614@SEM.BRL.ARPA> Date: 16 Apr 88 01:55:53 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 Mike writes: > ... Many would prefer to claim this as a peak rate of 400 packets/sec > (2 interface traversals per "packet", counting the ping responses as a > second packet) -- we would say "400 monodes/sec" in this case. Actually that should be "monograms" not "monodes". The term "monogram" is derived from the simile between "diodes" and "datagrams", and their one-legged cousins. (Ask Ron Natalie about "monodes" if you're interested). Later, Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804160645.AA03767@orc.olivetti.com] <1988041606453000> From: roode@orc.olivetti.COM (David Roode) Newsgroups: comp.protocols.tcp-ip Subject: bad press for NSFNET Message-ID: <8804160645.AA03767@orc.olivetti.com> Date: 16 Apr 88 06:45:30 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 The April 1988 issue of Data Communications magazine on p. 78 has an entry called "Kludgey NSF RT-based network?" It says it turns out each NSFNET T1 backbone switch will consist of from 3 to 9 RT's linked via a token ring. Local campuses will interface to one of the RT's via Ethernet and backbone trunks will be handled by multiple RT's. A dedicated RT will handle routing. The article then goes on to quote an unnamed 'key university network manager' who bemoans the 115 amps of current the switch will consume and the 32,500 BTU/h of cooling required. The article says power consumption was confirmed by the NSFnet operators, but says they referred the issue of heat dissipation to IBM. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23509@bbn.COM] <1988041616552000> From: wbe@bbn.com (Winston B Edmond) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <23509@bbn.COM> Date: 16 Apr 88 16:55:20 GMT References: <8921@e.ms.uky.edu> <8804150721.AA14117@bu-cs.bu.edu> Sender: news@bbn.COM Reply-To: wbe@BBN.COM (Winston B Edmond) Organization: BBN Laboratories Incorporated, Cambridge, MA Lines: 19 Barry Shein writes: > >Yes, but the problem is that those network elements cost the same >amount if you don't use them. > >I dunno, there's something wrong with these cost accounting arguments, >but I can't quite put my finger on it. > >Maybe that's it, you can't ever reclaim the unused capacity of a >network, all idle time is lost forever, so why charge someone simply >for making it not idle? Something like that. Back to the 1040... Indeed. The best charging scheme will probably be like the phone, electricity, and other utility bills: a basic charge for providing service at some level plus additional charges depending on usage and time of day (expected network loading). The problem is that in order to do the "depending on usage" part, one must implement per packet accounting, even if some usage is covered by the monthly flat rate. -WBE ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804162143.AA08987@malibu.usc.edu] <1988041621430900> From: tsudik@MALIBU.USC.EDU (Gene Tsudik) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <8804162143.AA08987@malibu.usc.edu> Date: 16 Apr 88 21:43:09 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Alternatively, a "best" charging scheme could be like the payphone scheme used in some European countries. There you pay for some fixed number of minutes and get a card (sorta like a debit card) and then you use it over time. One could simularly have a scheme where a machine (organization) buys X megabytes of data and uses it over time thus minimizing the extraneous traffic associated with accounting packet needed per connection. The scheme of course would have to be a little more complex than that. Per connection charges should also be available but discouraged. Gene Tsudik ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041700122500> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Sun 17 Apr 88 01:21:46-PDT Received: from UMDD.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 7168; Sun, 17 Apr 88 04:21:44 EDT Received: by UMDD (Mailer X1.23b) id 5859; Sun, 17 Apr 88 04:21:31 EDT Date: Sun, 17 Apr 88 04:12:25 EDT From: Bruce Crabill Subject: TCP state diagram mistake To: TCP-IP@SRI-NIC.ARPA This is probably a rediscovery of an old mistake, but in RFC-793 (TCP Protocol Specification) in the TCP Connection State Diagram on page 23, the transition from the SYN-SENT state to the SYN-RECEIVED state by the reception of a bare SYN, indicates that this should case a bare ACK to be sent. However, on page 32 (Simultaneous Connection Synchronizaton) and text on page 68, it would appear that the correct thing to do is to send a SYN,ACK. If this is a known problem, is there an RFC or other location where known problems are kept? Bruce ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804170013.aa05021@Huey.UDEL.EDU] <1988041704130800> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: bad press for NSFNET Message-ID: <8804170013.aa05021@Huey.UDEL.EDU> Date: 17 Apr 88 04:13:08 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 The reporter called me a month or so ago with the same quote. I told him that, even if the quote were correct, it had nothing to do with the functionality or performance of the net and was probably quoted out of context. Consider this: it could have been worse in the case of some other publications known to me. In the past I have had tailfeathers singed myself with publications quoting me out of context, so I have some sympathy for the quotee. Geeze, is it really 115 Amps? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804170022.aa05058@Huey.UDEL.EDU] <1988041704222100> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <8804170022.aa05058@Huey.UDEL.EDU> Date: 17 Apr 88 04:22:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Gene, You have discovered the Farecard used in the Washington Metro Underground (tube). You should ask a Washington dweller how well the Farecard dispensing machines work. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041707122900> Received: from vx2.GBA.NYU.EDU by SRI-NIC.ARPA with TCP; Sun 17 Apr 88 09:15:43-PDT Received: by vx2.GBA.NYU.EDU (5.51/) id AA00832; Sun, 17 Apr 88 12:12:32 EST Date: Sun, 17 Apr 1988 12:12:29 EST From: Ittai Hershman To: Mills@udel.edu Cc: Gene Tsudik , bbn.com!wbe@bbn.com, tcp-ip@sri-nic.arpa Office-Phone: 212-285-6080 Subject: Re: Packet level accounting in IP routers? In-Reply-To: Your message of Sun, 17 Apr 88 0:22:21 EDT Perhaps this should go to RISKS instead :-) When I was down at the TCP/IP Interoperability Conference in December, I found a few hours to go into town and meet a friend for lunch. I have a farecard I keep in my wallet which I use whenever I'm in DC -- miraculously it still worked. Well my friend decided to drag me to a State Dept press conference and I went through some metal detector. When I got back to the Metro station to return to Arlington, I discovered the farecard would not work (my Am Ex card was fine, and the farecard was readable in the station office's computer, but not by the turnstile). Maybe it was just a fluke, since I'm sure many State Dept employees ride the Metro, or maybe they have lead-lined wallets... Anyway, the discussion of farecards on the TCP-IP list was just too hard to pass up. -Ittai ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041708040000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 17 Apr 88 09:06:51-PDT Date: 17 Apr 1988 12:04-EDT Sender: CERF@A.ISI.EDU Subject: Re: Packet level accounting in IP routers? From: CERF@A.ISI.EDU To: kwe@BU-CS.BU.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]17-Apr-88 12:04:52.CERF> In-Reply-To: <21618@bu-cs.BU.EDU> Kent, Your flames seem a bit excessive (but I suppose that's a tautology...). In networks like the Internet there are components such as the gateways, wide area network switches, and shared trunks whose costs could reasonably be allocated on the basis of usage. When multiple administrations (such as DOE, DOD, NSF, HHS, etc.) share facilities, it is important to be able to demonstrate that costs are related to services rendered (used) in some fashion. The reason is that each agency quite properly could be asked by Congress, for instance, to show that it obtained its fair share of the facility (based on what it paid for). One might, as you suggest, some up with a formula for sharing some of the fixed cost of the network (a sort of base price you pay to be connected to the system at all). The issue of accounting becomes more significant as the services rendered become less research/experimental and more like commodities. Telephone services such as the Federal Telephone System run by the GSA are cost-allocated in accordance with usage and one doesn't find it odd to pay for telephone calls on the basis of time and distance. The parameters for packet nets may be different than for telephone voice service (maybe no distance charges). The important thing for the parties involved is to be able to demonstrate that there is a reasonable sharing of costs. I'm no longer with the government, so I certainly can't speak for the agencies involved, but I'm extrapolating from experiences I had at DARPA from 1976-82 when questions about access to ARPANET and sharing of costs were considered. One attractive thing about basing charges on usage is that as total usage goes up, it may be possible to make capital investments to increase capacity in a way that doesn't specifically require that all parties make an agreement to acquire more equipment - the service provider can buy it on the basis of increased usage and spread the cost in a reasonably equitable fashion. I'm not saying you couldn't do it on the basis of ports or nodes - the ARPANET did it that way for years - but thenit seemed to me a little harder to distribute the cost of adding a larger scale packet switch somewhere. In any case, the present focus on accounting is, in my view, important and valid and we should work to help the government folks find reasonable ways to implement it. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804170915.AA06490@ucbvax.Berkeley.EDU] <1988041708122500> From: BRUCE@UMDD.BITNET (Bruce Crabill) Newsgroups: comp.protocols.tcp-ip Subject: TCP state diagram mistake Message-ID: <8804170915.AA06490@ucbvax.Berkeley.EDU> Date: 17 Apr 88 08:12:25 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 This is probably a rediscovery of an old mistake, but in RFC-793 (TCP Protocol Specification) in the TCP Connection State Diagram on page 23, the transition from the SYN-SENT state to the SYN-RECEIVED state by the reception of a bare SYN, indicates that this should case a bare ACK to be sent. However, on page 32 (Simultaneous Connection Synchronizaton) and text on page 68, it would appear that the correct thing to do is to send a SYN,ACK. If this is a known problem, is there an RFC or other location where known problems are kept? Bruce ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041712082900> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Sun 17 Apr 88 15:55:36-PDT To: CERF@A.ISI.EDU cc: kwe@BU-CS.BU.EDU, tcp-ip@SRI-NIC.ARPA, haverty@CCV.BBN.COM Subject: Re: Packet level accounting in IP routers? In-reply-to: Your message of 17 Apr 88 12:04:00 -0400. <[A.ISI.EDU]17-Apr-88 12:04:52.CERF> Date: Sun, 17 Apr 88 18:48:29 -0400 From: haverty@CCV.BBN.COM Vint et al, One way we have found useful to think about accounting and charging in networks is to think of the network as a business. It has customers today, and offers a set of services to those customers with some charging policy ($0.45 an "ounce"?). In order to deliver those services it needs to acquire capital assets (lines, switches, satellites), and provide operations services (operators, field service, administrators). It can make a business decision between providing the services to its customers by use of its own assets (e.g., buy a satellite) or by use of services obtained from somewhere else (e.g., use dial-up trunks to provide service). At any point in time, the charter of the business is to provide the services to its clients at least cost, and to allocate those costs across the clients. Here's where it gets sticky. Clients' needs change, as new technology is introduced (e.g., 3D color workstations), and available communications technology changes as well as technology advances (fiber, etc.). Thus in order to stay in business, the network must plan to invest in new technologies, and must make smart business decisions about what to do and when in order to keep costs low, and remain competitive in the "marketplace". In addition to these 'engineering' kinds of decisions, the network must make 'marketing' decisions. For example, it might price a new service "unfairly" low, in order to encourage clients to upgrade (maybe mail should be cheaper if one uses the full domain server system?). There are also costs associated with "marketing", such as advertising (NIC management bulletins?) The point is that there is a large body of science and practice with elements such as depreciation, revenue, IR&D, etc which allows someone to place the network management into a business context. The real question is the one which the CEO of this hypothetical business has to answer - what is my business plan, how will I market my services, what should I invest in to remain competitive, etc. In the government network context, one should probably add the constraint that the network be non-profit, because of the limited competition and 'infrastructure' nature of the network. As far as charging algorithms go, that is the province of the hypothetical marketing department - how do I price my product. In the context of the current mail discussion, I think it is best to assume that somehow all of the costs must be recovered by charges, including costs for investments for the future. The real question is how to use a pricing policy to encourage the desired behavior. Perhaps triple charges for any host failing to obey a quench? As someone else pointed out, this is a real hot topic right now, and in fact I think it is a not insignificant flaw in the research activities that the methodology for 'chargeback' was not developed as part of the network architecture from day one. No one has 'the right answer' as far as I can see. Are there any MBAs or business school students who need a good meaty research area out there????? Jack ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]17-Apr-88.12:04:52.CERF] <1988041716040000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <[A.ISI.EDU]17-Apr-88.12:04:52.CERF> Date: 17 Apr 88 16:04:00 GMT References: <21618@bu-cs.BU.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 43 Kent, Your flames seem a bit excessive (but I suppose that's a tautology...). In networks like the Internet there are components such as the gateways, wide area network switches, and shared trunks whose costs could reasonably be allocated on the basis of usage. When multiple administrations (such as DOE, DOD, NSF, HHS, etc.) share facilities, it is important to be able to demonstrate that costs are related to services rendered (used) in some fashion. The reason is that each agency quite properly could be asked by Congress, for instance, to show that it obtained its fair share of the facility (based on what it paid for). One might, as you suggest, some up with a formula for sharing some of the fixed cost of the network (a sort of base price you pay to be connected to the system at all). The issue of accounting becomes more significant as the services rendered become less research/experimental and more like commodities. Telephone services such as the Federal Telephone System run by the GSA are cost-allocated in accordance with usage and one doesn't find it odd to pay for telephone calls on the basis of time and distance. The parameters for packet nets may be different than for telephone voice service (maybe no distance charges). The important thing for the parties involved is to be able to demonstrate that there is a reasonable sharing of costs. I'm no longer with the government, so I certainly can't speak for the agencies involved, but I'm extrapolating from experiences I had at DARPA from 1976-82 when questions about access to ARPANET and sharing of costs were considered. One attractive thing about basing charges on usage is that as total usage goes up, it may be possible to make capital investments to increase capacity in a way that doesn't specifically require that all parties make an agreement to acquire more equipment - the service provider can buy it on the basis of increased usage and spread the cost in a reasonably equitable fashion. I'm not saying you couldn't do it on the basis of ports or nodes - the ARPANET did it that way for years - but thenit seemed to me a little harder to distribute the cost of adding a larger scale packet switch somewhere. In any case, the present focus on accounting is, in my view, important and valid and we should work to help the government folks find reasonable ways to implement it. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041716490000> Received: from nswses.arpa by SRI-NIC.ARPA with TCP; Mon 18 Apr 88 00:54:21-PDT Date: 18 Apr 88 00:49:00 PST From: "TERVAX::EFBATEY" Subject: Packet accounting and a place to do it To: "tcp-ip" cc: efbatey Reply-To: "TERVAX::EFBATEY" I salute BARRY S.'s thought that it might be a little more complex to account the use by packets, by sites, by ... . Moreover, the internet, a-political as it is, is a place where intellectual processes are nurtured. Some of those might not be nurtured should a carelessly adopted plan evolve to choke off contributions of those automatically excluded by some carelessly adopted plan. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804180056.AA02604@ucbvax.Berkeley.EDU] <1988041717122900> From: ittai@VX2.GBA.NYU.EDU (Ittai Hershman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <8804180056.AA02604@ucbvax.Berkeley.EDU> Date: 17 Apr 88 17:12:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Perhaps this should go to RISKS instead :-) When I was down at the TCP/IP Interoperability Conference in December, I found a few hours to go into town and meet a friend for lunch. I have a farecard I keep in my wallet which I use whenever I'm in DC -- miraculously it still worked. Well my friend decided to drag me to a State Dept press conference and I went through some metal detector. When I got back to the Metro station to return to Arlington, I discovered the farecard would not work (my Am Ex card was fine, and the farecard was readable in the station office's computer, but not by the turnstile). Maybe it was just a fluke, since I'm sure many State Dept employees ride the Metro, or maybe they have lead-lined wallets... Anyway, the discussion of farecards on the TCP-IP list was just too hard to pass up. -Ittai ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4690@bloom-beacon.MIT.EDU] <1988041718471300> From: wesommer@athena.mit.edu (William Sommerfeld) Newsgroups: comp.protocols.tcp-ip Subject: Re: bad press for NSFNET Message-ID: <4690@bloom-beacon.MIT.EDU> Date: 17 Apr 88 18:47:13 GMT References: <8804170013.aa05021@Huey.UDEL.EDU> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: wesommer@athena.mit.edu (William Sommerfeld) Organization: Massachusetts Institute of Technology Lines: 20 In article <8804170013.aa05021@Huey.UDEL.EDU> Mills@UDEL.EDU writes: >Geeze, is it really 115 Amps? Well, if you believe what's printed on the back of the boxes, the IBM Reduced Taxes[1] desktop model is rated at 7.5 amps at 120VAC. The floor model is rated at 10 amps. The floor model has more expansion slots as well as room for up to three disk drives; the desktop model only has room for one internal disk. With 9 CPU's, that would be 67.5 or 90 amps total. RT's tend to run hot; you're not supposed to run them for very long (more than 5 minutes or so) with the cover off, or else they reportedly melt down. The CPU chips are mounted in massive heat sinks which are directly in the blast of a 4" fan. Four RT/PC's tend to keep a 10' x 20' room nice and toasty warm... - Bill [1] so called because it is rumoured that IBM gives more of them away than they sell... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804180113.AA03015@ucbvax.Berkeley.EDU] <1988041722482900> From: haverty@CCV.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <8804180113.AA03015@ucbvax.Berkeley.EDU> Date: 17 Apr 88 22:48:29 GMT References: <[A.ISI.EDU]17-Apr-88.12:04:52.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 59 Vint et al, One way we have found useful to think about accounting and charging in networks is to think of the network as a business. It has customers today, and offers a set of services to those customers with some charging policy ($0.45 an "ounce"?). In order to deliver those services it needs to acquire capital assets (lines, switches, satellites), and provide operations services (operators, field service, administrators). It can make a business decision between providing the services to its customers by use of its own assets (e.g., buy a satellite) or by use of services obtained from somewhere else (e.g., use dial-up trunks to provide service). At any point in time, the charter of the business is to provide the services to its clients at least cost, and to allocate those costs across the clients. Here's where it gets sticky. Clients' needs change, as new technology is introduced (e.g., 3D color workstations), and available communications technology changes as well as technology advances (fiber, etc.). Thus in order to stay in business, the network must plan to invest in new technologies, and must make smart business decisions about what to do and when in order to keep costs low, and remain competitive in the "marketplace". In addition to these 'engineering' kinds of decisions, the network must make 'marketing' decisions. For example, it might price a new service "unfairly" low, in order to encourage clients to upgrade (maybe mail should be cheaper if one uses the full domain server system?). There are also costs associated with "marketing", such as advertising (NIC management bulletins?) The point is that there is a large body of science and practice with elements such as depreciation, revenue, IR&D, etc which allows someone to place the network management into a business context. The real question is the one which the CEO of this hypothetical business has to answer - what is my business plan, how will I market my services, what should I invest in to remain competitive, etc. In the government network context, one should probably add the constraint that the network be non-profit, because of the limited competition and 'infrastructure' nature of the network. As far as charging algorithms go, that is the province of the hypothetical marketing department - how do I price my product. In the context of the current mail discussion, I think it is best to assume that somehow all of the costs must be recovered by charges, including costs for investments for the future. The real question is how to use a pricing policy to encourage the desired behavior. Perhaps triple charges for any host failing to obey a quench? As someone else pointed out, this is a real hot topic right now, and in fact I think it is a not insignificant flaw in the research activities that the methodology for 'chargeback' was not developed as part of the network architecture from day one. No one has 'the right answer' as far as I can see. Are there any MBAs or business school students who need a good meaty research area out there????? Jack ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804172041.aa11774@Huey.UDEL.EDU] <1988041800413400> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <8804172041.aa11774@Huey.UDEL.EDU> Date: 18 Apr 88 00:41:34 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Ittai, Well, in nine years Farecard machines munched not my oxide, but did munch the printer ribbons so I seldom knew how much money was left. I learned the trick of running an unreadable card through the machine anyway. If it spit the card back out, there was more than $2 on it. If it kept it there was less and you could get the card back by cancelling the transaction. The above trick is not well known and may rescue one of you someday. Try putting a Farecard through a credit-card reader. With this I promise to shut up. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041804150000> Received: from OAC.UCLA.EDU by SRI-NIC.ARPA with TCP; Mon 18 Apr 88 11:15:57-PDT Date: Mon, 18 Apr 88 11:15 PDT To: tcp-ip@SRI-NIC.ARPA From: Michael Stein Subject: Re: Packet level accounting in IP routers? > The "per packet accounting" load could be limited by using sampling > techniques, like the US Postal Service does when allocating costs > to government departments. Regards - Craig Is the overhead of counting packets really that high? I would assume that any IP router would have a "total" packet counter included in its overhead (1 counter). How much overhead would be added to count packets to each "interface" on the router (may already exist) and then "bill" each interface for it's count of packets? This doesn't divide the counts by host (IP address), possibly the hosts could be trusted to do that. (You would know the total). Hosts need accounting anyway, so that they can charge the packets back to the actual user anyway (assuming multiuser host). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804180443.AA04488@bu-cs.bu.edu] <1988041804435800> From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Packet level accounting in IP routers? Message-ID: <8804180443.AA04488@bu-cs.bu.edu> Date: 18 Apr 88 04:43:58 GMT References: <8804172310.AA13320@bu-cs.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 >Are there any MBAs or business school students who need a good meaty >research area out there????? > >Jack I agree wholeheartedly. As much as people like to tell themselves they understand the issues I honestly think this is the kind of thing for which professionals exist who can perhaps raise the level of the discussion beyond "is not" -- "is too". There are several models to look at (utility, infrastructure etc.) Just wandering around the machine room with a meter and wondering where to stick it is not the obvious answer. There are good reasons, for example, that you are not charged for every use of the road you drive on to go to the corner grocer but instead the costs are built into a larger structure. At the very least it would be interesting to hear what the goals are that people expect to accomplish with their proposed chargeback models, it's nice to have explicit goals and see if the models actually achieve them. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041804511400> Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by SRI-NIC.ARPA with TCP; Mon 18 Apr 88 08:34:30-PDT To: bruce%umdd.bitnet@cunyvm.cuny.edu cc: tcp-ip@sri-nic.ARPA Subject: re: TCP state diagram mistake Date: Mon, 18 Apr 88 11:31:14 -0400 From: Craig Partridge Bruce, There is actually a move afoot to write a Host specification document ala RFC 1009 (the Gateway specification). One of the sections in this document will be devoted to TCP. I'm responsible for writing the first draft of that section, and I plan to incorporate a list of known problems in the TCP RFC. Anyone who has a list of errors they've found in the TCP specification is encouraged to send those errors to me so they can be noted in the RFC. Craig PS: Bob Braden is editor-in-chief of this effort. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041804585800> Received: from LABS-N.BBN.COM by SRI-NIC.ARPA with TCP; Mon 18 Apr 88 06:07:44-PDT Date: Mon, 18 Apr 88 8:58:58 EDT From: Alex McKenzie To: tcp-ip@SRI-NIC.ARPA Subject: Accounting Jack and Barry have both said it right; a charging mechanism (tariff) is more than the rules for collecting money - it is also the concrete specification of a policy (and the only policy statement that really counts). Policies can be made to encourage or discourage connection to a network, encourage or discourage use of a network, or favor some classes of users over others. A proposed tariff has to be examined to see whether it supports or contradicts other "statements" of policy. For example, when DCA took over the ARPANET from ARPA in the mid-70's they adopted a "per-port" tariff because it was simple and predictable. The instantaneous response of the user community was the invention of a class of devices called "port expanders" which had no logical justification other than local cost minimization under the tariff, with a negative side-effect of making troubleshooting harder. Those are the kinds of effects which the folks formulating a tariff must be sensitive to. For every proposed tariff someone should ask, "If I had to pay according to this tariff, what would I do to minimize my own cost?" If we don't like the answer, the tariff should not be implemented. Alex ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041806580000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 18 Apr 88 08:13:26-PDT Date: 18 Apr 1988 10:58-EDT Sender: CERF@A.ISI.EDU Subject: Re: Accounting From: CERF@A.ISI.EDU To: mckenzie@LABS-N.BBN.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]18-Apr-88 10:58:11.CERF> In-Reply-To: The message of Mon, 18 Apr 88 8:58:58 EDT from Alex McKenzie Alex, I disagree with your assertion that the port expander was motivated by the per-port tariff on DDN/ARPANET. In fact, it was motivated by the fact that an IMP could only support 4 host ports at the time and we needed more connections but could not afford to pay for an entire IMP (the cost per port for a 4 port IMP was high; now IMPs can support many more ports at less cost per port). Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041806590000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 18 Apr 88 08:00:26-PDT Date: 18 Apr 1988 10:59-EDT Sender: CERF@A.ISI.EDU Subject: Re: Accounting From: CERF@A.ISI.EDU To: mckenzie@LABS-N.BBN.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]18-Apr-88 10:59:22.CERF> In-Reply-To: The message of Mon, 18 Apr 88 8:58:58 EDT from Alex McKenzie Addendum: It was CAPITAL cost, not operational cost, that motivated the port expander, in case it wasn't clear in my earlier response. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804180833.AA12023@ucbvax.Berkeley.EDU] <1988041808490000> From: efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY") Newsgroups: comp.protocols.tcp-ip Subject: Packet accounting and a place to do it Message-ID: <8804180833.AA12023@ucbvax.Berkeley.EDU> Date: 18 Apr 88 08:49:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "TERVAX::EFBATEY" Organization: The Internet Lines: 5 I salute BARRY S.'s thought that it might be a little more complex to account the use by packets, by sites, by ... . Moreover, the internet, a-political as it is, is a place where intellectual processes are nurtured. Some of those might not be nurtured should a carelessly adopted plan evolve to choke off contributions of those automatically excluded by some carelessly adopted plan. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804181606.AA19610@ucbvax.Berkeley.EDU] <1988041812585800> From: mckenzie@LABS-N.BBN.COM (Alex McKenzie) Newsgroups: comp.protocols.tcp-ip Subject: Accounting Message-ID: <8804181606.AA19610@ucbvax.Berkeley.EDU> Date: 18 Apr 88 12:58:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 Jack and Barry have both said it right; a charging mechanism (tariff) is more than the rules for collecting money - it is also the concrete specification of a policy (and the only policy statement that really counts). Policies can be made to encourage or discourage connection to a network, encourage or discourage use of a network, or favor some classes of users over others. A proposed tariff has to be examined to see whether it supports or contradicts other "statements" of policy. For example, when DCA took over the ARPANET from ARPA in the mid-70's they adopted a "per-port" tariff because it was simple and predictable. The instantaneous response of the user community was the invention of a class of devices called "port expanders" which had no logical justification other than local cost minimization under the tariff, with a negative side-effect of making troubleshooting harder. Those are the kinds of effects which the folks formulating a tariff must be sensitive to. For every proposed tariff someone should ask, "If I had to pay according to this tariff, what would I do to minimize my own cost?" If we don't like the answer, the tariff should not be implemented. Alex ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804181350.AA07046@mitre.arpa] <1988041813501500> From: mckee@MITRE.ARPA (H. Craig McKee) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <8804181350.AA07046@mitre.arpa> Date: 18 Apr 88 13:50:15 GMT References: <23509@bbn.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 9 >The problem is that in order to do the >"depending on usage" part, one must implement per packet accounting, >even if some usage is covered by the monthly flat rate. > -WBE The "per packet accounting" load could be limited by using sampling techniques, like the US Postal Service does when allocating costs to government departments. Regards - Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804181456.AA11953@cod.nosc.mil] <1988041814562600> From: neerma@COD.NOSC.MIL (Merle A. Neer) Newsgroups: comp.protocols.tcp-ip Subject: request for token ring experiences Message-ID: <8804181456.AA11953@cod.nosc.mil> Date: 18 Apr 88 14:56:26 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 We are planning to install an IBM token ring with PS/2s and IBM mainframes. Eventually there could be up to 200 PS/2s on the net. I'd be interested in hearing from those that have had IBM token ring experience to see what kind of problems we might enounter. Reply to : neerma at nosc.mil Thanks, Merle. ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]18-Apr-88.10:58:11.CERF] <1988041814580000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Accounting Message-ID: <[A.ISI.EDU]18-Apr-88.10:58:11.CERF> Date: 18 Apr 88 14:58:00 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Alex, I disagree with your assertion that the port expander was motivated by the per-port tariff on DDN/ARPANET. In fact, it was motivated by the fact that an IMP could only support 4 host ports at the time and we needed more connections but could not afford to pay for an entire IMP (the cost per port for a 4 port IMP was high; now IMPs can support many more ports at less cost per port). Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]18-Apr-88.10:59:22.CERF] <1988041814590000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Accounting Message-ID: <[A.ISI.EDU]18-Apr-88.10:59:22.CERF> Date: 18 Apr 88 14:59:00 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Addendum: It was CAPITAL cost, not operational cost, that motivated the port expander, in case it wasn't clear in my earlier response. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4632@watdcsu.waterloo.edu] <1988041815133800> From: alexew@watdcsu.waterloo.edu (A.E.Wielhouwer - Computing Services) Newsgroups: comp.protocols.tcp-ip Subject: Kinetic FastPath Keywords: TCP-IP, MAC, Ethernet Message-ID: <4632@watdcsu.waterloo.edu> Date: 18 Apr 88 15:13:38 GMT Distribution: na Organization: U of Waterloo, Ontario Lines: 16 Could someone please post or send me a synopsis of the capabilities of the Kinetics FastPath box and any equivalent systems in terms of: 1) connecting AppleTalk networks together - performance, addressing, special user knowledge and software considerations, etc. 2) using TCP-IP services from MACs - performance, addressing, special user knowledge, etc. By addressing, I am refering to 'how do I call a MAC on another net through the box' and whether or not each MAC requires an IP address, etc. Any info you may have would be appreciated. I'd like a user's opinion rather than a vendors. Thanks in advance. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804182241.AA28133@ucbvax.Berkeley.EDU] <1988041815311400> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: TCP state diagram mistake Message-ID: <8804182241.AA28133@ucbvax.Berkeley.EDU> Date: 18 Apr 88 15:31:14 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Bruce, There is actually a move afoot to write a Host specification document ala RFC 1009 (the Gateway specification). One of the sections in this document will be devoted to TCP. I'm responsible for writing the first draft of that section, and I plan to incorporate a list of known problems in the TCP RFC. Anyone who has a list of errors they've found in the TCP specification is encouraged to send those errors to me so they can be noted in the RFC. Craig PS: Bob Braden is editor-in-chief of this effort. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1983@hou2d.UUCP] <1988041817361600> From: n2dsy@hou2d.UUCP (G.BEATTIE) Newsgroups: rec.ham-radio,rec.ham-radio.packet,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc Subject: RATS Open Systems Environment (ROSE) Forum at the 1988 Dayton Hamvention Message-ID: <1983@hou2d.UUCP> Date: 18 Apr 88 17:36:16 GMT Organization: AT&T Bell Laboratories, Holmdel Lines: 88 Keywords: RATS ROSE Open Systems OSI ISO CCITT Amateur Radio The Radio Amateur Telecommunications Society 206 North Vivyen Street Bergenfield, New Jersey 07621 201-387-8896 The Radio Amateur Telecommunications Society (RATS) is proud to present a forum at the 1988 Dayton Hamvention called: ROSE: Open Systems Networking in the RATS Open Systems Environment The talk will focus on the reality of Open Systems Networking in Amateur Radio. The Society has been involved in the development of mail/file/directory servers and networking software based on international communications standards. Radio Amateurs who are telecommunications professionals or packet radio users will find this talk especially interesting and enlightening, but the novice networker will have no trouble following the presentation. * Software Distribution Currently, the beta version of the ROSE X.25 Packet Switch and the release of the ROSErver/Packet Radio MailBox System are available. The Society will distribute the latest releases of its software at the session. Bring 5-1/4 or 3- 1/2 inch diskettes for software and documentation. Remember RATS distributes its software for free! Come and get it! * Where to Find RATS at Dayton Members of RATS will be present in the PAC-COMM Packet Radio Systems booth (Booth 277/278). Members will be able to demonstrate and copy software for you to take home and use. Handouts describing our activities and frequencies of operation will be distributed at the packet forum on Friday afternoon from 1-5. We also are planning to be available for the Packet Get-Together at McNasty's on Saturday evening. The RATS ROSE Forum Time: 9:30 - 11:00 Place: ROOM 1 (check your programme to be sure) The forum will consist of three three 30 minute talks. Each will explore an aspect of the Open Systems implemented by the Radio Amateur Telecommunications Society (RATS). Questions will be taken by each speaker. Schedule 09:30 Review of Open Systems Networks and Protocols - Presented by J. Gordon Beattie, Jr., N2DSY This talk will provide an overview of a network based on Open Systems. The specific protocols and user services will be defined alone with the network management and planning dependencies found in a cooperative network. 10:00 The ROSE X.25 Packet Switch - Presented by Thomas A. Moulton, W2VY This talk will concentrate on the OSI Network Services and how the ROSE X.25 Switch will support the users of "vanilla" AX.25, OSI Applications, TCP/IP and Net/ROM. 10:30 The ROSErver Mail, File and Directory Server - Presented by Andrew R. Funk, KB7UV This talk will concentrate on OSI Application Services and how the ROSErver/Packet Radio Mail Box System will provide these services to users and other systems. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804190100.AA01036@ucbvax.Berkeley.EDU] <1988041818150000> From: CSYSMAS@OAC.UCLA.EDU (Michael Stein) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <8804190100.AA01036@ucbvax.Berkeley.EDU> Date: 18 Apr 88 18:15:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 > The "per packet accounting" load could be limited by using sampling > techniques, like the US Postal Service does when allocating costs > to government departments. Regards - Craig Is the overhead of counting packets really that high? I would assume that any IP router would have a "total" packet counter included in its overhead (1 counter). How much overhead would be added to count packets to each "interface" on the router (may already exist) and then "bill" each interface for it's count of packets? This doesn't divide the counts by host (IP address), possibly the hosts could be trusted to do that. (You would know the total). Hosts need accounting anyway, so that they can charge the packets back to the actual user anyway (assuming multiuser host). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [28900001@clio] <1988041823050000> From: berger@clio.las.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: bad press for NSFNET Message-ID: <28900001@clio> Date: 18 Apr 88 23:05:00 GMT Lines: 10 Nf-ID: #R:<8804160645.AA03767@orc.olivetti:-37:clio:28900001:000:256 Nf-From: clio.las.uiuc.edu!berger Apr 18 17:05:00 1988 Would anybody care to compare the old ARPA IMP boxes to this scheme? Mike Berger Department of Statistics Science, Technology, and Society University of Illinois berger@clio.las.uiuc.edu {ihnp4 | convex | pur-ee}!uiucuxc!clio!berger ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1455@pt.cs.cmu.edu] <1988041823143800> From: ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Message-ID: <1455@pt.cs.cmu.edu> Date: 18 Apr 88 23:14:38 GMT References: <8804150036.aa13833@Huey.UDEL.EDU> Sender: netnews@pt.cs.cmu.edu Organization: Carnegie-Mellon University, CS/RI Lines: 28 In article <8804150036.aa13833@Huey.UDEL.EDU> Mills@UDEL.EDU writes: >Steve, > >Yes, if what you mean by "fair queueing" (a term I find mesleading at best) >is multiple priority queues in the conventional sense, the fuzzball gateways ... do that for all network links, including SLIP. The scheme is >based on the Precedence field of the IP header, plus a few naughty tricks >... I can't say you should all go rush out and implement it. >... in the fuzzballs, priority scheduling ruthlessly shoves interactive >traffic to the head of the queue, even if bulk-transfer (FTP, mail) traffic >ends up waiting indefinitely at the end, then timing out. One might imagine something based on 'deadline scheduling', where a 'deadline to transmit', at which point some other layer will presumably retransmit. Theoretically (don't ask me - I can't prove it - I just heard it from an operating systems talk at another institution four years ago.) you can meet all the deadlines by picking the packet with the closest deadline first. [This assumes that all the deadlines can be met -- if they can't then you have a network enginerring problem which is beyond the scope of this message] Still not happy with interactive response? Then fragment those big packets and get the SLIP at the other end to unfragment them! Vendors everywhere will thank you for fully testing conformance of their TCP/IP implementations. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804181519.0.UUL1.3#948@fernwood.mpk.ca.us] <1988041823192600> From: geoff@fernwood.mpk.ca.us (Geoff Goodfellow) Newsgroups: comp.protocols.tcp-ip Subject: Thoughts on why packet accounting will be A Good Thing. Message-ID: <8804181519.0.UUL1.3#948@fernwood.mpk.ca.us> Date: 18 Apr 88 23:19:26 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 45 Packet accounting will make us use "our" networks more efficiently. Packet accounting will derail the virtual gravy train of network pork bellying we've grown accustom on "our" network. Packet accounting will engender new protocols which give us The Look and Feel of today's full duplex, character at-a-time, remote echo telnets & rlogins with local echo transmit-when-needed efficiency. Look how packet accounting networks such as Telenet & Tymnet have developed vs. "our" networks sans accounting. Packet accounting network users usually send terminal traffic line at a time and do local character echoing at the PAD or user telnet level. "Our" networks send telnet/rlogin traffic character at a time and echo at the remote host. No doubt "their" network is making a better use of its bandwidth (although "ours" may currently be `nicer' to use -- but at what cost?). We never really had the incentive to develop austere networking protocols because "our" network was usage and cost sensitive "free". Whether your IMP port sent 1 or a 1,000,000 packets a day, week or year, the cost was the same. Old Time Network Boys will remember the ARPANET's attempt in the early 70's at local echoing of telnet with RCTE via NCP. As i recall from that time, the purpose of RCTE was for the users in Hawaii, London/UK & Oslo/Norway to receive fast/local-like character echoing, not really to cut down on network traffic. I think the TIPs (what today's TACs were previously called), Tenex and MIT-Multics were the only hosts to implement RCTE. RCTE was never fully debugged and used in an operational mode (and i recall Mit-Multics only used RCTE to turn off echoing for passwords at login time). It did not seem to survive the NCP to TCP/IP transition. R.I.P RCTE Network bandwidth conservation is not only A Good Thing for "our" networks, but is an important efficiency in some networking technologies which have very finite amounts of bandwidth available to them such as packet radio, cellular and satellite. With these technologies in the commercial market place, it's not always possible to throw more capacity to gain bandwidth. There is only so much radio spectrum available. We need to be so ever parsimonious with our existing bandwidth/spectrum as possible. Perhaps packet accounting will bring about the networking equivalent of the 70s energy crisis. Fuel efficiency considerations and non OPEC sources of energy suddenly became the seminal issues of the day. Research and development ensued for more efficient motors. Alternate forms for fuel were explored and some developed such as synthetic. May necessity be "our" mother of invention too. __ Geoff Goodfellow fernwood!Geoff@sri-unix.arpa ..!sri-unix!fernwood!Geoff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804190202.AA18221@bu-cs.bu.edu] <1988041902025200> From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Thoughts on why packet accounting will be A Good Thing. Message-ID: <8804190202.AA18221@bu-cs.bu.edu> Date: 19 Apr 88 02:02:52 GMT References: <8804181519.0.UUL1.3#948@fernwood.mpk.ca.us> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 By the same token (pardon me) we could argue to raise the fares on on Rte 128 (for the w. coast, 101) until that messy thing called rush hour just stops. Of course, the sudden absence of employees will be a mere artifact of these nice, manageable highways, it is ignorable. I don't know about software engineering by dear resource, it's not self-evident to me. Computing resources have gotten really cheap lately and I daresay they have engendered better software, not worse. For once in history it is becoming clear who will serve whom (you can't tell me that JCL wasn't an attempt to make man serve the computer rather than the other way around.) Let's be real careful, that's all, I ain't sayin' yes and I ain't sayin' no... -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804190317.AA05848@Larry.McRCIM.McGill.EDU] <1988041903175700> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) Newsgroups: comp.protocols.tcp-ip Subject: Re: Thoughts on why packet accounting will be A Good Thing. Message-ID: <8804190317.AA05848@Larry.McRCIM.McGill.EDU> Date: 19 Apr 88 03:17:57 GMT Sender: uucp@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 4. Charge for higher level services based upon the service (eg. charge for local logins at one rate, remote logins at another rate, based upon connect time, as other services develop their charging units should also develop, distributed data base access based upon queries etc.) As long as we are being open-minded (and perhaps a tad unrealistic), why not charge on the basis of utility derived from a service? I know this is extremely subjective, but I have always been opposed to paying for a service by the service-unit (say packets or message-units) when the actual quality can vary tremendously. Should you pay as much for network usage when the latency and/or lossage is high? Or for SYNs sent to a host that is unreachable because their IMP crashed? If we all had extremely current, well-behaved TCPs then we wouldn't have to worry about paying for packets that are redundant (say the RTT calculation is off and you start retransmitting prematurely). But most of us are constrained to use commercial software that is of varying quality and functionality. I guess I'm moaning about a problem without presenting any sort of solution, but I feel it is something to be considered. As an aside, I would like to see "collect" packets (charged to destination) for mailing lists. There is no reason that the people who provide these enormously useful mailing lists (_not_ soc.singles) and invest time and resources should be further penalized. Maybe FTP clearing houses as well... -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1054@thumper.bellcore.com] <1988041905590500> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: rec.ham-radio,rec.ham-radio.packet,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc Subject: TCP/IP at Dayton and Trenton Message-ID: <1054@thumper.bellcore.com> Date: 19 Apr 88 05:59:05 GMT References: <1983@hou2d.UUCP> Organization: Bell Communications Research, Inc Lines: 48 Keywords: TCP IP ARPA Internet KA9Q Summary: KA9Q TCP/IP software available at Dayton The KA9Q Internet Protocol Package will also be described and demonstrated at both the Trenton Computer Festival and at the Dayton Hamvention. This package is now estimated to be in the hands of at least several thousand people around the world, and it is enjoying rapidly increasing popularity on amateur packet radio. It presently supports the following proven, industry standard protocols: Applications: Telnet - remote login and "chatting" FTP - File transfer (binary or text) SMTP - Mail transfer Transport/Session: TCP - Transmission Control Protocol UDP - User Datagram Protocol Network: IP - Internet Protocol ICMP - Internet Control Message Protocol Link/Subnet: ARP - Address Resolution Protocol Ethernet - 3Com 3C-501 interface driver AX.25 - packet radio (both connected and unconnected modes) SLIP - asynchronous point-to-point links The primary machine supported is the IBM PC (and clones). Versions are also available for the Apple Macintosh, Commodore Amiga, and UNIX System V. The entire package, which includes complete C source code and documentation, is copyrighted by myself and others, but it is completely FREE for noncommercial use. I encourage you to make copies for your friends back home; this minimizes the number of copies I have to make. I will bring a limited supply of copies, but bring your own blank disks if you want to be sure of getting a copy. The package fits on one high-density 1.2 meg 5.25" floppy, two 720K 3.5" floppies, or three 360K 5.25" floppies. I should be able to handle all three formats at both Trenton and Dayton. For those of you with Internet access, you may obtain the package by anonymous FTP from louie.udel.edu (10.0.0.96) under /pub/ka9q. 73, Phil Karn, KA9Q ----MESSAGE-END---- ----MESSAGE-BEGIN---- [WANCHO.12391659408.BABYL@SIMTEL20.ARPA] <1988041910180000> From: WANCHO@SIMTEL20.ARPA ("Frank J. Wancho") Newsgroups: comp.protocols.tcp-ip Subject: Accounting Message-ID: Date: 19 Apr 88 10:18:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 46 Last year I sent out a message outlining the pitfalls and problems with the per-packet chargeback algorithm to be levied on the MILNET hosts and gateways. No response at that time. Since then, the ARPANET Lives message came out, hinting at the imposition of similar charges for ARPANET hosts, followed recently by Bill Barnes' query. That combination must have triggered a sympathetic reaction. Let me point out several points to ponder: 1. Unlike the ARPANET, the MILNET backbone users have been offered not one single carrot/reason for the charges, such as the promise of an improved, high-speed backbone. The ONLY reason is to divide the EXISTING cost of the MILNET backbone among the services based on the usage by each service. (Service means Army, Navy, Air Force, etc.) 2. The mods to the PSN software have been in-place for over a year with delayed monthly charge reports being produced as a paper exercise only to check for accuracy and format. All that is required at this point to implement the scheme is the declaration of the date on which the paper charges become real. It would then be up to each service to pay the bills, possibly going back to charge each facility connected to the backbone - the reports are supplied at that level. I suspect that the effort to change the rates charged would be trivial as that would be a post-processing change. But, the effort required to change the underlying traffic collection algorithm would certainly be non-trivial at this point. 3. The algorithm itself is flawed (in my opinion): it is based on charges only for outgoing packets, and TAC access (including connect time, not just packet charges - in BOTH directions). That severely penalizes hosts which act as mailing list distribution points, those which offer anonymous ftp access, and those which allow telnet access, particularly from TACs. 4. Geoff is right. Given the rates and charging algorithm, we will find expedient solutions: shut down our mailing list redistributions, disallow all ftp and telnet access, including outgoing ftp and telnet, and move off the backbone... To answer Bill's query: the network applications programs on the hosts connected directly or indirectly to the corporate gateway(s) would have to tag each outgoing packet with a cost center code which is then counted and stripped at the gateway(s) prior to entering the backbone. I know it's absurd, but that is the "correct" method to keep the bean counters happy. --Frank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804191025.AA15331@LANAI.MCL.UNISYS.COM] <1988041910250100> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Thoughts on why packet accounting will be A Good Thing. Message-ID: <8804191025.AA15331@LANAI.MCL.UNISYS.COM> Date: 19 Apr 88 10:25:01 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Barry, Your comment about the fares on Rte 128 ring too close to home here in No. VA where you cannot ride the 'freeways' during rush hour (on I66) unless you have 4 or more in the car. Recent sentiment expressed in the paper indicates that this will not go away, but willexpand in concept. We are also going to build a private tole road. So, if with hiways, why not networks. Pay and 'packet pool'! dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804191328.AA25552@bu-cs.bu.edu] <1988041913280900> From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Thoughts on why packet accounting will be A Good Thing. Message-ID: <8804191328.AA25552@bu-cs.bu.edu> Date: 19 Apr 88 13:28:09 GMT References: <8804191025.AA15331@LANAI.MCL.UNISYS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 56 >So, if with hiways, why not networks. Pay and 'packet pool'! > >dennis Because we don't have a cartel forcing the price up on bits? (joke) Dennis, it's not a moral imperative or something that one can prove easily is right or wrong. I guess the problem is simply that whatever one does they are forced to engage in a form of social engineering. Unless the charges are so trivial that they can be ignored (in which case they won't have any effect on traffic volume) it will become a decision factor. Some folks have pointed out how this can be a good thing and I was trying to point out that this can also be a bad thing. I guess my views come down to whether we are metering the right thing, not really any PollyAnna view that someone won't pay the bill. For example, why not charge for the length of cable used to hook someone up, by the foot? That's a more direct cost than packet usage, wire costs, bandwidth only costs when you don't have enough (that is, what value is an unused wire?) If charging by the foot doesn't ring true with you then now you have insight into my feelings about metering packets. Places to charge: 1. One-time at point of hookup or, similarly, "rental of equipment" (eg. flat monthly rate.) 2. Per packet 3. Taxation model (thou shalt contribute N% of your overhead to networking.) This is probably the current model even tho it's not obvious to the casual observer (eg what agencies spend on networks they don't spend on other research costs, it's a witholding tax...) I realize that PSN hookups are charged and can more resemble (1), but that's a small part of the picture. 4. Charge for higher level services based upon the service (eg. charge for local logins at one rate, remote logins at another rate, based upon connect time, as other services develop their charging units should also develop, distributed data base access based upon queries etc.) I am sure there are others, I just don't see what's so compelling about packets as the charging unit other than it seems simple and straightforward (as many have pointed out, it really isn't very simple nor straightforward once we consider the details of implementation.) Personally I tend towards the taxation model which could be expanded because it gibes with my view of network as infrastructure rather than utility. Even the traditional public utilities have recognized these sorts of alternate models (eg. 800 numbers) to per-unit charging. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988041913374100> Received: from SUVM.ACS.SYR.EDU by SRI-NIC.ARPA with TCP; Tue 19 Apr 88 15:41:02-PDT Received: from SUVM.BITNET by SUVM.ACS.SYR.EDU ; Tue, 19 Apr 88 18:40:21 LCL Received: by SUVM (Mailer X1.25) id 6632; Tue, 19 Apr 88 18:40:20 LCL Date: Tue, 19 Apr 1988 18:37:41 LCL From: GRFXLS@SUVM.ACS.SYR.EDU To: TCP-IP@SRI-NIC.ARPA I'm sorry if I am at the wrong group. I'd like to find out where I could get parts for AT&T7300. I am looking for a power supply and 20 MB harddisk. Please, send me a mail if you have any information about it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804190912.AA01404@wb6rqn.UUCP] <1988041914122900> From: brian@wb6rqn.UUCP (Brian Lloyd) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting Message-ID: <8804190912.AA01404@wb6rqn.UUCP> Date: 19 Apr 88 14:12:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 Just because you see a packet doesn't mean that it arrived at the destination. For this reason counting packets in a lossy network is very unfair to the subscriber. The only place in IP/TCP/UDP where you can actually measure delivered packets is in TCP or UDP (only at the destination in the case of UDP). This makes accounting in a datagram based network non-trivial. Perhaps this is why the PTTs have adopted VC based networks. At least they know when a packet has been delivered to the host (or at least the edge of their network) and can charge reliably. Has anyone thought to define the measure of service delivered? Is it really the number and size of packets delivered? Off the top of my head I cannot think of another measure but that does not mean that there isn't one. Maybe a definition of service is in order before a discussion of service measurment. Brian Lloyd, President Sirius Systems, Inc. 19200 Tilford Way, Germantown, MD 20874 (301) 540-2066 brian@wb6rqn.uucp Share and enjoy! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [769@sun.soe.clarkson.edu] <1988041915335900> From: nelson@sun.soe.clarkson.edu (Russ Nelson) Newsgroups: rec.ham-radio,rec.ham-radio.packet,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc Subject: Re: TCP/IP at Dayton and Trenton Message-ID: <769@sun.soe.clarkson.edu> Date: 19 Apr 88 15:33:59 GMT References: <1983@hou2d.UUCP> <1054@thumper.bellcore.com> Reply-To: nelson@sun.soe.clarkson.edu.UUCP (Russ Nelson) Organization: Clarkson University, Potsdam, NY Lines: 16 Keywords: TCP IP ARPA Internet KA9Q In article <1054@thumper.bellcore.com> karn@thumper.bellcore.com (Phil R. Karn) writes: >The KA9Q Internet Protocol Package will also be described and >demonstrated at both the Trenton Computer Festival ... >The entire package, which includes complete C source code ... >I will bring a limited supply of copies, but bring your own blank disks >if you want to be sure of getting a copy. ... I'll give Phil a few copies of my Turbo C porting kit on 5 1/4 360 K disks. The porting kit is updated to version 871225.18, and is on clutx.clarkson.edu [128.153.4.3] in pub/Ka9q/kit.arc via anonymous ftp. -- char *reply-to-russ(int network) { if(network == BITNET) return "NELSON@CLUTX"; else return "nelson@clutx.clarkson.edu"; } ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804191548.AA01718@uc.msc.umn.edu] <1988041915481900> From: slevy@UC.MSC.UMN.EDU ("Stuart Levy") Newsgroups: comp.protocols.tcp-ip Subject: Re: Thoughts on why packet accounting will be A Good Thing. Message-ID: <8804191548.AA01718@uc.msc.umn.edu> Date: 19 Apr 88 15:48:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Plug: A proposal for X.3-style line buffering, echo control, output flushing etc. has just been published as RFC 1053. It works pretty well for X.25 networks and can probably do the same on wide-area TCP networks. Stuart Levy, Minnesota Supercomputer Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804191238.aa03821@Huey.UDEL.EDU] <1988041916382700> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Message-ID: <8804191238.aa03821@Huey.UDEL.EDU> Date: 19 Apr 88 16:38:27 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Ralph, There are lots of schemes to deal with the unfairness issue I mentioned, the most attractive of which may be based on schedule-to-deadline principles you mention. While fragmentation can be used to reduce latency, you have to be careful how the fragmentation is done. Those implementations I know about transmit all fragments of a gram one after the other, which would defeat the purpose. Fuzzballs (and maybe others I don't know about) requeue the datagram (with updated fragmentation info) after each fragment transmission. This results in a two-tier discipline; FB(n) (FIFO order in each priority queue) for grams less than the MTU and RR (round-robin in each priority queue) otherwise. Yes, the thought has struck me that actual queue priority could be adjusted for each fragment and also elapsed time on the queue. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12391742604.15.BILLW@MATHOM.CISCO.COM] <1988041917550900> From: BILLW@MATHOM.CISCO.COM (William Westfield) Newsgroups: comp.protocols.tcp-ip Subject: Re: Thoughts on why packet accounting will be A Good Thing. Message-ID: <12391742604.15.BILLW@MATHOM.CISCO.COM> Date: 19 Apr 88 17:55:09 GMT References: <8804191548.AA01718@uc.msc.umn.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 And there is also an IDEA016 "Telnet local edit option" from the people at Cray. Just what us vendor type people love. Multiple standards to do the same thing. Well, not quite the same thing. While RFC1053 proposes a PAD view of the world, IDEA016 proposes a unix view of the world (complete with local handling of signals). Personally, I'd like to mix up the two, and add some tops20-like features, like a full break mask, and some things that haven't ever existed, like a full echo mask. Oh well, I guess I just get to wait and see what happens. Bill Westfield cisco Systems ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804191850.AA03753@larry.cs.washington.edu] <1988041918504100> From: randy@LARRY.CS.WASHINGTON.EDU (Randy) Newsgroups: comp.protocols.tcp-ip Subject: Re: packet lengths Message-ID: <8804191850.AA03753@larry.cs.washington.edu> Date: 19 Apr 88 18:50:41 GMT References: <23572@hi.unm.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 What do you mean by "actual packet lengths"? If you mean the length field specified by the ethernet header, then be aware that the smallest legal ethernet packet is 64 bytes (counting header and checksum). If the IP part of the ethernet packet is smaller than 48 bytes (64- header), then the packet will be padded with garbage. Randy Day. Internet (ARPA): randy@cs.washington.edu CSNET: randy%washington@relay.cs.net UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804191854.AA00089@apolling.imagen.uucp] <1988041918544800> From: geof@imagen.UUCP (Geof Cooper) Newsgroups: comp.protocols.tcp-ip Subject: Re: packet lengths Message-ID: <8804191854.AA00089@apolling.imagen.uucp> Date: 19 Apr 88 18:54:48 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 > I have been comparing the lengths of packets specified in IP headers > against actual packet lengths. What I am seeing, ignoring IP packets > smaller than the minimum packet size, is that a fair number of machines > send out packets that are 1-3 bytes longer than is specified by the > IP length. The Ethernet requires that packets be an integral number of 16-bit words long. The Ethernet also has a minimum packet size of 60 bytes. Any IP packet that is less than 60 bytes in length (including ethernet header) will be padded to 60 bytes. The IEEE 802.3 length field would allow you to explicitly set the ethernet length, but Ethernet doesn't. - Geof Cooper ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3019@alvin.mcnc.org] <1988041920025600> From: sung@mcnc.org (Wayne Sung) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: bad packets passing through bridges Message-ID: <3019@alvin.mcnc.org> Date: 19 Apr 88 20:02:56 GMT Organization: Microelectronics Center of NC; RTP, NC Lines: 53 I had been following the checksum issue on tcpip with some interest when we started seeing what obviously were bad addresses showing up in our bridges. The most annoying thing was that these were not being flagged as having CRC errors on my own network monitor (just a plain programmable enet board with various test programs running) even though I am checking almost every error I know about. After collecting many megs of packet traces I finally caught one. Note that the beginning part of the packet (after the XX's) don't correspond to any manufacturer codes. But since it is in the head of the packet, all bridges duly noted the second 6 bytes as source addresses. This bad address allowed us to trace back to where the packet was generated. I can't say exactly yet how this is happening. It seems two packets have been amalgamated but the nearest bridge did not flag that as an error. Then it sent this "packet" out to the whole system, since the destination is not local (or exists!) This also possibly explains something else we have been seeing - addresses that are absolutely known to be remote nonetheless show up local. If packets can get shifted by 6 bytes then what was a destination shows up as a source. If you would like more specific info send me mail. v------------------------- 7E7C00 XXXX XXXX XXXX 5500 54BF 09FF 02A0 F403 _9_*_~U_T?___ t_ ---v note 1 7E7C10 FFFC 01AA FF2A FF82 2A2A 0081 D4AA 8090 _|_*_*__**__T*__ v------------------------- 7E7C20 0401 FF00 15C1 0800 2001 2995 0800 2001 _____A__ _)___ _ -------------v note 2 7E7C30 2879 0800 4500 0398 D250 039D FF11 D130 (y__E___RP____Q0 7E7C40 806D 8832 806D 8829 BABA AAAA 0000 0000 _m_2_m_)::**____ 7E7C50 0000 0004 4440 4000 0000 0000 4440 0155 ____D@@_____D@_U 7E7C60 5555 5555 5440 0000 0000 4045 5554 4444 UUUUT@____@EUTDD 7E7C70 4044 5444 4444 4040 4044 4445 5555 5555 @DTDDD@@@DDEUUUU 7E7C80 5555 5554 4444 4444 4444 5455 5454 4440 UUUTDDDDDDTUTTD@ 7E7C90 4044 5555 5555 5555 5400 0000 0000 0000 @DUUUUUUT_______ 7E7CA0 0000 0000 0000 0000 0000 0000 0000 0000 ________________ 7E7CB0 0005 5555 5555 5555 5555 D5D5 5540 0000 __UUUUUUUUUUU@__ 7E7CC0 0000 0000 0000 0000 0000 0005 5555 5555 ____________UUUU 7E7CD0 5555 5555 5555 5555 5555 5555 AAAA AAAA UUUUUUUUUUUU**** 7E7CE0 AAAA AAAA AAAA AAAA A8A8 A8AA AAA8 AAAA ********(((**(** 7E7CF0 AEEA AAEA AAA8 8888 88AA AAAA AAAA AAAA .j*j*(___******* 7E7D00 AAAA AAAA AAAA AAAA AAAA AAAA AAAB FFFE *************+_~ 7E7D10 AAEE EAAA AAAA AAAA AAAA AAAA AAAA AAAA *nj************* 7E7D20 AAAA AEFF EEFF FFFE EA88 8088 8888 8888 **._n__~j_______ 7E7D30 8888 8888 8888 8888 8880 8080 0080 8080 ________________ 7E7D40 00AA AAAA AAAA EAEA EFFF FFFF FAA8 8888 _*****jjo___z(__ 7E7D50 8888 8888 8888 8888 8888 8AAA EAEE EAFF ___________*jnj_ .....more of the same..... note 1: what obviously is a bad ethernet header note 2: what turns out to be a perfectly good ethernet header plus some ip header ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804192115.AA16635@milk10] <1988041921153600> From: robert@SPAM.ISTC.SRI.COM (Robert Allen) Newsgroups: comp.protocols.tcp-ip Subject: 4.3 TCP sockets revisited. Message-ID: <8804192115.AA16635@milk10> Date: 19 Apr 88 21:15:36 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 38 Last year I asked some questions about TCP sockets under 4.2-4.3BSD UNIX, concerning a dynamic alternate routing capability. Specifically I was concerned that under 4.2 routes are closely tied to the TCP sockets using that route, such that if the route dies then the TCP peers at the sockets also time out and die, forcing the application using the sockets to restart the sockets. Rumor had it that 4.3 would solve some of these problems, because the TCP timers could last long enough for a new route to be obtained. The part of the problem which was perhaps not addressed under 4.3 was the caching of only a single 'good' route at a time. Now I have heard that the Sun Internetwork Router (based on XNS) under the newer versions of SunOS supports load sharing, which leads me to believe that Sun must also support redundant routes in the routing tables. I have a need for highly responsive route switching under the socket layer in the work I'm doing, where the physical layer tends to be poor or non- existant on a per-route basis over time. If the functionality has not been implemented yet I have an interest in trying it myself, but I don't want to re-invent the wheel, Sooo... My questions are: (a) Has Sun implemented what I call here "dynamic redundant routing"? If so, under which releases of the OS? If so, is it only for the Internetwork Router? (b) If Sun has not implemented it, has Berkeley, or someone else? (c) If Sun has not implemented it, how are they doing load sharing over the I.R.? Did I hear a wrong rumor? Please call, write or post to the net. Thanks, Robert Allen, robert@spam.istc.sri.com 415-859-2143 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3950003@wdl1.UUCP] <1988041921221400> From: engle@wdl1.UUCP (David Engle) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet accounting and a place to do it Message-ID: <3950003@wdl1.UUCP> Date: 19 Apr 88 21:22:14 GMT References: <8804180833.AA12023@ucbvax.Berkeley.EDU> Lines: 11 >... . Moreover, the internet, a-political as >it is, is a place where intellectual processes are nurtured. Some of those >might not be nurtured should a carelessly adopted plan evolve to choke off >contributions of those automatically excluded by some carelessly adopted plan. A good example of what could be easily eliminated by a per packet billing system is the archival storage facilities around the net. How many sites are going to maintain files for anonymous ftp or gratuitous mailing to others, if it costs the site "real" money to do so. Dave engle@ford-wdl1.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6312@elroy.Jpl.Nasa.Gov] <1988041921424400> From: david@elroy.Jpl.Nasa.Gov (David Robinson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Accounting Message-ID: <6312@elroy.Jpl.Nasa.Gov> Date: 19 Apr 88 21:42:44 GMT References: Organization: Image Analysis Systems Grp, JPL Lines: 20 In article , WANCHO@SIMTEL20.ARPA ("Frank J. Wancho") writes: > 3. The algorithm itself is flawed (in my opinion): it is based on > charges only for outgoing packets, and TAC access (including connect > time, not just packet charges - in BOTH directions). That severely > penalizes hosts which act as mailing list distribution points, those > which offer anonymous ftp access, and those which allow telnet access, > particularly from TACs. This offers interesting accounting problems for sites that serve as a gateway for other organizations and networks. The number of networks that are gatewayed through a particular organization is growing. How will NSFnet and CSnet handle the chargebacks to their users? Same for Bitnet mail relays. I can see the unfortunate situations where these other networks shut off external Mail and FTP access to the Internet. Also how does one charge back between Arpanet and Milnet? Will the long hinted seperation of the nets by the mailbridges be put into effect? -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ARPA {cit-vax,ames}!elroy!david UUCP Disclaimer: No one listens to me anyway! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23574@hi.unm.edu] <1988041922180400> From: cyrus@hi.unm.edu (Tait Cyrus) Newsgroups: comp.protocols.tcp-ip Subject: IP UDP/TCP port numbers Message-ID: <23574@hi.unm.edu> Date: 19 Apr 88 22:18:04 GMT Organization: U. of New Mexico, Albuquerque Lines: 46 Keywords: port numbers What is the algorithm used by TCP and UDP to pick port numbers? Specifically I would like to know how the op sys picks src/dst port numbers. Let's say I have a socket between two machines. How does the op sys keep from picking port (socket) numbers that are defined in the RFC (RFC 1010) or by UN*X in /etc/services? The reason I ask is because will watching packets fly around on our local network, I have seen machines use port numbers that should be used ONLY for certain applications (who, timed, smtp, etc.). TCP port numbers seem to be ok, but UDP port numbers seem to be totally random. I have seen many UDP packets in which BOTH the source AND destination ports are zero (0). According to UDP RFC (RFC 768), only the src port can be zero "if not used". The "destination port has a meaning within the context of a particular internet destination address." Ok, what does this mean? Under what circumstances can the op sys pick port numbers (specifically dst port) that have predefined meanings? Below is some example output from my monitoring: UDP packets src port 0, dst port 1 src port 0, dst port 3 src port 0, dst port 6 src port 0, dst port 8 src port 0, dst port 12 src port 0, dst port 'DISCARD' DISCARD = 9 src port 0, dst port 'RJE' RJE = 5 src port 0, dst port 'CHARGEN' CHARGEN = 19 huh? -> src port 0, dst port 0 src port 0, dst port 'ECHO' ECHO = 7 What is going on? I would appreciate it if someone could enlighten me because I must be missing something. -- @__________@ W. Tait Cyrus (505) 277-0806 /| /| University of New Mexico / | / | Dept of Electrical & Computer Engineering @__|_______@ | Parallel Processing Research Group (PPRG) | | | | UNM/LANL Hypercube Project | | hc | | Albuquerque, New Mexico 87131 | @.......|..@ | / | / e-mail: @/_________@/ cyrus@hc.dspo.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804200219.AA20069@LANAI.MCL.UNISYS.COM] <1988042002192100> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Thoughts on why packet accounting will be A Good Thing. Message-ID: <8804200219.AA20069@LANAI.MCL.UNISYS.COM> Date: 20 Apr 88 02:19:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Barry, I agree with your sentiments. I also tend towards the taxation model and the view of networks as infrastructure or a 'utility'. At Los alamos, where I was before moving east, we charged for network connect time and port charges. Other methods of charging were always discussed, but it was hard to get concensus. The 'rich' users did not care about what you charged. They just justified more money for their work. the 'poor' users could not get more money and were forced into antisocial behavior, i.e. they quit using the network and went out and bought microcomputers. Afterall, you can compute anything on a micro that you can on a cray, it just takes more time. When 'time' is the color of your money, then you spend time instead of dollars. dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804200252.AA20255@LANAI.MCL.UNISYS.COM] <1988042002525400> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: record arpanet traffic Message-ID: <8804200252.AA20255@LANAI.MCL.UNISYS.COM> Date: 20 Apr 88 02:52:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 42 I believe that the nattached indicates that the Arpanet is carrying record traffic these days. At least in the 2.5 years I have been watching, this is a record. dennis >From sullivan@venera.isi.edu Tue Apr 19 17:15:39 1988 Received: from KAUAI.MCL.UNISYS.COM by LANAI.MCL.UNISYS.COM [3.2Unisys/Domain/jbp/2.4] id AA19827; Tue, 19 Apr 88 17:15:38 EDT Received: from venera.isi.edu by KAUAI.MCL.UNISYS.COM [3.2Unisys/Domain/jbp/2.4] id AA29781; Tue, 19 Apr 88 17:14:45 EDT Posted-Date: Tue, 19 Apr 88 14:03:47 PDT Message-Id: <8804192103.AA22370@venera.isi.edu> Received: from LOCALHOST by venera.isi.edu (5.54/5.51) id AA22370; Tue, 19 Apr 88 14:03:48 PDT To: Traffic-People@venera.isi.edu Cc: Sullivan@venera.isi.edu Subject: Traffic Graph - APR07 Date: Tue, 19 Apr 88 14:03:47 PDT From: Kathleen Sullivan Status: R TOTAL TRAFFIC PACKETS PER WEEK (MILLIONS) 1988* 0.0 * JAN07 171.8 ************************************** JAN14 189.4 ****************************************** JAN21 179.1 **************************************** JAN28 216.3 ************************************************ FEB04 218.4 ************************************************ FEB11 226.6 ************************************************** FEB18 213.7 *********************************************** FEB25 214.8 ************************************************ MAR03 240.1 ***************************************************** MAR10 227.5 ************************************************** MAR17 238.3 ***************************************************** MAR24 222.1 ************************************************* MAR31 232.6 *************************************************** APR07 265.0 ********************************************************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042015030000> Received: from nswses.arpa by SRI-NIC.ARPA with TCP; Wed 20 Apr 88 23:24:42-PDT Date: 20 Apr 88 23:03:00 PST From: "TERVAX::EFBATEY" Subject: Need Mail / TCP-IP for HP3000 under MPE V To: "tcp-ip" cc: efbatey Reply-To: "TERVAX::EFBATEY" ------------------------------------------------------------------------ # Date: Wed, 20 Apr 88 19:06:41 PDT # From: efbatey (4V33,x5881 Everett F Batey II) @ tervax # Reply-To: # Subject: HP3000/MPE_V/HP-Office to TCP-IP # Comment: < USNSWSES*SOCALSunLUG*DECUS*805/982-5881/983-1220 > I have 2 dozen P3000s with HP'sMPE_V operating system and HP Office / Desk. All my other hosts talk DECNet AND / OR TCP-IP .. I need a mail bridge and preferrably full TCP/IP Mail and TELNET/FTP .. I would probably commit a major felony for some good leads .. enet cards to replace RS232 and software ... ------------------------------------------------------------ | Everett F. Batey II } { UUCP: sun!tsunami!nswed5!efb | | USNSWSES - Code 4V33 } { ARPA: efbatey@NOBBS.UCSB.EDU | | After HOSTS.TXT.726 } { efbatey@NSWSES.ARPA | ------------------------------------------------------------ ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042015180000> Mail-From: VIVIAN created at 21-Apr-88 00:03:17 Return-Path: Received: from nswses.arpa by SRI-NIC.ARPA with TCP; Wed 20 Apr 88 23:25:26-PDT Date: 20 Apr 88 23:18:00 PST From: "TERVAX::EFBATEY" Subject: I'm getting rejected posted tcp-ip .. To: "vivian" cc: efbatey Reply-To: "TERVAX::EFBATEY" ReSent-Date: Thu, 21 Apr 88 00:01:21 PDT ReSent-From: Vivian Neou ReSent-To: tcp-ip@SRI-NIC.ARPA ReSent-Message-ID: <12392147871.17.VIVIAN@SRI-NIC.ARPA> Would you post this one for me .. Thanks .. Ev Reply-To: Subject: HP3000/MPE_V/HP-Office to TCP-IP Comment: < USNSWSES*SOCALSunLUG*DECUS*805/982-5881/983-1220 > I have 2 dozen HP3000s with HP's MPE_V operating system and HP Office / Desk. All my other hosts talk DECNet AND / OR TCP-IP .. I need a mail bridge and preferrably full SMTP Mail and TELNET/FTP .. I would probably commit a major felony for some good leads .. enet cards to replace RS232 and software ... ------------------------------------------------------------ | Everett F. Batey II } { UUCP: sun!tsunami!nswed5!efb | | USNSWSES - Code 4V33 } { ARPA: efbatey@NOBBS.UCSB.EDU | | After HOSTS.TXT.726 } { efbatey@NSWSES.ARPA | ------------------------------------------------------------ ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [SRA.12391999638.BABYL@XX.LCS.MIT.EDU] <1988042017270000> From: SRA@XX.LCS.MIT.EDU (Rob Austein) Newsgroups: comp.protocols.tcp-ip Subject: Whither chargeback policies? Message-ID: Date: 20 Apr 88 17:27:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 64 Hang on, this is getting a little too far down in the bits. Let's ignore the implementation details (counting packets, counting PSNs, etc) for the moment, and concentrate on what this whole business is designed to accomplish: 1) Generate some revenue to fund (and expand?) the operational network, and 2) Provide some negative feedback (that's a technical term, not a normative statement) so that users will make "efficient" use of the available network resources. Let us further assume, that (1) will take care of itself (with the help of the bean counters who are going to be fixing the rates anyway) and that our job is to decide what kind of things really need to be charged back so that (2) will be both fair and effective. I submit that, at the moment, the two most critical resources on the Internet are: a) Long distance trunk bandwidth, in particular (but not limited to) the three transcontinental ARPANET trunks, and b) Gateway CPU time (level-3 routers), in particular (but not limited to) the core gateways and ARPANET <=> MILNET "mailbridges". I would add ARPANET/MILNET PSN overhead, but that's beating a dead horse, no offense to the martyrs at BBN who keep that code running. These are also, of course, the two worst-imaginable places to try to intsert accounting telemetry, precisely because they are so overloaded. Nevertheless, if we are going to have to start paying money per usage for some resource, I for one would prefer to be paying for these. Perhaps some of the income can be used to increase the numbers of trunks and core gateways until they can adaquately handle the load. The point someone made a few days ago about examining the incentive implications of a policy before implementing it is well taken. For example, I'd hate to see the above musings turned into a general charge for router CPU time that encouraged everybody to connect networks with level-2 bridges. I applaud the idea of getting a Real Economist to analyze this mess so that we can giggle at his-or-her ideas rather than each other's. Lastly, if we're going to use highway analogies, let's not forget US 1A southbound through the Sumner Tunnel to Boston, where the traffic routinely backs up so badly, in spite of the toll, that it's -faster- to go 10 miles out of the way on state highways and city streets than to take the direct route. Much of the traffic is people who are either paying by the mile (taxis from Logan Airport) or people who are using the Tunnel simply because they don't know any other route. It happens that just last week I found myself TELNETing from MIT to a site in CT (to which we have a high speed three-hop link via NSFNet) via the ARPANET to Pittsburg and whoknowshow from there because the routing software couldn't tell which route was faster. I'm not sure how to implement a penalty charge for stupid software, but it'd probably be a good thing if we could; picture vendor-of-your-choice being told that ever single customer site would be hit with a surcharge until they fixed their broken software! People who think this is a joke should remember Paul Mockapetris's claim that a bug in bind v4.5 was eating up about a KL-10's worth of CPU time on the root domain servers last July. --Rob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21851@bu-cs.BU.EDU] <1988042017335800> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: bad press for NSFNET Message-ID: <21851@bu-cs.BU.EDU> Date: 20 Apr 88 17:33:58 GMT References: <28900001@clio> Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.protocols.tcp-ip Organization: Boston Univ. Information Tech. Dept. Lines: 15 Summary: What is the RT architecture? I found the Data Comm article intriguing. I haven't heard anything on usenet or the internet regarding the new NSFnet router architecture. Could someone point me toward a journal article, trade rag article, or other source where I could learn something about how these new RTs route? If there is nothing in print, I would like to invite someone from MERIT or other knowledgable developer to post something about how these RTs work compared to some plain vanilla (:-) router like a cisco, a proteon, a fuzzball, or homegrown router. Any takers? Kent England, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23668@bbn.COM] <1988042018104900> From: wbe@bbn.com (Winston B Edmond) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet accounting and a place to do it Message-ID: <23668@bbn.COM> Date: 20 Apr 88 18:10:49 GMT References: <8804180833.AA12023@ucbvax.Berkeley.EDU> <3950003@wdl1.UUCP> Sender: news@bbn.COM Reply-To: wbe@BBN.COM (Winston B Edmond) Organization: BBN Laboratories Incorporated, Cambridge, MA Lines: 21 David Engle writes: >A good example of what could be easily eliminated by a per packet billing >system is the archival storage facilities around the net. How many sites >are going to maintain files for anonymous ftp or gratuitous mailing to >others, if it costs the site "real" money to do so. This particular problem could be solved with "reverse billing": Create a means for a server and a client to negotiate billing charges. In the case of file archive servers, the server would ask the network to reverse the billing charges. The network then asks the client if it is willing to accept the charges for the file transfer. The client accepts by informing the network that it will accept charges for packets from the server, and the network informs the server that billing costs for that connection have been accepted by the client. It is important that the billing entity (the network) mediate this interaction so that hosts cannot unilaterally shift charges to other hosts. The main problem with this method is that it depends on having an identifiable "connection" that is recognizable by the network billing routines. -WBE ----MESSAGE-END---- ----MESSAGE-BEGIN---- [582@bpa.BELL-ATL.COM] <1988042018463900> From: espo@bpa.BELL-ATL.COM (Bob Esposito) Newsgroups: comp.protocols.tcp-ip Subject: Internetworking with TCP/IP Message-ID: <582@bpa.BELL-ATL.COM> Date: 20 Apr 88 18:46:39 GMT Organization: Bell of Penna., Phila. (A Bell Atlantic Company) Lines: 17 Keywords: Comer's book I received my copy just last week from Prentice Hall and its really a comprehensive view of the TCP/IP technology and the Internet. Although I'm only half-way finished, I would suggest getting a copy for your technical reference library. It has some great appendices explaining terms, RFC references and much more. Douglas Comer did a fine job with this one!!! -- Bob Esposito, Bell of Pennsylvania uucp: {rutgers|cbmvax|bellcore}!bpa!espo A Bell Atlantic Company domain: espo@bpa.bell-atl.com Philadelphia, PA. phone: +1 215 466 6831 ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-=== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21853@bu-cs.BU.EDU] <1988042020241400> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet Accounting (long) Message-ID: <21853@bu-cs.BU.EDU> Date: 20 Apr 88 20:24:14 GMT Organization: Boston Univ. Information Tech. Dept. Lines: 118 Keywords: accounting chargeback policy I have some further comments on the per packet accounting policy issue. I have excerpted comments from Vint Cerf, Jack Haverty, and Barry Shein in my rather longish reply. ----------------------------------------------------------------- From CERF@A.ISI.EDU Sun Apr 17 12:06:31 1988 Kent, Your flames seem a bit excessive (but I suppose that's a tautology...). Given. I am beginning to think that flames on lists like tcp-ip are out-of-date and that I should never flame on a list with an audience as large and diverse as this list. This reply is an effort to douse the flame and sound like a reasonable person. The issue of accounting becomes more significant as the services rendered become less research/experimental and more like commodities. Telephone services such as the Federal Telephone System run by the GSA are cost-allocated in accordance with usage and one doesn't find it odd to pay for telephone calls on the basis of time and distance. Well, distance is an historical rationale for charging. I subscribed at one time to Satellite Business Systems' long-distance service. They charged a rate that was distance insensitive, arguing that since it was satellite service, distance was not a true cost basis. On the other hand, time is still an obvious resource in a switched circuit network. There is no technical reason to do it one way or the other. You pick a method that your customers and auditors will find acceptable. My basic argument is that chargeback is isolated from network technology, except as used in arguments of equitability and fairness. The parameters for packet nets may be different than for telephone voice service (maybe no distance charges). The important thing for the parties involved is to be able to demonstrate that there is a reasonable sharing of costs. One attractive thing about basing charges on usage is that as total usage goes up, it may be possible to make capital investments to increase capacity in a way that doesn't specifically require that all parties make an agreement to acquire more equipment - the service provider can buy it on the basis of increased usage and spread the cost in a reasonably equitable fashion. Equity seems to be a key concept here. Of course, equity depends on the perception of those involved and implies that the rationale is understandable and "natural". The idea of using ramping usage charges as a capitalization tool had not occurred to me; it is an idea with merit. From haverty@CCV.BBN.COM Sun Apr 17 18:55:17 1988 Vint et al, In addition to these 'engineering' kinds of decisions, the network must make 'marketing' decisions. For example, it might price a new service "unfairly" low, in order to encourage clients to upgrade (maybe mail should be cheaper if one uses the full domain server system?). There are also costs associated with "marketing", such as advertising (NIC management bulletins?) As far as charging algorithms go, that is the province of the hypothetical marketing department - how do I price my product. In the context of the current mail discussion, I think it is best to assume that somehow all of the costs must be recovered by charges, including costs for investments for the future. The real question is how to use a pricing policy to encourage the desired behavior. I think your point about looking at chargeback as a marketing issue is particularly apropo. I think that puts the best light on the subject. Your argument begs the question, though, of "Will the charges from my external network vendor [the Internet] unduly constrict or restrict my ability to implement my own internal chargeback policy?" It should not. There is a difference, in my thinking, between the actual installation and recurring cost structure of something like a LAN and an artificial recovery model like a per-packet charge. Actual costs to install and maintain a LAN are fixed on a per-network and per-node basis rather than a per-packet basis. Of course, you can use either model to recover cost, but my point is that per-network, per-node is more natural and much easier to administer. I argue that the bean-counters should not be allowed to extend an improper model to LAN cost recovery. We should try to get them to accept another model, by arguing in their own financial or marketing terms. This assumes that we stay ahead of user bandwidth need and that there is always sufficient (I would recommend excessive) amounts of bandwidth, so that the question of scarce resources is not involved in the LAN model. If your Ethernet backbone is limited, go to FDDI, but don't adopt a new and restrictive cost model just to get through a temporary phase of technology transition. Is this whole issue of chargeback merely a temporary phase? Once we have "unlimited" bandwidth again, will the arguments for chargeback evaporate or will we be left with an obsolete legacy to overcome when wide area networks are as open as today's local area networks? Don't hamstring the technology of tomorrow with an inadequate policy today. Another way to put this is to say, let's decouple the WAN chargeback from the LAN chargeback issue. Both costs need recovery, but with different models. From: bzs@BU-CS.BU.EDU (Barry Shein) At the very least it would be interesting to hear what the goals are that people expect to accomplish with their proposed chargeback models, it's nice to have explicit goals and see if the models actually achieve them. --------------------------------------------------- Seems we have some goals already: o complete cost recovery o simple recovery formula o "natural" and "understandable" algorithm for cost recovery o equitable allocation of costs across our client base o capital recovery/generation for investment in new technology o decoupling between WAN cost recovery model and LAN cost recovery model I hope this helps forward the discussion. Kent England, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1987@rtech.UUCP] <1988042022331400> From: daveb@llama.rtech.UUCP (Crack? No thanks, I've got a new CD player) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong's TN3270 Message-ID: <1987@rtech.UUCP> Date: 20 Apr 88 22:33:14 GMT References: <8804182349.AA29557@ucbvax.Berkeley.EDU> Sender: news@rtech.UUCP Reply-To: daveb@rtech.UUCP (Crack? No thanks, I've got a new CD player) Organization: Relational Technology, Inc. Alameda, CA Lines: 9 In article <8804182349.AA29557@ucbvax.Berkeley.EDU> eva@TWG.COM writes: >2/ TN3270 is currently available only with EUNICE, not WIN/TCP. It requires > "libcurses" library which is not supported under WIN/TCP, due to the > requirement for a UNIX license. This is specious. There are a number of PD curses packages lying around. There must be another real reason. Could it be... -dB {amdahl, cpsc6a, mtxinu, ptsfa, sun, hoptoad}!rtech!daveb daveb@rtech.uucp ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042023360000> Received: from OAC.UCLA.EDU by SRI-NIC.ARPA with TCP; Thu 21 Apr 88 06:36:38-PDT Date: Thu, 21 Apr 88 06:36 PDT To: tcp-ip@SRI-NIC.ARPA From: Michael Stein Subject: packet charging (the EFT model?) Instead of a "WILL/WONT PAY" protocol (which only works on connections) how about something else: Suppose that it was possible to send packets containing "money"? This might be the IP level equivalent of "reverse charges" (since IP packets aren't related like traffic on a connection). The idea is that the "network" charges for packets sent (not new), but will also allow a packet to transfer "money" from the sender to the target This could show up as a charge on the bill to the sender and a "refund" on the bill of the target. Thus a UDP request to a name server should contain the money for the reply (or else it's likely there won't be a reply). It is clearly possible to build a "reverse charge" connection level protocol on top of this by having one side request (demand?) "money" to continue. Note however that much more is possible: o either side could pay the whole cost or they could split it in any way o this also works for 3 (or more) party traffic (it's possible to receive "money" and send it out to someone else). o this also works across time, I can send payment now for something you will do later (time to renew your subscription to TCP-IP?) o since "money" is general, other net-wide resources could also be handled This can't be practical, can it? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2860@emory.uucp] <1988042023553400> From: ospwd@emory.uucp (Peter Day {EUCC}) Newsgroups: comp.protocols.tcp-ip Subject: RIP, gated Message-ID: <2860@emory.uucp> Date: 20 Apr 88 23:55:34 GMT Organization: Emory University Computing Center Lines: 17 Keywords: RIP gated routing gateway How can I get more specific information about the Routing Information Protocol (RIP) used by Proteon, and gated, a demon which translates between RIP and EGP, the External Gateway Protocol? Although I would like the details of the protocols, I at least need as complete a functional description as I can get. Please send replies directly to me and I will summarize for the list. Thanks, Peter Day Emory University Bitnet: ospwd@emuvm1 CSnet: ospwd@emoryu1.arpa UUCP: ...!gatech!emoryu1!ospwd ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804210028.AA07717@hamlet.ultra.com] <1988042100284000> From: bob@ultra.UUCP (Bob Beach) Newsgroups: comp.protocols.tcp-ip Subject: Maximum sized IP packets Message-ID: <8804210028.AA07717@hamlet.ultra.com> Date: 21 Apr 88 00:28:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 In looking through the IP RFC, I noticed that IP allows up to a 64K byte datagram. I was wondering how many implementations of TCP/IP are actually capable of handling such a large datagram. Such a datagram would have to fragmented since no subnets that I know of support packet sizes that big, so I guess the real question is: what implementations can reassemble a 64K IP datagram that has been previously fragmented. A second question is: if the 64K datagram size is, in the words of the RFC "impractical", what is "practical"? 4K, 8K? I have heard rumors that many implementation don't support reassembly at all. Is this true? A third question is: given some implementation can reassemble 128 (or so) 576 byte packets into one big 64K datagram, how likely is it that all 128 would arrive at the destination node. The destination could be either a host on the Internet or on a local Ethernet. -Bob Beach Ultra Network Technologies ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042102070000> Received: from acc.arpa by SRI-NIC.ARPA with TCP; Thu 21 Apr 88 10:23:07-PDT Date: 21 Apr 88 10:07:00 PST From: Subject: NSFNet Routers To: "kwe" cc: tcp-ip@sri-nic.arpa Reply-To: > I found the Data Comm article intriguing. I haven't heard >anything on usenet or the internet regarding the new NSFnet router >architecture. Could someone point me toward a journal article, trade >rag article, or other source where I could learn something about how >these new RTs route? There is a document from MERIT titled "Management and Operation of the NSFNET Backbone Network" that describes the new NSFNet backbone. > If there is nothing in print, I would like to invite someone >from MERIT or other knowledgable developer to post something about how >these RTs work compared to some plain vanilla (:-) router like a >cisco, a proteon, a fuzzball, or homegrown router. There was a presentation by IBM at the last IETF mtng, and I'll try to summarize from memory. The NSFNet Router nodes will consist of a cluster of IBM PC/RTs running a BSD 4.3 derivitive. The RTs will be interconnected via token ring. Most of the RTs will be Packet Switching Processors (PSP) and will typically be connected to the high speed serial backbone trunks or to Ethernets of the regional networks. Each of the PSPs will route using it's local kernel routing table. A couple of the RTs will be running an SPF based routing protocol derived from the DEC routing protocol that ANSI is submitting to ISO. These Routing Control Processors (RCP) will pass the current routing information to each of the PSPs for updating of their local routing tables. I believe that the backbone will talk EGP to the regionals. (somebody correct me if I'm wrong) Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804210408.AA16030@bu-cs.bu.edu] <1988042104084100> From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: another thought on packet charging Message-ID: <8804210408.AA16030@bu-cs.bu.edu> Date: 21 Apr 88 04:08:41 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 44 [I think this gets more interesting in the second half] How exactly does packet accounting work? Being as it's so low level does it just charge the source address? Or do we distinguish between servers and clients (for example) to direct charges? Case 1: You FTP to my system to get a file. You are the client. I guess it seems clear that you should pay so "charge the client" seems reasonable. Case 2: I connect to your system to deliver mail being forwarded through me. I am the client. But it seems you should pay for the packets, no? Charge the client doesn't seem right. We won't even talk about UDP. If we just charge on source address then I guess I still end up paying to give you your mail or expand a mailing list etc. Does anyone have a proposed set of rules that are better than these? [SECOND HALF] About the only thing that comes to my mind is a meta-protocol (ICMP?) sort of like a WILL YOU/WONT YOU: WILL YOU PAY? -> <- YES/NO I WILL PAY-> <- GOOD which occurs on each connection ramp-up. Hmm, perhaps we can extend the ethernet "cocktail party" metaphor to a "picking up the check" metaphor. Maybe should add "DUTCH TREAT?". (does this lead to bistro mathematics?! [see Douglas Adams].) -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804210122.aa04241@SPARK.BRL.ARPA] <1988042105222500> From: phil@BRL.ARPA (Phil Dykstra) Newsgroups: comp.protocols.tcp-ip Subject: Re: [Phil Dykstra: more interesting numbers] Message-ID: <8804210122.aa04241@SPARK.BRL.ARPA> Date: 21 Apr 88 05:22:25 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 42 The numbers that I posted for the NSFNET fuzzies the the ARPA/MILNET Core gateways were for the week ending 21 March 88 (and came via Dave Mills). Only one of the mailbridges and five EGP speakers had been upgraded to 11/73's at that time. It would be interesting to see how they have improved. The numbers for the BRL gateway came from ~48 hours ending 30 March 88. That gateway has three ethernets, one 10 Mbit proteon ring, and two 1822 IMP connections (one MILNET, one local). Packet counts were half of in+out and included everything to/from the interfaces - EGP, ICMP, etc., included. If I had been posting to this list originally I would have spoken a bit more carefully. To answer/comment-on a few replys: > Mike Brescia > ... "average" throughput is a measure of packets actually offered over the > course of the day or week reporting period, .... > ... is a measure of handling offered load rather than limitation. Good point. They were all long term averages. For the record I believe that we all agree that "one packet" goes both in and back out of a gateway. Most vendors seem to count that as two, for obvious reasons. > Phill Gross > Do we understand why the mailbridges have such a higher drop rate? Mike Brescia mentioned a few possible reasons. Another, which I have heard about but don't know any details of, is a claim that the Core gateways maintain max queue lengths of eight packets per destination subnet (I would presume to avoid overloading the PSN's). That probably causes many more drops than a more generous gateway would have (unless there are only PSN's connected to it and they return the favor). > Dave Mills > I would like to believe the difference in drop rates is due to the design > of the NSFNET backfuzz selective-preemption and source-quench schemes. I note however that your numbers went from good to excellent. I am hoping to be able to test that theory by playing the same game locally. - Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804210125.AA00888@wb6rqn.UUCP] <1988042105250300> From: brian@wb6rqn.UUCP (Brian Lloyd) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP on Apollo Domain systems Message-ID: <8804210125.AA00888@wb6rqn.UUCP> Date: 21 Apr 88 05:25:03 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 I am bringing up an Ethernet LAN running TCP/IP. One of the hosts is an Apollo Domain system that runs BSD4.2. Can anyone provide me with the following information: 1. What Ethernet interfaces are supported (we were told to get a 3Com Etherlink+)? 2. What additional software is required, if any? (obviously a driver for the Etherlink+ is needed.) 3. What are the formats for the /etc/hosts /etc/networks/ and /etc/gateways files? Please reply directly to me. Thanks. Brian Lloyd, President Sirius Systems, Inc. 19200 Tilford Way, Germantown, MD 20874 (301) 540-2066 brian@wb6rqn.uucp Share and enjoy! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804210125.aa04335@SPARK.BRL.ARPA] <1988042105253700> From: phil@BRL.ARPA (Phil Dykstra) Newsgroups: comp.protocols.tcp-ip Subject: Re: [Phil Dykstra: more interesting numbers] Message-ID: <8804210125.aa04335@SPARK.BRL.ARPA> Date: 21 Apr 88 05:25:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 87 > Who is responsible for the remaining traffic? Good question. I would wager a bet that it is the old GGP induced "extra-hop" problem. Speaking EGP on the MILNET side of the world I can't verify this in your case, but here is an example of this very bad phenomena in action on this half of the core system. Several weeks ago a typical set of EGP routes received from MINET-GW (a MILNET Core EGP speaker) looked like this (summarized by number of routes per gateway): # routes Example net Gateway 307 10.0.0.0 26.0.0.106 Random "mailbridge" 19 128.165.0.0 26.3.0.75 EGP speaker (YUMA-GW) 18 128.171.0.0 26.1.0.65 EGP speaker (AERO-GW) 7 128.56.0.0 26.3.0.29 BRL gw1 6 128.20.0.0 26.2.0.29 BRL gw2 4 128.115.0.0 26.6.0.21 4 128.102.0.0 26.4.0.16 3 128.60.0.0 26.20.0.8 3 128.229.0.0 26.0.0.103 2 129.43.0.0 26.0.0.88 2 128.47.0.0 26.5.0.60 2 128.122.0.0 26.0.0.58 1 192.5.13.0 26.2.0.55 1 192.31.98.0 26.5.0.129 ... many more single route entries ... The mailbridge 26.0.0.106 happened to be the "choice of the day" for routes via the ARPANET. Seeing a very large number of routes to a single mailbridge is quite common; it changes every few hours or days. [I would like by the way to hear if this is load balanced on a per peer basis or something, or if everyone on a given EGP speaker gets the same selection.] But the real problem is the 37 routes to the Core EGP speakers! We got these routes by polling the MINET gateway, and MINET did what it was supposed to do - never gave ITSELF as a route to anything. Any exterior gateway which advertised its routes to MINET came out correctly. However, >>> any exterior gateway which advertised its routes to YUMA and/or AERO but not to MINET (i.e. not to the EGP peer that we polled), showed up as reachable via (one of) the EGP peer(s) that they spoke to! <<< This is a serious problem, because besides the sillyness of inducing an extra "hop" to reach those networks, it also directs a large amount of traffic to the Core EGP speakers - something which BBN(?) has been trying to avoid! Thus to answer Thomas Narten's question (I gather that the machine in question is an ARPA-side Core EGP speaker): The traffic is probably "extra-hop problem" induced. How It Happens (in brief - those that know this can skip it): Internal to the Core system GGP is used to communicate route information. A GGP speaker can only say "I CAN REACH netX", not HOW. EGP on the other hand says "I CAN REACH netX VIA gateY." When you speak EGP to one of the Core EGP speakers, he learns how to reach your nets VIA your gateway. If you ask that same EGP speaker how to get to netX you will get the "correct" answer - gateY. However, if you ask a *different* EGP speaker, his knowledge of the network in question came via GGP in which the first Core EGP speaker simply said "I CAN REACH netX." The HOW part, i.e. the gateway that advertised netX in the first place has been dropped (due to this GGP limitation). Thus someone receiving this information will end up (needlessly) sending packets to the Core EGP speaker netX was advertised to, rather than to the gateway that advertised it. How To Avoid the Problem: You can prevent others from getting extra-hop routes to YOU by advertising your nets to all available EGP speakers. You can avoid getting extra-hop routes to someone else by polling all available EGP speakers for routes and favoring those routes that DON'T point to an EGP speaker. [The real solution of course is to fix GGP.] Of course if everyone did the above the EGP speakers would be all the more loaded. One could also question at that point why there was more than one EGP speaker. One the other hand, licking the extra hop problem might get a lot of unnecessary non-EGP traffic off of the EGP speakers. It's hard to tell where the balance would lie. [It is interesting to note in the recent timetable how the EGP speakers were upgraded before most of the mailbridges were.] My apologies for such a long winded answer, but has been a long time since anyone discussed this problem on this list. - Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042106020000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Thu 21 Apr 88 07:02:32-PDT Date: 21 Apr 1988 10:02-EDT Sender: CLYNN@G.BBN.COM Subject: Re: Maximum sized IP packets From: CLYNN@G.BBN.COM To: ultra!bob@AMES.ARC.NASA.GOV Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]21-Apr-88 10:02:23.CLYNN> In-Reply-To: <8804210028.AA07717@hamlet.ultra.com> Bob, I have sent and reassembled datagrams up to about 28K bytes on the TOPS-20; I never tried the 64K experiment. The size of the datagram makes the probability of at least one lost fragment approach 1.0. In such cases, the reuse of IP ID by the transport layer (e.g., TCP, UDP) is very important, and the way the network driver sends the group should be considered carefully (e.g., leaving a little time between successive fragments (both to prevent back-to- back packets and to give others a chance to use the resources)); the relationship between IP TTL and transport retransmission timeouts and exactly how IP reassembly timeout is handled makes a big difference. What is practical depends on the environment, and the implementation(s). There is "no problem" across the ARPANET or MILNET as they have high end- to-end reliability; there is a problem across the ARPANET and the MILNET (the gateway queues between them). There should not be significant problems across a (segmented) lan. If monstergrans are IMPORTANT, we can write the software to get them through, but there is a high penalty in wasted bandwidth and cpu cycles if retransmissions are required. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804220916.AA25414@ucbvax.Berkeley.EDU] <1988042107030000> From: efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY") Newsgroups: comp.protocols.tcp-ip Subject: Need Mail / TCP-IP for HP3000 under MPE V Message-ID: <8804220916.AA25414@ucbvax.Berkeley.EDU> Date: 21 Apr 88 07:03:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "TERVAX::EFBATEY" Organization: The Internet Lines: 19 ------------------------------------------------------------------------ # Date: Wed, 20 Apr 88 19:06:41 PDT # From: efbatey (4V33,x5881 Everett F Batey II) @ tervax # Reply-To: # Subject: HP3000/MPE_V/HP-Office to TCP-IP # Comment: < USNSWSES*SOCALSunLUG*DECUS*805/982-5881/983-1220 > I have 2 dozen P3000s with HP'sMPE_V operating system and HP Office / Desk. All my other hosts talk DECNet AND / OR TCP-IP .. I need a mail bridge and preferrably full TCP/IP Mail and TELNET/FTP .. I would probably commit a major felony for some good leads .. enet cards to replace RS232 and software ... ------------------------------------------------------------ | Everett F. Batey II } { UUCP: sun!tsunami!nswed5!efb | | USNSWSES - Code 4V33 } { ARPA: efbatey@NOBBS.UCSB.EDU | | After HOSTS.TXT.726 } { efbatey@NSWSES.ARPA | ------------------------------------------------------------ ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804210927.AA01298@wb6rqn.UUCP] <1988042113270300> From: brian@wb6rqn.UUCP (Brian Lloyd) Newsgroups: comp.protocols.tcp-ip Subject: 64K octet datagrams Message-ID: <8804210927.AA01298@wb6rqn.UUCP> Date: 21 Apr 88 13:27:03 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Sirius Systems' implementation of TCP/IP for the Convergent Technologies workstations (the product is called Internet-CT) theoretically will support 64K octet datagrams if you allocate sufficient memory to hold such a datagram at service installation time (the size of the memory pool is user configurable when the transport service is installed, usually at system boot time). We have never run into a situation where anyone wanted to send a datagram that big and have never tried to send one that big but there is nothing in the code to prevent it either. Brian Lloyd, President Sirius Systems, Inc. 19200 Tilford Way, Germantown, MD 20874 (301) 540-2066 brian@wb6rqn.uucp Share and enjoy! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804220957.AA26052@ucbvax.Berkeley.EDU] <1988042113360000> From: csysmas@OAC.UCLA.EDU (Michael Stein) Newsgroups: comp.protocols.tcp-ip Subject: packet charging (the EFT model?) Message-ID: <8804220957.AA26052@ucbvax.Berkeley.EDU> Date: 21 Apr 88 13:36:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 35 Instead of a "WILL/WONT PAY" protocol (which only works on connections) how about something else: Suppose that it was possible to send packets containing "money"? This might be the IP level equivalent of "reverse charges" (since IP packets aren't related like traffic on a connection). The idea is that the "network" charges for packets sent (not new), but will also allow a packet to transfer "money" from the sender to the target This could show up as a charge on the bill to the sender and a "refund" on the bill of the target. Thus a UDP request to a name server should contain the money for the reply (or else it's likely there won't be a reply). It is clearly possible to build a "reverse charge" connection level protocol on top of this by having one side request (demand?) "money" to continue. Note however that much more is possible: o either side could pay the whole cost or they could split it in any way o this also works for 3 (or more) party traffic (it's possible to receive "money" and send it out to someone else). o this also works across time, I can send payment now for something you will do later (time to renew your subscription to TCP-IP?) o since "money" is general, other net-wide resources could also be handled This can't be practical, can it? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[G.BBN.COM]21-Apr-88.10:02:23.CLYNN] <1988042114020000> From: CLYNN@G.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Maximum sized IP packets Message-ID: <[G.BBN.COM]21-Apr-88.10:02:23.CLYNN> Date: 21 Apr 88 14:02:00 GMT References: <8804210028.AA07717@hamlet.ultra.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 Bob, I have sent and reassembled datagrams up to about 28K bytes on the TOPS-20; I never tried the 64K experiment. The size of the datagram makes the probability of at least one lost fragment approach 1.0. In such cases, the reuse of IP ID by the transport layer (e.g., TCP, UDP) is very important, and the way the network driver sends the group should be considered carefully (e.g., leaving a little time between successive fragments (both to prevent back-to- back packets and to give others a chance to use the resources)); the relationship between IP TTL and transport retransmission timeouts and exactly how IP reassembly timeout is handled makes a big difference. What is practical depends on the environment, and the implementation(s). There is "no problem" across the ARPANET or MILNET as they have high end- to-end reliability; there is a problem across the ARPANET and the MILNET (the gateway queues between them). There should not be significant problems across a (segmented) lan. If monstergrans are IMPORTANT, we can write the software to get them through, but there is a high penalty in wasted bandwidth and cpu cycles if retransmissions are required. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2975305@um.cc.umich.edu] <1988042115003000> From: Dave_Katz@UM.CC.UMICH.EDU Newsgroups: comp.protocols.tcp-ip Subject: bad press for NSFNET Message-ID: <2975305@um.cc.umich.edu> Date: 21 Apr 88 15:00:30 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 23 In response to Kent England: ?> If there is nothing in print, I would like to invite someone ?> from MERIT or other knowledgable developer to post something about how ?> these RTs work compared to some plain vanilla (:-) router like a > cisco, a proteon, a fuzzball, or homegrown router. The routing algorithm internal to the backbone is an implementation of the ANSI IS-IS Intradomain routing proposal. In a nutshell, it is an SPF variant with stable link metrics (assigned by "system management," which could be human or electronic). Reachability of routers and networks are flooded throughout the backbone. EGP is used to pass reachability info between the backbone, the regionals, and the ARPAnet. Various filtering tricks are used to try to ensure that ARPA routes don't leak out into the regionals, for example. Tables of potential EGP announcements are used to ensure that bogus info is not imported from the regionals. The routing algorithm is documented in ANSI X3S3.3/87-150R, which we will be making available for anonymous FTP once the NSFnet Info Services machine is in production. Local adaptations of the algorithm to DOD IP and the EGP mechanisms will likely be published in a paper once the panic subsides a little. Dave Katz, Merit/NSFnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [111@pastram.UUCP] <1988042115465100> From: dennis@pastram.UUCP (Dennis Norkus) Newsgroups: comp.databases,comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc Subject: DDN,LAN and Advanced Revelation. Keywords: Files transfer. Message-ID: <111@pastram.UUCP> Date: 21 Apr 88 15:46:51 GMT Organization: Pastram, Falls Church, VA Lines: 13 We are in the process of developing a system on a Local Area Network using Advanced Revelation as the DBMS. Passenger movement requirements will come in from Installation Transportation Offices through the Defense Data Network (DDN) to the LAN. Requests for service and offers for service will be a file transfer process with approximately 10 carriers/associations in the Washington D.C. area. Without getting into any more specifics, we would be interested in hearing about any general type problems one might think we'll encounter or your opinions regarding: Novell LAN, Advanced Revelation, DDN. -- Dennis Norkus uucp: pastram!dennis arpa: kanti@optimis-pent.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [794@sun.soe.clarkson.edu] <1988042116140100> From: nelson@sun.soe.clarkson.edu (Russ Nelson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <794@sun.soe.clarkson.edu> Date: 21 Apr 88 16:14:01 GMT References: Reply-To: nelson@sun.soe.clarkson.edu.UUCP (Russ Nelson) Organization: Clarkson University, Potsdam, NY Lines: 35 In article SRA@XX.LCS.MIT.EDU (Rob Austein) writes, and I edit: ... >2) Provide some negative feedback (that's a technical term, not a > normative statement) so that users will make "efficient" use of > the available network resources. ... >I submit that, at the moment, the two most critical resources on the ... > Perhaps some of the income can be used to increase the >numbers of trunks and core gateways until they can adaquately handle >the load. Another possibility: Charge users heavily for the use of the bottlenecks (whatever they may be at the time). Use the resultant income to FIX the bottlenecks. Theoretically (and in a perfect world :-) this will result in a network in which the load is spread evenly and there are no bottlenecks. Implications: o Short term bottlenecks due to down equipment should not be charged for, unless they recur, at which point they become long term bottlenecks. o The cost model is apparent to anyone who wants to do some pinging. Of course, they'll pay for their curiosity. o A site could easily run up a big bill unless the accounting is done in a timely manner. Without timely negative feedback, you can get into oscillations. o This still doesn't address who pays for which packets, just the amount charged for each packet. o Maybe a nominal fee for each packet to cover general costs? -- char *reply-to-russ(int network) { if(network == BITNET) return "NELSON@CLUTX"; else return "nelson@clutx.clarkson.edu"; } ----MESSAGE-END---- ----MESSAGE-BEGIN---- [658@fig.bbn.com] <1988042116455500> From: rsalz@bbn.com (Rich Salz) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong's TN3270 Message-ID: <658@fig.bbn.com> Date: 21 Apr 88 16:45:55 GMT Organization: BBN Laboratories Inc., Cambridge MA Lines: 13 In article <8804182349.AA29557@ucbvax.Berkeley.EDU> eva@TWG.COM writes: >2/ TN3270 is currently available only with EUNICE, not WIN/TCP. It requires > "libcurses" library which is not supported under WIN/TCP, due to the > requirement for a UNIX license. VMS has had a curses library for over a year (that's as far back as I go with VMS). While it has some bugs, it is quite possible to work around them and write full-screen character-at-a-time programs without too much pain. We've got some in the Cronus project. Better double-check what the "real" reason is. /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21898@bu-cs.BU.EDU] <1988042116480700> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internetworking with TCP/IP Message-ID: <21898@bu-cs.BU.EDU> Date: 21 Apr 88 16:48:07 GMT References: <582@bpa.BELL-ATL.COM> Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.protocols.tcp-ip Organization: Boston Univ. Information Tech. Dept. Lines: 18 Summary: Comer's bood available from LCIS In article <582@bpa.BELL-ATL.COM> espo@bpa.BELL-ATL.COM (Bob Esposito) writes: > > I received my copy just last week from Prentice Hall and its > really a comprehensive view of the TCP/IP technology and > the Internet. > > Douglas Comer did a fine job with this one!!! Comer's books are available from the Library of Computer and Information Sciences (LCIS) book club. I bring this up because some people were having trouble getting Stallings book set in a timely fashion. I'm not sure that people will have trouble with Comer's books, but it might be a good idea to look into LCIS if they are going to do a good job tracking unix/tcp-ip leterature. I subscribe, but have no other interest in LCIS. Kent England, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6140@shamash.UUCP] <1988042116555200> From: jwabik@shamash.UUCP (Jeff Wabik) Newsgroups: comp.protocols.tcp-ip Subject: Which version does Sun run? Message-ID: <6140@shamash.UUCP> Date: 21 Apr 88 16:55:52 GMT Organization: Control Data Corporation, Bloomington, MN. Lines: 13 Does anyone know which version of tcp-ip is implemented in the standard Sun OS (Sun UNIX 3.x) ? 802.2? 802.2/snap? 802.3? Thanks in advance .. -Jeff --- Jeff A. Wabik UUCP: {rosevax,umn-cs,meccts,ems}!shamash!jwabik ____ ____ ARPA: jwabik@ub.d.umn.edu NSFNET: jwabik@shamash.cdc.com / ___||___ \ | |___ ___| | Control Data Corporation - Better living through 64 bits. \____||____/ Live long and program. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2466@utah-gr.UUCP] <1988042117142500> From: haas@utah-gr.UUCP (Walt Haas) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet accounting and a place to do it Message-ID: <2466@utah-gr.UUCP> Date: 21 Apr 88 17:14:25 GMT References: <8804180833.AA12023@ucbvax.Berkeley.EDU> <3950003@wdl1.UUCP> <23668@bbn.COM> Organization: University of Utah CS Dept Lines: 13 It seems to me that the most sensible way to do packet accounting is the way that the public networks (Telenet, Tymnet) do it - that is, all packets on a virtual circuit are charged to whoever established that VC unless the call was placed and accepted as "collect", in which case the recipient pays for it. So if I had a public-domain database of general interest, I could make it available to anyone for anonymous FTP without concern that there would be a sudden explosion of my network packet charges - because whoever called in to copy my data would end up paying for the haulage. To be perfectly honest, I can't see any reason to reinvent a wheel that currently works just fine. Cheers -- Walt Haas haas@cs.utah.edu utah-cs!haas ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804221509.AA01550@ucbvax.Berkeley.EDU] <1988042118070000> From: art@ACC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: NSFNet Routers Message-ID: <8804221509.AA01550@ucbvax.Berkeley.EDU> Date: 21 Apr 88 18:07:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The Internet Lines: 33 > I found the Data Comm article intriguing. I haven't heard >anything on usenet or the internet regarding the new NSFnet router >architecture. Could someone point me toward a journal article, trade >rag article, or other source where I could learn something about how >these new RTs route? There is a document from MERIT titled "Management and Operation of the NSFNET Backbone Network" that describes the new NSFNet backbone. > If there is nothing in print, I would like to invite someone >from MERIT or other knowledgable developer to post something about how >these RTs work compared to some plain vanilla (:-) router like a >cisco, a proteon, a fuzzball, or homegrown router. There was a presentation by IBM at the last IETF mtng, and I'll try to summarize from memory. The NSFNet Router nodes will consist of a cluster of IBM PC/RTs running a BSD 4.3 derivitive. The RTs will be interconnected via token ring. Most of the RTs will be Packet Switching Processors (PSP) and will typically be connected to the high speed serial backbone trunks or to Ethernets of the regional networks. Each of the PSPs will route using it's local kernel routing table. A couple of the RTs will be running an SPF based routing protocol derived from the DEC routing protocol that ANSI is submitting to ISO. These Routing Control Processors (RCP) will pass the current routing information to each of the PSPs for updating of their local routing tables. I believe that the backbone will talk EGP to the regionals. (somebody correct me if I'm wrong) Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804211814.AA03140@loihi.HIG.HAWAII.EDU] <1988042118145700> From: bob@loihi.hig.hawaii.EDU (Bob Cunningham) Newsgroups: comp.protocols.tcp-ip Subject: RG58C/U hard to get? Message-ID: <8804211814.AA03140@loihi.HIG.HAWAII.EDU> Date: 21 Apr 88 18:14:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Two years ago I had to wait 8+ months to get a few thousand feet of RG58C/U (the real stuff, Belden number 8262). Since then I've been getting good delivery...until my last order that I've been waiting four months for. We can and do use RG58A/U in lieu, but there are some places where I really want to use C/U. Is this a common problem, or might it be just the Belden distributor here? If you get reliably-good delivery, who do you order from? Bob Cunningham bob@loihi.hig.hawaii.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1129@cadre.dsl.PITTSBURGH.EDU] <1988042118290600> From: sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <1129@cadre.dsl.PITTSBURGH.EDU> Date: 21 Apr 88 18:29:06 GMT References: <794@sun.soe.clarkson.edu> Reply-To: sean@cadre.dsl.pittsburgh.edu.UUCP (Sean McLinden) Organization: Decision Systems Lab., Univ. of Pittsburgh, PA. Lines: 47 The biggest single argument against chargeback is that is does NOT take into account the value of the network as a substrate for some greater activity. In terms of the volume of business on the DARPA side of the Internet, I suspect that the biggest users, who are, most probably, the biggest contributors to the evolution of the network, are hardly the deepest pockets, and this includes the many universities and research groups that provide software such as the recent TCP/IP updates to Unix, without charge to the users. There is no fair way to measure this contribution (unless we put it to a quorum), or to predict from where will the next significant contribution come. If the network were an end in and of itself, a chargeback policy based on usage would be quiet reasonable. Under a Libertarian system of government it would also make sense, but many other programs aimed at a greater good are not billed on the basis of usage but on the basis that the good to society represents a greater "fairness" than billing on a usage basis. A previous author, in criticizing my highway analogy, actually argued in favor of my point by noting that toll road was less utilized than the alternate routes which were subsidized by taxation rather than usage tax (except indirectly, by gasoline taxes). The arguement here is that there is a societal good which justifies the expenditure of public funds without regard to direct usage. In the sense that this benefits all of us, independent of our ability to pay, one might argue that it is more benevolent than a system which is more "fair". The problem with many policy-makers is that they love to deal with numbers and go to great pains to quantitize any problem so that they can deal with it using well established (if unimaginative), numeric systems. There is a qualitative issue here, which deals with our economic and technologic competitive edge as a function of information sharing, which cannot easily be reduced to a scalar. We have an obligation to study that thoroughly before we institute the policies of some pencil pusher who needs to show some federal budgeteer a black line that puts them in the clear and forces the rest of us to deal within the limits of short sighted policy-makers. I agree that a study should be done, but participants should not be limited solely to knife wiedling accountants and the clever technocrats who have demonstrated that we have the technology to institute such as system as packet accounting, but also to those people who are able to see how our future as developers and users of this technology and as a nation, would be best served. Sean McLinden Decision Systems Laboratory University of Pittsburgh ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4547@blia.BLI.COM] <1988042120391500> From: ted@blia.BLI.COM (Ted Marshall) Newsgroups: comp.protocols.tcp-ip Subject: Re: packet lengths Message-ID: <4547@blia.BLI.COM> Date: 21 Apr 88 20:39:15 GMT References: <8804191854.AA00089@apolling.imagen.uucp> Organization: Britton Lee, Los Gatos, CA Lines: 33 Summary: integral number of 8-bit octets, not 16-bit words In article <8804191854.AA00089@apolling.imagen.uucp>, geof@imagen.UUCP (Geof Cooper) writes: > The Ethernet requires that packets be an integral number of 16-bit words > long. Sorry, no. An integral number of 8-bit octets, not 16-bit words. Quoting from page 19 of the version 1.0 Ethernet specification: Figure 6-1 shows the five fields of a frame: the addresses of the frame's source and destination, a type field [...], a data field [...], and the frame check sequence [...]. Of these five fields, all are of fixed size except the data field which my contain any integral number of octets between the minimum and maximum values ^^^^^^^^^^^^^^^^^^^^^^^^^ [ ^'s are mine. TM] specified below (see 6.2.5). Figure 6-1 shows the layout of a frame and also of an octet (showing 8 bits, transmitted LSB first). I don't have a copy of the 2.0 spec, but I don't think they changed this. If they did, DEC is breaking the spec; I know that the VAX/VMS Ethernet cards and drivers allow odd-byte-count length packets to be sent. That is not to say that every Ethernet interface manufacturer built their unit so that it can transmit an odd number of bytes. In fact, I believe that there are some that can only transmit multiples of 4 bytes. In general, no Ethernet protocol should be used that depends on the data link layer to report exactly the number of bytes in the packet since short packets must be padded to the minimum size. -- Ted Marshall ...!ucbvax!mtxinu!blia!ted mtxinu!blia!ted@Berkeley.EDU Britton Lee, Inc., 14600 Winchester Blvd, Los Gatos, Ca 95030 (408)378-7000 The opinions expressed above are those of the poster and not his employer. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23737@bbn.COM] <1988042120410200> From: wbe@bbn.com (Winston B Edmond) Newsgroups: comp.protocols.tcp-ip Subject: Re: another thought on packet charging Message-ID: <23737@bbn.COM> Date: 21 Apr 88 20:41:02 GMT References: <8804210408.AA16030@bu-cs.bu.edu> Sender: news@bbn.COM Reply-To: wbe@BBN.COM (Winston B Edmond) Organization: BBN Laboratories Incorporated, Cambridge, MA Lines: 15 Barry Shein writes: >Does anyone have a proposed set of rules that are better than these? > >[SECOND HALF] > >About the only thing that comes to my mind is a meta-protocol (ICMP?) >sort of like a WILL YOU/WONT YOU: This (transfer of charges on request) is essentially what I proposed in my previous message. The main difference is that I claim the protocol should be between the hosts and the network (the entity collecting the billing information) and not between the hosts directly. What's important to the host trying to reverse the charges is that the network says billing has been transferred, not that the other host has made a promise to accept the bill. -WBE ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042200450300> Received: from unix.SRI.COM by SRI-NIC.ARPA with TCP; Fri 22 Apr 88 09:01:45-PDT Received: by unix.SRI.COM (5.31/5.14) id AA17688; Fri, 22 Apr 88 09:01:43 PDT Date: Fri, 22 Apr 88 08:45:03 PST From: geoff@fernwood.mpk.ca.us (Geoff Goodfellow) Subject: re: packet charging (EFT model), others. Message-Id: <8804220845.0.UUL1.3#948@fernwood.mpk.ca.us> To: tcp-ip@sri-nic.arpa Reply-To: Geoff%fernwood.mpk.ca.us@unix.sri.com i'd like to propose that methods of reverse charging or the negotiation thereof become known as The Internet Buck Passing Protocol. geoff  ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042200570000> Mail-From: STJOHNS created at 22-Apr-88 08:03:00 Date: 22 Apr 1988 07:57-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Packet accounting and a place to do it From: STJOHNS@SRI-NIC.ARPA To: haas@GR.UTAH.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]Fri, 22 Apr 88 07:57:38 PDT.STJOHNS> In-Reply-To: <2466@utah-gr.UUCP> Date: 21 Apr 88 17:14:25 GMT From: haas@gr.utah.edu (Walt Haas) To: tcp-ip@sri-nic.arpa Subject: Re: Packet accounting and a place to do it It seems to me that the most sensible way to do packet accounting is the way that the public networks (Telenet, Tymnet) do it - that is, all packets on a virtual circuit are charged to whoever established that VC unless the call was placed and accepted as "collect", in which case the recipient pays for it. .... Cheers -- Walt Haas haas@cs.utah.edu utah-cs!haas -------------------- One small problem with this approach - during the life of a TCP connection, many X.25 connections may come and go. The X.25 connections may be closed down due to idleness or resource reallocation, and may be reopened from either end of the pipe. Also, an X.25 connection may carry data from more than one TCP session. And it may also have UDP traffic mixed in. Who gets the bill? Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804220314.AA09716@nisc.nyser.net] <1988042203145300> From: fedor@NISC.NYSER.NET (Mark S. Fedor) Newsgroups: comp.protocols.tcp-ip Subject: Re: bad press for NSFNET Message-ID: <8804220314.AA09716@nisc.nyser.net> Date: 22 Apr 88 03:14:53 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Kent, Your are indeed brave! The NSFNet routing scheme (RT routing) is not for the week of heart! I could mail you relevant papers if you need them. Mark` ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042203491500> Received: from SUMEX-AIM.Stanford.EDU by SRI-NIC.ARPA with TCP; Fri 22 Apr 88 11:25:21-PDT Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Fri, 22 Apr 88 11:20:47 PDT Date: Fri, 22 Apr 88 10:49:15 PDT From: Mark Crispin Subject: Packet accounting To: TCP-IP@SRI-NIC.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12392527963.7.MRC@PANDA.PANDA.COM> Walt Haas' idea certainly makes the most amount of sense, provided that the concept of a "VC" under IP can be clearly identified to the accounting processes. It's a bit harder for UDP than TCP, but it still can be done. It is important that only packets which are delivered to the destination are charged. I won't worry about packets getting dropped at a site's LAN -- if they have a too-high drop rate then it's their own responsibility to fix their LAN/gateway!!! This seems to be a reasonable model for a typical "service host": . Telnet - accept collect calls (since the site is presumably already billing the customer and network charges can be easily added to the bill ala CompuServe, etc.) . FTP - accept collect calls for login FTP. Create a *new* FTP service for non-login (ANONYMOUS) FTP that does not accept collect calls. . Mail - do not accept collect calls for ordinary mail. Create a *new* mail service for bulk-distribution (mailing list, newsgroup, etc.) mail which does accept collect calls. The idea behind such a model is that the service host is charged for network traffic only when those charges can be clearly passed on to a customer of that service host. When an external agent is benefiting from access to the service host (e.g. ANONYMOUS FTP) that agent foots the bill. In mail, I follow the model of postal mail in that the sender puts the stamp on the mail. The "bulk-distribution" service is sort of a misnomer; a better name would be "collect mail". A site which doesn't want such mail can simply not offer the service; of course such a site may miss out on mailing lists, newsgroups, file transfer via mail, etc. It would be up to the site to decide upon how to handle the charging. One way would be to have a more limited list of recipients of collect mail than for ordinary mail. The technical problems in all of this are relatively straightforward: 1) the accounting mechanism must be in place and it must be clear to all parties who is paying for the datagrams!! Some mechanism is needed to handle those datagrams that don't neatly fit into a "VC" model. 2) FTP and Mail probably need to be split into two additional services. I am also assuming that it must be clear to all concerned that accounting begins and ends at the DDN. You won't be charged for packets the DDN drops, but if your gateway drops lots of packets that's tough. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804220415.AA17374@vax.ftp.com] <1988042204153600> From: jbvb@VAX.FTP.COM (James Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Maximum size IP packets Message-ID: <8804220415.AA17374@vax.ftp.com> Date: 22 Apr 88 04:15:36 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 Our PC/DOS TCP/IP will only assemble packets smaller than the MTU of the attached networks. We decided that anything fancier than that would waste too much memory for essentially no benefit. It helps that the smallest MTU any of our interfaces use is about 1K bytes, well above the IP requirement of 576. Mobygrams fail miserably in the face of *any* packet loss, because none of the IPs I know anything about allow retransmissions with the same IP identification value. All the fragments of a particular retransmission of a mobygram must survive the net before it can be re-assembled. In PCs in particular, you can't get below a certain level of packet loss due to cheap network interfaces, so you're stuck. NFS is the only conspicuous user of mobygrams that I know of, and I think that Van Jacobsen and Mike Karels have demonstrated that Sun's choice of fragmented UDP mobygrams, unchecksummed, was a costly way to achieve high throughput. James VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804212341.AA15356@ucbvax.Berkeley.EDU] <1988042205311900> From: GRFXLS@SUVM.ACS.SYR.EDU Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8804212341.AA15356@ucbvax.Berkeley.EDU> Date: 22 Apr 88 05:31:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 2 X-Unparsable-Date: Tue, 19 Apr 1988 18:37:41 LCL I'm sorry if I am at the wrong group. I'd like to find out where I could get parts for AT&T7300. I am looking for a power supply and 20 MB harddisk. Please, send me a mail if you have any information about it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1064@mcgill-vision.UUCP] <1988042206433600> From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.protocols.tcp-ip Subject: Re: BITNET mail follows (really: IP forwarding) Message-ID: <1064@mcgill-vision.UUCP> Date: 22 Apr 88 06:43:36 GMT References: <8804090447.AA06537@ucbvax.Berkeley.EDU> Organization: McGill University, Montreal Lines: 33 In article <8804090447.AA06537@ucbvax.Berkeley.EDU>, B32357@ANLVM.BITNET writes: > Subject: BITNET mail follows Can't someone do something about this? It's got to be one of the least informative subject lines in existence, right up there with "(none)". Can't the BITNET gateway be kludged to recognize when it's about to generate a posting with this subject and do something more useful? > How does one disable IP forwarding? This depends on the gateway machine software. For Berkeley UNIX, 4.3 at least, there's a kernel variable called ipforwarding which can be set to 0 to disable forwarding. To change it, use adb: % adb -w -k /vmunix /dev/mem _ipforwarding/W 0 <- in running system _ipforwarding?W 0 <- in kernel file $q Changes made to the running system take effect immediately but go away at next reboot; changes made to the kernel file are permanent but don't take effect until next reboot. (Well, permanent until you rebuild an new kernel and install it. To fix it *really* permanently, change the initialization in netinet/ip_input.c (or you may be able to use a config file line options "IPFORWARDING=0" ).) der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042209165600> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Fri 22 Apr 88 14:30:48-PDT Received: from ODUVM.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 0308; Fri, 22 Apr 88 16:11:29 EDT Received: by ODUVM (Mailer X1.24) id 5805; Fri, 22 Apr 88 14:33:07 EST Date: Fri, 22 Apr 88 14:16:56 EST From: Bob Alston Subject: Help with Netware compatible (hardware independent) pc-tcp/ip To: pcip lists , pcip list , Telnet list , tcp-ip list We at ODU Computing Services are looking for a hardware topologically independent tcp/ip solution for our Novell Networks. We have an ethernet based TCP/IP backbone that we would like to be able to take advantage of from several existing and proposed Novell pc networks using IBM Token Ring, 3COM 501 Ethernet, SMS Arcnet, and other asstd. hardware topologies. I have seen the Micom-Interlan (Netware) TCP/IP gateway, but have concerns about its performance. Also, I have seen several workstation based solutions (ie Excelan, Ungermann-Bass, etc.), but we already have a substantial hardware investment in other pc network interface cards (token ring, ethernet, etc. as mentioned above) and also have heard that the aformentioned workstation based solutions are prohibitively expensive. I have heard rumors of a netbios based solution and I would be very interested in learning more. Please send me any and all info you can share. I will be glad to post the responses to the lists. Thanks in Advance Bob Alston Old Dominion University Norfolk, VA BITNET: RWA100S@ODUVM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804221102.AA16240@kappa.rice.edu] <1988042211021500> From: rich@RICE.EDU (Richard Murphey) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP on Apollo Domain systems Message-ID: <8804221102.AA16240@kappa.rice.edu> Date: 22 Apr 88 11:02:15 GMT References: <8804210125.AA00888@wb6rqn.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: rich@rice.edu Organization: Rice U., Dept. of Elec. & Comp. Engr. (rich@rice.edu) Lines: 8 Hi Brian, I have an office mate who is using a couple of Apollos in his lab. They are in the process of getting an ethernet with TCP-IP up and running. His name is John Halter and his address is jah@rice.edu. I'll see what information I can get regarding their solution so far. rich ----MESSAGE-END---- ----MESSAGE-BEGIN---- [843@wright.EDU] <1988042211092000> From: jsloan@wright.EDU (John Sloan) Newsgroups: comp.protocols.tcp-ip Subject: Re: bad press for NSFNET Message-ID: <843@wright.EDU> Date: 22 Apr 88 11:09:20 GMT References: <21851@bu-cs.BU.EDU> Organization: Wright State University, Dayton OH, 45435 Lines: 27 Apart from the Datacomm article, all the wide area networks, including NSFNET, got a lot of bad, or at least interesting, press in the _The_Chronicle_of_Higher_Education_, 6 April 1988, A11. The gist of the article is that the WANS (NSFNET, ARPANET and BITNET are specifically mentioned) are victims of their own success, and that they don't have the financial resources (and all that implies: staff, equipment, etc.) to support the exploding growth in their use. It mentions too the cost of local (campus-wide) area networking, and that many universities are finding it expensive to support, also in part because of the growth in usage. The _Chronicle_ is a trade rag for the education industry. University administrators read it routinely. The thing that concerns me is that they'll only see the bottom line, not the fact that most of these problems are occurring because the networks are immensely popular. I just co-wrote a proposal for a more extensive campus network, and this article came out right when we fielded the proposal to the administration. Great. In times when university administrators are more bean-counters than educators (and, admittedly, perhaps necessarily so) this is probably going to make selling networking more difficult. -- John Sloan, The SPOTS Group Wright State University Research Building CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!cbosgd!wright!jsloan +1-513-259-1384 +1-513-873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]Fri,.22.Apr.88.07:57:38.PDT.STJOHNS] <1988042214570000> From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet accounting and a place to do it Message-ID: <[SRI-NIC.ARPA]Fri,.22.Apr.88.07:57:38.PDT.STJOHNS> Date: 22 Apr 88 14:57:00 GMT References: <2466@utah-gr.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 Date: 21 Apr 88 17:14:25 GMT From: haas@gr.utah.edu (Walt Haas) To: tcp-ip@sri-nic.arpa Subject: Re: Packet accounting and a place to do it It seems to me that the most sensible way to do packet accounting is the way that the public networks (Telenet, Tymnet) do it - that is, all packets on a virtual circuit are charged to whoever established that VC unless the call was placed and accepted as "collect", in which case the recipient pays for it. .... Cheers -- Walt Haas haas@cs.utah.edu utah-cs!haas -------------------- One small problem with this approach - during the life of a TCP connection, many X.25 connections may come and go. The X.25 connections may be closed down due to idleness or resource reallocation, and may be reopened from either end of the pipe. Also, an X.25 connection may carry data from more than one TCP session. And it may also have UDP traffic mixed in. Who gets the bill? Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804221603.AA29856@LANAI.MCL.UNISYS.COM] <1988042216031700> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <8804221603.AA29856@LANAI.MCL.UNISYS.COM> Date: 22 Apr 88 16:03:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 Sean, I agree with you arguments whole heartedly! Your argument is essentially that the communications cabpability provided by networks like the Arpanet provide a higher level good than just commuications. This is often thought of as 'infrastructure' in some circles, where the infrastructure is what allows society as a whole to operate at a higher level than it could otherwise. How does one pay for infrastructure? Usually thru some means other than usage, although that could be a part of the rate structure. More often infrastructure is paid for thru taxes of some form. Taxes, as we all know, are also often used to provide societal gains, and not all pay according to use (perhaps inversely? :-). I suspect that usage charges on the Arpanet will cause unknown sociological behavior which may turn out to be worse for the government than for the research community as a whole, and what started out as a way to solve a simple budgeting problem may well end up creating a more complicated infrastructure problems which will work against DARPA's desire to foster scientific research in the US and aid the competitiveness of other countries. dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804221749.AA00135@apolling.imagen.uucp] <1988042217492500> From: geof@imagen.UUCP (Geof Cooper) Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: packet lengths Message-ID: <8804221749.AA00135@apolling.imagen.uucp> Date: 22 Apr 88 17:49:25 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 > Your statement that the Ethernet (IEEE 802.3 as well?) requires packets to > be in integral number of 16-bit words long is incorrect. On reference to the original Ethernet 1 spec, I stand corrected. The packet length is an integral number of octets. I must have been thinking of the 3MB experimental ethernet, as you say. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23792@bbn.COM] <1988042218104000> From: wbe@bbn.com (Winston B Edmond) Newsgroups: comp.protocols.tcp-ip Subject: Re: packet charging (the EFT model?) Message-ID: <23792@bbn.COM> Date: 22 Apr 88 18:10:40 GMT References: <8804220957.AA26052@ucbvax.Berkeley.EDU> Sender: news@bbn.COM Reply-To: wbe@BBN.COM (Winston B Edmond) Organization: BBN Laboratories Incorporated, Cambridge, MA Lines: 29 Michael Stein writes: >Instead of a "WILL/WONT PAY" protocol (which only works on >connections) how about something else: > >Suppose that it was possible to send packets containing "money"? This sounds like a good, general solution. If I understand it right, billing by the network ALWAYS go to the sender of the packet, but the "money" transferred becomes a promise to pay from one host to another. Thus, at the end of the month, the host administrator will get a bill for network services, pays the bill, and has X dollars in Accounts Receivable from other hosts sending "money", and Y dollars in Accounts Payable the host has promised to send to other hosts. You will need to figure out how to say "I'll pay up to D dollars", since the cost of a message may well depend on the Internet path it takes between the hosts. It may also be difficult to "make change", since the price of the packets to return money may cost more than the amount to be refunded. However, if you want the end-of-the-month bill from the networks to directly reflect the "money" exchanged, then I caution again that the final exchange of money or billing charges should be between the billed client and the billing entity (the network) in order to prevent counterfeiting, empty promises, and even ordinary billing errors. This means the protocol for paying wouldn't a high level protocol like IP, but an enhancement to the network level protocols. The Automatic Teller networks have solved this kind of reliable money transfer, so perhaps we don't need to reinvent everything. -WBE ----MESSAGE-END---- ----MESSAGE-BEGIN---- [0WPteYy00W0rE5pUQQ@andrew.cmu.edu] <1988042219102800> From: ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet level accounting in IP routers? Message-ID: <0WPteYy00W0rE5pUQQ@andrew.cmu.edu> Date: 22 Apr 88 19:10:28 GMT References: <23509@bbn.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 27 There is lots of good economics research on how to price for services which are mostly based on fixed capital investments. Consider local phone service: you need a wire from your house to the local telephone central office whether you make one call or many calls. On the other hand, the computer which sets up calls grows in proportion to the number of calls made, while the cost of the switch matrix is proportional to total length of all calls. Inter-office trunk requirements depend upon the volume of calling minutes in the peak hour. Thus optimal local phone prices should probably have some component which is based on connection cost (to cover the local loop), some component based on call frequency, and some component based on call minutes. Moreover, these rates should be different in peak hours than in off peak hours, because only peak hour traffic stimulates the need for more trunks. Using pricing to shift usage from peak to off peak hours reduces the peak trunk requirements. Long distance telephone rates already make use of this simple fact. Computer service bureaus have long since learned these theories and have implemented them in their pricing policies. Two particularly good articles are: Mitchell, Bridger M., "Economic Issues in Usage Sensitive Pricing," The RAND Corporation P-6530, 1980, and Park, Rolla Edward, and Bridger Mitchell, "Optimal Peak-Load Pricing for Local Telephone Calls," RAND, R-3404-1-RC, March 1987. A more accessible article is: Mitchell, "Optimal Pricing of Local Telephone Service," American Economic Review, Sept, 1978, and ----MESSAGE-END---- ----MESSAGE-BEGIN---- [532@interlan.UUCP] <1988042219130900> From: brad@interlan.UUCP (Brad Kemp) Newsgroups: comp.protocols.tcp-ip Subject: Re: packet lengths Message-ID: <532@interlan.UUCP> Date: 22 Apr 88 19:13:09 GMT References: <8804191854.AA00089@apolling.imagen.uucp> Reply-To: brad@interlan.UUCP (Brad Kemp) Organization: MICOM-Interlan, Boxborough, MA (1-800-LAN-TALK) Lines: 30 In article <8804191854.AA00089@apolling.imagen.uucp> geof@imagen.UUCP (Geof Cooper) writes: > > > I have been comparing the lengths of packets specified in IP headers > > against actual packet lengths. What I am seeing, ignoring IP packets > > smaller than the minimum packet size, is that a fair number of machines > > send out packets that are 1-3 bytes longer than is specified by the > > IP length. > >The Ethernet requires that packets be an integral number of 16-bit words >long. The Ethernet also has a minimum packet size of 60 bytes. Any IP >packet that is less than 60 bytes in length (including ethernet header) >will be padded to 60 bytes. The IEEE 802.3 length field would allow >you to explicitly set the ethernet length, but Ethernet doesn't. The Ethernet 2.0 spec states: ...Of these five fields, all are fixed size except the data field, which may contain any integral number of octets between the minimum and maximum values specified below (see 6.2.5) Ethernet 2.0 pg 25 This means that odd length packets are legal. IEEE 820.3 also specifies an intregral number of octets. (pg 26 3.2.7) Most impelemntations of protocols pad to an even byte length to keep their more braindamaged bretheren from puking. IP only cares about the octets specified in its length field, the pad octets are ignored Brad Kemp MICOM-Interlan {ulowell,mit-eddie}!interlan!brad ----MESSAGE-END---- ----MESSAGE-BEGIN---- [472@mailrus.cc.umich.edu] <1988042219271300> From: emv@starbarlounge (Edward Vielmetti) Newsgroups: comp.protocols.tcp-ip Subject: Re: packet charging (the EFT model?) Message-ID: <472@mailrus.cc.umich.edu> Date: 22 Apr 88 19:27:13 GMT References: <8804220957.AA26052@ucbvax.Berkeley.EDU> Sender: usenet@mailrus.cc.umich.edu Reply-To: emv@starbarlounge.cc.umich.edu (Edward Vielmetti) Organization: University of Michigan Computing Center, Ann Arbor Lines: 13 Summary: money is too easy to print UUCP-Path: {uunet,rutgers}!umix!emv In article <8804220957.AA26052@ucbvax.Berkeley.EDU> csysmas@OAC.UCLA.EDU (Michael Stein) writes: >Instead of a "WILL/WONT PAY" protocol (which only works on >connections) how about something else: > >Suppose that it was possible to send packets containing "money"? > Fake "money" is too easy to "print". Me and my PC can decipher the money protocol and send out bogus cash at our leisure. Schemes like this violate the principle that hosts are not to be trusted. Edward Vielmetti, U of Michigan mail group. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [668@ncrcce.StPaul.NCR.COM] <1988042220165200> From: cavanaug@ncrcce.StPaul.NCR.COM (John David Cavanaugh) Newsgroups: comp.protocols.tcp-ip Subject: Telnet Commands in 3270 Data Stream Message-ID: <668@ncrcce.StPaul.NCR.COM> Date: 22 Apr 88 20:16:52 GMT Reply-To: John.Cavanaugh@StPaul.NCR.COM Organization: NCR Comten, Inc. Lines: 24 Keywords: Telnet, 3270, tn3270 References: I wonder if anyone can help me with a protocol question. Suppose you have a Telnet connection that has been put into 3270 mode either by the 3270 Regime option or a la tn3270 (Terminal Type, Binary, and End of Record options). When you get a 3270 data stream, you look for IAC EOR to mark the end of it. The question is: What do you do when you find some other Telnet command (e.g. IAC AO) before you find the EOR? I can imagine four choices: 1. Ignore the command (doesn't seem like a good idea). 2. Handle the command immediately (the problem with this is that a lot of the Telnet commands don't have much meaning in 3270 mode). 3. Save the command and do it after you find the EOR (doesn't seem right). 4. Throw away the whole data stream and send an error message back to the user (which hoplessly messes up some poor data entry clerk's session). My understanding is that Telnet commands "shouldn't" appear in the middle of the data stream. Is this correct? Does any implementation of tn3270 or the 3270 Regime option put commands there? Thanks in advance for your help. Reply to: John Cavanaugh John.Cavanaugh@StPaul.NCR.COM NCR Comten, Inc. 2700 Snelling Ave. N St. Paul, MN 55113 (612) 638-2822 The opinions expressed ... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804222219.AA01478@LANAI.MCL.UNISYS.COM] <1988042222193700> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <8804222219.AA01478@LANAI.MCL.UNISYS.COM> Date: 22 Apr 88 22:19:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Barry, In New Mexico we had a saying (and I am sure it applys to other states as well) that one should vote early and often! :-) I agree with suggestions made by some that a study of the possible outcomes of varioius policies on charging would be an interesting thing to do. Such a study could help convince those that make such decisions that certain policies might not be worth pursuing. After all, many decisions get made because of 'hot buttons' that might be better avoided than pushed. I would be glad to organize a group of people that would like to meet in DC or whereever to discuss such a study, make up an agenda, parcel out assignments, and the reassemble to put the paper together. dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804222230.AA09291@bu-cs.bu.edu] <1988042222305200> From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Whither chargeback policies? Message-ID: <8804222230.AA09291@bu-cs.bu.edu> Date: 22 Apr 88 22:30:52 GMT References: <8804222219.AA01478@LANAI.MCL.UNISYS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 22 The way I've heard it is: Vote Often, Vote Early, Vote for James Michael Curly! (Curly was a notorious ward-healer who became mayor of Boston in the 1930's I believe, they still talk about those "good ole days" when corruption went to the -right- people.) Well, at least it scans... I would be interested in attending a meeting in DC (or wherever) to discuss such issues. Assembling an invitees list would be interesting although for starters it might just need "activists", others can be contacted once several of us figure out how to start saying the same things. I believe this upcoming election might make this an opportune time to start, a new administration might be more receptive to new-sounding programs such as computer networking. It would be hard to imagine any broad-based objection to it (other than those of a particularly privatizing bent, which should be addressed.) -B ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042301500000> Received: from nswses.arpa by SRI-NIC.ARPA with TCP; Sat 23 Apr 88 09:54:01-PDT Date: 23 Apr 88 09:50:00 PST From: "TERVAX::EFBATEY" Subject: Micom-Interlan NST-100 with 1200b 3124EH Modem To: "tcp-ip" cc: efbatey Reply-To: "TERVAX::EFBATEY" --------------- Reply-To: I have a half dozen Micon-Interlan NTS-100 Telnet / Rlogin servers (V2.0 Boot Feature Packs). Any one of them interfacing my Micom 3124EH-S1 Hayes-Clone or different 3124 suffer from a common problem. Conditions are 1200 baud, DTE-set, XON/XOFF IN, XON/XOFF OUT, using the vi editor, a screen busy process (best, but not only demo). An inbound caller is executing commands which solicit more output while the output (to users terminal crt). Output to remote terminal from last command is in progress (user TYPE AHEAD). User gets rudely awakened when the { BSD or SysV host | network | NTS-100 } exits. The process on the host terminates. The user is greeted by Serv_prompt> without even a courtesy { 'buffer overflow' | 'if only XON/XOFF really worked' | 'if server had more spool space' } message. I bought nearly a year ago from the newly formed Micom .AND. Interlan which now barely admit the other exists. Interlan keeps trying but they seem to be an East coast company and will not even log onto my system to witness my problem. Anyone with any experience or suggestions IS INVITED. I'll buy lunch. ------------------------------------------------------------ | Everett F. Batey II } { UUCP: sun!tsunami!nswed5!efb | | USNSWSES - Code 4V33 } { ARPA: efbatey@NOBBS.UCSB.EDU | | After HOSTS.TXT.726 } { efbatey@NSWSES.ARPA | ------------------------------------------------------------ ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [Apr.22.22.18.36.1988.18656@athos.rutgers.edu] <1988042302183700> From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Which version does Sun run? Message-ID: Date: 23 Apr 88 02:18:37 GMT References: <6140@shamash.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 49 To: jwabik@shamash.UUCP In article <6140@shamash.UUCP> jwabik@shamash.UUCP (Jeff Wabik) writes: > Does anyone know which version of tcp-ip is implemented in the standard > Sun OS (Sun UNIX 3.x) ? 802.2? 802.2/snap? 802.3? The wording of this question is not perhaps as precise as it might be. TCP/IP as a protocol suite covers OSI layers 3 and above. The 802 things you cite are at layers 2 and below. So whether or not of 802.2 is used, with or without SNAP's, is not really a matter of the version of TCP/IP. The way IP works is that there is a standard for how to run it on each particular type of network medium. This is referred to as an "encapsulation", since normally what happens is that the IP packets get encapsulated in a packet appropriate to the medium. So whether 802.2 is used is a question of the particular encapsulation used, not the version of IP used. There is an official IP encapsulation for 802-type networks. It is defined by RFC 1042. It supports 802.2 LLC and SNAP over 802.3, .4, and .5 networks. However this is a new RFC, defined primarily for the benefit of IBM token ring and similar new 802 technologies. In fact the "traditional" TCP/IP medium is Ethernet, as opposed to 802.3, and this is what Sun supports. Of course there's very little difference between Ethernet and 802.3. The main one is that what Ethernet calls a type field, 802.3 calls a length field. The IP encapsulation for Ethernet uses the type field to identify the packets as IP packets. This encapsulation has a bare minimum of overhead. The Ethernet headers are put immediately in front of the IP headers. So you've just got Ethernet addresses and a type code identifying the packet as IP. No LLC or SNAP type stuff is used. (There is also a different Ethernet type code used for a secondary protocol called ARP. This protocol is used to map from IP address to Ethernet address. This protocol is officially considered part of the Ethernet encapsulation specification.) Suns normally use this Ethernet encapsulation, not the newer 802-style encapsulation. Of course the defined Ethernet types are large enough that they do not form legal 802.3 packet lengths, so in fact there's no reason that a single cable can't carry both types of protocol. Indeed in theory one could have two separate (and non-communicating) TCP/IP networks on the same cable, one using the traditional Ethernet encapsulation, and the other using the new 802-style encapsulation. However so far I haven't seen 802-style encapsulations used on Ethernet or 802.3, except by HP (who designed a different encapsulation that apparently only HP and cisco implemented) and cisco (who implement all three encapsulations: Ethernet, the HP version, and the new 802.3 standard). In general the TCP/IP community is really using Ethernet version 2, not IEEE, except to the extent that IEEE happens to be compatible with Ethernet. This may change over time, as other 802 networks become more common. At the moment the same is true of DECnet, XNS, and other network protocols that we see on our cables. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042303130000> Received: from twg.com by SRI-NIC.ARPA with TCP; Sat 23 Apr 88 10:18:18-PDT Received: from TWG.COM by twg.com with SMTP ; Sat, 23 Apr 88 09:16:14 PST Received: from vax2.twg.com by Gonzo.TWG.COM id aa20902; 23 Apr 88 10:11 PDT Date: 23 Apr 88 10:13:00 PDT From: eva@TWG.COM MMDF-Warning: Parse error in original version of preceding line at TWG.COM Subject: Re: Wollongong's TN3270 To: tcp-ip Especially to: "Crack? No thanks, I've got a new CD player" <...!daveb> We are not aware of the existence of curses in the PD. In my article I wrote "currently available", which really means the state of out products at this "currently available", which really means the state of our products at this time. Definitely, it does not mean we will do it this way till the final day of existence of our solar system... We are pursuing the option in our WIN/TCP, which will allowe you to have TN3270 without any UNIX license. By the way... Which PD curses are your favorite and where are the sources? Eva The Wollongong Group The Wollongong Group ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042306581300> Received: from vax.ftp.com by SRI-NIC.ARPA with TCP; Sat 23 Apr 88 08:02:55-PDT Received: by vax.ftp.com id AA22781; Sat, 23 Apr 88 10:58:13 EDT Date: Sat, 23 Apr 88 10:58:13 EDT From: jbvb@vax.ftp.com (James Van Bokkelen) Message-Id: <8804231458.AA22781@vax.ftp.com> To: RWA100S@ODUVM.BITNET Cc: pcip@UDEL.EDU, telnet@ncsa.uiuc.edu, tcp-ip@sri-nic.arpa In-Reply-To: Bob Alston's message of Fri, 22 Apr 88 14:16:56 EST <8804221611.aa01260@Louie.UDEL.EDU> Subject: Re: Help with Netware compatible (hardware independent) pc-tcp/ip None of them use NETBIOS to encapsulate IP datagrams, but there are several Novell-compatible, hardware- (but not media-) independent versions of TCP/IP for the IBM PC that are either commercially supported, or widely available in the public domain. Our product for the IBM 802.5 Token Ring calls the IBM-supplied software driver (the ASI interface), and can share it with other programs (Banyan Vines, Novell Netware). IBM's PC product might be able to manage the same trick, but I don't know of anyone who has tried it. A number of Novell's OEMs have modified their versions of Netware so that they support our Packet Driver spec. This allows our Generic Ethernet version to share the interface with Netware. (Or you can ask Karl Auerbach for the CMU version he posted about on pc-ip a week or two ago. It also uses the spec.) Regrettably, none of the versions of Netware that support the Packet Driver spec run on the 3C501, but there may be a workaround: The 3C501 is so simple (I'm being nice) that it is possible for two pieces of software using it to co-exist: You can run a TCP/IP package that is careful about restoring the interrupt vector, as long as you don't try to use the LAN program while the TCP/IP has the card. I know this works with our PC/TCP or the CMU freeware and 3Com's 3+, it would be worth trying with Netware. For Arcnet, you could try Philip Prindeville's version of the CMU code, which has also been mentioned on pc-ip. I don't know if you could manage the "co-existence" trick with Netware, or not. Of course, this approach requires IP routers to forward normal IP packets back and forth across the various networks. Keep in mind that encapsulating IP in NETBIOS datagrams requires at least one IP router, too. Somebody has to get the packets onto and off of your normal-IP backbone (?) Ethernet, and the NETBIOS-space, however it is mapped to the various LANs, is at least one subnet on its own. If you aren't totally committed to Netware, you might try looking up Banyan and asking them how they'd solve your problem. James VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804230938.AA07265@sluggo.sun.com] <1988042309385800> From: melohn@SUN.COM (Bill Melohn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Which version does Sun run? Message-ID: <8804230938.AA07265@sluggo.sun.com> Date: 23 Apr 88 09:38:58 GMT References: <6140@shamash.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: Sun Microsystems, Mountain View Lines: 8 In article <6140@shamash.UUCP> jwabik@shamash.UUCP (Jeff Wabik) writes: > Does anyone know which version of tcp-ip is implemented in the standard > Sun OS (Sun UNIX 3.x) ? 802.2? 802.2/snap? 802.3? Charles's observations are correct; the standard SunOS kernel provides support for TCP/IP over Ethernet/802.3. Sun does offer TCP/IP using snap over 802.2 (as defined in RFC1042) layered on either 802.3 or 802.4 using the Sunlink OSI product, which also comes with TP4/CLNS. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804240349.AA08383@ucbvax.Berkeley.EDU] <1988042317130000> From: eva@TWG.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong's TN3270 Message-ID: <8804240349.AA08383@ucbvax.Berkeley.EDU> Date: 23 Apr 88 17:13:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 Especially to: "Crack? No thanks, I've got a new CD player" <...!daveb> We are not aware of the existence of curses in the PD. In my article I wrote "currently available", which really means the state of out products at this "currently available", which really means the state of our products at this time. Definitely, it does not mean we will do it this way till the final day of existence of our solar system... We are pursuing the option in our WIN/TCP, which will allowe you to have TN3270 without any UNIX license. By the way... Which PD curses are your favorite and where are the sources? Eva The Wollongong Group The Wollongong Group ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042317260000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Sat 23 Apr 88 19:51:32-PDT Date: 23 Apr 88 22:26:00 EST From: Subject: WHY are those mailbridges dropping so many packets???? To: "tcp-ip" Folks: I must disagree with some of the remarks made about the recent mailbridge and EGP core server upgrades. I think the efforts of the IETF and the Adopt-A-Gateway donors have made a noticable improvement. I can recall a time when there were delays on the order of tens of seconds just to get an interactive character echo when crossing from Arpanet to Milnet. In some cases these were EGP/GGP extra hop delays, in others it would seem to be entirely attributable to the mailbridges. I haven't encountered anything like that lately, have you? Recent "ping" testing from MY host to the Arpanet side of the mailbridges doesn't reveal any dramatic delays or loss rates. I have run ping sessions that have sent out 500 packets without seeing one dropped, and obtained sub-second response in all cases. I'll admit sub-second response is not that much to be proud of, but it beats the old 30 second delays. It has been observed that the mailbridge gateways' packet drop rates are high. Someone conjectured that the cause might STILL be insufficient CPU cycles. The consistently "low" delays seen from my host would seem to indicate that the units are NOT that short on CPU horsepower. Another person suggested that the mailbridges may be I/O bound due to all the overhead-type traffic. Being I/O bound should lead to queuing (delays), and if excessive, packet loss. I don't seem to be seeing large ammounts of this when MY host pings the net-10 side of the mailbridges. So why are the official loss figures so high? In reviewing the graphs of the mailbridge long term packet drop rates, some persons have indicated that it looked like the drop rate INCREASED after the CPU upgrades! One explanation for this is as follows: the faster CPU now allows the mailbridge to ACCEPT much more traffic from the subnets; but it is still somehow limited in the rate at which it can SEND traffic into the subnets. When the packets cannot be sent, they are dropped. Why can't the packets be sent? Supposedly one of the major reasons is complying with the 8-in-flight rule (RFNM blocking). Once a mailbridge has taken a packet off of an input queue and "routed" it, it supposedly has no place to keep the packet if it cannot immediately be placed in the output queue. To make matters worse, a packet is considered "in-flight" when it is placed into the output queue, NOT when it has finally made its way through the output queue and the 1822 interface, and into the PSN. Thus, large numbers of packets are being dropped even when there may be space in memory in which they could be held, if either the 8-in-flight rule, or the design of the mailbridge software were changed to allow it. I am told that PSN 7 frees the Arpanet from the 8-in-flight limitation; blocking the host at the link layer when it has exhausted its quota of PSN buffering. The mailbridges, however, use revision controlled software which cannot be tinkered with to remove the RFNM counting. If the counting were removed, the mailbridge could better use what memory it has, as well as more of its quota of the buffering available in the PSN. I am told the Arpanet EGP servers have already been freed from the RFNM chains. Ah, but what about the Milnet side? It still runs PSN 6 software. What can be done on gateways' interfaces to the Milnet? Since the mailbridges are dropping lots of packets due to their "rfnm blocking", one might ask why are they being blocked? What's holding up those acknowledgements? Regardless of how rapidly a mailbridge can place packets into a subnet, in the long term a mailbridge can't successfully unload traffic at a rate faster than the next "IP entity" can accept it. That rate will be affected by the entity's horsepower and I/O limitations. Many of us run down the mailbridges for being antiquated junk. However, consider what the mailbridge may be sending to: a busy EGP core server (due to GGP extra hop traffic), or some other busy or underpowered gateway or host, such as a VAX 750 or worse (possibly with *USERS* to further degrade things). Even a good "IP entity" though, can't accept data faster than its interface rate (~56Kbps at most, the same as the mailbridges). If the interface is receiving traffic from another source besides the mailbridge (pretty likely for EGP servers and gateways), then the mailbridge can't send to it at full speed. For whatever reason, if the mailbridge can't deliver a traffic flow at the same rate as it is receiving it, it will eventually have to drop some of the packets of that flow. Unless the traffic source is somehow flow controlled, the source will continue to send at a rate faster than the rate at which the mailbridge can unload it. Given sufficient time (to fill up available queuing), this would seem to mandate dropping at the mailbridge. To obtain lower drop rates (which will conserve the bandwidth of the source subnet) we must exert some form of flow control on the sender. Since the mailbridge software is revision controlled (and destined for the Smithsonian anyway) it isn't likely that it will be enhanced. So implementation of Dr. Mills' sophisticated queue management/source quench systems will probably have to wait for the next generation of mailbridges. What can be done in the mean time? It would seem that a good way to stamp out excess packet loss (and wastefull retransmissions on the source subnet) is to stamp out old style TCP. Maybe we should have a campaign to promote the use of Jacobson/Karrels-TCP? Bob Enger ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804231838.AA05191@Larry.McRCIM.McGill.EDU] <1988042318382500> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <8804231838.AA05191@Larry.McRCIM.McGill.EDU> Date: 23 Apr 88 18:38:25 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 The way I've heard it is: Vote Often, Vote Early, Vote for James Michael Curly! (Curly was a notorious ward-healer who became mayor of Boston in the 1930's I believe, they still talk about those "good ole days" when corruption went to the -right- people.) Well, at least it scans... Is Curly the one who was re-elected while doing time because of a federal conviction? Something to do with putting too many friends and relatives on the city payroll? (Maybe that was Hurley) Ah, Boston... I believe this upcoming election might make this an opportune time to start, a new administration might be more receptive to new-sounding programs such as computer networking. It would be hard to imagine any broad-based objection to it (other than those of a particularly privatizing bent, which should be addressed.) This is a good point. And from the sound of it, you might already have certain such groups in mind? -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804232047.AA07129@Larry.McRCIM.McGill.EDU] <1988042320471200> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet accounting and a place to do it Message-ID: <8804232047.AA07129@Larry.McRCIM.McGill.EDU> Date: 23 Apr 88 20:47:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 Date: 21 Apr 88 17:14:25 GMT From: haas@gr.utah.edu (Walt Haas) Subject: Re: Packet accounting and a place to do it To: tcp-ip@sri-nic.arpa It seems to me that the most sensible way to do packet accounting is the way that the public networks (Telenet, Tymnet) do it - that is, [ ... ] To be perfectly honest, I can't see any reason to reinvent a wheel that currently works just fine. Not everyone is thrilled with the fairness of billing under Telenet. It doesn't reflect the (sometimes) wild variations in quality of service. The longer it takes my packet to get to its destination, the less I'm willing to pay... Anyway, why accept that existing models are sufficient and therefore refuse any possibility of inventing a superior method? The wheel is fine, but there are someplaces it just can't go. So we need the hovercraft too. The MILnet is not a public utility, and should not be run as one. A research facility model is more appropriate. -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804240344.AA08317@ucbvax.Berkeley.EDU] <1988042403260000> From: enger@BLUTO.SCC.COM Newsgroups: comp.protocols.tcp-ip Subject: WHY are those mailbridges dropping so many packets???? Message-ID: <8804240344.AA08317@ucbvax.Berkeley.EDU> Date: 24 Apr 88 03:26:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 95 Folks: I must disagree with some of the remarks made about the recent mailbridge and EGP core server upgrades. I think the efforts of the IETF and the Adopt-A-Gateway donors have made a noticable improvement. I can recall a time when there were delays on the order of tens of seconds just to get an interactive character echo when crossing from Arpanet to Milnet. In some cases these were EGP/GGP extra hop delays, in others it would seem to be entirely attributable to the mailbridges. I haven't encountered anything like that lately, have you? Recent "ping" testing from MY host to the Arpanet side of the mailbridges doesn't reveal any dramatic delays or loss rates. I have run ping sessions that have sent out 500 packets without seeing one dropped, and obtained sub-second response in all cases. I'll admit sub-second response is not that much to be proud of, but it beats the old 30 second delays. It has been observed that the mailbridge gateways' packet drop rates are high. Someone conjectured that the cause might STILL be insufficient CPU cycles. The consistently "low" delays seen from my host would seem to indicate that the units are NOT that short on CPU horsepower. Another person suggested that the mailbridges may be I/O bound due to all the overhead-type traffic. Being I/O bound should lead to queuing (delays), and if excessive, packet loss. I don't seem to be seeing large ammounts of this when MY host pings the net-10 side of the mailbridges. So why are the official loss figures so high? In reviewing the graphs of the mailbridge long term packet drop rates, some persons have indicated that it looked like the drop rate INCREASED after the CPU upgrades! One explanation for this is as follows: the faster CPU now allows the mailbridge to ACCEPT much more traffic from the subnets; but it is still somehow limited in the rate at which it can SEND traffic into the subnets. When the packets cannot be sent, they are dropped. Why can't the packets be sent? Supposedly one of the major reasons is complying with the 8-in-flight rule (RFNM blocking). Once a mailbridge has taken a packet off of an input queue and "routed" it, it supposedly has no place to keep the packet if it cannot immediately be placed in the output queue. To make matters worse, a packet is considered "in-flight" when it is placed into the output queue, NOT when it has finally made its way through the output queue and the 1822 interface, and into the PSN. Thus, large numbers of packets are being dropped even when there may be space in memory in which they could be held, if either the 8-in-flight rule, or the design of the mailbridge software were changed to allow it. I am told that PSN 7 frees the Arpanet from the 8-in-flight limitation; blocking the host at the link layer when it has exhausted its quota of PSN buffering. The mailbridges, however, use revision controlled software which cannot be tinkered with to remove the RFNM counting. If the counting were removed, the mailbridge could better use what memory it has, as well as more of its quota of the buffering available in the PSN. I am told the Arpanet EGP servers have already been freed from the RFNM chains. Ah, but what about the Milnet side? It still runs PSN 6 software. What can be done on gateways' interfaces to the Milnet? Since the mailbridges are dropping lots of packets due to their "rfnm blocking", one might ask why are they being blocked? What's holding up those acknowledgements? Regardless of how rapidly a mailbridge can place packets into a subnet, in the long term a mailbridge can't successfully unload traffic at a rate faster than the next "IP entity" can accept it. That rate will be affected by the entity's horsepower and I/O limitations. Many of us run down the mailbridges for being antiquated junk. However, consider what the mailbridge may be sending to: a busy EGP core server (due to GGP extra hop traffic), or some other busy or underpowered gateway or host, such as a VAX 750 or worse (possibly with *USERS* to further degrade things). Even a good "IP entity" though, can't accept data faster than its interface rate (~56Kbps at most, the same as the mailbridges). If the interface is receiving traffic from another source besides the mailbridge (pretty likely for EGP servers and gateways), then the mailbridge can't send to it at full speed. For whatever reason, if the mailbridge can't deliver a traffic flow at the same rate as it is receiving it, it will eventually have to drop some of the packets of that flow. Unless the traffic source is somehow flow controlled, the source will continue to send at a rate faster than the rate at which the mailbridge can unload it. Given sufficient time (to fill up available queuing), this would seem to mandate dropping at the mailbridge. To obtain lower drop rates (which will conserve the bandwidth of the source subnet) we must exert some form of flow control on the sender. Since the mailbridge software is revision controlled (and destined for the Smithsonian anyway) it isn't likely that it will be enhanced. So implementation of Dr. Mills' sophisticated queue management/source quench systems will probably have to wait for the next generation of mailbridges. What can be done in the mean time? It would seem that a good way to stamp out excess packet loss (and wastefull retransmissions on the source subnet) is to stamp out old style TCP. Maybe we should have a campaign to promote the use of Jacobson/Karrels-TCP? Bob Enger ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042417280000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 24 Apr 88 19:49:55-PDT Date: 24 Apr 1988 21:28-EDT Sender: CERF@A.ISI.EDU Subject: Re: Whither chargeback policies? From: CERF@A.ISI.EDU To: perry@MCL.UNISYS.COM Cc: sean@CADRE.DSL.PITTSBURGH.EDU, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]24-Apr-88 21:28:52.CERF> In-Reply-To: <8804221603.AA29856@LANAI.MCL.UNISYS.COM> Dennis, we pay a tax on gasoline which goes to maintain the Interstae Highway system. Gas usage is related to road usage - though how much of the use is on interstantes and how much on local roads isn't clear cut. I still think a usage-related charge is preferable to the fully subsidized free good we have today; there isn't any negative feedback on use, so we have congestion. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804242233.AA11948@braden.isi.edu] <1988042422330600> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: WHY are those mailbridges dropping so many packets???? Message-ID: <8804242233.AA11948@braden.isi.edu> Date: 24 Apr 88 22:33:06 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 Maybe we should have a campaign to promote the use of Jacobson/Karels-TCP? Bob Enger What do you mean, "maybe"? Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042423410000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 25 Apr 88 01:49:42-PDT Date: 25 Apr 1988 03:41-EDT Sender: CERF@A.ISI.EDU Subject: Re: Whither chargeback policies? From: CERF@A.ISI.EDU To: bzs%bu-cs.bu.edu@BU-IT.BU.EDU Cc: perry@MCL.UNISYS.COM, sean@CADRE.DSL.PITTSBURGH.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]25-Apr-88 03:41:01.CERF> In-Reply-To: <8804250323.AA11206@bu-cs.bu.edu> Barry (Shein): The reason I like the notion of trying to find a charge-back scheme is that it puts some motivation for efficient use into the loop. For cases where the need for or utility of service exceeds revenues generated, it is possible to subsidize (like lifeline service on the telephone system). I like that because it makes the subsidy visible and forces a decision about providing the subsidy to those who need it. It would be nice to discover that at some point these services could be provided commercially at affordable rates so that the system need not be run by the government at all. At the moment, I have the feeling that commercial rates would be prohibitive - but if there is an economy of scale, it might be that the commercial rates could be reduced if the entire Internet traffic were added to existing commercial traffic. I haven't looked at that at all recently and we'd need some statistics (which is why working on charge-back schemes is good - we may learn enough to figure out make the system pay for itself). Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]24-Apr-88.21:28:52.CERF] <1988042501280000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <[A.ISI.EDU]24-Apr-88.21:28:52.CERF> Date: 25 Apr 88 01:28:00 GMT References: <8804221603.AA29856@LANAI.MCL.UNISYS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Dennis, we pay a tax on gasoline which goes to maintain the Interstae Highway system. Gas usage is related to road usage - though how much of the use is on interstantes and how much on local roads isn't clear cut. I still think a usage-related charge is preferable to the fully subsidized free good we have today; there isn't any negative feedback on use, so we have congestion. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042503052600> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Mon 25 Apr 88 06:54:12-PDT To: tcp-ip@SRI-NIC.ARPA cc: CERF@A.ISI.EDU, sean@CADRE.DSL.PITTSBURGH.EDU, haverty@CCV.BBN.COM Subject: Re: Whither chargeback policies? In-reply-to: Your message of Mon, 25 Apr 88 06:15:05 -0400. <8804251015.AA04421@LANAI.MCL.UNISYS.COM> Date: Mon, 25 Apr 88 09:45:26 -0400 From: haverty@CCV.BBN.COM It's encouraging to see a discussion like this happening. I think it may be useful and/or important to note the distinction between cost-recovery and "cost"-feedback. All of a network's costs must be recovered somehow, and mechanisms must be in place to collect the data about costs to support collecting the needed funds. Basing that scheme on end-user usage is only one scheme, which is in favor right now - the analogy on the interstates might be if every vehicle's odometer reading was reported to some accounting system that produced bills. Cost feedback is a separable question, though closely related. The goal is to encourage efficiency and reduce waste usually, but also may be to encourage certain kinds of use that the benevolent network owner wants to promote. Feedback may be in the form of inconvenience (slow network performance, long gas lines at the pumps), or money, or availability (a T1 circuit to your campus, an interstate interchange at your town). My suspicion is that a mix of such techniques is needed. As people have noted, a blanket usage-based scheme might tend to stifle new ideas or uses; a free-networking approach drives costs out of sight for the benefactor. Maybe we need a scheme which promotes new ideas, but assures that efficiency gets introduced along the way to large scale usage of any particular idea? This sounds like a topic which needs wide input and thinking. Does it make sense to hold a session of some kind at the upcoming TCP/IP conference in Santa Clara this summer? Dan Lynch's shows seem to be drawing a good mix of academic, industry, government, and user representation. Dennis Perry - maybe in addition to pulling together that paper you mentioned, you could pull together a session to present results and a large dose of open discussion? Jack ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804250323.AA11206@bu-cs.bu.edu] <1988042503233800> From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Whither chargeback policies? Message-ID: <8804250323.AA11206@bu-cs.bu.edu> Date: 25 Apr 88 03:23:38 GMT References: <[A.ISI.EDU]24-Apr-88.21:28:52.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 This is coming down to "do we form bread lines, or do we bake more bread?" Some of it is a futures issue, given a reasonable "taxation" scheme could we keep ahead (or reasonably in line with) the traffic or do we consign ourselves to needing negative feedback to control usage? Even the Interstate Highway system recognizes that you need more highways going in/out of NYC than Coldwater Flats, which would seem to help. This is a two-edged sword, you justify more highways to NYC because there's more gas taxes collected there, but you still have the freedom to have a highway through Coldwater Flats (a tributary or exit or whatever makes sense) even if they could never justify such a think given a fair-share payback scheme. Maybe that's part of the problem, how do you deal with a few researchers who are deserving (that is, would get access at a larger institution) but won't generate enough packet charges to justify (payback) a net connection, the volume clout is just not there? Leave them out in the cold? Tell them to request special and specific subsidy from their funding source? Can some of that be reflected in the bandwidth they and others get? I think part of the idea of infrastructure includes subsidizing otherwise unprofitable ventures, like a highway exit to Coldwater Flats, on the assumption that most everyone needs minimal access, while still being able to respond appropriately to large needs. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]25-Apr-88.03:41:01.CERF] <1988042507410000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <[A.ISI.EDU]25-Apr-88.03:41:01.CERF> Date: 25 Apr 88 07:41:00 GMT References: <8804250323.AA11206@bu-cs.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 Barry (Shein): The reason I like the notion of trying to find a charge-back scheme is that it puts some motivation for efficient use into the loop. For cases where the need for or utility of service exceeds revenues generated, it is possible to subsidize (like lifeline service on the telephone system). I like that because it makes the subsidy visible and forces a decision about providing the subsidy to those who need it. It would be nice to discover that at some point these services could be provided commercially at affordable rates so that the system need not be run by the government at all. At the moment, I have the feeling that commercial rates would be prohibitive - but if there is an economy of scale, it might be that the commercial rates could be reduced if the entire Internet traffic were added to existing commercial traffic. I haven't looked at that at all recently and we'd need some statistics (which is why working on charge-back schemes is good - we may learn enough to figure out make the system pay for itself). Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804251005.AA04387@LANAI.MCL.UNISYS.COM] <1988042510055000> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <8804251005.AA04387@LANAI.MCL.UNISYS.COM> Date: 25 Apr 88 10:05:50 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 66 Vint, I belive that you gasoline tax illustrate the point I was trying to make, namely, usage charges are ignored by those who can afford it, e.g. they buy low efficiency automobiles like laborginis. It is not clear how much charging it takes to make a difference. Even with HOV in norther VA on I66 and other roads, many, if not most, people still prefer to drive one to an automobile. I posit that usage charges, to affect behvaior, will have to be unreasonably high. And then when they affect behavior, that behavior will become 'antisocial', that is, they will not use the system they way that is optimal, so efficiency becomes an issue again. My experience says that port charges, connect time, etc are not unreaonable type of charges. Volume usage charges are counter productive and drive people to find other means of solving their problems. After all, how much communications does it take to do the research you are involved in. Do you stop your research just because you cannot afford to pay the network charges? I suspect what will happen is you will pick up the telephone and play telephone tag with someone, a much less efficient way to communicate your research ideas. Or you may resort to no communication and just publish your results without feedback from you peers. Both of these alternatives are 'antisocial' behvior in that it is the opposite behavior expected from developing the net in the first place. But you might say, what about users who are using resources attached to the net? Again, if you talk to the operators of those resources, you will find that most of them do not care about the net except to provide service to their customers. They can provide better direct service then a general purpose net can, and probably cheaper. And the efficiency issue arrises here as well. If volume sensive charging were in effect, users of supercomputer centers may well ask for printouts to be done at the center and mailed to the user in order to avoid large charges for printouts. This results in time delay and increased cost to the research, where the cost in this case is the time it takes to turn around a compuation from one set of inputs to another. Again, connect time is one thing, volume sensitive charging is another. When ISDN becomes fully functional, it may become feasible to build a high speed network that is build around circuit switches instead of packet switches and one will get rid of the idea of dedicated lines. You just dial up what you need, use it for the time you need it, and then hang up. Just like the telephone service today, you do not get charged for how fast you talk (volume of data), but how long you talk (time) plus some type of port charge (basic monthly fee). In dedicated line systems, like the Arpanet, etc., there is no contention for a port in current implementations. Perhaps the gateways or PSNs could refuse virtual circuit connections based upon load so that connect time has some value associated with it, such as some level of service. The issue is not an easy one, but I don't think one should run down the road without exploring the issues. The DoD is already experiencing people moving off the DDN because of the expense required for the service provided. Many are setting up their own networks, because the commong network does not work well for them. What are they using? Well, the Navy is setting up a UUCP type of network based on dial up lines and 9.6 kbit/s service! It isolates them from other, it is inefficient, etc., but it was done because of perceived problems with upcoming usage charges on Milnet and performance issues that such charging would generate. enough for now, dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804251015.AA04421@LANAI.MCL.UNISYS.COM] <1988042510150500> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <8804251015.AA04421@LANAI.MCL.UNISYS.COM> Date: 25 Apr 88 10:15:05 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Vint, one of the reasons that DARPA is haveing problems with paying for the Arpanet, is the charging mechanism which is in place. There are many connections which would like to pay for their port charge, but cannot because DARPA has no way currently to collect the money. So we dismantle the infrastructure because of an accounting problem. Usage charges are based on the flawed idea that one can change behavior based upon how much it costs. All it really does is inforce behavior based upon how much money you have. Can you really say that someones research is more valuable because they have lots of grant money to pay for communication charges? dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042510242900> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Mon 25 Apr 88 14:11:17-PDT To: tcp-ip@SRI-NIC.ARPA Cc: tmallory@PARK-STREET.BBN.COM Subject: Type of service charging(Re: packet level accounting) Date: Mon, 25 Apr 88 17:04:29 -0400 From: tmallory@PARK-STREET.BBN.COM Before we sit back and let the new marketing department build us a tarif, we might want to look again at the type-of-service issues and how they ought to be included into the new scheme. Without belaboring an obvious point, it is clear that there are different types of network usage that could reasonably be charged at different rates if they were mapped onto appropriate types of service. The network would have to actually provide different services in order to charge for them, but it ought to cost more for high-reliability(an internet VC?), or guaranteed low delay, or high-bandwidth schedule to deadline (perhaps charged by bandwidth*connect-time). Given the current IP, provide a low basic rate for traffic with TOS=0 which will leave the existing situation unchanged: fight for your share of whatever is available. Then give better service for more money when someone wants it. There probably ought to be an option for even cheaper refusable service that could be used by most mailers(4th class/bulk rate), and for other time-insensitive file-transfers. 'Nuff said. Cheers, Tracy Mallory BBNCC ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042511083400> Received: from twg.com by SRI-NIC.ARPA with TCP; Mon 25 Apr 88 22:53:20-PDT Received: from TWG.COM by twg.com with SMTP ; Mon, 25 Apr 88 21:53:58 PST Received: from gonzo by Gonzo.TWG.COM id aa05699; 25 Apr 88 22:48 PDT To: Valdis Kletnieks cc: tcp-ip@sri-nic.arpa, kzm@TWG.COM Subject: Re: My two cents about charge schemes on the Arpanet In-reply-to: Your message of Mon, 25 Apr 88 17:36:52 -0400. Date: Mon, 25 Apr 88 22:48:34 -0700 From: kzm@TWG.COM > I know that my users will freak if we suddenly restrict them to 'free > call' sites only. Especially if gateways being up/down make day-to-day > differences. (Huh? Why did I get billed for this telnet session to > BNL? It always uses Nysernet. Sorry Charlie, that day a router was > down at Cornell and it went via MilNet). You raise an interesting issue : the mixing of free networks and charge-back networks. In practice this is bound to occur when the first charge-back scheme gets introduced. Even if all networks became charge-back after some period of time, it's hardly likely that they will all charge the same amount. This points out (in my view) that charging within an internet (consisting of multiple separately-administered networks) cannot be done at the application layer (i.e. charging for individual Telnet/FTP sessions), but rather must be done at the IP layer. Since the IP layer is datagram oriented, charging will have to be done on the basis of packets sent/received (but not necessarily based on packet-counts, e.g. charging could be based on time periods during which packets were sent). There's also the spectre of a central WAN administration charging each of its neighbouring administrations, which might pass on the charges to its users, some of whom might be other adminstrations, and etc. !!! Given that users need to be able to specify whether (and how much ?) they are willing to pay, it would appear that the decision to route a packet across a charge-back network must be made by IP routers, and therefore must be made based on the content of a packet's IP header. If so, IP's Type-of-Service could be the right place for the information to be encoded (e.g. "cost" to be added to the existing Delay/Throughput/Reliability, although one bit is probably not enough information, especially if "collect" were encoded here also). Keith McCloghrie The Wollongong Group. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042512534100> Received: from terminus.UMD.EDU by SRI-NIC.ARPA with TCP; Mon 25 Apr 88 14:34:05-PDT Received: from localhost.umd.edu by terminus.UMD.EDU (5.54/umd.04) id AA04657; Mon, 25 Apr 88 16:53:43 EDT Message-Id: <8804252053.AA04657@terminus.UMD.EDU> To: jbvb@vax.ftp.com (James Van Bokkelen) Cc: tcp-ip@sri-nic.arpa, David R. Conrad Subject: Re: Telnet Commands in 3270 Data Stream In-Reply-To: Your message of Mon, 25 Apr 88 13:42:18 -0400. <8804251742.AA29274@vax.ftp.com> Date: Mon, 25 Apr 88 16:53:41 EDT From: David R. Conrad >You might want to pose this question on the TN3270 mailing list: > tn3270@trantor.umd.edu (I think it is trantor) Nope, other end... :-) tn3270@terminus.umd.edu -drc ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042513365200> Received: from omnigate.clarkson.edu by SRI-NIC.ARPA with TCP; Mon 25 Apr 88 14:53:47-PDT Received: by CLVM (Mailer X1.25) id 2602; Mon, 25 Apr 88 17:50:29 EDT Date: Mon, 25 Apr 88 17:36:52 EDT From: Valdis Kletnieks Subject: My two cents about charge schemes on the Arpanet To: tcp-ip@sri-nic.arpa Uh.. OK. I *enjoy* all this theoredical chit-chat about passing moneygrams and how to place a collect VC call over TCP and all the rest. Now I have an interesting question motivated from self-interest: We here at Clarkson have two links into the Internet - one via Nysernet and one via Milnet (which we'll ignore for right now). Now - my users just say 'telnet some.bogon.host.domain' and boom they're there. Now, that connection might be via Nysernet only - which requires no billing. Or it may be nysernet+nsfnet. Or maybe nysernet+arpanet+suranet. The point is that now not only do the bean counters have to keep track of the usage on the internet core, but the gateways must also do bill-back for the people behind them. I know that my users will freak if we suddenly restrict them to 'free call' sites only. Especially if gateways being up/down make day-to-day differences. (Huh? Why did I get billed for this telnet session to BNL? It always uses Nysernet. Sorry Charlie, that day a router was down at Cornell and it went via MilNet). I know my finance department is going to freak trying to do the bill-back. Sites that ARE on billable nets are going to want to dun us for our packets. (Heck, if I was the gate from Clarkson to MIT, *I* wouldn't swallow the charges for a Clarkson user FTP'ing in X11R2 or GNU Emacs or.....) Of course, this leaves all the gates billinging all the nets. With 400 or so nets reachable, and I don't know HOW many gates, it's gonna become a zoo really fast... (Hmm. We got a bill from 3 gateways at Cornell to 5 users, and another from someplace in Pittsburgh, and this place in Saskechewan wants its $1.25 for the 15 packets from Bozoville and.....) I guess the bottom line is that it won't fly unless the ENTIRE Internet goes with the same scheme, even those regional nets that don't otherwise CARE. Well, that's enough rambling on a heavy-duty mailing list. Hmm. Am I gonna get a bill for this? :-) Valdis Kletnieks Systems Programmer Clarkson University P.S. Standard disclaimers apply. I'm just rambling on my own time. As such, the people I answer to don't even know I mailed this yet.... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804251446.AA06237@ucbvax.Berkeley.EDU] <1988042513452600> From: haverty@CCV.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <8804251446.AA06237@ucbvax.Berkeley.EDU> Date: 25 Apr 88 13:45:26 GMT References: <8804251015.AA04421@LANAI.MCL.UNISYS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 32 It's encouraging to see a discussion like this happening. I think it may be useful and/or important to note the distinction between cost-recovery and "cost"-feedback. All of a network's costs must be recovered somehow, and mechanisms must be in place to collect the data about costs to support collecting the needed funds. Basing that scheme on end-user usage is only one scheme, which is in favor right now - the analogy on the interstates might be if every vehicle's odometer reading was reported to some accounting system that produced bills. Cost feedback is a separable question, though closely related. The goal is to encourage efficiency and reduce waste usually, but also may be to encourage certain kinds of use that the benevolent network owner wants to promote. Feedback may be in the form of inconvenience (slow network performance, long gas lines at the pumps), or money, or availability (a T1 circuit to your campus, an interstate interchange at your town). My suspicion is that a mix of such techniques is needed. As people have noted, a blanket usage-based scheme might tend to stifle new ideas or uses; a free-networking approach drives costs out of sight for the benefactor. Maybe we need a scheme which promotes new ideas, but assures that efficiency gets introduced along the way to large scale usage of any particular idea? This sounds like a topic which needs wide input and thinking. Does it make sense to hold a session of some kind at the upcoming TCP/IP conference in Santa Clara this summer? Dan Lynch's shows seem to be drawing a good mix of academic, industry, government, and user representation. Dennis Perry - maybe in addition to pulling together that paper you mentioned, you could pull together a session to present results and a large dose of open discussion? Jack ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042514570000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Mon 25 Apr 88 19:13:48-PDT Received: from UTMEM1.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 6399; Mon, 25 Apr 88 21:58:53 EDT Date: Mon, 25 Apr 88 20:57 CST From: (ED BIBISI) Subject: Protocol Analyzers To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, EBIBISI Hi there, I am in the process of determining which protocol analyzer to invest in for our LAN. We have XNS on our LAN as well as DECnet, TCP/IP, MS-NET, and one ethernet appletalk encapsulation (PNP from Pacer s'ware connected via Kinetics Bridges). We have three main VAXen: 8650, 8700 and 8800. They all support the above protocols. We have a small army of microvaxen about our campus that support only DECnet. We have had evaluation units of Exelan's Lanalyzer and currently have Micom - Interlan's product based upon Network General's Sniffer s'ware. U-B's NetScope does not seem to be as versatile as I would like for our LAN, as well as DEC's software offerings (EtherNIM, etc.) I have not seen HP's offering or anyone else's. I would appreciate input from those that have gone through this process. Thanks, Ed Bibisi Director, Telecommunication Systems Information Systems and Services University of Tennessee, Memphis EBIBISI@UTMEM1.BITNET (901) 528-5848 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1764@thebes.UUCP] <1988042515024600> From: jeremy@swatsun.uucp (Jeremy Brest) Newsgroups: comp.os.vms,comp.protocols.tcp-ip,comp.mail.misc Subject: VMS mail question Message-ID: <1764@thebes.UUCP> Date: 25 Apr 88 15:02:46 GMT Reply-To: jeremy@swatsun.UUCP (Jeremy Brest) Organization: Swarthmore College, Swarthmore PA Lines: 17 We're going to be internetworking VAXen using PMDF on a TCP/IP network. The question is, can you ask the VAX mailer (or is there another front end for mail?) to use the internet as its default, rather than having to address every mail to a non-VAX system in%"user@system"? Thanks, Jeremy Brest Swarthmore College uucp: ...seismo!bpa!swatsun!jeremy CSnet: jeremy@swatsun.swarthmore.edu Internet: jeremy%swatsun.swarthmore.edu@relay.cs.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7080007@eecs.nwu.edu] <1988042515501600> From: gore@eecs.nwu.edu (Jacob Gore) Newsgroups: comp.protocols.tcp-ip Subject: New BSD TCP/IP & Mt. Xinu Message-ID: <7080007@eecs.nwu.edu> Date: 25 Apr 88 15:50:16 GMT Organization: Northwestern U, Evanston IL, USA Lines: 4 Has anybody incorporated the new 4.3BSD TCP/IP code into Mt. Xinu's 4.3BSD+NFS? Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,gargoyle,ihnp4}!nucsrl!gore ----MESSAGE-END---- ----MESSAGE-BEGIN---- [183@ftp.COM] <1988042516492900> From: sam@ftp.COM (Shelli Meyers) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <183@ftp.COM> Date: 25 Apr 88 16:49:29 GMT References: <8804222219.AA01478@LANAI.MCL.UNISYS.COM> <8804222230.AA09291@bu-cs.bu.edu> Organization: FTP Software, Inc. Lines: 15 In article <8804222230.AA09291@bu-cs.bu.edu>, bzs@BU-CS.BU.EDU (Barry Shein) writes: > > I believe this upcoming election might make this an opportune time to > start, a new administration might be more receptive to new-sounding > programs such as computer networking. There is an interesting article in the April 18th issue of _Computerworld_ regarding the high tech issues playing a part in this year's election, and the specific stands of Bush, Dukakis, Gore, and Jackson on things like federal tax credit for R&D, telecommunications regulations, corporate tax rates, etc. The article is somewhat brief and pretty general, but worth a look. Shelli Meyers FTP Software, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [93400005@uiucdcsp] <1988042516500000> From: zweig@uiucdcsp.cs.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: Thoughts on why packet accounting w Message-ID: <93400005@uiucdcsp> Date: 25 Apr 88 16:50:00 GMT Lines: 22 Nf-ID: #R:<8804191328.AA25552@bu-cs.bu.edu:-33:uiucdcsp:93400005:000:1000 Nf-From: uiucdcsp.cs.uiuc.edu!zweig Apr 25 11:50:00 1988 Here's a paranoid thought: could this whole pay-per-packet thing simply be a ploy to help drive the last nails in the coffin of the arpanet? If charging is going to be unfair and unrealistic (i.e. bad for gateways and archives both of which are very important to the network) then the arpanet dies right on schedule, making way for the DRI and some nice OSI based kludgery that will make all this nonsense with pay-per-packet seem like the Dark Ages. I, for one, smell a rat. Johnny Zweig University of Illinois at Urbana-Champaign Department of Computer Science --------------------------------Disclaimer:------------------------------------ My views are my own, at least as far as I know, and should in no way be construed to represent the official views of this university or the department. Rule 1: Don't believe everything you read. Rule 2: Don't believe anything you read. Rule 3: There is no Rule 3. ------------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804251742.AA29274@vax.ftp.com] <1988042517421800> From: jbvb@VAX.FTP.COM (James Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet Commands in 3270 Data Stream Message-ID: <8804251742.AA29274@vax.ftp.com> Date: 25 Apr 88 17:42:18 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 I can't say what is right, but I can say what we do: In the incoming data stream, our client processes IAC regardless of IAC EOR blocking (this also means we assume that IAC-stuffing applies within EOR blocks). The data stream we send to the server won't contain any telnet command sequences within a 3270 block (after the AID but before the IAC EOR), but it may contain IAC IAC. You might want to pose this question on the TN3270 mailing list: tn3270@trantor.umd.edu (I think it is trantor) James VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804261451.AA00136@ucbvax.Berkeley.EDU] <1988042521042900> From: tmallory@PARK-STREET.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Type of service charging(Re: packet level accounting) Message-ID: <8804261451.AA00136@ucbvax.Berkeley.EDU> Date: 25 Apr 88 21:04:29 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 Before we sit back and let the new marketing department build us a tarif, we might want to look again at the type-of-service issues and how they ought to be included into the new scheme. Without belaboring an obvious point, it is clear that there are different types of network usage that could reasonably be charged at different rates if they were mapped onto appropriate types of service. The network would have to actually provide different services in order to charge for them, but it ought to cost more for high-reliability(an internet VC?), or guaranteed low delay, or high-bandwidth schedule to deadline (perhaps charged by bandwidth*connect-time). Given the current IP, provide a low basic rate for traffic with TOS=0 which will leave the existing situation unchanged: fight for your share of whatever is available. Then give better service for more money when someone wants it. There probably ought to be an option for even cheaper refusable service that could be used by most mailers(4th class/bulk rate), and for other time-insensitive file-transfers. 'Nuff said. Cheers, Tracy Mallory BBNCC ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804260753.AA23692@ucbvax.Berkeley.EDU] <1988042521365200> From: VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks) Newsgroups: comp.protocols.tcp-ip Subject: My two cents about charge schemes on the Arpanet Message-ID: <8804260753.AA23692@ucbvax.Berkeley.EDU> Date: 25 Apr 88 21:36:52 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 44 Uh.. OK. I *enjoy* all this theoredical chit-chat about passing moneygrams and how to place a collect VC call over TCP and all the rest. Now I have an interesting question motivated from self-interest: We here at Clarkson have two links into the Internet - one via Nysernet and one via Milnet (which we'll ignore for right now). Now - my users just say 'telnet some.bogon.host.domain' and boom they're there. Now, that connection might be via Nysernet only - which requires no billing. Or it may be nysernet+nsfnet. Or maybe nysernet+arpanet+suranet. The point is that now not only do the bean counters have to keep track of the usage on the internet core, but the gateways must also do bill-back for the people behind them. I know that my users will freak if we suddenly restrict them to 'free call' sites only. Especially if gateways being up/down make day-to-day differences. (Huh? Why did I get billed for this telnet session to BNL? It always uses Nysernet. Sorry Charlie, that day a router was down at Cornell and it went via MilNet). I know my finance department is going to freak trying to do the bill-back. Sites that ARE on billable nets are going to want to dun us for our packets. (Heck, if I was the gate from Clarkson to MIT, *I* wouldn't swallow the charges for a Clarkson user FTP'ing in X11R2 or GNU Emacs or.....) Of course, this leaves all the gates billinging all the nets. With 400 or so nets reachable, and I don't know HOW many gates, it's gonna become a zoo really fast... (Hmm. We got a bill from 3 gateways at Cornell to 5 users, and another from someplace in Pittsburgh, and this place in Saskechewan wants its $1.25 for the 15 packets from Bozoville and.....) I guess the bottom line is that it won't fly unless the ENTIRE Internet goes with the same scheme, even those regional nets that don't otherwise CARE. Well, that's enough rambling on a heavy-duty mailing list. Hmm. Am I gonna get a bill for this? :-) Valdis Kletnieks Systems Programmer Clarkson University P.S. Standard disclaimers apply. I'm just rambling on my own time. As such, the people I answer to don't even know I mailed this yet.... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2875@emory.uucp] <1988042521574400> From: ospwd@emory.uucp (Peter Day {EUCC}) Newsgroups: comp.protocols.tcp-ip Subject: RIP, gated reply summary Message-ID: <2875@emory.uucp> Date: 25 Apr 88 21:57:44 GMT Organization: Emory University Computing Center Lines: 61 Keywords: RIP EGP gateway routing protocol tcp-ip network (Since the question was originally posted to both the BIG-LAN BITnet list and this newsgroup, the summary is being posted both places as well. I hope anyone who reads both will forgive me for the multiple posting.) Thanks to all who responded to my question: >How can I get more specific information about the Routing Information >Protocol (RIP) used by Proteon, and gated, a demon which translates >between RIP and EGP, the External Gateway Protocol? RFC 827, 888 and 904 describe EGP, the *Exterior* Gateway Protocol. RFC 827 is less formal and is easier to read. RFCs are available from a number of sources, but in particular, may be obtained by sending a note to service@sri-nic.arpa with Subject: RFC nnn where of course nnn is the RFC number. Here is a summary: "From: Charley Kline The best functional description of RIP is a paper called IDEA004, soon to be an RFC, from Chuck Hedrick at Rutgers. Gated an implementation of RIP and HELLO and EGP, and the best documentation of that I know if is the gated man page. In a complex networking environment though, you need to have a deep understanding of what is going on to use gated effectively From: Philip Prindeville [CC] Send mail to "service@sri-nic.arpa" with subject as "get idea:idea004.txt". Or, ftp to sri-nic.arpa and login as anonymous. cd into "idea:". get the file idea004.txt. "From: David Wasley There is a document available from the sri-nic that describes RIP. It is currently called IDEA004 but may become an RFC. Here is the blurb on how to get this: The IDEAS can be found at SRI-NIC.ARPA (10.0.0.51). Login as 'anonymous'. The directory is . Each IDEA is named "IDEAnnn.TXT", where nnn is the IDEA number. The indices are IDEA-INDEX.TXT (the short index, no abstracts) and IDEA-INDEX-ABS.TXT (the long index, with abstracts). "From: "Mark S. Fedor" Peter, I have written a implementation paper on gated which was just accepted for presentation and publication at the summer 1988 USENIX conference. There is also a gated document (man) page. The routed(8) man page describes RIP, but the ultimate RIP document was done by Charles Hedrick of rutgers. The document is available via anonymous FTP from topaz.rutgers.edu or I`m sure hedrick@topaz.rutgers.edu could mail it to you. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042522294500> Received: from omnigate.clarkson.edu by SRI-NIC.ARPA with TCP; Mon 25 Apr 88 23:49:31-PDT Received: by CLVM (Mailer X1.25) id 3741; Tue, 26 Apr 88 02:46:38 EDT Date: Tue, 26 Apr 88 02:29:45 EDT From: Valdis Kletnieks Subject: Another problem with usage charges To: tcp-ip@sri-nic.arpa (Forgive me - it *is* 2:30AM here, so I may be a TAD off base, but...) Ever have this happen to you? % ftp someplace.faraway.arpa ftp>get big.manymeg.file (....) (....) (14 meg of the 15 meg file has been transferred) netinet: net unreachable ftp> (Insert typesetting symbol for 'scream of anguish' here) Who pays for the 14 meg of usage? I sure don't want to - I didn't get the service I asked for. Defining 'got requested service' for each service type is left as an exercise for the student. Don't forget the case of homegrown TCP client programs. Valdis Kletnieks P.S. Usual disclaimers apply. Flame me, not my boss... I'm not a TCP guru, I just use the stuff - a lot. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042601250900> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Tue 26 Apr 88 02:27:10-PDT Received: from UMDD.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 5071; Tue, 26 Apr 88 05:26:35 EDT Received: by UMDD (Mailer X1.23b) id 9633; Tue, 26 Apr 88 05:26:35 EDT Date: Tue, 26 Apr 88 05:25:09 EDT From: Bruce Crabill Subject: Re: TN3270 mailing list address To: TCP-IP@SRI-NIC.ARPA No, the proper address for the TN3270 mailing list is TN3270@TERMINUS.UMD.EDU. If anyone wishes to be added to the list, please contact me. Bruce ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042602501000> Received: from NNSC.NSF.NET by SRI-NIC.ARPA with TCP; Tue 26 Apr 88 06:38:01-PDT To: perry@mcl.unisys.com cc: tcp-ip@sri-nic.ARPA Subject: refund mechanisms in charging Date: Tue, 26 Apr 88 09:30:10 -0400 From: Craig Partridge Dennis, I suspect you can't permit a refund mechanism.... Take the case of the 14 of 15 megabytes transferred. If I know that aborting a connection before all the data requested has been passed then I can happily set up schemes with my friends to pad all FTPable files with an extra few megabytes of junk. Then we transfer our data, abort while the junk is being transferred, and apply for a refund. Voila, free networking.... I think the implication of this is that you'd have to certify programs as not able to abuse the charging scheme this way before you permitted a refund mechanism. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804260850.AA24618@ucbvax.Berkeley.EDU] <1988042602570000> From: EBIBISI@UTMEM1.BITNET (ED BIBISI) Newsgroups: comp.protocols.tcp-ip Subject: Protocol Analyzers Message-ID: <8804260850.AA24618@ucbvax.Berkeley.EDU> Date: 26 Apr 88 02:57:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 29 Hi there, I am in the process of determining which protocol analyzer to invest in for our LAN. We have XNS on our LAN as well as DECnet, TCP/IP, MS-NET, and one ethernet appletalk encapsulation (PNP from Pacer s'ware connected via Kinetics Bridges). We have three main VAXen: 8650, 8700 and 8800. They all support the above protocols. We have a small army of microvaxen about our campus that support only DECnet. We have had evaluation units of Exelan's Lanalyzer and currently have Micom - Interlan's product based upon Network General's Sniffer s'ware. U-B's NetScope does not seem to be as versatile as I would like for our LAN, as well as DEC's software offerings (EtherNIM, etc.) I have not seen HP's offering or anyone else's. I would appreciate input from those that have gone through this process. Thanks, Ed Bibisi Director, Telecommunication Systems Information Systems and Services University of Tennessee, Memphis EBIBISI@UTMEM1.BITNET (901) 528-5848 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23585@hi.unm.edu] <1988042603402300> From: cyrus@hi.unm.edu (Tait Cyrus) Newsgroups: comp.protocols.tcp-ip Subject: udp port numbers Message-ID: <23585@hi.unm.edu> Date: 26 Apr 88 03:40:23 GMT Organization: U. of New Mexico, Albuquerque Lines: 31 Keywords: udp I asked something similar to this last week without ANY responses so here is a rephrase.... What `rules' does "UN*X like" operating systems use when picking udp port numbers? By watching packets fly around on our network it appears that if both the source and destination ports are less than 1024, then they have the meaning specified in RFC 1010 and /etc/services. If one of the ports is > 1024, then this is a generic network connect where the port numbers have no special meaning. This would be fine if it were not for NFS which appears to use 1023 and 2049 as port numbers. NFS total breaks my idea of > 1024 numbers being generic. Also, what does 1022 and 2049 for ports mean? Is this still NFS or just a coincidence? I am trying to `parse' packets and am having a difficult time figuring out RFC's and UN*X source (SUN 3.2 & BSD 4.3). Any comments would be appreciated. -- @__________@ W. Tait Cyrus (505) 277-0806 /| /| University of New Mexico / | / | Dept of Electrical & Computer Engineering @__|_______@ | Parallel Processing Research Group (PPRG) | | | | UNM/LANL Hypercube Project | | hc | | Albuquerque, New Mexico 87131 | @.......|..@ | / | / e-mail: @/_________@/ cyrus@hc.dspo.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804260521.AA11423@sluggo.sun.com] <1988042605211400> From: melohn@SUN.COM (Bill Melohn) Newsgroups: comp.protocols.tcp-ip Subject: Re: 4.3 TCP sockets revisited. Message-ID: <8804260521.AA11423@sluggo.sun.com> Date: 26 Apr 88 05:21:14 GMT References: <8804192115.AA16635@milk10> Sender: usenet@ucbvax.BERKELEY.EDU Organization: Sun Microsystems, Mountain View Lines: 13 The load sharing option of the Sunlink Internetwork Router allows you to connect two Suns with some number of parallel serial lines using the Xerox Point to Point protocol on each line. The load sharing driver tries to distribute the outgoing IP packets over these lines in a method which tries to maximize the utiltization of each line; essentially a round robin when all of the packets are the same (maximum) size. This allows you to get effective throughput close to the sum of the baudrate of all lines used, and to continue to send packets as long as at least one of the lines is operating. Routing is still done on a per-interface basis; all of the load-shared lines use the same IP network interface for transmission of packets. In contrast, if you used an IP interface per line between two nodes, only one of the lines would be used at any time by routing algorithm provided in standard 4BSD software. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042605300400> Received: from cc7.bbn.com by SRI-NIC.ARPA with TCP; Tue 26 Apr 88 06:37:04-PDT Date: Tue, 26 Apr 88 9:30:04 EDT From: "Alan R. Hill" Subject: Re: Whither chargeback policies? In-Reply-To: Your message of Mon, 25 Apr 88 09:45:26 -0400 To: haverty@ccv.bbn.com Cc: tcp-ip@sri-nic.arpa, CERF@a.isi.edu, sean@cadre.dsl.pittsburgh.edu Why is it that I have a fear that worthy discussions of issues such as these will not survive the introduction of the tarrif? Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804260929.AA25210@ucbvax.Berkeley.EDU] <1988042605483400> From: kzm@TWG.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: My two cents about charge schemes on the Arpanet Message-ID: <8804260929.AA25210@ucbvax.Berkeley.EDU> Date: 26 Apr 88 05:48:34 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 36 > I know that my users will freak if we suddenly restrict them to 'free > call' sites only. Especially if gateways being up/down make day-to-day > differences. (Huh? Why did I get billed for this telnet session to > BNL? It always uses Nysernet. Sorry Charlie, that day a router was > down at Cornell and it went via MilNet). You raise an interesting issue : the mixing of free networks and charge-back networks. In practice this is bound to occur when the first charge-back scheme gets introduced. Even if all networks became charge-back after some period of time, it's hardly likely that they will all charge the same amount. This points out (in my view) that charging within an internet (consisting of multiple separately-administered networks) cannot be done at the application layer (i.e. charging for individual Telnet/FTP sessions), but rather must be done at the IP layer. Since the IP layer is datagram oriented, charging will have to be done on the basis of packets sent/received (but not necessarily based on packet-counts, e.g. charging could be based on time periods during which packets were sent). There's also the spectre of a central WAN administration charging each of its neighbouring administrations, which might pass on the charges to its users, some of whom might be other adminstrations, and etc. !!! Given that users need to be able to specify whether (and how much ?) they are willing to pay, it would appear that the decision to route a packet across a charge-back network must be made by IP routers, and therefore must be made based on the content of a packet's IP header. If so, IP's Type-of-Service could be the right place for the information to be encoded (e.g. "cost" to be added to the existing Delay/Throughput/Reliability, although one bit is probably not enough information, especially if "collect" were encoded here also). Keith McCloghrie The Wollongong Group. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804260944.AA25473@ucbvax.Berkeley.EDU] <1988042606294500> From: VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks) Newsgroups: comp.protocols.tcp-ip Subject: Another problem with usage charges Message-ID: <8804260944.AA25473@ucbvax.Berkeley.EDU> Date: 26 Apr 88 06:29:45 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 23 (Forgive me - it *is* 2:30AM here, so I may be a TAD off base, but...) Ever have this happen to you? % ftp someplace.faraway.arpa ftp>get big.manymeg.file (....) (....) (14 meg of the 15 meg file has been transferred) netinet: net unreachable ftp> (Insert typesetting symbol for 'scream of anguish' here) Who pays for the 14 meg of usage? I sure don't want to - I didn't get the service I asked for. Defining 'got requested service' for each service type is left as an exercise for the student. Don't forget the case of homegrown TCP client programs. Valdis Kletnieks P.S. Usual disclaimers apply. Flame me, not my boss... I'm not a TCP guru, I just use the stuff - a lot. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042608462400> Received: from clash.cisco.com by SRI-NIC.ARPA with TCP; Tue 26 Apr 88 15:49:37-PDT Received: from clash.cisco.com by clash.cisco.com with TCP; Tue, 26 Apr 88 15:46:26 PDT To: bzs%bu-cs.bu.edu@bu-it.bu.edu (Barry Shein) Cc: perry@mcl.unisys.com, VALDIS@clvm.clarkson.edu, tcp-ip@sri-nic.arpa Subject: Re: Another problem with usage charges In-Reply-To: Your message of Tue, 26 Apr 88 09:05:34 -0400. <8804261305.AA20900@bu-cs.bu.edu> Date: Tue, 26 Apr 88 15:46:24 PDT From: cire@clash.cisco.com >> Date: Tue, 26 Apr 88 09:05:34 EDT >> From: bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein) >> To: perry@MCL.UNISYS.COM >> Cc: VALDIS@clvm.clarkson.edu, tcp-ip@sri-nic.ARPA, perry@mcl.unisys.com >> Subject: Another problem with usage charges >> >> If nothing else this is becoming an object lesson in why AT&T was >> granted a monopoly, it certainly did simplify a lot of things. Sure, >> that's been broken up, perhaps around 2080 Judge Greene will see that >> the internet can be "deregulated" also. One of the depressing things about the deregulation of AT&T is that in many ways it may have been better to not deregulate. I haven't seen lower prices or better service. But then again I live in the hinter land of the Santa Clara Valley. There are some things that should perhaps be left as a monopoly or set up that way because the overhead of other structures is too costly. >> >> There are other examples, I think people on this list are starting to >> understand what the word "infrastructure" really means. It has a lot >> to do with services who's very value is based upon their universality >> (roads that go to other roads, phones that can call all other phones, >> railroads that can use other tracks, canals that link to other >> waterways, consistent rules and tariffs etc.) >> Is the infrastructure of networks universal to an Information Age? What ever that is. >> -Barry Shein, Boston University >> -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804270804.AA16635@ucbvax.Berkeley.EDU] <1988042609250900> From: BRUCE@UMDD.BITNET (Bruce Crabill) Newsgroups: comp.protocols.tcp-ip Subject: Re: TN3270 mailing list address Message-ID: <8804270804.AA16635@ucbvax.Berkeley.EDU> Date: 26 Apr 88 09:25:09 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 No, the proper address for the TN3270 mailing list is TN3270@TERMINUS.UMD.EDU. If anyone wishes to be added to the list, please contact me. Bruce ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042609395000> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Tue 26 Apr 88 12:41:05-PDT Date: 26 Apr 1988 14:39:50 CDT Subject: Network Operating Systems From: Link@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA cc: LINK@GUNTER-ADAM.ARPA I've reviewed RFCs 1001 and 1002, NETBIOS over TCP/IP, but have been unable to resolve a nagging question: Do I need a Network Operating System to provide PC to PC communications on a 802.3/TCP/IP/NETBIOS LAN? I've spoken to several vendors, such as Novell, Torus, and Bridge/3Com, and received conflicting and contradictory answers. Can anyone out there give me some help/point me in the right direction? I'm also in need of the NETBIOS spec. IBM has been most uncooperative helping me find their technical documentation; " it was last marketed in October 1987, and I can't give to you..." Please reply to me directly and I will summarize for the rest of the TCP/IP mailing list. Thanks. |====================================================================| | Link Verstegen Network Solutions, Inc. (NSI) | | Lead Hardware Engineer 4350 Will Rogers Parkway, Suite 100 | | Oklahoma City, OK 73064 | | Link@Gunter-Adam.ARPA (405)942-8884 | |====================================================================| ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804260952.AA08097@LANAI.MCL.UNISYS.COM] <1988042609524900> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: My two cents about charge schemes on the Arpanet Message-ID: <8804260952.AA08097@LANAI.MCL.UNISYS.COM> Date: 26 Apr 88 09:52:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Valdis, you raise an interesting point about multiple routes and some nets that charge and some that don't. This gets into some interesting issues about routing and routing restrictions. Indeed, one might develop several PhD thesis about 'routing with restrictions' or gateways that spend 50% of there time deciding if they can accept you packet (no money, wrong organization, wrong destination, etc.) A similar issue apparent arose in the Arpanet connections to Europe that went over x.25 links thru the PTTs. The X.25 networks wanted to charge the Arpanet for traffice originating in the Arpanet destined to Europe, across the X.25 links. The Europeans were already paying for their half. DARPA refused to pay, making the argument that it was a 'wash'. If we charged the Europeans to carry their traffic and they charged us to carry their traffic, the excercise was one of exchanging the same amount of money, so why waste the money on the overhead of breaking even? The net result was the Europeans pay for both directions of traffic. dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804260956.AA08119@LANAI.MCL.UNISYS.COM] <1988042609562500> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Another problem with usage charges Message-ID: <8804260956.AA08119@LANAI.MCL.UNISYS.COM> Date: 26 Apr 88 09:56:25 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I suspect there should be some mechanism to ask for a refund. Isn't this fun? dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042613050000> Received: from ddn3.arpa by SRI-NIC.ARPA with TCP; Tue 26 Apr 88 14:51:43-PDT Date: 26 Apr 88 17:05 EDT From: Corrigan @ DDN3.ARPA Subject: Network Charges To: tcp-ip @ sri-nic.arpa 1. Members of the list (at least collectively) probably won't make the decision, but that's DARPA's call. 2. Members can influence the decision, not only for the ARPANET, but for the MILNET as well. I am batching up the collected comments for delivery to the keeper of the "Commercial Communications Industrial Fund". They set the rate structure for both nets in conjunction with the network manager. It is a revolving fund, and as long as expenditures equal receipts over time, there is some freedom in making the "right things" happen. Mike Corrigan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804261305.AA20900@bu-cs.bu.edu] <1988042613053400> From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Another problem with usage charges Message-ID: <8804261305.AA20900@bu-cs.bu.edu> Date: 26 Apr 88 13:05:34 GMT References: <8804260956.AA08119@LANAI.MCL.UNISYS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 If nothing else this is becoming an object lesson in why AT&T was granted a monopoly, it certainly did simplify a lot of things. Sure, that's been broken up, perhaps around 2080 Judge Greene will see that the internet can be "deregulated" also. There are other examples, I think people on this list are starting to understand what the word "infrastructure" really means. It has a lot to do with services who's very value is based upon their universality (roads that go to other roads, phones that can call all other phones, railroads that can use other tracks, canals that link to other waterways, consistent rules and tariffs etc.) -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804270853.AA17812@ucbvax.Berkeley.EDU] <1988042613300400> From: ahill@CC7.BBN.COM ("Alan R. Hill") Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <8804270853.AA17812@ucbvax.Berkeley.EDU> Date: 26 Apr 88 13:30:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Why is it that I have a fear that worthy discussions of issues such as these will not survive the introduction of the tarrif? Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804261909.AA01813@ucbvax.Berkeley.EDU] <1988042613301000> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: refund mechanisms in charging Message-ID: <8804261909.AA01813@ucbvax.Berkeley.EDU> Date: 26 Apr 88 13:30:10 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Dennis, I suspect you can't permit a refund mechanism.... Take the case of the 14 of 15 megabytes transferred. If I know that aborting a connection before all the data requested has been passed then I can happily set up schemes with my friends to pad all FTPable files with an extra few megabytes of junk. Then we transfer our data, abort while the junk is being transferred, and apply for a refund. Voila, free networking.... I think the implication of this is that you'd have to certify programs as not able to abuse the charging scheme this way before you permitted a refund mechanism. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042614380000> Received: from relay.MOD.UK by SRI-NIC.ARPA with TCP; Tue 26 Apr 88 11:37:56-PDT Received: from rsre.mod.uk by relay.MOD.UK via PSS with NIFTP id aa01053; 26 Apr 88 18:29 WET To: Dennis Perry <@nss:perry@mcl.unisys.com> From: John Laws (on UK.MOD.RSRE) Date: Tue, 26 Apr 88 19:38 In-reply-to: <8804260952.AA08097@LANAI.MCL.UNISYS.COM> Cc: tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa> Message-Id: <26 APR 1988 19:38:02 LAWS@RSRE> Subject: Re: My two cents about charge schemes on the Arpanet Dennis, Not so. The issue with X25 connected to Arpanet was that the caller pays for the whole circuit - not half. When Europe called Arpanet that was fine, Europe paid. But if for example e-mail was routing from Arpanet to Europe over X25 and a X25 call had to be opened then Arpanet would be billed. Bob Kahn then proposed that in such situations he would raise a matching equal bill from Arpanet to be paid by Europe. (Remember between Europe and US it is not possible to do reverse charging on X25 for legal reasons rather than technical I understand.) So as of now if X25 is used between Europe and Arpanet it is only used in the west direction. Traffic initiated in Arpanet for Europe takes other paths - and that is another issue. I have found this discussion most interesting because it parallels many of the issues I see in how to route within the future NATO community of interconnected peer level National/Service networks. John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804261630.AA08983@hoquiam] <1988042616301500> From: don@SRI-LEWIS.ARPA (Donald Holman) Newsgroups: comp.protocols.tcp-ip Subject: Network charges. (A snide comment.) Message-ID: <8804261630.AA08983@hoquiam> Date: 26 Apr 88 16:30:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 Fellow net-workers, Because of time I have only read the occasional note regarding network charges, thus if I am restating old ideas I appologize. I have a question with regard to the network charge decision process. Is the decision to be made by members of this list? For if not then I submit that the time being charged on the timeslips for all of this rhetoric may be adequate to pay for the 'net' for the next fiscal year. ON THE OTHER HAND, if the members of this list can influence the decision process, I have a more palatable comment. Is it not true that the real cost of keeping the 'net' up and running can be closely determined. (i.e. I am sure that someone in the bill paying department can tell us that last year network connection fees totaled X dollars, thus this year the budget for these fees has been allocated as Y dollars.) If this is the case, we can use this value Y along with (perhaps a swag) the amount of data to be transfered next year last year. Thus if Y is 100 dollars and 'swag' is 1kbyte the network charge is $1/kbyte across the board. As far as re-routing and use of other peoples network services, this amount is charged locally (i.e. as data leaves the local site and uses PBN or the like) and placed into a central pot to pay for the network as a whole. Just a thought, (Usual disclaimers apply) Don ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804261236.aa23838@Huey.UDEL.EDU] <1988042616361800> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: My two cents about charge schemes on the Arpanet Message-ID: <8804261236.aa23838@Huey.UDEL.EDU> Date: 26 Apr 88 16:36:18 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 29 Dennis, You may have left out the most interesting fact: Reverse-charging was not available for international public packet-switching nets. So far as I know, it still is not available. Consider how the various carriers collect charges in the case of a call placed to a ship at sea. The landside originator pays (1) the landline segment from point of origin to coastal radio station (possibly international), (2) the radio station usage itself and (3) the ship radio station usage. Any or all three charges may be payable to operators in different countries. While payable in different currencies, all charges must be expressable in Swiss Francs; however, the caller may pay his local carrier in the currency of origin, so you can see there may be lots of Swiss francs floating around for each call. Once a year the various countries settle their accounts with each other (in Swiss francs). If everything works right (your "wash" rule), very little currency actually has to change hands. If a balance-of-Swiss- francs is not preserved, some carrier, station or ship may need to invest some capital to correct the imbalance. Here's another one: venerable coastal station WLO (Mobile, AL) operates a high-seas radio bulletin board/mail relay using SITOR (semi-reliable HF radio link protocol) which, presumably, can relay onward via landline to domestic destinations. To the above we add volume charges, selection of domestic carrier and mailbox system charges. I submit this community may not be the first to squarely face the charging issue. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804261642.AA10400@zippy] <1988042616421700> From: kozel@SPAM.ISTC.SRI.COM (Edward R. Kozel) Newsgroups: comp.protocols.tcp-ip Subject: Re: 4.3 TCP sockets revisited. Message-ID: <8804261642.AA10400@zippy> Date: 26 Apr 88 16:42:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 Bill, You implied that routing of packets over load sharing serial lines occurs once within the 4.3 router and again at the Internetwork Router interface handler. Is this true? Also, does your round robin handling dynamically pass packets from one queue to another if, for example, one of the serial links failed? I guess my question really is - do you have one outgoing queue from which packets are dynamically allocated to each interface or is there a N-deep queue for each interface (latter scenario raising my earlier question). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804261815.AA10307@acetes.dec.com] <1988042618151100> From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Charging and aborted transfers Message-ID: <8804261815.AA10307@acetes.dec.com> Date: 26 Apr 88 18:15:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 Someone asked why one should pay "network charges" if 14 of 15 megabytes are transferred and then the FTP connection aborts. If we are still asking this question when usage-based charges are common, we deserve what we get. There is (almost) no reason why this should be a problem, given some thought to protocol design; in other words, the problem is in FTP, not in whatever charging scheme. Consider what happens today when you've just lost an FTP connection after waiting 3 hours for a large file to ooze across the ARPAnet. Do you think "wow, what I really want to do is retransfer all those bytes" or do you think "darn, all I really want is the last 37 bytes"? FTP is a good protocol for efficient transfers over stable networks, but it's not particularly useful if the probability that the transfer will never complete approaches 1. If our bulk-transfer protocol allowed us to ask for a piece of a file, rather than the whole thing, life today would be a lot easier (and life in the pay-per-packet future would be a lot cheaper). A robust FTP user program might then be able to automatically retry failed transfers without duplicating data already transferred. I'm not saying that NFS is perfect, but at least it makes this kind of thing possible. The reason why I used the word "almost" in the 2nd paragraph is that one would have to worry more about locking (in case the file changed) between two partial transfers, and that opens up a hornets nest ... but many current systems don't guarantee consistency anyway. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804271007.AA19029@ucbvax.Berkeley.EDU] <1988042619395000> From: Link@GUNTER-ADAM.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Network Operating Systems Message-ID: <8804271007.AA19029@ucbvax.Berkeley.EDU> Date: 26 Apr 88 19:39:50 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 I've reviewed RFCs 1001 and 1002, NETBIOS over TCP/IP, but have been unable to resolve a nagging question: Do I need a Network Operating System to provide PC to PC communications on a 802.3/TCP/IP/NETBIOS LAN? I've spoken to several vendors, such as Novell, Torus, and Bridge/3Com, and received conflicting and contradictory answers. Can anyone out there give me some help/point me in the right direction? I'm also in need of the NETBIOS spec. IBM has been most uncooperative helping me find their technical documentation; " it was last marketed in October 1987, and I can't give to you..." Please reply to me directly and I will summarize for the rest of the TCP/IP mailing list. Thanks. |====================================================================| | Link Verstegen Network Solutions, Inc. (NSI) | | Lead Hardware Engineer 4350 Will Rogers Parkway, Suite 100 | | Oklahoma City, OK 73064 | | Link@Gunter-Adam.ARPA (405)942-8884 | |====================================================================| ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13544@comp.vuw.ac.nz] <1988042621031800> From: hine@comp.vuw.ac.nz (John Hine) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <13544@comp.vuw.ac.nz> Date: 26 Apr 88 21:03:18 GMT References: <8804222219.AA01478@LANAI.MCL.UNISYS.COM> <8804222230.AA09291@bu-cs.bu.edu> <183@ftp.COM> Reply-To: hine@comp.vuw.ac.nz (John Hine) Organization: Comp Sci, Victoria Univ, Wellington, New Zealand Lines: 25 Summary: And outside the DOD breadbasket... This has been an interesting discussion. Unfortunately it seems to ignore those of us a long way from the centre of activity. COnsider the case for usage charges. I would have to agree that usage charges don't always create an immediate increase in efficiency of use, but they might introduce some fairness. Down here we pay real money for our X.25 link to UUNET, and we pay both ways. Because the Internet has no chargeback mechanism we pay for you to send us mail. This makes an e-mail connection expensive but still worthwhile. The problem arises when someone decides they have something you would like and, without thinking, pops it in the e-mail. Voila, we have a $60 bill for something that might not have been solicited. We've had worse cases than this and it happens with annoying regularity. Some form of chageback would at least get these people to think about their actions -- at least after their first $60 bill. For a lot of things air mail is still a cost effective communication medium! jh -- ----------------------------------------------------------------------- Domain: hine@comp.vuw.ac.nz Dept. of Computer Science UUCP: ...!uunet!vuwcomp!hine Victoria University P.O. Box 600, Wellington, NZ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804270243.AA10163@ucbvax.Berkeley.EDU] <1988042621050000> From: Corrigan@DDN3.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Network Charges Message-ID: <8804270243.AA10163@ucbvax.Berkeley.EDU> Date: 26 Apr 88 21:05:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 1. Members of the list (at least collectively) probably won't make the decision, but that's DARPA's call. 2. Members can influence the decision, not only for the ARPANET, but for the MILNET as well. I am batching up the collected comments for delivery to the keeper of the "Commercial Communications Industrial Fund". They set the rate structure for both nets in conjunction with the network manager. It is a revolving fund, and as long as expenditures equal receipts over time, there is some freedom in making the "right things" happen. Mike Corrigan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804262142.AA13511@LANAI.MCL.UNISYS.COM] <1988042621423200> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: refund mechanisms in charging Message-ID: <8804262142.AA13511@LANAI.MCL.UNISYS.COM> Date: 26 Apr 88 21:42:32 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Craig, you are right about the certification of bad transfers. Messages from some trusted network component might satisfy such a requirement. I know this sounds messy, but even the telephone system sort of relys upon my work to say the a call was disconnected during use and I get a full refund, even if I only call back and say goodbye and pay only the minimum charge. Such are the issues of charging for useage. dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804262145.AA13529@LANAI.MCL.UNISYS.COM] <1988042621451400> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <8804262145.AA13529@LANAI.MCL.UNISYS.COM> Date: 26 Apr 88 21:45:14 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Alan, certainly if I had to pay for each character I sent I would try to find a better way of participating in this discussion, or not participate at all. After all, this conversation is not related to very many of our jobs, but is extreamly important in that the network facilitates the performance of our job. dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804262206.AA13680@LANAI.MCL.UNISYS.COM] <1988042622064400> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Charging and aborted transfers Message-ID: <8804262206.AA13680@LANAI.MCL.UNISYS.COM> Date: 26 Apr 88 22:06:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Jeffrey, I think you have hit on and important question that is not asked very offten, namely, how does policy affect the architecture? Certainly, this was answered when packet switching was chosen over circuit switching. Now that we have a network, new policy questions may force us to reexamine the architecture we use. This of course may have some interesting consequences for the DoD. For example, suppose we go to pay per packet and the architecture is changed to minimize costs. Now we find that we are in conflict with survivability or security or robustness policy issues. What does the DoD do? does it want to recover cost, or develop technology which will survive in a stress environment. Oh well, in this case it may not matter, because if we get involved in a stressed situation, there may not be anyone around to use the net anyway.:-) dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804271432.AA24735@ucbvax.Berkeley.EDU] <1988042622462400> From: cire@CLASH.CISCO.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Another problem with usage charges Message-ID: <8804271432.AA24735@ucbvax.Berkeley.EDU> Date: 26 Apr 88 22:46:24 GMT References: <8804261305.AA20900@bu-cs.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 42 >> Date: Tue, 26 Apr 88 09:05:34 EDT >> From: bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein) >> To: perry@MCL.UNISYS.COM >> Cc: VALDIS@clvm.clarkson.edu, tcp-ip@sri-nic.ARPA, perry@mcl.unisys.com >> Subject: Another problem with usage charges >> >> If nothing else this is becoming an object lesson in why AT&T was >> granted a monopoly, it certainly did simplify a lot of things. Sure, >> that's been broken up, perhaps around 2080 Judge Greene will see that >> the internet can be "deregulated" also. One of the depressing things about the deregulation of AT&T is that in many ways it may have been better to not deregulate. I haven't seen lower prices or better service. But then again I live in the hinter land of the Santa Clara Valley. There are some things that should perhaps be left as a monopoly or set up that way because the overhead of other structures is too costly. >> >> There are other examples, I think people on this list are starting to >> understand what the word "infrastructure" really means. It has a lot >> to do with services who's very value is based upon their universality >> (roads that go to other roads, phones that can call all other phones, >> railroads that can use other tracks, canals that link to other >> waterways, consistent rules and tariffs etc.) >> Is the infrastructure of networks universal to an Information Age? What ever that is. >> -Barry Shein, Boston University >> -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804262306.AA12435@acetes.dec.com] <1988042623050000> From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Re: Charging and aborted transfers Message-ID: <8804262306.AA12435@acetes.dec.com> Date: 26 Apr 88 23:05:00 GMT References: <8804262206.AA13680@LANAI.MCL.UNISYS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 53 Jeffrey, I think you have hit on and important question that is not asked very offten, namely, how does policy affect the architecture? Actually, I was trying to make a slightly different point: that we are already "paying" for lost packets, even if we aren't actually mailing in checks. We should be looking for ways to avoid "wasting" packets even before we have to pay for them in real money, because we can't afford the latency/congestion/low bandwidth anyway. Alas, charging real money might be the only way to get people to listen. Thus, if I'm doing a transaction protocol and the network loses a packet late in the transaction, or I'm running NFS with mobygrams and the fragmentation demons strike (thanks to JQJ for these examples), why should I not have to pay for the packets that the network delivered properly? Perhaps some sense of "justice" implies that the work I've lost is the fault of the network, but nowadays when the network is "free" we still have to deal with those losses, so we might as well think about making our protocols more robust rather than looking for someone else to pay. True, if the phone company gives you a bad connection, you expect them not to charge when you complain. If the "network company" doesn't meet their service guarantees (error rate) then you shouldn't pay them either. That doesn't make it any less necessary to make the best of the situation. I don't pretend to know how to build a transaction protocol that is efficient yet responds well to lost packets. I have, however, trashed NFS in public before for using fragmentation instead of a real protocol; there's no excuse for that and I have no sympathy for people who don't want to pay for the successfully transmitted fragments if the network drops one. For example, suppose we go to pay per packet and the architecture is changed to minimize costs. Now we find that we are in conflict with survivability or security or robustness policy issues. What does the DoD do? does it want to recover cost, or develop technology which will survive in a stress environment. Oh well, in this case it may not matter, because if we get involved in a stressed situation, there may not be anyone around to use the net anyway.:-) Does too matter, since if the network collapses from stress during a crisis, we might launch those missiles by accident (or through panic). I think it's foolish to try to combine both pay-per-packet and serious real-time constraints; if you want guaranteed service you should pay for it in advance, where "pay" may mean "assign a high priority" or "build a VC and reserve the resources". Datagram networks seems best if "spreading the pain" is your goal; I'm not sure I would be a datagram fan if I had to guarantee service through a big hairy internet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804262312.AA01690@braden.isi.edu] <1988042623124900> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Charging and aborted transfers Message-ID: <8804262312.AA01690@braden.isi.edu> Date: 26 Apr 88 23:12:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 If we are still asking this question when usage-based charges are common, we deserve what we get. There is (almost) no reason why this should be a problem, given some thought to protocol design; in other words, the problem is in FTP, not in whatever charging scheme. We GAVE that thought to the FTP design, in 1975! Alex McKenzie came up with the simple and elegant Restart mechanism which is in the FTP protocol. All that is needed is for people to implement it. File access protocols are very useful, but they are not needed, and probably not particularly useful, to replace FTP Restart. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [cWRFicy00Vsf09FUcV@andrew.cmu.edu] <1988042623221600> From: cg13+@ANDREW.CMU.EDU ("Curtis C. Galloway") Newsgroups: comp.protocols.tcp-ip Subject: Broadcast-induced crash stories wanted Message-ID: Date: 26 Apr 88 23:22:16 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 I'm looking for horror stories of network crashes (or dramatic congestion) caused by broadcast packets. In particular, I am interested in problems caused by local broadcast address mismatches. Any and all replies will be greatly appreciated. Thanks -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Curt Galloway ARPA: cg13+@andrew.cmu.edu UUCP: ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!cg13+ Drop In Any Mailbox, Return Postage Guaranteed ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804270104.AA13908@LANAI.MCL.UNISYS.COM] <1988042701040800> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: My two cents about charge schemes on the Arpanet Message-ID: <8804270104.AA13908@LANAI.MCL.UNISYS.COM> Date: 27 Apr 88 01:04:08 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Dave, as you may know by now, John Laws, bless his heart, has set me straight on the way x.25 charges were made or not made as the case may be. I am also constantly amazed at the mass of information you have stored in your permenant memory on type of networks and stories attached thereto. I do not doubt that there are many inovative ways to make money in this world. I like the one about the DJ who announced on the air to send him $20 and he now as $240K and doesn't know what to do with it. He gave no reason for people to send him money, just that they do it. I suspect some of are like that. When someone says send money for the datagram I just sent you, we will, no questions asked. dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042701290000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 27 Apr 88 02:31:06-PDT Date: 27 Apr 1988 05:29-EDT Sender: CERF@A.ISI.EDU Subject: Re: Whither chargeback policies? From: CERF@A.ISI.EDU To: perry@MCL.UNISYS.COM Cc: sean@CADRE.DSL.PITTSBURGH.EDU, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]27-Apr-88 05:29:28.CERF> In-Reply-To: <8804251005.AA04387@LANAI.MCL.UNISYS.COM> Dennis, I don't see much difference between connect time charge and volume if the data rate is fixed (e.g. at 64 kb/s). Some people would argue that connect time is regressive if you are charged the same to send a little as a person who sends a lot. That's one reason the Telenets and Compuserves charge more for 1200 baud than for 300 baud access. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [26.APR.1988.19:38:02.LAWS@RSRE] <1988042702380000> From: LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE) Newsgroups: comp.protocols.tcp-ip Subject: Re: My two cents about charge schemes on the Arpanet Message-ID: <26.APR.1988.19:38:02.LAWS@RSRE> Date: 27 Apr 88 02:38:00 GMT References: <8804260952.AA08097@LANAI.MCL.UNISYS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 22 Dennis, Not so. The issue with X25 connected to Arpanet was that the caller pays for the whole circuit - not half. When Europe called Arpanet that was fine, Europe paid. But if for example e-mail was routing from Arpanet to Europe over X25 and a X25 call had to be opened then Arpanet would be billed. Bob Kahn then proposed that in such situations he would raise a matching equal bill from Arpanet to be paid by Europe. (Remember between Europe and US it is not possible to do reverse charging on X25 for legal reasons rather than technical I understand.) So as of now if X25 is used between Europe and Arpanet it is only used in the west direction. Traffic initiated in Arpanet for Europe takes other paths - and that is another issue. I have found this discussion most interesting because it parallels many of the issues I see in how to route within the future NATO community of interconnected peer level National/Service networks. John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042702540000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 27 Apr 88 03:55:36-PDT Date: 27 Apr 1988 06:54-EDT Sender: CERF@A.ISI.EDU Subject: Re: refund mechanisms in charging From: CERF@A.ISI.EDU To: perry@MCL.UNISYS.COM Cc: craig@NNSC.NSF.NET, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]27-Apr-88 06:54:06.CERF> In-Reply-To: <8804262142.AA13511@LANAI.MCL.UNISYS.COM> At MCI, we had the policy of refunding charges if users called with complaints - both for the telephone charges and for MCI Mail. If, however, a user had a track record of claiming refunds regularly, we looked a lot more closely and sometimes revoked the user's subscription to service. Its generally good business to believe customers but, like the Russian saying quoted by Reagan: Trust but Verify. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042702570000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 27 Apr 88 03:59:53-PDT Date: 27 Apr 1988 06:57-EDT Sender: CERF@A.ISI.EDU Subject: Re: Protocol Analyzers From: CERF@A.ISI.EDU To: EBIBISI%UTMEM1.BITNET@CUNYVM.CUNY.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]27-Apr-88 06:57:14.CERF> In-Reply-To: The message of Mon, 25 Apr 88 20:57 CST from (ED BIBISI) Ed, I suggest you get in touch with Charles Brown at Complete Systems, Inc. He is in Reston, VA (or close to that) in area code (703). I don't have his telephone number handy, but you ought to be able to reach it via information (703) 555-1212. Charles handles a lot of LAN equipment and is familiar with a number of LAN monitoring tools. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042703100000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 27 Apr 88 04:12:19-PDT Date: 27 Apr 1988 07:10-EDT Sender: CERF@A.ISI.EDU Subject: Re: My two cents about charge schemes on the Arpanet From: CERF@A.ISI.EDU To: perry@MCL.UNISYS.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]27-Apr-88 07:10:45.CERF> In-Reply-To: <8804260952.AA08097@LANAI.MCL.UNISYS.COM> Dennis, one of the reasons policy based routing is important is to accommodate charging. Some nets may say "don't send traffic to me if you can't pay for it" - it happens in the X.25 public data net arena all the time. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042703260000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 27 Apr 88 04:28:15-PDT Date: 27 Apr 1988 07:26-EDT Sender: CERF@A.ISI.EDU Subject: Re: My two cents about charge schemes on the Arpanet From: CERF@A.ISI.EDU To: LAWS%rsre.mod.uk@RELAY.MOD.UK Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]27-Apr-88 07:26:26.CERF> In-Reply-To: <26 APR 1988 19:38:02 LAWS@RSRE> Internatinal reverse charging has not been implemented, in general, because it was too hard to collect from the calling party (usually, reverse charges were billed back to the caller along with services rendered at the destination of the call - as in timesharing service). Some experiments in international reverse charing have been conducted. Between the U.S. and Canada, for example, calls are treated as "domestic" for purpose of allowing reverse charging. Clarification: in reverse charging, the network bills the called party, but typically, the called party bills the costs back to the caller, bundled with other service charges. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804270048.aa02631@Huey.UDEL.EDU] <1988042704481900> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: My two cents about charge schemes on the Arpanet Message-ID: <8804270048.aa02631@Huey.UDEL.EDU> Date: 27 Apr 88 04:48:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Dennis, Gotta tell you that I worked my way through undergrad school partly as a DJ/combo man for every radio station within ten miles of Ann Arbor, MI.\ This was during the Payola years and, lemme tell you, a DJ that collected $240 that way would instantly be connected from the base of the antenna to ground with full carrier on. My how times they do change... Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042706314000> Received: from venera.isi.edu by SRI-NIC.ARPA with TCP; Wed 27 Apr 88 13:31:19-PDT Received: from braden.isi.edu by venera.isi.edu (5.54/5.51) id AA06711; Wed, 27 Apr 88 13:31:57 PDT Date: Wed, 27 Apr 88 13:31:40 PDT From: braden@venera.isi.edu Posted-Date: Wed, 27 Apr 88 13:31:40 PDT Message-Id: <8804272031.AA02655@braden.isi.edu> Received: by braden.isi.edu (5.54/5.51) id AA02655; Wed, 27 Apr 88 13:31:40 PDT To: craig@nnsc.nsf.net, perry@mcl.unisys.com Subject: Re: refund mechanisms in charging Cc: tcp-ip@sri-nic.arpa Craig, you are right about the certification of bad transfers. Messages from some trusted network component might satisfy such a requirement. I know this sounds messy, but even the telephone system sort of relys upon my work to say the a call was disconnected during use and I get a full refund, even if I only call back and say goodbye and pay only the minimum charge. Such are the issues of charging for useage. dennis Dennis, The solution is to implement the FTP protocol, including FTP Restart! The user DID transfer most of the bytes... why should we return his money? Why create a hard problem when there is a trivial solution? Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042706481800> Received: from NNSC.NSF.NET by SRI-NIC.ARPA with TCP; Wed 27 Apr 88 10:38:26-PDT To: tcp-ip@sri-nic.ARPA Subject: Why charge for packets Date: Wed, 27 Apr 88 13:28:18 -0400 From: Craig Partridge Perhaps I'm covering ground already mentioned somewhere (if so, set me straight) but I wonder if charging by packet is the right mechanism. Consider charging people entirely by the capacity of their link to the Internet. I.e., if you have a 56Kbit connection you pay a certain sum, if you have a 9.6Kbit connection you pay much less and if you have a T1 connection you pay much more. These cost are set in such a way to cover the infrastructure costs (e.g. the cost of the backbone networks). The logic behind this scheme is that your line speed tells us roughly how much traffic you can introduce into the network (as either a sender or receiver), and if the costing is done right, you have an incentive to pay for only as much bandwidth as you need. Similar schemes are in use in other fields. Pardon the choice of example, but in cities where you pay for garbage collection, an oft used payment scheme is that you (even residential customers) rent approved garbage dumpsters from the city -- and the city only picks up trash in approved dumpsters. The result is that you buy as much dumpster capacity as you need to get rid of your trash (and you have some incentive to minimize your trash production). Of course this scheme can be rigged slightly so that lucky folks in high network density areas are paying more than their fair share of the infrastructure costs so folks in low density areas can get networking too. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]27-Apr-88.05:29:28.CERF] <1988042709290000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <[A.ISI.EDU]27-Apr-88.05:29:28.CERF> Date: 27 Apr 88 09:29:00 GMT References: <8804251005.AA04387@LANAI.MCL.UNISYS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 Dennis, I don't see much difference between connect time charge and volume if the data rate is fixed (e.g. at 64 kb/s). Some people would argue that connect time is regressive if you are charged the same to send a little as a person who sends a lot. That's one reason the Telenets and Compuserves charge more for 1200 baud than for 300 baud access. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042710452000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed 27 Apr 88 13:20:48-PDT Received: from AKRONVM.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 3891; Wed, 27 Apr 88 16:09:06 EDT Received: by AKRONVM (Mailer X1.25) id 1711; Wed, 27 Apr 88 15:52:35 EST Date: Wed, 27 Apr 1988 15:45:20 EST From: Greg Swartwout Subject: Connecting IBM 3090's to internet To: COMM-L@OHSTVMA, TCPIP-L@UIUCVMD, IBM-MAIN@AKRONVM, IBM-NETS@BITNIC, TCP-IP@SRI-NIC.ARPA We have just recently started connecting the different system here to internet and are innterested in finding out how other sites had handled IBM mainframes. We are particularly interested in knowing what hardware and software has been used, and the advantages and disadvantages of each. TCP/IP, Ethernet, and DECNET are the main protocol we are interested in. Please respond directly to me, as I am not on all of these lists. Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]27-Apr-88.06:54:06.CERF] <1988042710540000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: refund mechanisms in charging Message-ID: <[A.ISI.EDU]27-Apr-88.06:54:06.CERF> Date: 27 Apr 88 10:54:00 GMT References: <8804262142.AA13511@LANAI.MCL.UNISYS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 At MCI, we had the policy of refunding charges if users called with complaints - both for the telephone charges and for MCI Mail. If, however, a user had a track record of claiming refunds regularly, we looked a lot more closely and sometimes revoked the user's subscription to service. Its generally good business to believe customers but, like the Russian saying quoted by Reagan: Trust but Verify. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D27-Apr-88.06:57:14.CERF] <1988042710570000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Protocol Analyzers Message-ID: <[A.ISI.EDU]27-Apr-88.06:57:14.CERF> Date: 27 Apr 88 10:57:00 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Ed, I suggest you get in touch with Charles Brown at Complete Systems, Inc. He is in Reston, VA (or close to that) in area code (703). I don't have his telephone number handy, but you ought to be able to reach it via information (703) 555-1212. Charles handles a lot of LAN equipment and is familiar with a number of LAN monitoring tools. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]27-Apr-88.07:10:45.CERF] <1988042711100000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: My two cents about charge schemes on the Arpanet Message-ID: <[A.ISI.EDU]27-Apr-88.07:10:45.CERF> Date: 27 Apr 88 11:10:00 GMT References: <8804260952.AA08097@LANAI.MCL.UNISYS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Dennis, one of the reasons policy based routing is important is to accommodate charging. Some nets may say "don't send traffic to me if you can't pay for it" - it happens in the X.25 public data net arena all the time. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804271116.AA14429@LANAI.MCL.UNISYS.COM] <1988042711164200> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <8804271116.AA14429@LANAI.MCL.UNISYS.COM> Date: 27 Apr 88 11:16:42 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 53 Vint, we had different connect time charges at Los Alamos, depending on the rate, so rate sensitivity is was understood by the users. The difference between volume and connect charges is of course rather small, but I think goes the right way to support an infrastructure. After all, we are not arguing about wheather one should pay, just about how one goes about collecting the money and how much for what services. You pay for the resourse you use in keeping others out of the system. The resourse you use to get to the system, telecommunications, may in fact be dedicated to you, but there were limited number of users who could effectively use the ports available to get to the supercomputers. Now, you could sign on and use the facility at any rate you chose, i.e. usage rate is not the same as bandwidth. Typing characters at 20 word per minute is not the same as transmitting each character at 56 kbit/s. Those who only type text could get by with 2400 to 4800 b/sec service, while those who generated lots of graphics to a textronix would much prefer a 9.6 kbit/s service or higher (we had some that ran substantially higher, I don't remember now how high). In the arpanet one does not normally have the option of connection and disconnecting to the PSN, thus, one has a static connection. What we do have is random receipt and sending of packets accros the interface. Even today, the Arpanet folks have the option of giving you a 9.6 kbit/s line connection to the PSN or a 56 kbit/s line connection. I do not remember for sure, but I believe that the cost to DARPA is the same. This is one of the flawed aspects of current billing for the Arpanet. The only cost to the user is the connection line to the PSN (excpet for early connection which were still being paid for by DARPA, but were being looked at to have the user pay the connect charges.) I am not sure where this conversation is going, but I sense an attitude by some that usage sensivitive charging is the way to go with out looking at alternatives and resultant possible reactions by the community or the purpose of fostering the network in the first place (policy). My bottom line is that the existing system may not be designed to support certain types of charges and one should examine that as well. Do we want to change the protocols, do we have to, how does it affect the policy if we do, etc.? I do not claim to know the answeres, nor do I believe a simple solution is necessarily available outside of the Government to continue to provide 'free' service. Another solution might be for the Government to find a way for connectees to pay their port charge instead of DARPA having to pay it. That way DARPA could continue to subsidize those whom they wished, others would pay. I suspect that solution alone would reduce the DARPA part of the bill to less than a $1M. By the way, I am not convinced that DARPA really wants to reduce its cost that much. The DARPA default connection is to the Milnet, which is going to usage charges. It used to be the Arpanet, but we switched over when the Arpanet became so congested and DARPA folks could not get to ISI to read their mail. I suggested that they switch back, but that has not happened (yet?). dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]27-Apr-88.07:26:26.CERF] <1988042711260000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: My two cents about charge schemes on the Arpanet Message-ID: <[A.ISI.EDU]27-Apr-88.07:26:26.CERF> Date: 27 Apr 88 11:26:00 GMT References: <26.APR.1988.19:38:02.LAWS@RSRE> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Internatinal reverse charging has not been implemented, in general, because it was too hard to collect from the calling party (usually, reverse charges were billed back to the caller along with services rendered at the destination of the call - as in timesharing service). Some experiments in international reverse charing have been conducted. Between the U.S. and Canada, for example, calls are treated as "domestic" for purpose of allowing reverse charging. Clarification: in reverse charging, the network bills the called party, but typically, the called party bills the costs back to the caller, bundled with other service charges. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042714372500> Received: from vx2.GBA.NYU.EDU by SRI-NIC.ARPA with TCP; Wed 27 Apr 88 15:37:02-PDT Received: by vx2.GBA.NYU.EDU (5.51/) id AA04903; Wed, 27 Apr 88 18:37:29 EDT Date: Wed, 27 Apr 1988 18:37:25 EDT From: Ittai Hershman To: Craig Partridge Cc: tcp-ip@sri-nic.arpa Office-Phone: 212-285-6080 Subject: Re: Why charge for packets In-Reply-To: Your message of Wed, 27 Apr 88 13:28:18 -0400 I have been sitting on the sidelines watching the discussion on network costing/charging. I am afraid that some people have missed the forest for the trees. Craig Partridge has put us back on the right track. The Internet is a tool to increase R&D and productivity. Because this increase is a result of sharing among competitors (regardless of whether these are profit-making or non-profit institutions, sharing of information results in a loss of competitive edge). Yet it promotes a common good and the rules-of-the-game are changed by this sharing: standards are formed, technology is advanced, and competition is spurred. This, in my opinion, is precisely why the Internet is an "infrastructure issue" as are interstate highways; like interstate highways, the cost of the network infrastructure -- the PSNs and the trunks which interconnect them -- should be federally funded from general revenues. I suspect that the Internet infrastructure operating and capital costs can be budgeted with a high degree of certainty. Furthermore, the States have gotten involved, and we now have a bunch of regional networks with State funding as well. So the model is one of a federally funded national infrastructure which serves two subordinate layers: federal institutions, and regional subnets. The regional networks, in turn have subordinate institutions. And finally, the institutions are responsible for their own internal networking. All of this, I think, conforms to the spirit of FCCSET. The pragmatic problem, of course, is that it is (unfortunately) unlikely that the Congress and the State Legislatures will value the Internet as we (who are biased consumers of it) do. And so, in this imperfect world, we must find a way to raise some of the money ourselves. And since many of the consumers of this resource are cash poor, we struggle to find an equitable method of cost distribution which does not negate the raison-d'etre. I agree with Craig. Charging by "bandwidth" is both equitable and reasonable. Look at the rousing sucess of BITnet -- it permitted virtually all institutions of higher education an affordable but minimal level of service. A lifeline service. Mail. To get more, you pay more. To further raise revenues, I think the Internet should allow/encourage involvement of commercial companies. Aside from the computer manufacturers and software houses, there are many commercial companies involved in (non-defense) research and would benefit from Internet access. For example, the financial institutions in the Wall Street area hire PHDs (and faculty) galore and have more advanced computer technology than most CS departments. Many would be interested, and certainly could be "sold" on joining. They would be charged higher fees, since their return to the Internet will be less direct. The fees could be used to subsidize the non-profits. (Note that we would not be selling communications media, rather the data, so I think this can be justified legally). Lastly, I suspect that the most expensive (read: inefficient) part of the Internet at present is not the traffic per se. Rather, that the redundency is at the site level rather than at the infrastructure level. NYU, for example, has three Internet connections: MILnet, JVNCnet, and NYSERnet. Wouldn't the resources required for all of this (computers, gateways, leased lines) be better spent on the PSN/trunk level?!? Reorganizing the whole mess will probably save enough money to make some needed capital improvements. On a final note, as a member of the University-wide network planning committee at NYU, I see that we are a microcosm of the Internet. We are a huge institution, spanning unwieldy amounts of real estate, with decentralized control. We have "rich schools" and "poor schools" and the rich subsidize the poor. We have not found a good method of charging for network services, and I suspect we never will. You can't quantify the loss of an infrastructure service -- only what it costs a part to run, and what it costs to replace that part if it fails. The value of the whole is immeasurable. Apologies for the length... -Ittai ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22135@bu-cs.BU.EDU] <1988042717094500> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <22135@bu-cs.BU.EDU> Date: 27 Apr 88 17:09:45 GMT References: <8804262145.AA13529@LANAI.MCL.UNISYS.COM> Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.protocols.tcp-ip Organization: Boston Univ. Information Tech. Dept. Lines: 8 In article <8804262145.AA13529@LANAI.MCL.UNISYS.COM> perry@MCL.UNISYS.COM (Dennis Perry) writes: >Alan, certainly if I had to pay for each character I sent I would >try to find a better way of participating in this discussion, or >not participate at all. If we mst al py per char, ther my b wys to rduc th no o chars xmitd. kwe, BU ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804301621.AA29125@ucbvax.Berkeley.EDU] <1988042717281800> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: Why charge for packets Message-ID: <8804301621.AA29125@ucbvax.Berkeley.EDU> Date: 27 Apr 88 17:28:18 GMT Sender: uucp@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 31 Perhaps I'm covering ground already mentioned somewhere (if so, set me straight) but I wonder if charging by packet is the right mechanism. Consider charging people entirely by the capacity of their link to the Internet. I.e., if you have a 56Kbit connection you pay a certain sum, if you have a 9.6Kbit connection you pay much less and if you have a T1 connection you pay much more. These cost are set in such a way to cover the infrastructure costs (e.g. the cost of the backbone networks). The logic behind this scheme is that your line speed tells us roughly how much traffic you can introduce into the network (as either a sender or receiver), and if the costing is done right, you have an incentive to pay for only as much bandwidth as you need. Similar schemes are in use in other fields. Pardon the choice of example, but in cities where you pay for garbage collection, an oft used payment scheme is that you (even residential customers) rent approved garbage dumpsters from the city -- and the city only picks up trash in approved dumpsters. The result is that you buy as much dumpster capacity as you need to get rid of your trash (and you have some incentive to minimize your trash production). Of course this scheme can be rigged slightly so that lucky folks in high network density areas are paying more than their fair share of the infrastructure costs so folks in low density areas can get networking too. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880427181048.413242@DOCKMASTER.ARPA] <1988042718100000> From: Plummer@DOCKMASTER.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Net usage charges Message-ID: <880427181048.413242@DOCKMASTER.ARPA> Date: 27 Apr 88 18:10:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Suppose I decide to get rich by implementing a new, world wide net and get it patched into many of the existing nets using standard gateways. My net will be a good one but my gateways will advertize infinite bandwidth, zero delay so my net will soak up all of your traffic. Since you probably won't agree to subsidize me, Ihave to be able to send bills and be able to collect. But none of you are actually on my net, I'm just a transport with marketeering gateways. But you probably won't like my bills which will be the max I can get away with. Do you need a Type Of Service that says "avoid high priced nets"? What if I'm the only path available? Can my profiteering be legislated out? Should it be? --Bill Plummer -at DOCKMASTER ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804272028.AA02646@braden.isi.edu] <1988042720283700> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Another problem with usage charges Message-ID: <8804272028.AA02646@braden.isi.edu> Date: 27 Apr 88 20:28:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Valdis, Scream at the implementors who thought FTP Restart was only for sliderule nurds. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804292038.AA02060@ucbvax.Berkeley.EDU] <1988042720452000> From: R1ECGF@AKRONVM.BITNET (Greg Swartwout) Newsgroups: comp.protocols.tcp-ip Subject: Connecting IBM 3090's to internet Message-ID: <8804292038.AA02060@ucbvax.Berkeley.EDU> Date: 27 Apr 88 20:45:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 We have just recently started connecting the different system here to internet and are innterested in finding out how other sites had handled IBM mainframes. We are particularly interested in knowing what hardware and software has been used, and the advantages and disadvantages of each. TCP/IP, Ethernet, and DECNET are the main protocol we are interested in. Please respond directly to me, as I am not on all of these lists. Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3482@psuvax1.psu.edu] <1988042721120600> From: ehrlich@blitz.cs.psu.edu (Dan Ehrlich) Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards,comp.unix.questions Subject: How do I trace IP packets across the InterNet? Message-ID: <3482@psuvax1.psu.edu> Date: 27 Apr 88 21:12:06 GMT Sender: netnews@psuvax1.psu.edu Reply-To: ehrlich@blitz.cs.psu.edu (Dan Ehrlich) Organization: Department of Computer Science, Penn State University Lines: 9 Keywords: IP packet trace Would someone out there tell me how to "trace" the route an packet takes on an IP network? In the IP header there is a "Record Route" option but I can not find any utilities, etc, that use it. Any help or hints would be apprecited. Thanks in advance. Dan Ehrlich The Pennsylvania State University, Department of Computer Science 333 Whitmore Laboratory, University Park, PA 16802 +1 814 863 1142 or +1 814 865 9723 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12393878510.64.AI.CLIVE@MCC.COM] <1988042721280200> From: AI.CLIVE@MCC.COM (Clive Dawson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Why charge for packets Message-ID: <12393878510.64.AI.CLIVE@MCC.COM> Date: 27 Apr 88 21:28:02 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 Another scheme which might come in useful, and which is often used by city utilities, is to pick a period of time where usage is monitored to obtain a figure for "average" usage. Then a charge is based on this figure. There are no meters on our sewage lines which can be used to bill for wastewater. Instead, the city bases its wastewater charges by sampling potable water usage for a month or two. (This usually is done in the winter time to avoid the lawn watering factor, etc.) In this case, the network administrators might wish to compute an "average" packet count for each host by monitoring for some period of time. (Such times should obviously be well-kept secrets so that hosts don't influence the result by changing their behavior.) Network charges could then be assessed based on these results. Just figured I had to get MY two cents in...! Clive Dawson ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805011721.AA29937@ucbvax.Berkeley.EDU] <1988042722372500> From: ittai@VX2.GBA.NYU.EDU (Ittai Hershman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Why charge for packets Message-ID: <8805011721.AA29937@ucbvax.Berkeley.EDU> Date: 27 Apr 88 22:37:25 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 82 I have been sitting on the sidelines watching the discussion on network costing/charging. I am afraid that some people have missed the forest for the trees. Craig Partridge has put us back on the right track. The Internet is a tool to increase R&D and productivity. Because this increase is a result of sharing among competitors (regardless of whether these are profit-making or non-profit institutions, sharing of information results in a loss of competitive edge). Yet it promotes a common good and the rules-of-the-game are changed by this sharing: standards are formed, technology is advanced, and competition is spurred. This, in my opinion, is precisely why the Internet is an "infrastructure issue" as are interstate highways; like interstate highways, the cost of the network infrastructure -- the PSNs and the trunks which interconnect them -- should be federally funded from general revenues. I suspect that the Internet infrastructure operating and capital costs can be budgeted with a high degree of certainty. Furthermore, the States have gotten involved, and we now have a bunch of regional networks with State funding as well. So the model is one of a federally funded national infrastructure which serves two subordinate layers: federal institutions, and regional subnets. The regional networks, in turn have subordinate institutions. And finally, the institutions are responsible for their own internal networking. All of this, I think, conforms to the spirit of FCCSET. The pragmatic problem, of course, is that it is (unfortunately) unlikely that the Congress and the State Legislatures will value the Internet as we (who are biased consumers of it) do. And so, in this imperfect world, we must find a way to raise some of the money ourselves. And since many of the consumers of this resource are cash poor, we struggle to find an equitable method of cost distribution which does not negate the raison-d'etre. I agree with Craig. Charging by "bandwidth" is both equitable and reasonable. Look at the rousing sucess of BITnet -- it permitted virtually all institutions of higher education an affordable but minimal level of service. A lifeline service. Mail. To get more, you pay more. To further raise revenues, I think the Internet should allow/encourage involvement of commercial companies. Aside from the computer manufacturers and software houses, there are many commercial companies involved in (non-defense) research and would benefit from Internet access. For example, the financial institutions in the Wall Street area hire PHDs (and faculty) galore and have more advanced computer technology than most CS departments. Many would be interested, and certainly could be "sold" on joining. They would be charged higher fees, since their return to the Internet will be less direct. The fees could be used to subsidize the non-profits. (Note that we would not be selling communications media, rather the data, so I think this can be justified legally). Lastly, I suspect that the most expensive (read: inefficient) part of the Internet at present is not the traffic per se. Rather, that the redundency is at the site level rather than at the infrastructure level. NYU, for example, has three Internet connections: MILnet, JVNCnet, and NYSERnet. Wouldn't the resources required for all of this (computers, gateways, leased lines) be better spent on the PSN/trunk level?!? Reorganizing the whole mess will probably save enough money to make some needed capital improvements. On a final note, as a member of the University-wide network planning committee at NYU, I see that we are a microcosm of the Internet. We are a huge institution, spanning unwieldy amounts of real estate, with decentralized control. We have "rich schools" and "poor schools" and the rich subsidize the poor. We have not found a good method of charging for network services, and I suspect we never will. You can't quantify the loss of an infrastructure service -- only what it costs a part to run, and what it costs to replace that part if it fails. The value of the whole is immeasurable. Apologies for the length... -Ittai ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804272341.AA06154@corwin.CCS.Northeastern.EDU] <1988042723411600> From: mckee@corwin.ccs.northeastern.EDU (George McKee) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <8804272341.AA06154@corwin.CCS.Northeastern.EDU> Date: 27 Apr 88 23:41:16 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 60 Alternative-Subject: "what price broadcasts?" Dennis Perry writes: >... >The resourse you use to get to the system, telecommunications, may in >fact be dedicated to you, but there were limited number of users >who could effectively use the ports available to get to the supercomputers. >Now, you could sign on and use the facility at any rate you chose, i.e. >usage rate is not the same as bandwidth. Typing characters at 20 word >per minute is not the same as transmitting each character at 56 kbit/s. >Those who only type text could get by with 2400 to 4800 b/sec service, >while those who generated lots of graphics to a textronix would much >prefer a 9.6 kbit/s service or higher (we had some that ran substantially >higher, I don't remember now how high). >... >dennis When I think about network service, this statement is more like the mental model I have than the other one that seems to be implicit in much of this discussion. The fact that mail is perhaps the most visible form of network use leads people think about billing in terms of per-message (i.e. per-packet) charges, just like the post office or the telephone company. An alternative model that I think is just as valid is cable television, where you pay (in advance, even) for a guarantee of a certain amount of bandwidth. Subscribers are offered different levels of service, and it is provided whether your TV is on or not. Few people watch HBO 24 hours a day, but that's what you pay for. I'd guess that there's at least as much internet traffic generated by "broadcast" lists such as this one, as there is traffic generated by individual-to-individual messages, though I have no idea how the relevant data could be collected. In a research-oriented community, the free flow of information is widely acknowledged to be essential for productivity. It seems to me that bandwidth limits would be much less painful to run up against than would usage limits. I wouldn't like to be in the middle of transferring some important file and suddenly get hit by a "sorry: packet quota exceeded" message. Or to be told that I've exceeded my network budget with a whole month left in the fiscal year. Bandwidth limits could avoid this kind of trouble because the costs are fixed in advance. Of course, there would have to be ways of limiting bandwith (and other forms of net access, as well) by software rather than hardware, so that senior researchers could obtain the bandwith to transfer their supercomputer output, while undergraduates or other peons who happen to have signons on the same machine/subnet could be restricted to a harmless trickle, but this should be preferable to flooding the network with accounting packets. If this alternative has already been considered and rejected, I apologize. I'd appreciate knowing the reasons, though, if someone could point to an article where this is discussed. - George McKee Software Coordinator College of Computer Science Northeastern University, Boston 02115 CSnet: mckee@Corwin.CCS.Northeastern.EDU Phone: (617) 437-5204 Usenet: the signal/noise ration here is already too low... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804281347.AA11469@gateway.mitre.org] <1988042813473100> From: gross@GATEWAY.MITRE.ORG (Phill Gross) Newsgroups: comp.protocols.tcp-ip Subject: Re: RIP, gated reply summary Message-ID: <8804281347.AA11469@gateway.mitre.org> Date: 28 Apr 88 13:47:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 22 > The IDEAS can be found at SRI-NIC.ARPA (10.0.0.51). > Login as 'anonymous'. The directory is . Each > IDEA is named "IDEAnnn.TXT", where nnn is the IDEA number. > The indices are IDEA-INDEX.TXT (the short index, no abstracts) > and IDEA-INDEX-ABS.TXT (the long index, with abstracts). As luck would have it, Charles Hedrick has just submitted a final version of the RIP paper, which has not yet been placed at the NIC. He just mailed it to me yesterday and it is still sitting in my mailbox. This also comes at the exact same time that we are changing the IDEA numbering scheme to accomodate revisions (rather than issuing new numbers). So it may be Monday before the new version gets into place with its new not-quite- zip-code-sized number IDEA0004-01. I strongly encourage interested folks to wait for the new version. It is this version that will be submitted as an RFC. I promise to mail a notice to this list as soon as the new RIP document and the new numbering scheme are in place. As they say, timing is everything. Phill Gross ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042814160000> Received: from CORNELLC.CCS.CORNELL.EDU by SRI-NIC.ARPA with TCP; Thu 28 Apr 88 16:24:14-PDT Received: from TECMTYVM.BITNET by CORNELLC.CCS.CORNELL.EDU ; Thu, 28 Apr 88 19:24:43 EDT Date: 28 Apr 88 18:16 EDT From: PL233270%TECMTYVM.BITNET@CORNELLC.CCS.CORNELL.EDU To: TCP-IP @ SRI-NIC.ARPA Subject: BITNET mail follows Date: 28 April 1988, 18:10:26 EDT From: Teresa Lucio Nieto Mexico (83) 58 56 49 PL233270 at TECMTYVM To: TCP-IP at SRI-NIC.ARPA unsubscribe pl233270 at tecmtyvm and pp192157 at tecmtyvm ----MESSAGE-END---- ----MESSAGE-BEGIN---- [11957189476588001@vms3.macc.wisc.edu] <1988042815520000> From: LIVINGSTONE@BERT.DECNet (LIVINGSTONE) Newsgroups: comp.protocols.tcp-ip Subject: Re: Whither chargeback policies? Message-ID: <11957189476588001@vms3.macc.wisc.edu> Date: 28 Apr 88 15:52:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 1 SIGNOFF TCPIP-L UNSUBSCRIBE TCPIP-L ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22165@bu-cs.BU.EDU] <1988042817025300> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Simple Cost Accounting Policy Message-ID: <22165@bu-cs.BU.EDU> Date: 28 Apr 88 17:02:53 GMT Organization: Boston Univ. Information Tech. Dept. Lines: 34 Keywords: chargeback billback policy cost accounting All this talk about problems and issues that would happen if cost recovery just starts up ad-hoc proves that a straightforward attempt to implement cost recovery piecemeal will fail. I would think that one place to start in coming up with something reasonable for a campus/regional/backbone hierarchical model would be to look at the network management data in the Management Information Base (MIB). IpPktsIn, IpPktsOut, TcpPktsIn, etc. I don't think usage charges should get any more complicated than that for LAN/internet traffic. If the jvnc-net people sent me a bill for $xxx per month line charge for my 56kbps link and $yyy per thousand IpPktsIn/IpPktsOut I could check that against what my router tells me went in/out that interface. I could set up the same kind of billing per k of IpPkts for my local Ethernets if I wanted. I really don't think it should get any more complex than that. Even this simple scheme has problems. What if BITnet and jvncnet have vastly different charging schemes? What if jvncnet and the nsfnet backbone have different schemes? What if jvncnet wants to bill me for traffic that goes onto the backbone? How will they measure that? How will I verify or understand charges like that? There have to be simple rules for collecting traffic information and collecting charges at limited specific points in the network. I don't see how it will work unless the campus nets, the regionals, and the backbones all have similar models for collecting money. Services like the backbone should charge the regionals only and the regionals pass on charges to the campus LANs without trying to account for individual packets as they traverse nets. Trying to differentiate intra-regional from inter-regional (sound like intraLATA vs interLATA? :-) would be too complicated to do at first. Point is, it has to be coordinated among the various nets or we have games being played where traffic seeks the least literal cost route and not most effective transport route. Keep it simple. Kent England, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2320@louie.udel.EDU] <1988042817372700> From: rminnich@udel.EDU (Ron Minnich) Newsgroups: comp.protocols.tcp-ip Subject: Re: Another problem with usage charges Message-ID: <2320@louie.udel.EDU> Date: 28 Apr 88 17:37:27 GMT References: <8804260944.AA25473@ucbvax.Berkeley.EDU> Reply-To: rminnich@udel.EDU (Ron Minnich) Organization: University of Delaware Lines: 19 In article <8804260944.AA25473@ucbvax.Berkeley.EDU> VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks) writes: >% ftp someplace.faraway.arpa >ftp>get big.manymeg.file >(14 meg of the 15 meg file has been transferred) >netinet: net unreachable >Who pays for the 14 meg of usage? I sure don't want to - I didn't get the >service I asked for. Hmm, this is the second comment on this sort of thing. Is this an argument AGAINST charging or an argument FOR something better than ftp- something that lets you move pieces of things instead of the whole thing, and that would let you pop off that last megabyte or so. After all, it did move 14/15th of the file for you :-). What if that 15 mb were 15 seperate files, and you did an mget, then recovery would be easy. Maybe it is an argument for a different way of storing ftp-able things? -- ron (rminnich@udel.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [822@xyzzy.UUCP] <1988042819112800> From: karwowska@xyzzy.UUCP (Joanna Karwowska) Newsgroups: comp.protocols.tcp-ip Subject: Public Domain Software for Bootp Message-ID: <822@xyzzy.UUCP> Date: 28 Apr 88 19:11:28 GMT Reply-To: Joanna Karwowska@dg-rtp.dg.com Organization: Data General Corporation, Research Triangle, NC Lines: 10 I would like to get an access to the public domain software for remote bootstrap protocol - bootp (RFC951). Can anybody help? Joanna Karwowska karwowska@dg-rtp.dg.com -- Joanna Karwowska Data General, Research Triangle Park, NC !mcnc!rti-sel!rtp46!karwowska ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805011755.AA00594@ucbvax.Berkeley.EDU] <1988042822160000> From: PL233270@TECMTYVM.BITNET Newsgroups: comp.protocols.tcp-ip Subject: BITNET mail follows Message-ID: <8805011755.AA00594@ucbvax.Berkeley.EDU> Date: 28 Apr 88 22:16:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Date: 28 April 1988, 18:10:26 EDT From: Teresa Lucio Nieto Mexico (83) 58 56 49 PL233270 at TECMTYVM To: TCP-IP at SRI-NIC.ARPA unsubscribe pl233270 at tecmtyvm and pp192157 at tecmtyvm ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9012@eddie.MIT.EDU] <1988042900332200> From: jbs@fenchurch.MIT.EDU (Jeff Siegal) Newsgroups: comp.protocols.tcp-ip Subject: Re: Another problem with usage charges Message-ID: <9012@eddie.MIT.EDU> Date: 29 Apr 88 00:33:22 GMT References: <8804260944.AA25473@ucbvax.Berkeley.EDU> Sender: uucp@eddie.MIT.EDU Reply-To: jbs@fenchurch.MIT.EDU (Jeff Siegal) Organization: MIT EE/CS Computer Facilities, Cambridge, MA Lines: 15 In article <8804260944.AA25473@ucbvax.Berkeley.EDU> VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks) writes: >Ever have this happen to you? >% ftp someplace.faraway.arpa >ftp>get big.manymeg.file >(14 meg of the 15 meg file has been transferred) >netinet: net unreachable > >Who pays for the 14 meg of usage? The serial-line file transfer protocol Zmodem supports "crash recovery." This allows you to restart an aborted transfer, and the protocol negotiates the restart point. Charging for your 14 meg would likely inspire the prompt creation of a similar internet protocol. Jeff Siegal ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804290515.aa02343@note.nsf.gov] <1988042909151100> From: steve@NOTE.NSF.GOV (Stephen Wolff) Newsgroups: comp.protocols.tcp-ip Subject: Re: Simple Cost Accounting Policy Message-ID: <8804290515.aa02343@note.nsf.gov> Date: 29 Apr 88 09:15:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 1 The NSFNET backbone will be directly funded by NSF. -s ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042910473200> Received: from OFFICE-1.ARPA by SRI-NIC.ARPA with TCP; Fri 29 Apr 88 13:50:01-PDT Received: from F29.Tymnet by OFFICE-1.ARPA; 29 Apr 88 13:48:56 PDT Received: from SLVMCL1.McAuto.Tymnet by F29.Tymnet; Fri, 29 Apr 88 13:48:33 PDT From: Keith R. Hacke Date: 04/29/88 15:47:32 To: Subject: TCP/IP Books QUESTION: Does anyone know what the title of Douglas Comer's TCP/IP book? It is something like "Internetworking with TCP/IP". If you know the ISBN, that would do it for me. Keith Hacke McDonnell Douglas - St. Louis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804291239.AA21630@jvnca.csc.org] <1988042912392400> From: heker@JVNCA.CSC.ORG (Sergio Heker) Newsgroups: comp.protocols.tcp-ip Subject: Re: Simple Cost Accounting Policy Message-ID: <8804291239.AA21630@jvnca.csc.org> Date: 29 Apr 88 12:39:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 32 Kent, You have made two valid points here that should be differenciated, one is how to charge (fix cost versus measured traffic cost), second is consistency among all the mid-level networks (i.e. JVNCNet) and the backbone networks (i.e. NSFNET). On the first point you have to cover your costs whether you charge for measured traffic or fix cost. The problem with measured traffic is that: (1) we have to further agree among all the other networks administrations what parameters to use in the charging model, (2) the implementation can become "expensive" to accomplish from the bandwidth and cpu point of view. Thus I suggest the fix cost depending on line bandwidth (as I recall Craig Partridge suggested this before). These costs have to: (1) cover the operational costs of the network, and (2) be consistent among other networks. All this can be worked on, with the exception that this assumes one type of user (i.e. University), what about if the user of the network is a researcher working for a profit making organization?, shall he pay the same as a researcher working for a University?. The networks then have to get into an aggreement that is consistent, and take all these issues in consideration. As a point of information, there is a task force whithin the Federation of American Research Networks (FARnet), working on this issue right now. -- Sergio ----------------------------------------------------------------------------- Sergio Heker tel: (609) 520-2000 Internet: "heker@jvnca.csc.org" Bitnet: "heker@jvnc" JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager ----------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988042914150000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 29 Apr 88 15:53:25-PDT Date: 29 Apr 1988 18:15-EDT Sender: CERF@A.ISI.EDU Subject: Re: Thoughts on why packet accounting w From: CERF@A.ISI.EDU To: zweig@P.CS.UIUC.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]29-Apr-88 18:15:38.CERF> In-Reply-To: <93400005@uiucdcsp> Johnny, Get your nose tested. There isn't a rat. The ARPANET is old technology now (56 kb/s) and costs a lot to operate. The ARPA guys want to spend their R&D money on new networking technology operating at much higher raes. The accounting issue comes up for two reasons: the MILNET operation folks need to allocate costs among the users of MILNET and the general growth of the Internet infrastructure can't be supported solely on government subsidy in today's climate. So we need to find ways for those who can to pay for services rendered. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10268@ulysses.homer.nj.att.com] <1988042914183200> From: smb@ulysses.homer.nj.att.com (Steven Bellovin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Another problem with usage charges Message-ID: <10268@ulysses.homer.nj.att.com> Date: 29 Apr 88 14:18:32 GMT References: <8804260944.AA25473@ucbvax.Berkeley.EDU> <9012@eddie.MIT.EDU> Organization: AT&T Bell Laboratories, Murray Hill Lines: 18 In article <8804260944.AA25473@ucbvax.Berkeley.EDU> VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks) writes: >Ever have this happen to you? >% ftp someplace.faraway.arpa >ftp>get big.manymeg.file >(14 meg of the 15 meg file has been transferred) >netinet: net unreachable > >Who pays for the 14 meg of usage? Well -- if you read the spec, FTP itself implements checkpoint/restart. Better protocols may be desirable, but for now we should make the most of the ones we already have. Has anyone implemented checkpoint/restart in FTP? --Steve Bellovin ulysses!smb smb@ulysses.att.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804291520.AA02554@uunet.UU.NET] <1988042915141300> From: mo@maximo.UUCP (Mike O'Dell) Newsgroups: comp.protocols.tcp-ip Subject: Amazing conversation Message-ID: <8804291520.AA02554@uunet.UU.NET> Date: 29 Apr 88 15:14:13 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 I'm sure glad we're having this "How many FTP transfers can dance on the head of a chargeback packet" conversation now, because when chargebacks happen, it will surely be too expensive to read these amazing conversations. Smile broadly - it keeps 'em guessing. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2886@emory.uucp] <1988042915180900> From: km@emory.uucp (Ken Mandelberg) Newsgroups: comp.protocols.tcp-ip Subject: TCP for Dec RT11 or DG RDOS Message-ID: <2886@emory.uucp> Date: 29 Apr 88 15:18:09 GMT Organization: Math & Computer Science, Emory University, Atlanta Lines: 7 Does anyone know of a TCP implementation for either of these environments? -- Ken Mandelberg | {decvax,sun!sunatl,gatech}!emory!km UUCP Emory University | km@emory BITNET Dept of Math and CS | km@emory.ARPA ARPA,CSNET Atlanta, GA 30322 | Phone: (404) 727-7963 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [218@turbo.RAY.COM] <1988042919381600> From: Robin@turbo.RAY.COM (Robin Alston) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Many things on ethernet together??? Message-ID: <218@turbo.RAY.COM> Date: 29 Apr 88 19:38:16 GMT Organization: Raytheon Company, Marlborough MA Lines: 27 Keywords: TCP-IP. XNS. DECNET. We have a bunch of SGI workstations currently running XNS over ethernet. We have just been informed that when we move into a new building at the end of May we will have to use a single ethernet cable for the whole building which includes many vaxen running VMS many many pc's with some kind of future-net link and many pc's with simple vax links. My question is can this really work? Can XNS and TCP-IP share the same coax cable with no possible problems? Can we have our own domain (we really have no interest at this time in talking to our vaxes), while decnet has its own on the same cable? Am I right to be paranoid about some bureaucrats decision to limit internal cabling this way? We are intending at some future time to upgrade to TCP-IP so we can run NFS but we want to do that in our own sweet time and not in a hurry. Any help or hard facts would be gratefully accepted before I go out and humanely shoot myself. -- ------------------------------------------------- # Whats worse than two MA drivers on a freeway? # Dr. Robin the REAL # Answer: One Toronto driver # SuperUser Atilla! ------------------------------------------------- (617)-460-8225 Robin@turbo.ray.com .....!rayssd!turbo!Robin ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]29-Apr-88.18:15:38.CERF] <1988042922150000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Thoughts on why packet accounting w Message-ID: <[A.ISI.EDU]29-Apr-88.18:15:38.CERF> Date: 29 Apr 88 22:15:00 GMT References: <93400005@uiucdcsp> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Johnny, Get your nose tested. There isn't a rat. The ARPANET is old technology now (56 kb/s) and costs a lot to operate. The ARPA guys want to spend their R&D money on new networking technology operating at much higher raes. The accounting issue comes up for two reasons: the MILNET operation folks need to allocate costs among the users of MILNET and the general growth of the Internet infrastructure can't be supported solely on government subsidy in today's climate. So we need to find ways for those who can to pay for services rendered. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [680@tetra.NOSC.MIL] <1988042922362100> From: budden@tetra.NOSC.MIL (Rex A. Buddenberg) Newsgroups: comp.protocols.tcp-ip Subject: Re: Charging and aborted transfers Message-ID: <680@tetra.NOSC.MIL> Date: 29 Apr 88 22:36:21 GMT References: <8804261815.AA10307@acetes.dec.com> Reply-To: budden@tetra.nosc.mil.UUCP (Rex A. Buddenberg) Organization: Naval Ocean Systems Center, San Diego Lines: 5 It seems you are arguing that the charges should be based on an assessment of usage at the application layer, where earlier posters, talking about per-packet, are at the transport or lower layer. Rex Buddenberg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8805010313.AA12840@ucbvax.Berkeley.EDU] <1988042922473200> From: M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA (Keith R. Hacke) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP Books Message-ID: <8805010313.AA12840@ucbvax.Berkeley.EDU> Date: 29 Apr 88 22:47:32 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 is something like "Internetworking with TCP/IP". If you know the ISBN, that would do it for me. Keith Hacke McDonnell Douglas - St. Louis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [Apr.29.21.32.58.1988.6839@athos.rutgers.edu] <1988043001325900> From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Another problem with usage charges Message-ID: Date: 30 Apr 88 01:32:59 GMT References: <8804260944.AA25473@ucbvax.Berkeley.EDU> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 10 To: VALDIS@CLVM.CLARKSON.EDU In many cases there are things the local site can do to improve the reliability of long-distance FTP's. The problem of getting 95% of a file and then having the connection break is often due to a bug in your TCP that causes it to interrupt the connection when it gets a transient error message. Newer versions of TCP and gateway code can also make a dramatic difference. I'm not sure that I approve of usage-sensitive charging, at least in the research context. But if we're going to do it, paying for broken connections may not be so bad. At the moment, people don't have much incentive to clean up old, decrepit TCP's. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804300148.AA05575@bel.isi.edu] <1988043001482800> From: postel@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP Books Message-ID: <8804300148.AA05575@bel.isi.edu> Date: 30 Apr 88 01:48:28 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 Keith Hacke: ISBN 0-13-470154-2 025 --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [800@jimi.cs.unlv.edu] <1988043004585200> From: greg@muddy.cs.unlv.edu (Greg Wohletz) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Campus Network Query Message-ID: <800@jimi.cs.unlv.edu> Date: 30 Apr 88 04:58:52 GMT Sender: news@jimi.cs.unlv.edu Reply-To: greg@jimi.cs.unlv.edu (Greg Wohletz) Organization: The Cave Lines: 8 I am interested in hearing any comments people might have on campus wide networks; experiences with particular types of networks, and the companies that provide them. I'll post a summary if there is sufficient interest. --Greg greg@jimi.cs.unlv.edu <@relay.cs.net:greg@jimi.cs.unlv.edu> ...!convex!jimi!greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804300559.AA21399@sun.Sun.COM] <1988043005590700> From: limes@SUN.COM (Greg Limes) Newsgroups: comp.protocols.tcp-ip Subject: Re: Many things on ethernet together??? Message-ID: <8804300559.AA21399@sun.Sun.COM> Date: 30 Apr 88 05:59:07 GMT References: <218@turbo.RAY.COM> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: limes@Sun.COM (Greg Limes) Organization: Sun Microsystems, Mountain View Lines: 28 Keywords: TCP-IP. XNS. DECNET. In article <218@turbo.RAY.COM> Robin@turbo.RAY.COM (Robin Alston) writes: >Can XNS and TCP-IP share the same coax cable with no possible problems? No problem. At the bottem layer, all the packets are tagged with source and destination ethernet addresses, so packets only go where they are expected -- except for the broadcast packets ... Also, there is a field in the ethernet packet that determines the protocol type; this should be checked by your network software. Hopefully the drivers will not bitch about unknown packet types, as the XNS packets are a complete mystery to TCP, and TCP is just greek to XNS. It is even possible (gag) to run both TCP/IP and XNS through the same physical interface, but the bottom layer does need to know where to send each packet type. You might consider contacting someone at Communcation Machinery Corporation in Santa Barbara, California; when I was there we did some XNS development that shared the building-wide ethernet with normal TCP used by all the other iron. >Can we have our own domain (we really have no interest at this time in >talking to our vaxes), while decnet has its own on the same cable? You do not need to do anything special to ignore each other; in fact, quite a bit would need to be done to make them talk. One would have to understand the other's protocol. Imagine red and blue light in an optical fiber. The upper level packet layouts just do not jibe. -- Greg Limes [limes@sun.com] frames to /dev/fb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [51442@sun.uucp] <1988043005591400> From: limes@sun.uucp (Greg Limes) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Many things on ethernet together??? Message-ID: <51442@sun.uucp> Date: 30 Apr 88 05:59:14 GMT References: <218@turbo.RAY.COM> Reply-To: limes@sun.UUCP (Greg Limes) Organization: Sun Microsystems, Mountain View Lines: 30 Keywords: TCP-IP. XNS. DECNET. In article <218@turbo.RAY.COM> Robin@turbo.RAY.COM (Robin Alston) writes: >Can XNS and TCP-IP share the same coax cable with no possible problems? No problem. At the bottem layer, all the packets are tagged with source and destination ethernet addresses, so packets only go where they are expected -- except for the broadcast packets ... Also, there is a field in the ethernet packet that determines the protocol type; this should be checked by your network software. Hopefully the drivers will not bitch about unknown packet types, as the XNS packets are a complete mystery to TCP, and TCP is just greek to XNS. It is even possible (gag) to run both TCP/IP and XNS through the same physical interface, but the bottom layer does need to know where to send each packet type. You might consider contacting someone at Communcation Machinery Corporation in Santa Barbara, California; when I was there we did some XNS development that shared the building-wide ethernet with normal TCP used by all the other iron. >Can we have our own domain (we really have no interest at this time in >talking to our vaxes), while decnet has its own on the same cable? You do not need to do anything special to ignore each other; in fact, quite a bit would need to be done to make them talk. One would have to understand the other's protocol. Imagine red and blue light in an optical fiber. The upper level packet layouts just do not jibe. -- Greg Limes [limes@sun.com] frames to /dev/fb -- Greg Limes [limes@sun.com] frames to /dev/fb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12394611685.27.LYNCH@A.ISI.EDU] <1988043016352900> From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP Books Message-ID: <12394611685.27.LYNCH@A.ISI.EDU> Date: 30 Apr 88 16:35:29 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Doug Comer's new book on TCP/IP is entitled "Internetworking with TCP/IP", with a subtitle of "Principles, Protocols, and Architecture". It is published by Prentice Hall. The ISBN is 0-13-470154-2. It is a 375 page book that explains how and why it all works. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7@mace.cc.purdue.edu] <1988043017373300> From: dls@mace.cc.purdue.edu (David L Stevens) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Many things on ethernet together??? Message-ID: <7@mace.cc.purdue.edu> Date: 30 Apr 88 17:37:33 GMT References: <218@turbo.RAY.COM> Reply-To: dls@mace.cc.purdue.edu.UUCP (David L Stevens) Organization: PUCC UNIX Group Lines: 7 Keywords: TCP-IP. XNS. DECNET. We ran two distinct logical TCP/IP networks on one Ethernet cable for a time with no problems. The only thing you'll have to worry about are (Ethernet) broadcast packets, since those will go everywhere. IP should drop them quietly, but I don't know about XNS. -- +-DLS (dls@s.cc.purdue.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12394624949.27.LYNCH@A.ISI.EDU] <1988043017482000> From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: WHY are those mailbridges dropping so many packets???? Message-ID: <12394624949.27.LYNCH@A.ISI.EDU> Date: 30 Apr 88 17:48:20 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 Bob, Your last paragraph suggested a campaign to get everyone running the "new, improved" version of TCP that Jacobson and Karels have developed. Van and Mike are putting on a two day seminar on that very subject in a week and thus far we have more than half of the reelvant vendors signed up to attend. Hopefully those will provide enough oomph to get products in the field soon. (And goad the others to upgrade their products or suffer vanishing sales...) Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8804301921.AA07273@p.cs.uiuc.edu] <1988043019210700> From: zweig@P.CS.UIUC.EDU (Jonathan Zweig) Newsgroups: comp.protocols.tcp-ip Subject: Re: Thoughts on why packet accounting w Message-ID: <8804301921.AA07273@p.cs.uiuc.edu> Date: 30 Apr 88 19:21:07 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 I agree heartily. ARPANET is old technology and should be phased out. I was merely speculating because it struck me as rather *too* con- venient that now that many people want to junk the arpanet, all of a sudden the arpanet is much less fun to use and harder to hook into. Does it matter? ARPANET is doomed anyway. We'll have DRI and OSI and all that sort of FUN (``eff-you-enn'') before long and the Earth shall smell again of roses. -Johnny Zweig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880430-160146-2098@Xerox] <1988043023011700> From: "Thomas_D._Herbst.HENR801c"@XEROX.COM Newsgroups: comp.protocols.tcp-ip Subject: RE:Many things on ethernet together??? Message-ID: <880430-160146-2098@Xerox> Date: 30 Apr 88 23:01:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 At our facility XNS and TCP/IP coexist quite well on the same ethernet and even the same interfaces. The Xerox 1186, Xerox 6085 and two Sun 3/60's in my office and the VMS MicroVax II next door all do both TCP/IP and XNS at the same time. The Vax also does DECNet/LAT and the two Xerox machine also do PUP. The Suns may soon do PUP (somethings just won't die, we still have a working 3 MBit net connecting working Altos...). They exist quite well on a coax that has nearly 1000 devices including limited DECNet, lots of XNS, lots of PUP and growing amount of TCP/IP with NFS, but no diskless workstations. tom tom.henr801c@xerox.com Disclaimer - If my opinion was corporate opinion, I wouldn't have time to write electronic mail. ----MESSAGE-END----